Sierpień 2026 roku to data, o której żaden zespół IT pracujący z systemami sztucznej inteligencji nie powinien zapomnieć. Właśnie wtedy w pełni wchodzą w życie wymogi dotyczące systemów AI wysokiego ryzyka — najobszerniejsza i najbardziej wymagająca część unijnego rozporządzenia AI Act. Dla inżynierów, architektów, testerów i liderów technicznych oznacza to konkretne zmiany w codziennej pracy: nowe procesy dokumentacyjne, obowiązkowe testowanie pod kątem stronniczości i odporności, mechanizmy nadzoru ludzkiego oraz ciągły monitoring systemów w produkcji.
Ten artykuł to praktyczny przewodnik dla zespołów IT, które muszą zrozumieć, co dokładnie zmienia się w ich obszarze odpowiedzialności i jak się do tego przygotować, zanim przyjdzie termin.
Czym jest AI Act i dlaczego powstał
AI Act (Rozporządzenie Parlamentu Europejskiego i Rady (UE) 2024/1689) to pierwsze na świecie kompleksowe rozporządzenie regulujące rozwój, wprowadzanie na rynek i stosowanie systemów sztucznej inteligencji. Zostało opublikowane w Dzienniku Urzędowym UE 12 lipca 2024 roku i weszło w życie 1 sierpnia 2024.
Motywacją stojącą za rozporządzeniem jest potrzeba ustanowienia ram prawnych, które pozwolą czerpać korzyści z AI, jednocześnie chroniąc prawa podstawowe obywateli UE. W przeciwieństwie do podejścia sektorowego (np. regulowanie AI osobno w medycynie, finansach czy transporcie), UE zdecydowała się na podejście horyzontalne — jedno rozporządzenie obejmujące wszystkie sektory, z klasyfikacją opartą na poziomie ryzyka.
Dla zespołów IT kluczowe jest zrozumienie, że AI Act nie reguluje technologii jako takiej, lecz zastosowania systemów AI. Ten sam model uczenia maszynowego może podlegać różnym wymogom w zależności od tego, do czego jest używany. System rekomendujący filmy na platformie streamingowej to zupełnie inna kategoria ryzyka niż system oceniający zdolność kredytową — nawet jeśli pod spodem pracuje podobna architektura.
Zakres terytorialny
AI Act obowiązuje każdą organizację, która:
- Dostarcza (provider) systemy AI na rynku UE — niezależnie od siedziby firmy
- Wdraża (deployer) systemy AI w UE — nawet jeśli system pochodzi spoza UE
- Importuje lub dystrybuuje systemy AI na rynku UE
Firma z siedzibą w USA dostarczająca system AI europejskiemu klientowi podlega AI Act w takim samym stopniu jak firma z Warszawy czy Berlina. Podobnie firma z Singapuru wdrażająca narzędzie AI dla swojego europejskiego oddziału.
Harmonogram wdrażania — co już obowiązuje, a co nadchodzi
AI Act nie wchodzi w życie jednego dnia w pełnym zakresie. Przepisy są implementowane etapowo, aby dać organizacjom czas na dostosowanie się:
| Data | Co wchodzi w życie |
|---|---|
| 1 sierpnia 2024 | Rozporządzenie wchodzi w życie |
| 2 lutego 2025 | Zakaz systemów AI o niedopuszczalnym ryzyku (social scoring, manipulacja podprogowa, biometryczna kategoryzacja wrażliwych cech) |
| 2 sierpnia 2025 | Przepisy dotyczące AI ogólnego zastosowania (GPAI/general-purpose AI), w tym modeli fundamentalnych; ustanowienie AI Office |
| 2 sierpnia 2026 | Pełne wymogi dla systemów wysokiego ryzyka — dokumentacja techniczna, zarządzanie jakością, conformity assessment, rejestracja w bazie EU, human oversight, monitoring postmarketowy |
| 2 sierpnia 2027 | Przepisy dla systemów wysokiego ryzyka będących komponentami produktów podlegających istniejącym regulacjom sektorowym (np. urządzenia medyczne, maszyny, zabawki) |
Dla zespołów IT najważniejszą datą jest sierpień 2026. To moment, w którym każdy system AI sklasyfikowany jako wysokiego ryzyka musi spełniać pełen zestaw wymogów technicznych — albo nie może być wprowadzony na rynek ani używany w UE.
Klasyfikacja ryzyka — fundament regulacji
Sercem AI Act jest system klasyfikacji ryzyka, który dzieli systemy AI na cztery kategorie. Od kategorii zależy zakres obowiązków spoczywających na dostawcy i użytkowniku systemu.
Ryzyko niedopuszczalne — systemy zakazane
Od lutego 2025 roku zakazane są systemy AI, które:
- Stosują techniki podprogowe lub manipulacyjne w celu istotnego zniekształcenia zachowania osób, w sposób powodujący lub mogący spowodować szkodę fizyczną lub psychiczną
- Wykorzystują podatności konkretnych grup ludzi wynikające z wieku, niepełnosprawności lub sytuacji społeczno-ekonomicznej
- Realizują social scoring przez władze publiczne — ocenianie obywateli na podstawie zachowań społecznych, prowadzące do krzywdzącego lub nieproporcjonalnego traktowania
- Stosują zdalną identyfikację biometryczną w czasie rzeczywistym w przestrzeniach publicznych do celów egzekwowania prawa (z wąskimi wyjątkami dotyczącymi poszukiwania zaginionych, zapobiegania zamachom terrorystycznym i lokalizowania podejrzanych o najpoważniejsze przestępstwa)
- Tworzą bazy danych rozpoznawania twarzy na podstawie masowego, nietargetowanego zbierania obrazów z internetu lub monitoringu CCTV
- Rozpoznają emocje w miejscu pracy lub instytucjach edukacyjnych (z wyjątkami medycznymi i dotyczącymi bezpieczeństwa)
- Kategoryzują osoby fizyczne na podstawie danych biometrycznych w celu dedukowania rasy, poglądów politycznych, przynależności związkowej, przekonań religijnych lub orientacji seksualnej
- Tworzą predyktywne profile przestępcze na podstawie samego profilowania (bez obiektywnych, weryfikowalnych faktów)
Dla zespołów IT oznacza to konieczność audytu istniejących systemów — jeśli jakikolwiek system w organizacji mieści się w tych kategoriach, musi zostać natychmiast wyłączony lub gruntownie przebudowany.
Ryzyko wysokie — główny przedmiot regulacji
Systemy AI wysokiego ryzyka to obszar, w którym AI Act nakłada najobszerniejsze wymagania. System jest uznawany za wysoko ryzykowny w dwóch przypadkach:
1. Komponent produktu objętego istniejącymi regulacjami bezpieczeństwa UE (Załącznik I), np.:
- Urządzenia medyczne i wyroby medyczne do diagnostyki in vitro
- Systemy bezpieczeństwa w pojazdach
- Wyposażenie lotnicze
- Zabawki, maszyny, windy
- Urządzenia radiowe i telekomunikacyjne
2. Samodzielny system AI w jednym z wyszczególnionych obszarów (Załącznik III):
- Identyfikacja biometryczna — zdalna identyfikacja biometryczna (nie w czasie rzeczywistym), systemy kategoryzacji biometrycznej
- Infrastruktura krytyczna — systemy bezpieczeństwa zarządzające ruchem drogowym, zaopatrzeniem w wodę, ogrzewaniem, energetyką, sieciami telekomunikacyjnymi
- Edukacja i szkolenia — systemy oceniające uczniów i studentów, automatyczne egzaminy, systemy przydziału do szkół i placówek edukacyjnych, systemy monitorujące zachowanie uczniów podczas egzaminów
- Zatrudnienie i zarządzanie pracownikami — systemy do selekcji CV i rekrutacji, prowadzenia rozmów kwalifikacyjnych, oceny kandydatów, podejmowania decyzji o awansach i rozwiązywaniu umów, monitorowania i oceny wydajności pracowników
- Dostęp do usług publicznych i prywatnych — systemy oceniające uprawnienia do świadczeń publicznych, ocena zdolności kredytowej osób fizycznych, systemy ustalania priorytetów w usługach ratunkowych, scoring ubezpieczeniowy
- Egzekwowanie prawa — ocena ryzyka popełnienia przestępstwa, poligrafy i analogiczne narzędzia AI, analiza dowodów, profilowanie w toku postępowań
- Migracja, azyl i kontrola granic — ocena ryzyka związanego z bezpieczeństwem, weryfikacja autentyczności dokumentów, rozpatrywanie wniosków azylowych
- Wymiar sprawiedliwości i procesy demokratyczne — systemy wspierające sądy w interpretacji prawa i stosowaniu przepisów, systemy wpływające na wynik wyborów lub referendów
Dla przeciętnego zespołu IT w firmie komercyjnej najczęściej w grę wchodzą systemy rekrutacyjne (ATS z elementami AI, automatyczna selekcja CV), scoringowe (kredytowe, ubezpieczeniowe), systemy monitorujące wydajność pracowników oraz narzędzia AI wbudowane w infrastrukturę krytyczną.
Ryzyko ograniczone — obowiązki transparencji
Systemy AI o ograniczonym ryzyku podlegają przede wszystkim obowiązkom informacyjnym:
- Chatboty i systemy konwersacyjne — użytkownik musi wiedzieć, że rozmawia z systemem AI, a nie z człowiekiem
- Systemy generujące treści (deepfakes, syntetyczny tekst, syntetyczne obrazy i dźwięk) — treść musi być wyraźnie oznaczona jako wygenerowana lub zmanipulowana przez AI, w formacie nadającym się do odczytu maszynowego
- Systemy rozpoznawania emocji i kategoryzacji biometrycznej (tam, gdzie są dozwolone) — osoba poddana działaniu systemu musi być o tym poinformowana
Ryzyko minimalne
Wszystkie pozostałe systemy AI — filtry spamu, systemy rekomendacji produktów, gry z elementami AI, narzędzia do optymalizacji procesów wewnętrznych — nie podlegają specjalnym wymogom. Komisja Europejska zachęca jednak dostawców do dobrowolnego stosowania kodeksów postępowania (codes of conduct).
Co konkretnie musi zrobić zespół IT dla systemów wysokiego ryzyka
Artykuły 8-15 AI Act definiują szczegółowe wymogi techniczne dla systemów AI wysokiego ryzyka. Każdy z nich przekłada się na konkretne zadania i procesy, które zespół IT musi wdrożyć.
System zarządzania ryzykiem (Art. 9)
Rozporządzenie wymaga ustanowienia, wdrożenia, udokumentowania i utrzymywania ciągłego systemu zarządzania ryzykiem przez cały cykl życia systemu AI. Nie jest to jednorazowa analiza ryzyka na początku projektu — to iteracyjny, żyjący proces obejmujący:
- Identyfikację i analizę znanych i przewidywalnych zagrożeń dla zdrowia, bezpieczeństwa i praw podstawowych użytkowników i osób trzecich
- Oszacowanie i ocenę ryzyk, które mogą się zmaterializować zarówno przy zgodnym z przeznaczeniem użyciu, jak i racjonalnie przewidywalnym nieprawidłowym użyciu
- Przyjęcie odpowiednich środków zarządzania ryzykiem — technicznych (np. filtrowanie wyników, ograniczenie zakresu działania), organizacyjnych (np. procedury eskalacji) i informacyjnych (np. instrukcje użytkowania)
- Testowanie w celu identyfikacji najodpowiedniejszych środków zarządzania ryzykiem, przeprowadzane przed wprowadzeniem systemu na rynek i w trakcie jego funkcjonowania
W praktyce oznacza to prowadzenie rejestru ryzyk (risk register) dla każdego systemu AI wysokiego ryzyka, regularne przeglądy po zmianach w systemie lub jego otoczeniu, dokumentowanie decyzji dotyczących akceptowalnego poziomu ryzyka rezydualnego oraz testowanie zidentyfikowanych scenariuszy ryzyka na danych realnych.
Dane i zarządzanie danymi (Art. 10)
Wymogi dotyczące danych to jeden z najbardziej wymagających technicznie aspektów AI Act. Rozporządzenie stanowi, że:
- Zbiory danych szkoleniowych, walidacyjnych i testowych muszą podlegać odpowiednim praktykom zarządzania danymi (data governance), obejmującym wybory projektowe, procesy zbierania danych, operacje przetwarzania, etykietowanie i czyszczenie danych
- Dane muszą być istotne, wystarczająco reprezentatywne, wolne od błędów i kompletne w odniesieniu do zamierzonego zastosowania systemu
- Zbiory danych muszą uwzględniać specyficzne ustawienia geograficzne, kontekstualne, behawioralne lub funkcjonalne, w których system ma być używany — system szkolony na danych z rynku amerykańskiego może nie być odpowiedni dla rynku europejskiego
- Dla systemów wykorzystujących techniki uczenia się na danych konieczne jest zbadanie możliwych stronniczości (biases), szczególnie takich, które mogą prowadzić do dyskryminacji ze względu na cechy chronione
Przełożenie na codzienną pracę zespołu IT:
- Data lineage — pełna śledzalność pochodzenia każdego zbioru danych, historii transformacji, wersjonowania
- Bias auditing — regularne testowanie zbiorów danych i wyników modelu pod kątem dyskryminacji ze względu na płeć, wiek, pochodzenie etniczne, niepełnosprawność i inne cechy chronione
- Data quality monitoring — ciągła kontrola jakości danych zasilających system, z alertami przy odchyleniach od oczekiwanych rozkładów
- Dokumentacja zbiorów danych — formalne datasheets opisujące metody zbierania, przetwarzania, etykietowania, czyszczenia i walidacji danych
Dokumentacja techniczna (Art. 11)
Zanim system AI wysokiego ryzyka zostanie wprowadzony na rynek, musi posiadać aktualną dokumentację techniczną obejmującą (zgodnie z Załącznikiem IV):
- Opis ogólny systemu AI — przeznaczenie, wersja, relacje z poprzednimi wersjami, interakcje z innymi systemami
- Opis elementów systemu — algorytmy, modele (architektura, rozmiar, hiperparametry), procesy obliczeniowe, zasoby sprzętowe
- Opis procesu rozwoju — metody projektowania, decyzje dotyczące modelowania, dane szkoleniowe (rozmiar, zakres, charakterystyka), metryki walidacyjne, wyniki testów
- Informacje o monitoringu — zdolności systemu do logowania, metryki wydajności monitorowane w produkcji
- Opis interakcji z człowiekiem — sposób i zakres nadzoru ludzkiego, interfejsy, ograniczenia i ryzyka znane użytkownikowi
- Analiza ryzyka — zidentyfikowane ryzyka i przyjęte środki ich ograniczania
Dokumentacja musi być na tyle szczegółowa, aby organy nadzoru mogły ocenić zgodność systemu z rozporządzeniem. To radykalna zmiana kultury pracy w wielu zespołach — z modelu „dokumentacja jest opcjonalna i powstaje post factum” na model „dokumentacja jest obowiązkowa, aktualna i audytowalna”.
Model cards, datasheets for datasets, architecture decision records, logi decyzji projektowych — wszystko musi być utrzymywane od początku projektu i aktualizowane przy każdej istotnej zmianie.
Rejestrowanie zdarzeń — logi (Art. 12)
Systemy AI wysokiego ryzyka muszą posiadać mechanizmy automatycznego rejestrowania zdarzeń przez cały okres ich funkcjonowania. Logi muszą umożliwiać:
- Śledzalność działania systemu — identyfikację sytuacji mogących powodować ryzyko lub istotne zmiany w zachowaniu
- Monitoring zgodności z wymogami w trakcie użytkowania
- Monitorowanie postmarketowe przez dostawcę
Minimalne wymagania logowania obejmują: okres działania systemu (początek i koniec każdego użycia), dane referencyjne użyte do weryfikacji danych wejściowych, dane wejściowe dla których system wygenerował wynik, oraz identyfikację osób fizycznych zaangażowanych w weryfikację wyników.
Logi muszą być przechowywane przez okres adekwatny do przeznaczenia systemu, przy czym rozporządzenie sugeruje minimum odpowiednie do zamierzonego celu. W praktyce zespoły IT powinny przyjąć retencję nie krótszą niż okres potrzebny do wykrycia i zbadania incydentu — co zwykle oznacza co najmniej 6-12 miesięcy.
Transparencja i informacje dla użytkowników (Art. 13)
Systemy AI wysokiego ryzyka muszą być zaprojektowane tak, aby ich działanie było wystarczająco przejrzyste dla użytkowników (deployers). Dostawca musi dostarczyć instrukcje użytkowania zawierające:
- Dane identyfikacyjne dostawcy
- Charakterystykę, zdolności i ograniczenia systemu
- Zamierzone zastosowanie i racjonalnie przewidywalne nieprawidłowe użycie
- Metryki wydajności (dokładność, odporność) dla konkretnych grup docelowych
- Specyfikacje danych wejściowych
- Informacje o mechanizmach nadzoru ludzkiego
- Oczekiwaną żywotność systemu i niezbędne środki utrzymania
Nadzór ludzki (Art. 14)
Systemy AI wysokiego ryzyka muszą być zaprojektowane tak, aby mogły być skutecznie nadzorowane przez osoby fizyczne w trakcie użytkowania. Nadzór ludzki musi zapewniać możliwość:
- Pełnego zrozumienia zdolności i ograniczeń systemu AI przez osobę nadzorującą
- Monitorowania działania systemu i wykrywania anomalii, dysfunkcji oraz nieoczekiwanych wyników — w tym przy pomocy narzędzi technicznych
- Interpretacji wyników systemu AI w kontekście dostępnych danych i wiedzy eksperckiej
- Podjęcia decyzji o niestosowaniu, odrzuceniu, nadpisaniu lub odwróceniu wyniku systemu AI w konkretnym przypadku
- Przerwania działania systemu w dowolnym momencie za pomocą mechanizmu „stop”
Dla zespołów IT oznacza to projektowanie interfejsów z realnymi mechanizmami human-in-the-loop (człowiek zatwierdza każdą decyzję) lub human-on-the-loop (człowiek monitoruje i może interweniować) — które nie mogą być tylko formalnością. Osoba nadzorująca musi mieć realne narzędzia do zrozumienia, dlaczego system podjął daną decyzję, i możliwość jej zakwestionowania.
Dokładność, odporność i cyberbezpieczeństwo (Art. 15)
Systemy AI wysokiego ryzyka muszą osiągać odpowiedni poziom dokładności, odporności i cyberbezpieczeństwa i działać konsekwentnie w tych aspektach przez cały cykl życia:
- Dokładność — deklarowane i regularnie mierzone metryki dokładności muszą być komunikowane użytkownikom. Dostawca musi określić, dla jakich grup osób i warunków metryki zostały zmierzone
- Odporność (robustness) — system musi być odporny na błędy, usterki, niespójności i nieoczekiwane sytuacje w otoczeniu, w tym na próby manipulacji przez osoby trzecie wykorzystujące podatności systemu (adversarial attacks). Środki odporności mogą obejmować redundancję techniczną, mechanizmy fail-safe i fallback
- Cyberbezpieczeństwo — ochrona przed specyficznymi atakami na systemy AI: manipulacja zbiorem danych szkoleniowych (data poisoning), manipulacja danymi wejściowymi w celu uzyskania błędnych wyników (adversarial inputs), ataki na poufność modelu (model extraction i model inversion), oraz ataki na infrastrukturę wspierającą system
W praktyce zespół IT musi wdrożyć:
- Adversarial testing — regularne testowanie odporności modelu na przykłady adwersaryjne z wykorzystaniem narzędzi takich jak IBM Adversarial Robustness Toolbox
- Robustness testing — testowanie zachowania systemu na danych spoza dystrybucji treningowej, przypadkach brzegowych i danych z szumem
- Specjalistyczne testy bezpieczeństwa AI — testy penetracyjne uwzględniające wektory ataku specyficzne dla AI: prompt injection, data poisoning, model stealing, membership inference
- Performance monitoring — ciągłe monitorowanie metryk dokładności w produkcji z automatycznym alertowaniem przy drycie danych lub spadku wydajności
AI ogólnego zastosowania (GPAI) — modele fundamentalne pod regulacją
Od sierpnia 2025 obowiązują osobne przepisy dla dostawców modeli AI ogólnego zastosowania (general-purpose AI, GPAI) — czyli modeli fundamentalnych zdolnych do wykonywania wielu różnych zadań. Dotyczy to przede wszystkim dużych modeli językowych (LLM), ale także multimodalnych modeli generatywnych.
Standardowe obowiązki dostawców GPAI
Każdy dostawca modelu GPAI musi:
- Sporządzić i utrzymywać dokumentację techniczną modelu, obejmującą proces szkolenia i testowania, wraz z wynikami ewaluacji
- Udostępnić informacje dostawcom niższego szczebla (downstream providers) integrującym model w swoje systemy AI — wystarczające do wypełnienia ich własnych obowiązków zgodności
- Wprowadzić politykę poszanowania prawa autorskiego UE, w szczególności mechanizmy identyfikacji i przestrzegania zastrzeżeń dotyczących eksploatacji tekstów i danych (text and data mining opt-outs)
- Opublikować szczegółowe podsumowanie treści użytych do szkolenia modelu — zgodnie ze wzorem przygotowanym przez AI Office
GPAI o ryzyku systemowym
Modele GPAI uznane za stwarzające ryzyko systemowe — na podstawie zdolności obliczeniowych użytych do szkolenia (próg ustalony na 10^25 FLOP) lub na mocy decyzji Komisji Europejskiej uwzględniającej inne kryteria — muszą dodatkowo:
- Przeprowadzać zaawansowane ewaluacje modelu zgodnie z opracowywanymi kodeksami praktyki, z wykorzystaniem standaryzowanych protokołów i narzędzi (w tym testów red-teaming)
- Oceniać i podejmować środki ograniczające ryzyka systemowe, w tym ryzyka dla zdrowia publicznego, bezpieczeństwa, praw podstawowych, środowiska i demokracji
- Raportować poważne incydenty do AI Office niezwłocznie po ich wykryciu
- Zapewnić odpowiedni poziom cyberbezpieczeństwa modelu i infrastruktury
Dla zespołów IT w organizacjach korzystających z modeli GPAI (np. integrujących API OpenAI, Anthropic, Google czy modele open-source jak Llama lub Mistral) fundamentalne jest zrozumienie, że odpowiedzialność za zgodność systemu końcowego leży po stronie dostawcy tego systemu — nie dostawcy modelu bazowego. Jeśli Twoja firma buduje system AI wysokiego ryzyka z wykorzystaniem modelu GPT-4 lub Claude, to Twoja firma jako dostawca systemu końcowego odpowiada za spełnienie wymogów artykułów 8-15.
Ocena zgodności (Conformity Assessment)
Zanim system AI wysokiego ryzyka zostanie wprowadzony na rynek UE lub oddany do użytku, musi przejść ocenę zgodności. Procedura zależy od rodzaju systemu:
- Większość systemów z Załącznika III — ocena zgodności na podstawie kontroli wewnętrznej (samoocena przez dostawcę, zgodnie z Załącznikiem VI). Dostawca sam weryfikuje spełnienie wymogów i sporządza dokumentację
- Systemy zdalnej identyfikacji biometrycznej i niektóre inne kategorie szczególnie wrażliwe — ocena z udziałem jednostki notyfikowanej (niezależnej akredytowanej instytucji certyfikacyjnej, zgodnie z Załącznikiem VII)
- Systemy będące komponentami produktów z Załącznika I — ocena zgodności AI jest częścią istniejącej procedury oceny zgodności produktu
Ocena zgodności obejmuje weryfikację spełnienia wszystkich wymogów:
- Systemu zarządzania ryzykiem (art. 9)
- Zarządzania danymi (art. 10)
- Dokumentacji technicznej (art. 11)
- Rejestrowania zdarzeń (art. 12)
- Transparencji (art. 13)
- Nadzoru ludzkiego (art. 14)
- Dokładności, odporności i cyberbezpieczeństwa (art. 15)
- Systemu zarządzania jakością (QMS, art. 17)
Po pozytywnej ocenie dostawca sporządza deklarację zgodności UE, umieszcza oznakowanie CE (jeśli wymagane) i rejestruje system w unijnej bazie danych systemów AI wysokiego ryzyka prowadzonej przez Komisję Europejską. Rejestracja jest publiczna — każdy może sprawdzić, jakie systemy AI wysokiego ryzyka działają na rynku UE.
Istotne: ocena zgodności musi być powtórzona przy każdej istotnej modyfikacji systemu. Drobne aktualizacje (np. patche bezpieczeństwa) nie wymagają ponownej oceny, ale zmiana architektury modelu, znaczące poszerzenie zakresu danych szkoleniowych lub zmiana zamierzonego zastosowania — już tak.
Kary — jakie ryzyko finansowe
AI Act przewiduje trzy poziomy kar administracyjnych:
| Naruszenie | Maksymalna kara |
|---|---|
| Stosowanie zakazanych systemów AI (art. 5) | 35 mln EUR lub 7% globalnego rocznego obrotu (wyższa kwota) |
| Naruszenie wymogów dla systemów wysokiego ryzyka (art. 8-15, 25-27 i inne) | 15 mln EUR lub 3% globalnego rocznego obrotu |
| Podanie fałszywych, niekompletnych lub wprowadzających w błąd informacji organom nadzoru | 7,5 mln EUR lub 1% globalnego rocznego obrotu |
Dla MŚP i startupów rozporządzenie przewiduje proporcjonalnie niższe progi kar (stosuje się niższą z dwóch kwot, nie wyższą), ale nawet w tym przypadku kary mogą być dotkliwe.
Ważny kontekst: AI Act to rozporządzenie, nie dyrektywa — obowiązuje bezpośrednio we wszystkich państwach członkowskich UE bez konieczności transpozycji. Krajowe organy nadzoru mogą nakładać kary od pierwszego dnia obowiązywania danego przepisu.
Praktyczna checklista compliance dla zespołów IT
Konkretna lista kroków, które zespół IT powinien podjąć:
Faza 1: Inwentaryzacja (natychmiast)
- Zidentyfikuj wszystkie systemy AI w organizacji — własne, kupowane (SaaS), budowane na API zewnętrznych modeli, open-source
- Sklasyfikuj każdy system według kategorii ryzyka AI Act (zakazany / wysoki / ograniczony / minimalny)
- Sprawdź, czy jakikolwiek system mieści się w kategorii zakazanej — jeśli tak, wyłącz natychmiast lub przebuduj
- Zmapuj role — kto jest dostawcą (provider), kto wdrażającym (deployer), kto dystrybutorem dla każdego systemu
- Sporządź rejestr systemów AI — centralną bazę wszystkich systemów AI z przypisaną klasyfikacją ryzyka
Faza 2: Gap analysis (Q2 2026)
- Porównaj istniejącą dokumentację z wymogami art. 11 i Załącznika IV — zidentyfikuj brakujące elementy
- Oceń istniejące procesy testowania — czy obejmują bias detection, adversarial testing, robustness testing, czy tylko testy funkcjonalne
- Sprawdź mechanizmy logowania — czy spełniają wymogi art. 12 co do zakresu, szczegółowości i retencji
- Oceń mechanizmy nadzoru ludzkiego — czy osoby nadzorujące mają realne narzędzia do zrozumienia i zakwestionowania decyzji AI
- Zidentyfikuj luki w cyberbezpieczeństwie specyficzne dla AI — data poisoning, model extraction, adversarial inputs, prompt injection
- Sprawdź umowy z dostawcami zewnętrznych modeli i usług AI — czy zawierają klauzule compliance
Faza 3: Implementacja (Q2-Q3 2026)
- Wdróż system zarządzania ryzykiem — risk register, procesy oceny, środki mitigacji
- Uzupełnij dokumentację techniczną do pełnego poziomu wymaganego Załącznikiem IV
- Wdróż lub rozbuduj system logowania — zakres, retencja, integralność logów
- Zaprojektuj i wdróż interfejsy nadzoru ludzkiego — dashboardy, mechanizmy override, alerty
- Przeprowadź pełne testy — bias, fairness, robustness, adversarial, security
- Ustanów procesy monitoringu postmarketowego — metryki, alerty, procedury reakcji na anomalie
- Wdróż lub rozszerz system zarządzania jakością (QMS)
Faza 4: Ocena zgodności (Q3 2026)
- Przeprowadź wewnętrzną ocenę zgodności lub zaangażuj jednostkę notyfikowaną
- Sporządź deklarację zgodności UE
- Zarejestruj system w unijnej bazie danych
- Ustanów procesy ciągłego utrzymywania zgodności — przeglądy okresowe, aktualizacje dokumentacji, ponowna ocena przy zmianach
Kompetencje, które zespół IT musi rozwinąć
AI Act wymaga od zespołów IT kompetencji wykraczających poza tradycyjny zakres inżynierii oprogramowania:
Klasyfikacja i zarządzanie ryzykiem AI — umiejętność oceny, czy system AI podlega regulacjom i na jakim poziomie, prowadzenie ciągłego procesu zarządzania ryzykiem z uwzględnieniem specyfiki systemów probabilistycznych.
Dokumentacja techniczna systemów AI — tworzenie i utrzymywanie dokumentacji spełniającej wymogi Załącznika IV. Model cards, data sheets, architecture decision records, risk assessments — formaty, które w wielu organizacjach nie istnieją.
Testowanie i walidacja AI — bias detection i fairness metrics (np. demographic parity, equalized odds, calibration), adversarial robustness testing, testowanie na danych spoza dystrybucji, performance degradation monitoring. To osobna specjalizacja od tradycyjnego QA.
Explainability i interpretowalność — zdolność do wyjaśnienia decyzji systemu AI w sposób zrozumiały dla użytkowników i organów nadzoru. Techniki takie jak SHAP, LIME, attention visualization, counterfactual explanations stają się wymaganą kompetencją.
AI security — ochrona przed specyficznymi atakami na systemy AI: data poisoning, adversarial inputs, model extraction, model inversion, prompt injection, membership inference. To odrębna dziedzina od tradycyjnego cyberbezpieczeństwa, wymagająca zrozumienia zarówno bezpieczeństwa, jak i ML.
Data governance dla AI — zarządzanie jakością, pochodzeniem, przetwarzaniem i wersjonowaniem danych szkoleniowych zgodnie z wymogami art. 10. Obejmuje data lineage, quality monitoring, bias auditing.
Monitoring postmarketowy — ciągłe monitorowanie zachowania systemu w produkcji, wykrywanie dryfu danych (data drift) i wydajności (concept drift), alertowanie przy anomaliach, procesy incydentowe.
Relacja AI Act z innymi regulacjami
AI Act nie działa w próżni — zespoły IT muszą uwzględniać jego interakcję z innymi regulacjami:
- RODO (GDPR) — AI Act nie zastępuje RODO. Przetwarzanie danych osobowych przez systemy AI nadal w pełni podlega RODO, w tym art. 22 (prawo do niepodlegania decyzji opartej wyłącznie na zautomatyzowanym przetwarzaniu). W praktyce oznacza to podwójny reżim compliance
- Dyrektywa NIS2 — wymogi cyberbezpieczeństwa dla podmiotów kluczowych i ważnych. Systemy AI w infrastrukturze krytycznej podlegają zarówno AI Act, jak i NIS2
- Akt o odporności cybernetycznej (Cyber Resilience Act, CRA) — wymogi bezpieczeństwa dla produktów z elementami cyfrowymi. Systemy AI będące częścią takich produktów podlegają obu regulacjom
- Dyrektywa o odpowiedzialności za AI (AI Liability Directive) — ułatwia dochodzenie roszczeń cywilnoprawnych za szkody wyrządzone przez systemy AI, wprowadzając domniemanie związku przyczynowego przy naruszeniu AI Act
Piaskownice regulacyjne i wsparcie dla innowacji
AI Act przewiduje mechanizmy wspierające innowacje:
- Piaskownice regulacyjne (regulatory sandboxes) — każde państwo członkowskie musi ustanowić co najmniej jedną piaskownicę do 2 sierpnia 2026. To kontrolowane środowisko, w którym organizacje mogą rozwijać i testować innowacyjne systemy AI pod nadzorem regulatora, z uproszczonymi wymogami
- Real-world testing — możliwość testowania systemów AI wysokiego ryzyka w warunkach rzeczywistych, pod warunkiem zatwierdzenia planu testów przez organ nadzoru i zapewnienia odpowiednich zabezpieczeń
- Uproszczenia dla MŚP i startupów — proporcjonalne kary, priorytetowy dostęp do piaskownic, uproszczone kanały informacyjne
Jak przygotować zespół — rekomendacje praktyczne
Na podstawie wymogów AI Act i doświadczeń organizacji, które już rozpoczęły przygotowania:
1. Wyznacz AI Compliance Ownera — jedną osobę lub mały zespół odpowiedzialny za koordynację. Najskuteczniejsze są osoby z doświadczeniem technicznym, które potrafią przełożyć wymogi prawne na konkretne zadania inżynierskie.
2. Przeprowadź szkolenie fundamentalne — cały zespół musi rozumieć podstawy AI Act: klasyfikację ryzyka, obowiązki, harmonogram. Bez wspólnego języka niemożliwa jest efektywna współpraca między działem prawnym, biznesem i IT.
3. Zbuduj AI Risk Assessment Framework — standaryzowane szablony i procesy do klasyfikacji ryzyka nowych i istniejących systemów. Przy większej liczbie systemów AI kluczowa jest powtarzalność i spójność oceny.
4. Zainwestuj w tooling — bias detection (IBM AI Fairness 360, Fairlearn), explainability (SHAP, LIME, Captum), adversarial testing (Adversarial Robustness Toolbox, CleverHans), monitoring (MLflow, Evidently AI, WhyLabs, NannyML), dokumentacja (Model Card Toolkit).
5. Ustanów AI Act by design — analogicznie do privacy by design z RODO, wbuduj wymogi compliance w standardowy proces rozwoju systemów AI od fazy projektowej. Znacznie taniej jest projektować z myślą o zgodności od początku niż dostosowywać istniejące systemy.
6. Uruchom pilotaż — wybierz jeden system AI wysokiego ryzyka i przeprowadź pełny cykl compliance: inwentaryzacja, gap analysis, dokumentacja, testowanie, ocena zgodności. Pilotaż ujawni realne problemy i pozwoli wypracować procesy przed skalowaniem na pozostałe systemy.
Podsumowanie
AI Act to nie odległa perspektywa — to regulacja, której kluczowe wymogi dla systemów wysokiego ryzyka wchodzą w pełną moc w sierpniu 2026. Dla zespołów IT oznacza to konkretne, wymierne zmiany: obowiązkowa dokumentacja techniczna, testowanie pod kątem stronniczości i odporności, mechanizmy nadzoru ludzkiego, kompleksowe logowanie, ciągły monitoring i cyberbezpieczeństwo specyficzne dla AI.
Organizacje, które zaczną przygotowania wcześniej, zyskują przewagę — nie tylko w kontekście uniknięcia kar sięgających 35 mln EUR lub 7% globalnego obrotu, ale przede wszystkim w budowaniu zaufania klientów i partnerów do swoich systemów AI. W dłuższej perspektywie dojrzałe podejście do zarządzania ryzykiem AI przekłada się na wyższą jakość systemów, mniejszą liczbę incydentów i lepsze wyniki biznesowe.
Kluczowe jest zrozumienie, że AI Act nie hamuje innowacji — wymusza odpowiedzialne podejście do AI, które powinno być standardem niezależnie od regulacji. Zespoły IT, które opanują wymagane kompetencje — od klasyfikacji ryzyka po adversarial testing i explainability — będą lepiej przygotowane nie tylko regulacyjnie, ale też technologicznie.
Jeśli chcesz przygotować swój zespół do wdrożenia wymagań AI Act, sprawdź ofertę szkoleń EITT z zakresu regulacji AI i compliance. Praktyczne warsztaty prowadzone przez ekspertów pomagają zespołom IT przejść od zrozumienia przepisów do konkretnego wdrożenia — z narzędziami, szablonami dokumentacji i gotowym planem działania.