AI Act: obowiązki testowania systemów wysokiego ryzyka, termin przesunięty na 2027

AI Act testowanie systemów wysokiego ryzyka to temat, który bywa wrzucany do jednego worka z DORA jako „przepisy o AI”, a to dwie różne regulacje z różnymi adresatami i różną logiką. AI Act nie pyta, czy jesteście bankiem. Pyta, czy budujecie albo wdrażacie system AI, który wpływa na decyzje o ludziach. Pierwotnie ta granica miała się zaostrzyć od 2 sierpnia 2026. Tak się nie stało: Digital Omnibus, który wszedł w życie 27 lipca 2026, przesunął ten termin o szesnaście miesięcy. Poniżej wyjaśniamy, co to realnie zmienia i dlaczego to dobra wiadomość tylko dla tych, którzy już teraz zaczną z niej korzystać.

Dlaczego termin się przesunął: Digital Omnibus

Digital Omnibus to pakiet zmian w AI Act, zaproponowany przez Komisję Europejską w listopadzie 2025, a przyjęty w formie Rozporządzenia UE 2026/1744. Dokument opublikowano w Dzienniku Urzędowym UE 24 lipca 2026, wszedł w życie trzy dni później. Jego głównym celem było danie firmom i regulatorom więcej czasu na przygotowanie się do obowiązków dla systemów wysokiego ryzyka, których szczegółowe wytyczne wykonawcze wciąż nie były gotowe w momencie zbliżania się pierwotnego terminu. Innymi słowy: to nie jest wycofanie się z AI Act, tylko uznanie, że zarówno firmy, jak i sama administracja unijna, potrzebowały więcej czasu, żeby zrobić to porządnie, zamiast na siłę zdążyć na sztywną datę.

Przesunięcie nie dotyczy całego AI Act. Zakaz praktyk uznanych za niedopuszczalne obowiązuje od lutego 2025, a obowiązki dla modeli ogólnego przeznaczenia od sierpnia 2025, i żadne z tych dwóch nie zostało ruszone. Nie zmieniły się też obowiązki przejrzystości z artykułu 50, czyli oznaczanie treści wygenerowanych przez AI, tu zostawiono jedynie okres przejściowy do grudnia 2026 dla systemów, które już działają na rynku. Przesunięciu uległy wyłącznie terminy dla systemów wysokiego ryzyka i dla piaskownic regulacyjnych, które mają za zadanie umożliwić firmom testowanie zgodności zanim padnie pierwsze pytanie inspekcji.

Kto wpada w kategorię wysokiego ryzyka

Najszerszy zakres obowiązków AI Act dotyczy systemów wysokiego ryzyka z załącznika III, czyli między innymi systemów używanych w rekrutacji, ocenie zdolności kredytowej, edukacji, ocenie ryzyka w ubezpieczeniach, a także w wymiarze sprawiedliwości i kontroli granicznej. To nie jest wąska nisza. Każda firma, która buduje własny model scoringowy, system rekomendacji kandydatów albo automatyczną ocenę wniosków, powinna dziś sprawdzić, czy nie mieści się w tej kategorii, zanim zrobi to za nią regulator.

Warto podkreślić, co odróżnia AI Act od większości wcześniejszych regulacji technologicznych: nie interesuje go, jak zaawansowany technicznie jest model. Prosty, ręcznie skonfigurowany system punktowy do oceny kandydatów może wpaść w tę samą kategorię co skomplikowana sieć neuronowa, jeśli obie podejmują decyzje wpływające na dostęp ludzi do pracy, kredytu czy edukacji. Klasyfikacja odbywa się po skutku decyzji, nie po metodzie, jaką ta decyzja została podjęta, co zaskakuje firmy przyzwyczajone myśleć o regulacjach AI wyłącznie w kontekście dużych modeli językowych.

Druga rzecz, którą firmy mylą równie często, to rola, jaką pełnią względem konkretnego systemu. AI Act rozróżnia dostawcę, czyli firmę, która buduje system i wprowadza go na rynek pod własną marką, od operatora, czyli firmę, która ten system tylko wykorzystuje w swojej działalności. Obowiązki dostawcy są znacznie szersze: to on odpowiada za dokumentację techniczną, ocenę zgodności i oznakowanie CE. Firma, która kupuje gotowe narzędzie rekrutacyjne od zewnętrznego dostawcy, jest zwykle tylko operatorem, ale traci ten status, jeśli istotnie zmodyfikuje system albo zacznie sprzedawać go dalej pod własną marką. Wtedy automatycznie przejmuje obowiązki dostawcy, często nie zdając sobie z tego sprawy.

AI Act a DORA: dwie różne regulacje, ten sam błąd firm

DORA, czyli Digital Operational Resilience Act, dotyczy odporności operacyjnej sektora finansowego: banków, ubezpieczycieli, firm inwestycyjnych. Reguluje zarządzanie ryzykiem ICT, testy odporności cyfrowej i nadzór nad dostawcami zewnętrznymi, i obowiązuje wyłącznie podmioty finansowe wskazane wprost w rozporządzeniu.

AI Act działa inaczej: nie patrzy na branżę, tylko na sam system i jego skutki. Software house budujący system rekrutacyjny dla klienta z sektora publicznego wpada pod AI Act tak samo jak bank budujący model scoringowy, mimo że żadna z tych dwóch firm nie jest instytucją finansową w rozumieniu DORA. Firma, która sprawdziła, że nie podlega DORA, i na tej podstawie założyła, że regulacje AI jej nie dotyczą, popełnia błąd, bo to dwa niezależne testy zgodności, nie jeden.

Co konkretnie oznacza obowiązek testowania

AI Act nie wymyśla testowania od zera. Ustawodawca wprost dopuszcza, żeby dostawcy systemów wysokiego ryzyka zintegrowali wymagane procesy testowania i raportowania z dokumentacją, którą już prowadzą na mocy innych przepisów unijnych. To dobra wiadomość dla firm, które mają dojrzały proces QA: nie budujecie osobnego reżimu od zera, tylko rozszerzacie istniejący, co realnie skraca czas dojścia do zgodności.

Zła wiadomość jest taka, że rozszerzenie to nie jest kosmetyczne. Dokumentacja techniczna musi wykazać, że system był testowany pod kątem dokładności, odporności i braku dyskryminacji, nie tylko funkcjonalnej poprawności. To wymaga zestawów testowych, które dziś rzadko istnieją w typowym cyklu QA: testów na reprezentatywnych, zróżnicowanych danych, testów odporności na dane spoza rozkładu, i udokumentowanego procesu oceny błędu systematycznego.

Praktyczna trudność polega na tym, że tradycyjny plan testów jest projektowany wokół oczekiwanego zachowania systemu, nie wokół pytania, czy to zachowanie jest sprawiedliwe względem różnych grup użytkowników. Zespół, który testuje model rekrutacyjny wyłącznie pod kątem tego, czy poprawnie parsuje CV i zwraca wynik w oczekiwanym formacie, może przejść wszystkie testy funkcjonalne, a jednocześnie nie mieć żadnego dowodu na to, że wynik nie różni się systematycznie dla różnych grup kandydatów. To jest dokładnie ta luka, którą AI Act każe zamknąć, i dla większości zespołów QA wymaga ona nowego zestawu narzędzi i metryk, nie tylko więcej czasu na testowanie tego, co już testują.

Nasza perspektywa: co z tego realnie wynika

Co dokumentacja techniczna musi dziś wykazać

Źródło: CRIDO, „Obowiązki operatorów systemów AI według AI Act”, 2026.

Czwarty obszar, nadzór człowieka, bywa najbardziej niedoceniany, bo wygląda na czysto proceduralny, a w praktyce wymaga zmian w samym produkcie. System, w którym decyzja AI trafia bezpośrednio do klienta bez żadnego punktu interwencji, nie spełnia tego wymogu, niezależnie od tego, jak dokładny jest sam model. Zespół QA musi więc testować nie tylko jakość predykcji, ale i realną dostępność ścieżki odwołania się od decyzji, w tym czas, w jakim człowiek może tę decyzję zweryfikować, zanim wywoła ona nieodwracalny skutek.

Ile kosztuje brak zgodności

AI Act ma trójstopniową skalę kar, i żaden z trzech progów nie jest symboliczny. Najwyższy próg, do 35 milionów euro albo 7% globalnego rocznego obrotu, dotyczy złamania zakazu praktyk uznanych za niedopuszczalne, na przykład manipulacyjnych technik wpływania na zachowanie ludzi. Drugi próg, do 15 milionów euro albo 3% obrotu, dotyczy właśnie niezgodności systemów wysokiego ryzyka, czyli tego, o czym jest ten artykuł. Trzeci próg, do 7,5 miliona euro albo 1,5% obrotu, dotyczy podania nieprawdziwych albo niepełnych informacji organom nadzoru.

Przesunięcie terminu nie obniża tych kwot ani nie zmienia logiki kar, tylko przesuwa moment, od którego zaczynają one realnie grozić za brak testów i dokumentacji dla systemów z załącznika III. Firma, która zbuduje proces testowy w ciągu najbliższego roku, wchodzi w grudzień 2027 z gotowym dowodem zgodności, zamiast liczyć, ile z tych progów kar może jej dotyczyć.

Warto też pamiętać, że błędna klasyfikacja własnego systemu działa w obie strony finansowo niekorzystnie. Firma, która uzna system za system wysokiego ryzyka, choć nim nie jest, buduje kosztowną dokumentację i testy, których nikt od niej nie wymaga. Firma, która uzna, że system nie jest wysokiego ryzyka, choć jest, naraża się na te same kary co brak testów, tylko dowiaduje się o tym dopiero przy kontroli, nie przy planowaniu budżetu. Żaden z tych błędów nie jest tańszy od rzetelnej klasyfikacji na wejściu.

Co to oznacza praktycznie dla waszej firmy

Zanim odłożycie ten temat do 2027 roku, warto odpowiedzieć sobie na trzy pytania. Pierwsze: czy ktokolwiek w firmie formalnie sklasyfikował Wasze systemy AI pod kątem załącznika III, czy to wciąż założenie na wyczucie. Drugie: czy Wasz obecny plan testów w ogóle zawiera testy odporności na dyskryminację i błąd systematyczny, czy kończy się na testach funkcjonalnych. Trzecie: czy macie udokumentowaną ścieżkę nadzoru człowieka nad decyzją systemu, czy decyzja trafia do klienta bez żadnego punktu interwencji.

Firmy, które zaczną odpowiadać na te pytania teraz, wykorzystują dodatkowy rok z Digital Omnibus tak, jak powinien być wykorzystany: nie jako odroczenie problemu, tylko jako czas na zbudowanie procesu bez presji ostatniego kwartału.

Dobra wiadomość jest taka, że żadnego z tych trzech kroków nie trzeba robić od zera osobno dla samego AI Act. Klasyfikacja systemu, testy odporności i dokumentacja nadzoru człowieka najlepiej wychodzą jako rozszerzenie istniejącego procesu QA, nie jako osobny projekt zgodności prowadzony obok niego przez dział prawny. Zespół, który już dziś ma dojrzały proces testowy, zwykle potrzebuje kilku tygodni pracy, żeby dopisać brakujące kategorie testów, nie kilku miesięcy budowy nowego działu. Zespół, który takiego procesu nie ma, powinien zacząć od niego, zanim w ogóle zajmie się specyfiką AI Act, bo bez podstawowego porządku w testowaniu żadna dokumentacja zgodności nie będzie wiarygodna.

Powiązane na blogu Quality Island

• Testowanie systemów AI: jak zapewnić jakość w erze sztucznej inteligencji
• Cyber Resilience Act: nowy obowiązek testowania podatności

Pełna lista źródeł

• Rozporządzenie UE 2026/1744 (Digital Omnibus), Dziennik Urzędowy Unii Europejskiej, 24.07.2026
• Dudkowiak & Putyra, Systemy AI wysokiego ryzyka, nowe terminy AI Act, 2026
• CRIDO, Obowiązki operatorów systemów AI według AI Act
• Gibson Dunn, EU AI Act Omnibus Agreement, postponed high-risk deadlines