AI Act: systemy wysokiego ryzyka w praktyce (HR, finanse, scoring)

Firma buduje narzędzie do rekrutacji, które rankuje kandydatów na podstawie CV. Albo pipeline kredytowy, który wstępnie ocenia wnioski. Albo system scoringowy dla klientów B2B, który nadaje priorytety leadom. Każde z tych narzędzi robi dokładnie to, na co AI Act patrzy najuważniej: wpływa na sytuację konkretnego człowieka w sposób, który może mu przynieść korzyść albo szkodę.

W 2026 to nie jest teoria. Od sierpnia 2026 regulatorzy mają mandat egzekucyjny, a kary sięgają 3% globalnego obrotu za naruszenia w systemach wysokiego ryzyka. Poniżej opisujemy, które systemy podlegają temu reżimowi, jakie obowiązki z niego wynikają i jak je zaprojektować tak, żeby zgodność nie blokowała wartości biznesowej.

AI Act załącznik III wymienia obszary wysokiego ryzyka wprost. Dla polskich firm liczą się cztery:

Granica między „ograniczonym ryzykiem" a „wysokim ryzykiem" przebiega przez jedno pytanie: czy system ocenia lub klasyfikuje człowieka w sposób, który wpływa na konkretną decyzję o nim? Chatbot, który odpowiada na pytania z bazy wiedzy, jest ograniczonym ryzykiem. Ten sam chatbot, który podczas rozmowy ocenia zdolność kredytową klienta i na tej podstawie zmienia ofertę, wchodzi w wysokie ryzyko.

Kiedy system kwalifikuje się jako wysokiego ryzyka, AI Act nakłada sześć konkretnych obowiązków. Nie są to rekomendacje.

1. Dokumentacja techniczna. Zanim system trafi do użytku, dostawca musi sporządzić dokumentację opisującą: cel i zakres systemu, dane użyte do treningu lub kalibracji, metryki jakości i dokładności, znane ograniczenia i przypadki graniczne, ścieżki logowania. Dokumentacja musi być dostępna dla organów nadzoru na żądanie.

2. Nadzór ludzki. Każda decyzja istotna dla człowieka musi przechodzić przez potwierdzenie przez człowieka albo być technicznie odwracalna. Wzorzec: AI rekomenduje, człowiek zatwierdza lub odrzuca, system loguje obie akcje. Human-gate nie jest opcjonalny.

3. Przejrzystość wobec osoby, której dotyczy decyzja. Osoba, której system dotknął, ma prawo wiedzieć, że decyzja była wspomagana przez AI, i żądać wyjaśnienia logiki. To wymóg, który musi być zaimplementowany technicznie, nie tylko wspomniany w regulaminie.

4. Zarządzanie ryzykiem. Ciągły cykl: identyfikacja ryzyk przed wdrożeniem, monitoring po wdrożeniu, aktualizacja dokumentacji przy zmianie modelu lub danych. Raz na rok minimum; częściej przy istotnych zmianach.

5. Rejestracja systemu. Dostawcy systemów wysokiego ryzyka muszą rejestrować swoje produkty w unijnej bazie danych AI. Dla systemów używanych wewnętrznie (deployer) rejestracja spoczywa na dostawcy systemu, ale deployer musi weryfikować, że system jest zarejestrowany.

6. DPIA przy przetwarzaniu danych osobowych. Jeśli system przetwarza dane osobowe (a prawie zawsze tak jest), równolegle działa RODO. Ocena skutków dla ochrony danych jest wymagana gdy ryzyko jest wysokie. W praktyce: scoring kandydatów, scoring kredytowy i profilowanie klientów zawsze wymagają DPIA.

System rekrutacyjny jest klasycznym przykładem wysokiego ryzyka AI Act. Kluczowy przepływ wygląda tak: model odczytuje CV, wyciąga cechy, klasyfikuje kandydata i rankuje aplikacje. Każdy z tych kroków jest dozwolony. Problem pojawia się, gdy wynik rankingu jest stosowany bez weryfikacji przez rekrutera.

Trzy wymagania techniczne, które muszą być spełnione zanim taki system trafi do produkcji:

• Klasyfikator musi działać na cechach anonimizowanych. Imię (wskazówka płci i etniczności), wiek i adres zamieszkania muszą być usunięte przed przekazaniem do modelu oceniającego. Nie przez politykę, lecz przez PII masking na poziomie kodu.
• Każda rekomendacja musi mieć log wyjaśnienia. Jakie cechy zadecydowały o rankingu tego kandydata? Bez tego logu nie można wykazać braku dyskryminacji ani odpowiedzieć na pytanie kandydata o podstawę decyzji.
• Human-gate przed komunikacją z kandydatem. Żadna automatyczna odpowiedź odrzucająca nie wychodzi bez zatwierdzenia rekrutera. AI proponuje, człowiek zatwierdza.

Więcej o architekturze pipeline'u rekrutacyjnego i danych treningowych omawia artykuł AI w HR i rekrutacji.

Scoring kredytowy i ocena ryzyka ubezpieczeniowego to obszar, gdzie AI Act nakłada obowiązki najsurowiej. Powód jest prosty: decyzja o przyznaniu lub odmowie kredytu może radykalnie zmienić sytuację życiową człowieka.

Specyficzne wymagania dla systemów finansowych:

• Wyjaśnialność każdej decyzji. Klient, któremu odmówiono kredytu z pomocą systemu AI, ma prawo do wyjaśnienia głównych czynników decyzji. SHAP values, LIME lub inny mechanizm wyjaśnialności musi być zaimplementowany produkcyjnie, nie tylko w notebooku analitycznym.
• Testowalność pod kątem dyskryminacji. Model scoringowy musi być regularnie testowany na zbiorach kontrolnych, czy wskaźniki aprobaty nie różnią się systematycznie między grupami chronionymi. Różnica, której nie możesz wyjaśnić zmiennymi finansowymi, to problem regulacyjny.
• Nadzór ludzki na decyzjach granicznych. Wnioski, których score mieści się w przedziale niepewności, powinny trafiać do weryfikacji przez analityka, nie być automatycznie odrzucane przez algorytm.
• Izolacja danych i data residency. Dane finansowe klientów nie powinny opuszczać infrastruktury kontrolowanej przez instytucję bez szyfrowania i umów powierzenia danych. Self-hosting warstwy inference dla danych najbardziej wrażliwych jest standardem, nie luksusem.

W Polsce Komisja Nadzoru Finansowego (KNF) wydała w 2025 roku wytyczne dotyczące AI w usługach finansowych, które uzupełniają AI Act o sektorowe wymagania. Każdy system scoringowy dla instytucji regulowanej przez KNF musi być audytowany pod kątem obu zestawów wymogów.

Nie każdy lead scoring jest wysokim ryzykiem. Klasyfikacja leadów B2B według dopasowania do ICP (branża, wielkość firmy, aktywność na stronie) to ograniczone ryzyko, o ile wynik nie decyduje o dostępie do usługi.

Problem pojawia się, gdy scoring zaczyna wpływać na ceny, dostępność oferty lub sposób traktowania klienta. Wtedy, w zależności od obszaru, system może wejść w reżim wysokiego ryzyka lub co najmniej wymagać DPIA.

Praktyczna reguła do stosowania przy projektowaniu systemu:

Lead scoring oparty na aktywności anonimowej (strony, UTM, typ firmy) jest bezpieczny. Scoring łączący dane finansowe, dane z mediów społecznościowych i historię zachowań konkretnej osoby wchodzi w obszar regulowany.

Zgodność z AI Act dla systemów wysokiego ryzyka nie jest warstwą dodawaną na koniec projektu. Sześć elementów, które projektujemy od pierwszego commita:

Log każdego kroku. Każde wywołanie modelu, każde wygenerowanie rekomendacji, każde zatwierdzenie lub odrzucenie przez człowieka trafia do logu z timestampem, identyfikatorem sesji i identyfikatorem osoby, której dotyczy. Log jest niezmienny i przechowywany minimum 5 lat dla systemów finansowych, minimum przez okres rozpatrywania skarg dla rekrutacji.

Human-gate jako blokada techniczna. Human-gate to nie komunikat „pamiętaj, żeby sprawdzić". To techniczne uniemożliwienie wysłania wyniku do użytkownika końcowego bez potwierdzenia przez uprawnioną osobę. Implementujemy go jako warunek w pipeline, nie jako prośbę w dokumentacji.

Guardrails z rejection logiem. Każde zapytanie, które system odrzucił ze względu na guardrails (wykroczenie poza zakres, próba wymuszenia decyzji poza kompetencjami systemu), jest logowane. Rejection log jest dowodem, że system działa zgodnie z projektem.

Moduł wyjaśnień. Każda decyzja, która dotknęła człowieka, musi być technicznie odtwarzalna: co model widział, jakie cechy były istotne, jaki był wynik. Structured output z obowiązkowym polem reasoning ułatwia budowę tego modułu.

Testy na dyskryminację przed produkcją. Przed wdrożeniem uruchamiamy klasyfikator na zbiorze testowym z kontrolowaną dystrybucją cech chronionych i mierzymy różnicę wskaźników pozytywnych. Wyniki trafiają do dokumentacji technicznej.

Zarządzanie zmianami modelu. Zmiana modelu bazowego, danych lub progu decyzyjnego to zmiana wymagająca ponownego przejścia przez cykl walidacji i aktualizacji dokumentacji. Nie robimy cichych swapów modeli w produkcji.

Więcej o monitoringu jakości systemu AI po wdrożeniu omawia dedykowany artykuł.

Ocena skutków dla ochrony danych (DPIA) jest wymagana przez RODO gdy przetwarzanie może powodować wysokie ryzyko. W praktyce każdy system wysokiego ryzyka AI Act, który przetwarza dane osobowe, wymaga DPIA. Czyli prawie zawsze.

Minimalna zawartość DPIA dla systemu AI:

• Opis celu przetwarzania i danych wejściowych
• Ocena niezbędności: czy można osiągnąć cel przy mniejszym zakresie danych?
• Identyfikacja ryzyk: nieuprawniony dostęp, dyskryminacja algorytmiczna, błędna decyzja
• Środki zaradcze: szyfrowanie, masking PII, izolacja danych, human-gate, logowanie
• Przegląd po 12 miesiącach lub przy istotnej zmianie systemu

DPIA to dokument roboczy, nie formalność. Pisany rzetelnie, staje się najlepszą dokumentacją techniczną projektu i skraca czas odpowiedzi na zapytania organów nadzoru z tygodni do godzin. Metodykę DPIA opisuje bardziej szczegółowo artykuł AI Act i RODO 2026.

Opisz swój system (HR, scoring, finanse) i zakres przetwarzanych danych, a model wstępnie oceni, które obowiązki AI Act mogą mieć zastosowanie — jako punkt wyjścia do rozmowy z prawnikiem, nie zamiast niej (playground: PII maskowane, zero retencji):

Nie zawsze. Scoring oparty na danych firmowych (branża, wielkość, aktywność) bez wpływu na dostęp do usługi to zwykle ograniczone ryzyko. Wysokie ryzyko pojawia się, gdy scoring dotyczy osób fizycznych w obszarach wymienionych w AI Act — zatrudnienie, finanse, ubezpieczenia, usługi publiczne. Jeśli scoring dotyczy decyzji o przedsiębiorcy jako osobie fizycznej (np. jednoosobowa działalność, scoring dla mikropożyczki), obowiązki AI Act mogą mieć zastosowanie. Zawsze warto to zweryfikować z prawnikiem przed wdrożeniem produkcyjnym.

Przez log i test. Log musi zawierać dla każdej rekomendacji: jakie cechy były istotne i z jaką wagą. Test przed wdrożeniem: uruchom klasyfikator na zbiorze z kontrolowaną dystrybucją cech chronionych (płeć, wiek, etniczność wskazana przez imię) i zmierz, czy wskaźniki rekomendacji pozytywnych są porównywalne między grupami. Różnica powyżej kilku punktów procentowych wymaga korekty modelu lub danych. Wyniki testu trafiają do dokumentacji technicznej jako dowód, nie jako deklaracja.

AI Act rozróżnia dostawcę i deployer, ale nie zwalnia małych podmiotów z wymogów dla systemów wysokiego ryzyka. Mikroprzedsiębiorstwa i małe firmy korzystają z uproszczonego formatu dokumentacji technicznej, ale obowiązki merytoryczne pozostają: nadzór ludzki, logowanie, przejrzystość, DPIA gdy dotyczy. Skala systemu i zasobów wpływa na sposób implementacji, nie na to, czy wymagania obowiązują.

Gdy zmiana wpływa na logikę decyzyjną lub dane wejściowe. Swap modelu bazowego (nowa wersja LLM, inny embedding), zmiana danych treningowych, zmiana progu decyzyjnego powyżej ustalonego marginesu, dodanie nowych cech wejściowych — każda z tych zmian wymaga ponownego testu na dyskryminację, aktualizacji dokumentacji i wpisu w rejestrze zmian. Zmiana promptu systemowego bez zmiany logiki decyzyjnej zwykle nie wymaga pełnego restartu walidacji, ale wymaga wpisu w logu zmian i smoke testu.

Nie. Guardrails blokują nieautoryzowane zapytania i ograniczają zakres odpowiedzi systemu — to konieczna warstwa bezpieczeństwa. Ale AI Act wymaga, żeby człowiek miał realną możliwość weryfikacji i odrzucenia każdej decyzji istotnej dla osoby, której dotyczy. Guardrails nie są decyzją człowieka — są filtrem przed decyzją. Obie warstwy muszą być obecne i obie są logowane osobno.