Najczęstszy błąd popełnia się na samym początku: ktoś otwiera listę kontrolną AI Act, zanim w firmie ustalono, z ilu systemów AI ta firma faktycznie korzysta i w jakiej roli prawnej występuje. Audyt sprawdza wtedy to, co ktoś wpisał w ankiecie, i omija narzędzia, które weszły do organizacji przez kartę firmową, wtyczkę do przeglądarki i darmowy plan usługi SaaS.
Czym jest audyt zgodności AI i z czego się składa
Audyt zgodności AI to uporządkowane sprawdzenie, czy konkretne systemy AI — używane albo oferowane przez organizację — spełniają wymogi rozporządzenia (UE) 2024/1689, czyli AI Act, oraz przepisów, które się z nim zazębiają: RODO, prawa pracy i regulacji sektorowych. Składa się z sześciu kroków: inwentaryzacji systemów, ustalenia roli prawnej i klasy ryzyka, zebrania dowodów, testów sprawdzających, analizy luk wraz z planem naprawczym oraz raportu i przejścia do stałego nadzoru. Od zwykłego przeglądu odróżnia go jedno: kończy się dowodami — dokumentami, logami, zapisami z testów — a nie zapewnieniami właścicieli systemów.
Punkty odniesienia dla harmonogramu są dziś dwa. Obowiązki przejrzystości z art. 50 obowiązują od 2 sierpnia 2026 roku — tu nie ma już czego planować „na przyszłość”, zgodność trzeba umieć wykazać teraz. Wymogi dla samodzielnych systemów wysokiego ryzyka z załącznika III zaczną obowiązywać 2 grudnia 2027 roku (termin przesunięty przez przyjęty w czerwcu 2026 r. pakiet Digital Omnibus). Od tych dat planuje się wstecz — a nie od tego, kiedy zespół będzie miał wolne moce.
Warto od razu wyjaśnić jedno nieporozumienie. AI Act nie nakazuje „audytu” jako osobnej czynności i nie zna certyfikatu o nazwie „audyt zgodności AI”. Nakłada obowiązek wykazania zgodności przed organem nadzoru rynku. Audyt jest sposobem, żeby sprawdzić, czy w ogóle potrafisz to zrobić — zanim ktoś o to poprosi.
Krok 1. Zakres, czyli co w ogóle wchodzi do audytu
Zakres ustala się z danych, nie z deklaracji. Najpełniejszy obraz daje w praktyce sześć źródeł: logi logowań w systemie zarządzania tożsamością (SSO), wyciągi z kart firmowych i faktury, rejestr umów i zamówień, katalog aplikacji podpiętych do Microsoft 365 lub Google Workspace, lista rozszerzeń przeglądarki na komputerach służbowych oraz repozytoria kodu — biblioteki modeli i klucze API mówią więcej niż niejedna ankieta.
Przy każdym znalezionym narzędziu odpowiedz na trzy pytania rozstrzygające. Czy to system AI w rozumieniu art. 3 pkt 1 rozporządzenia? Pomagają tu wytyczne Komisji Europejskiej dotyczące definicji systemu AI. Czy funkcja AI nie siedzi przypadkiem w środku większego produktu — jak moduł oceniający kandydatów w systemie rekrutacyjnym? Czy korzystasz z modelu ogólnego przeznaczenia przez API? Jeśli tak, dochodzi cała warstwa obowiązków po stronie dostawcy modelu.
Efektem tego kroku jest lista systemów, w której przy każdej pozycji stoi nazwisko właściciela biznesowego, cel wykorzystania i podstawa prawna przetwarzania danych. Sposób jej prowadzenia opisaliśmy osobno w tekście o rejestrze systemów AI, a najczęstsze białe plamy — w materiale o shadow AI.
Krok 2. Rola prawna i klasa ryzyka
Bez tego kroku reszta audytu bada nie to, co trzeba. Rozporządzenie inaczej traktuje dostawcę, podmiot stosujący, importera, dystrybutora i upoważnionego przedstawiciela. Wiele firm wychodzi z założenia „jesteśmy tylko podmiotem stosującym” — i to założenie bywa błędne.
Uwaga na art. 25. Podmiot stosujący staje się dostawcą, z całym pakietem obowiązków, gdy opatrzy system własną nazwą lub znakiem towarowym, dokona w nim istotnej modyfikacji albo zmieni jego przeznaczenie tak, że system staje się systemem wysokiego ryzyka. Własny interfejs postawiony na cudzym modelu i sprzedawany klientom pod swoją marką to dokładnie ten przypadek.
Klasyfikacja ryzyka ma cztery kategorie: praktyki zakazane (art. 5), systemy wysokiego ryzyka (art. 6 w powiązaniu z załącznikami I i III), systemy objęte obowiązkami przejrzystości (art. 50 — chatboty, treści syntetyczne, deepfake) oraz cała reszta. Jeśli powołujesz się na wyłączenie z art. 6 ust. 3 — bo system pełni wyłącznie zadanie przygotowawcze albo wąską funkcję proceduralną — tę ocenę trzeba udokumentować. Sam wniosek „to nie jest wysokie ryzyko” dowodem nie jest. Szczegóły kwalifikacji rozwijamy w tekście o systemach AI wysokiego ryzyka.
Krok 3. Dowody — co audytor musi zobaczyć na własne oczy
Dowód zgodności ma trzy cechy: datę, autora i wersję. Prezentacja bez daty, polityka bez śladu zatwierdzenia i zrzut ekranu z ustawień to materiał pomocniczy, nie dowód.
| Obszar | Podstawa w AI Act | Dowód, którego szuka audytor | Kto zwykle go ma |
|---|---|---|---|
| Klasyfikacja systemu | art. 6, zał. III, art. 6 ust. 3 | podpisana ocena klasyfikacyjna z datą i uzasadnieniem | zgodność / właściciel systemu |
| Zarządzanie ryzykiem | art. 9 | rejestr ryzyk z powiązaniem ryzyko → środek → przegląd | zespół ryzyka |
| Dane i ich jakość | art. 10 | opis zbiorów, źródeł i badań pod kątem błędów systematycznych | zespół danych lub dostawca |
| Dokumentacja techniczna | art. 11 i zał. IV | dokumentacja z historią wersji, nie karta produktu z marketingu | dostawca |
| Rejestry zdarzeń | art. 12, art. 19, art. 26 ust. 6 | rzeczywiste logi za wymagany okres, nie sama konfiguracja | IT / bezpieczeństwo |
| Przejrzystość | art. 13, art. 50 | instrukcja obsługi, komunikat o kontakcie z AI, oznaczanie treści | produkt |
| Nadzór człowieka | art. 14, art. 26 ust. 2 | wyznaczone osoby, ich kompetencje i ślad realnych interwencji | operacje |
| Odporność i bezpieczeństwo | art. 15 | wyniki testów, w tym testów odpornościowych i red-teamingu | bezpieczeństwo IT |
| Kompetencje w zakresie AI | art. 4 | program szkoleń, zakres, listy uczestników | HR |
| Skutki dla praw podstawowych | art. 27 | ocena FRIA tam, gdzie jest wymagana | zgodność |
| Ocena zgodności i rejestracja | art. 43, 47, 48, 49 | deklaracja zgodności UE, oznakowanie CE, wpis do bazy UE | dostawca |
| Incydenty | art. 73 | procedura zgłaszania i rejestr zgłoszeń z terminami | zgodność / bezpieczeństwo |
Dwie liczby warto znać na pamięć, bo rozstrzygają spory o to, jak długo trzeba trzymać zapisy. Automatycznie generowane rejestry zdarzeń przechowuje się co najmniej sześć miesięcy — po stronie dostawcy (art. 19) i podmiotu stosującego (art. 26 ust. 6), o ile przepis szczególny nie wymaga dłuższego okresu. Dokumentację systemu wysokiego ryzyka dostawca trzyma dziesięć lat od wprowadzenia do obrotu lub oddania do użytku (art. 18).
Osobny wątek to dowody, których nie masz, bo leżą u dostawcy. Jeśli umowa nie daje ci prawa do dokumentacji technicznej, do informacji o zmianach modelu i do wsparcia przy incydencie, audyt kończy się luką w umowie. Jej zamknięcie trwa zwykle najdłużej z całego planu naprawczego, bo wymaga renegocjacji z drugą stroną, a nie decyzji wewnętrznej.
Krok 4. Testy zamiast deklaracji
Papier przyjmie wszystko. Najwięcej ujawniają trzy próby, a żadna z nich nie wymaga dostępu do kodu ani tygodni przygotowań.
Test odtworzenia decyzji. Wylosuj kilkanaście rzeczywistych spraw i poproś zespół, żeby odtworzył, jaki wynik zwrócił system, na której wersji modelu i co ten wynik zmienił w decyzji wobec konkretnej osoby. Przy systemach wysokiego ryzyka pamiętaj o art. 86 — osoba, której decyzja dotyczy, ma prawo dowiedzieć się, jaką rolę odegrał w niej system AI.
Test logów. Nie pytaj, czy logowanie jest włączone. Poproś o log konkretnej sprawy sprzed pięciu miesięcy. Bardzo często okazuje się, że rejestrowanie działa, ale okres przechowywania ktoś ustawił na trzydzieści dni.
Test nadzoru człowieka. Poproś o przypadek, w którym operator odrzucił rekomendację systemu. Jeśli nikt takiego przypadku nie potrafi wskazać i nikt tego nie liczy, nadzór istnieje wyłącznie w polityce. Sama polityka to za mało — jak piszemy w tekście o polityce AI w firmie, dokument bez mechanizmu kontroli nie dowodzi niczego poza tym, że ktoś go napisał.
Krok 5. Luki, ocena ryzyka i plan naprawczy
Luki porządkuj według dwóch kryteriów: co obowiązuje już dziś i co grozi najwyższą karą. Art. 99 przewiduje do 35 mln euro lub 7% światowego rocznego obrotu za praktyki zakazane, do 15 mln euro lub 3% za naruszenie większości pozostałych obowiązków oraz do 7,5 mln euro lub 1% za przekazanie organom informacji nieprawdziwych lub wprowadzających w błąd — liczy się kwota wyższa. Dla MŚP i startupów jest odwrotnie: stosuje się niższy z dwóch progów.
Każda luka powinna dostać właściciela z imienia i nazwiska, termin oraz opis dowodu, który zamknie sprawę. Zapis „wdrożyć nadzór człowieka” jest bezużyteczny. Zapis „do 30 września wyznaczyć dwóch operatorów, przeszkolić ich z art. 14 i uruchomić comiesięczny raport z liczbą odrzuconych rekomendacji” da się sprawdzić.
Krok 6. Raport i stały nadzór
Raport ma odpowiadać na trzy pytania zarządu: w których miejscach nie spełniamy przepisów, ile kosztuje doprowadzenie tego do porządku i kiedy sprawa będzie zamknięta. Reszta idzie w załączniki.
Potem audyt przechodzi w cykl: monitorowanie po wprowadzeniu do obrotu (art. 72, po stronie dostawcy), procedura zgłaszania poważnych incydentów (art. 73 — zgłoszenie natychmiast po ustaleniu związku przyczynowego, najpóźniej w ciągu 15 dni od powzięcia wiedzy, a przy najcięższych zdarzeniach odpowiednio 2 lub 10 dni) oraz ponowna ocena po każdej istotnej zmianie systemu.
Norma ISO/IEC 42001:2023 dobrze porządkuje ten cykl jako system zarządzania, a ISO/IEC 23894:2023 — samo zarządzanie ryzykiem AI. Z jednym zastrzeżeniem, i to istotnym: certyfikat ISO nie jest równoznaczny ze zgodnością z AI Act. Domniemanie zgodności dają dopiero normy zharmonizowane, które opracowuje CEN-CENELEC (komitet JTC 21); ich aktualny status sprawdzisz w Dzienniku Urzędowym UE i na stronach komitetu.
Ile to realnie trwa
Harmonogram planuj od terminu wstecz, a nie od tego, kiedy zespół znajdzie czas. Obowiązujące daty rozporządzenia: 2 lutego 2025 — praktyki zakazane i obowiązek zapewnienia kompetencji w zakresie AI; 2 sierpnia 2025 — obowiązki dostawców modeli ogólnego przeznaczenia oraz przepisy o organach i karach; 2 sierpnia 2026 — obowiązki przejrzystości z art. 50 (obowiązują) wraz z uprawnieniami egzekucyjnymi Komisji wobec dostawców GPAI; 2 grudnia 2027 — samodzielne systemy wysokiego ryzyka z załącznika III (termin przesunięty przez przyjęty w czerwcu 2026 r. Digital Omnibus); 2 sierpnia 2028 — systemy wysokiego ryzyka będące elementem bezpieczeństwa produktów z załącznika I (również po przesunięciu). Art. 111 przewiduje odrębne, późniejsze terminy dla systemów wprowadzonych do obrotu wcześniej oraz dla systemów używanych przez organy publiczne — ten przepis przeczytaj w oryginale, bo dla sektora publicznego bywa rozstrzygający.
Dochodzi do tego jedna porządkująca informacja: pakiet Digital Omnibus został ostatecznie przyjęty w czerwcu 2026 r. (Parlament Europejski 16 czerwca, Rada UE 29 czerwca) i to on odpowiada za przesunięte terminy dla systemów wysokiego ryzyka — nowe daty są wiążącym prawem, nie projektem. Szczegóły opisujemy w tekście o zmianach w AI Act.
Czas samego audytu zależy od czterech rzeczy: ile systemów obejmuje, czy rejestr już istnieje, czy występujesz jako dostawca (wtedy dochodzi dokumentacja techniczna i ocena zgodności) i — przede wszystkim — jak szybko dostawcy odpowiadają na pytania. Ta ostatnia zmienna zwykle rządzi całym kalendarzem, bo na formalne pytanie o dokumentację potrafisz czekać kilka tygodni. Publicznych, wiarygodnych danych porównawczych o czasochłonności audytów AI Act na razie nie ma, więc pierwszy audyt potraktuj jako pomiar: zmierz czas każdego etapu i dopiero na tej podstawie planuj kolejne.
W polskich realiach dochodzi jeszcze nadzór krajowy. Projekt ustawy o systemach sztucznej inteligencji, przygotowywany przez Ministerstwo Cyfryzacji, przewiduje powołanie krajowego organu nadzoru rynku; status prac śledź w wykazie prac legislacyjnych Rady Ministrów i na stronach Sejmu. Niezależnie od tego już dziś obowiązują przepisy równoległe: RODO wraz z oceną skutków dla ochrony danych, Kodeks pracy oraz obowiązek poinformowania przedstawicieli pracowników, zanim system wysokiego ryzyka trafi do użytku w miejscu pracy (art. 26 ust. 7), a w sektorze finansowym — wymogi KNF i rozporządzenie DORA.
Pięć powodów, dla których audyty AI się sypią
- Rejestr powstał z ankiety. Ankieta pokazuje narzędzia zatwierdzone, a nie używane. Zacznij od faktur i logów SSO.
- Źle ustalona rola. Firma bada się jako podmiot stosujący, choć przez zmianę przeznaczenia stała się dostawcą w rozumieniu art. 25.
- Dowód „na słowo dostawcy”. Zapewnienie o zgodności w materiale sprzedażowym nie zastąpi dokumentacji technicznej ani zapisu w umowie.
- Logi bez wymaganego okresu przechowywania. Rejestrowanie włączone, ale zapisy kasują się wcześniej, niż wymaga rozporządzenie.
- Audyt jednorazowy. Bez ponownej oceny po istotnej zmianie modelu raport przestaje opisywać system, który naprawdę działa.
Jeśli dopiero zaczynasz i nie wiesz, czy organizacja jest gotowa na pełne badanie, zacznij od lżejszego przeglądu opisanego w tekście o audycie gotowości AI. Do bieżącej pracy przyda się natomiast lista kontrolna AI Act.
Materiał ma charakter informacyjny i nie stanowi porady prawnej. Stan przepisów może się zmieniać — w razie wątpliwości skonsultuj się z prawnikiem.