AI Act: testowanie systemów wysokiego ryzyka, test stronniczości i terminy 2027

AI Act testowanie systemów wysokiego ryzyka oznacza udokumentowane sprawdzenie, że system AI, który wpływa na decyzje o ludziach, działa zgodnie z przeznaczeniem, z deklarowaną dokładnością i bez nieuzasadnionej stronniczości wobec grup osób. AI Act nie pyta, czy jesteście bankiem. Pyta, czy budujecie albo stosujecie system AI, który decyduje o pracy, kredycie albo edukacji człowieka. Poniżej znajdziecie aktualne terminy po Digital Omnibus, podział obowiązków między dostawcę a podmiot stosujący i kompletny przykład testu stronniczości z metryką, progiem i kodem.

Wszystkie przepisy cytujemy z polskiej wersji rozporządzenia (UE) 2024/1689 w serwisie EUR-Lex, z numerem artykułu i ustępu, oraz ze zmieniającego je rozporządzenia (UE) 2026/1744. Artykuł opisuje wymogi z perspektywy jakości oprogramowania i nie jest poradą prawną.

Od kiedy obowiązują wymogi dla systemów wysokiego ryzyka po Digital Omnibus?

Wymogi dla samodzielnych systemów wysokiego ryzyka z załącznika III stosuje się od 2 grudnia 2027 roku, a dla systemów wbudowanych w produkty regulowane z załącznika I od 2 sierpnia 2028 roku. Według art. 113 akapit trzeci lit. c rozporządzenia 2024/1689, w brzmieniu nadanym przez rozporządzenie 2026/1744, termin dla systemów z załącznika III przesunięto z pierwotnego 2 sierpnia 2026 na 2 grudnia 2027. Rozporządzenie zmieniające, nazywane Digital Omnibus, przyjęto 8 lipca 2026, opublikowano w Dzienniku Urzędowym UE 24 lipca 2026 i weszło w życie trzeciego dnia po publikacji, czyli 27 lipca 2026.

Przesunięcie nie dotyczy całego aktu. Zakazane praktyki z art. 5 obowiązują od 2 lutego 2025, a obowiązki przejrzystości z art. 50 nie zostały odroczone. Systemy generujące treści syntetyczne, wprowadzone do obrotu przed 2 sierpnia 2026, mają czas do 2 grudnia 2026 na oznaczanie treści zgodnie z art. 50 ust. 2, co przewiduje nowy art. 111 ust. 4. Krajowe piaskownice regulacyjne mają ruszyć do 2 sierpnia 2027 według zmienionego art. 57 ust. 1.

Jedna rzecz łatwo umyka przy czytaniu nagłówków o „odroczeniu”. Według art. 111 ust. 2 systemy wysokiego ryzyka wprowadzone do obrotu przed datą stosowania podlegają wymogom dopiero wtedy, gdy po tej dacie przejdą istotną zmianę projektu. Dla zespołów, które rozwijają model co sprint, to oznacza, że każda większa wersja po 2 grudnia 2027 może uruchomić pełne obowiązki, więc proces testowy musi być gotowy przed tą datą, a nie po niej.

Kto wpada w kategorię wysokiego ryzyka?

Najszerszy zakres obowiązków dotyczy systemów z załącznika III. W praktyce zespołów QA najczęściej spotykamy trzy punkty: załącznik III pkt 4 lit. a, czyli systemy do rekrutacji, filtrowania podań i oceny kandydatów, pkt 5 lit. b, czyli ocenę zdolności kredytowej i scoring osób fizycznych, oraz pkt 5 lit. c, czyli ocenę ryzyka i ustalanie cen w ubezpieczeniach na życie i zdrowotnych. Punkt 5 lit. b wprost wyłącza systemy wykrywania oszustw finansowych; o tym, jak mimo to testować takie modele, piszemy w artykule AI w bankowości: jak testować systemy wykrywania oszustw.

Klasyfikacja odbywa się po skutku decyzji, nie po technice. Prosty system punktowy do oceny kandydatów może trafić do tej samej kategorii co sieć neuronowa. Od zasady jest wyjątek: według art. 6 ust. 3 system z załącznika III nie jest systemem wysokiego ryzyka, jeśli nie stwarza znaczącego ryzyka, na przykład wykonuje wąskie zadanie proceduralne albo tylko poprawia wynik pracy człowieka, ale system, który profiluje osoby fizyczne, jest zawsze systemem wysokiego ryzyka. Dostawca, który korzysta z wyjątku, musi według art. 6 ust. 4 udokumentować swoją ocenę przed wprowadzeniem systemu do obrotu.

Dostawca czy podmiot stosujący: kto odpowiada za testy?

AI Act rozróżnia role, a słowo „operator” bywa tu mylące. Według art. 3 pkt 8 operator to pojęcie zbiorcze, obejmujące dostawcę, producenta produktu, podmiot stosujący, upoważnionego przedstawiciela, importera i dystrybutora. Firma, która buduje system i wprowadza go do obrotu pod własną nazwą, jest dostawcą (art. 3 pkt 3). Firma, która używa cudzego systemu w swojej działalności, jest podmiotem stosującym (art. 3 pkt 4). Obowiązki testowe ciążą głównie na dostawcy, ale podmiot stosujący też ma swoje.

Źródło: rozporządzenie (UE) 2024/1689, art. 3, 9, 10, 11, 14, 15, 26, 27 i 72.

Granica ról jest ruchoma. Według art. 25 ust. 1 podmiot stosujący staje się dostawcą, gdy umieści swoją nazwę na systemie wysokiego ryzyka, dokona w nim istotnej zmiany albo zmieni przeznaczenie systemu tak, że staje się on systemem wysokiego ryzyka. Firma, która kupiła gotowe narzędzie rekrutacyjne i dotrenowała je na własnych danych, powinna sprawdzić, czy nie przejęła właśnie wszystkich obowiązków z lewej kolumny tabeli. Pracodawca stosujący taki system musi też, według art. 26 ust. 7, poinformować pracowników i ich przedstawicieli przed jego użyciem w miejscu pracy.

Testowanie systemów wysokiego ryzyka: co AI Act mówi wprost?

Więcej, niż zwykle się zakłada, i bardziej konkretnie. Art. 9 ust. 8 wymaga, by testy przeprowadzać w odniesieniu do uprzednio określonych wskaźników i progów probabilistycznych, stosownych ze względu na przeznaczenie systemu, w każdym przypadku przed wprowadzeniem go do obrotu. To zdanie ma ogromne znaczenie dla QA: metrykę i próg trzeba zapisać, zanim zobaczycie wynik, a nie dobrać je tak, żeby test przeszedł.

Digital Omnibus dodał jeszcze jedną zmianę ważną dla testerów. Dotychczasowy art. 10 ust. 5, który pozwalał wyjątkowo przetwarzać szczególne kategorie danych osobowych, na przykład pochodzenie etniczne, w celu wykrywania stronniczości, uchylono i zastąpiono nowym art. 4a. Warunki pozostały rygorystyczne: przetwarzanie jest dopuszczalne tylko wtedy, gdy stronniczości nie da się skutecznie wykryć na innych danych, w tym syntetycznych lub zanonimizowanych. Dla zespołu QA wynika z tego prosta kolejność: najpierw próbujecie na danych syntetycznych, a dopiero potem, z udokumentowanym uzasadnieniem, na danych wrażliwych.

Testowanie systemów AI różni się od klasycznego QA przede wszystkim tym, że wynik jest probabilistyczny. Szerzej opisujemy to w tekście o testowaniu systemów AI i ewaluacji modeli, a tutaj przechodzimy do testu, którego AI Act wymaga, a którego prawie nikt nie ma dziś w planie testów.

Jak wygląda test stronniczości na zbiorze kandydatów?

Najprostsza metryka stronniczości dla systemu, który odrzuca albo przepuszcza kandydatów, to wskaźnik wpływu nieproporcjonalnego (ang. disparate impact). Liczycie odsetek osób z pozytywną decyzją w każdej grupie, a potem dzielicie najniższy odsetek przez najwyższy. Według amerykańskich Uniform Guidelines on Employee Selection Procedures, 29 CFR 1607.4 lit. D, wskaźnik wyboru dla grupy niższy niż cztery piąte, czyli 80 procent, wskaźnika grupy z najwyższym wynikiem jest zwykle traktowany jako dowód niekorzystnego wpływu. AI Act nie podaje żadnej liczby, więc reguła 4/5 to sprawdzony punkt wyjścia do ustalenia progu, który art. 9 ust. 8 każe zapisać z góry.

Przykład. Model rekrutacyjny ocenia zbiór testowy 1000 kandydatów: 400 kobiet i 600 mężczyzn o porównywalnych kwalifikacjach. Na rozmowę zaprasza 84 kobiety i 180 mężczyzn.

Ten sam test w Pythonie, gotowy do wpięcia w potok CI jako bramka jakości. Kod uruchomiliśmy z pandas; wynik 0,70 potwierdziła funkcja demographic_parity_ratio z biblioteki Fairlearn 0.14.0:

import pandas as pd

# Zbiór testowy: 1000 kandydatów, decyzja modelu (1 = zaproszenie na rozmowę)
kandydaci = pd.DataFrame({
    "plec": ["K"] * 400 + ["M"] * 600,
    "decyzja": [1] * 84 + [0] * 316 + [1] * 180 + [0] * 420,
})

wskazniki = kandydaci.groupby("plec")["decyzja"].mean()
print(wskazniki)                         # K 0.21, M 0.30

ratio = wskazniki.min() / wskazniki.max()
print(f"Disparate impact: {ratio:.2f}")  # 0.70

PROG = 0.8  # reguła czterech piątych, zapisana w planie testów
assert ratio >= PROG, f"Test stronniczości oblany: {ratio:.2f} < {PROG}"

Test kończy się błędem asercji: 0,70 to mniej niż 0,80. Różnica nie jest przypadkiem małej próby, bo dwustronny test różnicy dwóch proporcji daje tu z równe 3,16 i p około 0,0016. Przy małych grupach, na przykład 20 osobach, sam wskaźnik potrafi spaść poniżej progu przez losowość, dlatego w planie testów zapiszcie oba warunki: próg metryki i minimalną liczebność grupy albo test istotności.

Disparate impact to tylko pierwsza metryka. Gdy macie dane o rzeczywistej przydatności kandydatów, sprawdźcie też równość szans (equal opportunity), czyli czy odsetek trafnie zaproszonych wśród osób faktycznie spełniających wymagania jest podobny w każdej grupie. Te dwie metryki potrafią dać sprzeczne wyniki i wybór między nimi jest decyzją biznesową i prawną, którą warto zapisać w dokumentacji, a nie zostawić domyślnym ustawieniom biblioteki.

AI Act a DORA: dlaczego to dwa osobne testy zgodności?

DORA dotyczy odporności operacyjnej podmiotów finansowych wymienionych w rozporządzeniu: banków, ubezpieczycieli, firm inwestycyjnych. AI Act nie patrzy na branżę, tylko na system i jego skutki. Software house budujący system rekrutacyjny dla urzędu podlega AI Act tak samo jak bank budujący model scoringowy, choć żadne z nich nie jest w tej roli podmiotem DORA. Firma, która sprawdziła, że nie podlega DORA, i na tej podstawie uznała temat regulacji AI za zamknięty, robi dwa testy zgodności w jednym, a to za mało. Szczegóły obowiązków testowych z DORA opisujemy w tekście o rozporządzeniu DORA i testach niezależnych.

Ile kosztuje brak zgodności z AI Act?

AI Act ma trzy progi kar i żaden nie jest symboliczny. Według art. 99 ust. 4 nieprzestrzeganie obowiązków dostawców z art. 16 albo podmiotów stosujących z art. 26 podlega karze do 15 mln euro albo do 3 procent rocznego światowego obrotu, w zależności od tego, która kwota jest wyższa.

Źródło: rozporządzenie (UE) 2024/1689, art. 99.

Błędna klasyfikacja działa w obie strony. Firma, która uzna swój system za system wysokiego ryzyka, choć nim nie jest, płaci za dokumentację i testy, których nikt od niej nie wymaga. Firma, która uzna, że system nie jest wysokiego ryzyka, choć jest, dowiaduje się o tym przy kontroli, a nie przy planowaniu budżetu. Rzetelna klasyfikacja na wejściu jest tańsza od obu błędów.

Co z tego realnie wynika dla zespołów QA?

Od czego zacząć przed grudniem 2027?

Zanim odłożycie temat do 2027 roku, odpowiedzcie na trzy pytania. Czy ktoś w Waszej firmie formalnie sklasyfikował Wasze systemy AI według art. 6 i załącznika III, czy to wciąż założenie? Czy Wasz plan testów zawiera metrykę stronniczości z progiem zapisanym przed testem? Czy macie udokumentowaną ścieżkę, w której człowiek może zweryfikować i odwrócić decyzję systemu, zanim wywoła ona skutek?

Jeśli na któreś pytanie odpowiedź brzmi „nie wiem”, mamy szkolenia dopasowane do roli: testowanie systemów AI wysokiego ryzyka pod AI Act dla dostawców budujących dokumentację testową i system zarządzania jakością, AI Act w HR i rekrutacji dla działów kadr, AI Act w bankowości i ubezpieczeniach ze scoringiem kredytowym i oceną skutków dla praw podstawowych oraz AI Act w wyrobach medycznych dla producentów objętych MDR. Testy dokładności, solidności i stronniczości systemów AI wykonujemy w ramach usługi testowania systemów AI.

W sektorach regulowanych często pada też pytanie, czy testy musi wykonać firma niezależna od producenta. Strefa QA rozkłada to szczegółowo w tekście testy niezależne od producenta jako wymóg prawny: kto, kiedy i co musi udokumentować.

Powiązane na blogu Quality Island

• Testowanie systemów AI: jak zapewnić jakość w erze sztucznej inteligencji
• Sztuczna inteligencja w bankowości: jak testować AI, która wykrywa oszustwa
• Cyber Resilience Act: nowy obowiązek testowania podatności
• Rozporządzenie DORA a testy: kto musi, jak często i dlaczego niezależnie
• Testy API i sztuczna inteligencja: co realnie zmienia w pracy QA

Pełna lista źródeł

• Unia Europejska, EUR-Lex, Rozporządzenie Parlamentu Europejskiego i Rady (UE) 2024/1689 (akt w sprawie sztucznej inteligencji), 2024. Stąd art. 3 pkt 3, 4 i 8, art. 6 ust. 3 i 4, art. 9 ust. 6 do 8, art. 10 ust. 2 i 3, art. 11, 14, 15, 25 ust. 1, art. 26 ust. 1, 2, 4, 5 i 7, art. 27, 72, 99 i załącznik III.
• Unia Europejska, EUR-Lex, Rozporządzenie Parlamentu Europejskiego i Rady (UE) 2026/1744 z 8 lipca 2026 (akt zbiorczy prawa cyfrowego dotyczący AI, Digital Omnibus), 2026. Stąd nowe brzmienie art. 113, art. 57 ust. 1 i art. 111 ust. 4, uchylenie art. 10 ust. 5, nowy art. 4a i data publikacji 24.07.2026.
• Cornell Law School, Legal Information Institute, 29 CFR 1607.4, Uniform Guidelines on Employee Selection Procedures, 1978. Stąd reguła czterech piątych (lit. D) i zastrzeżenie, że mniejsze różnice też mogą oznaczać niekorzystny wpływ.
• Fairlearn, Common fairness metrics, 2026. Stąd definicja demographic parity ratio i ostrzeżenie przed utożsamianiem reguły 4/5 ze zgodnością z prawem; obliczenia w przykładzie sprawdzone w wersji 0.14.0.
• Dane własne Quality Island, 2026: ponad 40 wdrożeń AI przeprowadzonych przez Tomasza Stelmacha w firmach i dużych organizacjach.