Jak przygotować JSFP do kontroli zgodności z AI Act? Dokumenty, dowody i checklista audytowa

Przygotowanie jednostki sektora finansów publicznych (JSFP) do AI Act coraz mniej przypomina tworzenie kolejnej polityki, a coraz bardziej budowę systemu dowodowego.

Nie wystarczy powiedzieć:

„mamy procedurę AI”.

Trzeba umieć wykazać:

jakich systemów AI używamy → do czego → jak je zakwalifikowaliśmy → jakie obowiązki mają zastosowanie → kto za nie odpowiada → jakie mechanizmy wdrożyliśmy → czym możemy udowodnić, że rzeczywiście działają.

To szczególnie istotne po przyjęciu ustawy z 3 lipca 2026 r. o systemach sztucznej inteligencji. Ustawa utworzyła Komisję Rozwoju i Bezpieczeństwa Sztucznej Inteligencji i krajowe ramy nadzoru nad stosowaniem AI Act. Większość ustawy weszła w życie 11 sierpnia 2026 r., natomiast art. 8–18 oraz rozdziały 3–5, 8 i 9 zaczną obowiązywać 28 października 2026 r.

Na 4 września 2026 r. trwa więc organizacyjne uruchamianie krajowego systemu nadzoru, a szczególny tryb kontroli i postępowania przewidziany w polskiej ustawie jeszcze nie obowiązuje.

To dobry moment na przeprowadzenie audytu wstępnego.

Stan prawny: 4 września 2026 r.

Dokumenty opisane w artykule nie są ustawowym katalogiem

AI Act nie ustanawia ogólnego obowiązku prowadzenia dokumentów nazwanych:

• „rejestr AI”;
• „karta kwalifikacji”;
• „macierz obowiązków”;
• „centralne repozytorium dowodów”;
• „rejestr działań korygujących”.

Są to rekomendowane narzędzia organizacyjne, które pomagają przypisać obowiązki, utrzymywać aktualność informacji i wykazać rzeczywiste wykonanie wymagań.

Zakres dokumentacji powinien wynikać z:

roli jednostki → kwalifikacji systemu → konkretnego przypadku użycia → wykorzystywanych danych → wpływu na osoby → rzeczywiście mających zastosowanie przepisów.

Najpierw rozdziel obowiązki już stosowane od przyszłych

Jednym z pierwszych elementów przygotowania powinien być harmonogram obowiązków.

Nie wszystkie wymagania AI Act stosują się już dzisiaj.

Przykładowo:

• art. 4 dotyczący kompetencji w zakresie AI jest już stosowany;
• zasadnicza część zakazów z art. 5 jest już stosowana;
• art. 50 dotyczący transparentności jest co do zasady stosowany od 2 sierpnia 2026 r.;
• sekcje 1–3 rozdziału III, z wyjątkiem art. 6 ust. 5, będą stosowane od 2 grudnia 2027 r. dla systemów z art. 6 ust. 2 i załącznika III;
• te same sekcje dla systemów z art. 6 ust. 1 i załącznika I będą stosowane od 2 sierpnia 2028 r.

Wyjątek przejściowy dotyczący art. 50 ust. 2

Art. 50 wymaga dodatkowego zastrzeżenia.

Dostawcy systemów AI, w tym systemów AI ogólnego przeznaczenia, generujących syntetyczne treści audio, obrazy, wideo lub tekst, które zostały wprowadzone do obrotu przed 2 sierpnia 2026 r., mają czas do 2 grudnia 2026 r. na zapewnienie zgodności z technicznym obowiązkiem oznaczania wyników z art. 50 ust. 2.

Nie jest to przesunięcie stosowania całego art. 50.

W macierzy obowiązków warto więc stosować trzy statusy:

Systemy istniejące – sprawdź art. 111

Daty 2027 i 2028 nie oznaczają, że każdy starszy system automatycznie zostanie objęty pełnym zestawem obowiązków w tych dniach.

Art. 111 ust. 2 przewiduje szczególny reżim przejściowy dla systemów wysokiego ryzyka wprowadzonych do obrotu lub oddanych do użytku przed właściwą datą rozpoczęcia stosowania rozdziału III. Co do zasady znaczenie ma to, czy po tej dacie system zostanie poddany znaczącym zmianom konstrukcji.

Jednocześnie dostawcy i podmioty stosujące systemy wysokiego ryzyka przeznaczone do używania przez organy publiczne mają podjąć niezbędne działania zapewniające zgodność najpóźniej do 2 sierpnia 2030 r.

Dlatego rejestr powinien uwzględniać także historię istotnych zmian systemu, jego przeznaczenia i konfiguracji.

Jak może wyglądać krajowa kontrola?

Od 28 października 2026 r. zastosowanie znajdzie rozdział 3 polskiej ustawy dotyczący kontroli.

Ustawa przewiduje prowadzenie kontroli m.in. zgodnie z planem, na podstawie pozyskanych informacji oraz w ramach monitorowania przestrzegania przepisów.

W praktyce oznacza to, że jednostka nie powinna zakładać, iż kontrola nastąpi wyłącznie według z góry znanego harmonogramu.

Kontrolujący może zajrzeć dalej niż do „teczki AI”

Ustawowe uprawnienia kontrolne pozwalają badać nie tylko specjalnie przygotowaną dokumentację zgodności.

Przedmiotem żądania mogą być w szczególności:

• dokumenty i materiały związane z kontrolą;
• korespondencja elektroniczna;
• dane znajdujące się na urządzeniach i nośnikach;
• systemy informatyczne i teleinformatyczne;
• w określonych przypadkach również dane przechowywane w chmurze, do których kontrolowany posiada dostęp;
• informacje, zestawienia i wyjaśnienia.

Najważniejszy praktyczny wniosek brzmi:

dokumentację zgodności będzie można porównać z rzeczywistym sposobem używania AI.

Jeżeli procedura mówi jedno, a konfiguracja, logi czy korespondencja pokazują coś innego, problemem nie jest już jedynie jakość dokumentacji.

1. Rejestr AI – audyt zaczyna się od inwentaryzacji

Pierwsze pytanie powinno brzmieć:

Jakich systemów i przypadków użycia AI jednostka rzeczywiście używa?

Nie wystarczy lista produktów.

Rejestr powinien rozróżniać:

produkt → konfigurację i środowisko → przypadek użycia → proces organizacyjny.

Ten sam produkt może być używany do korekty językowej dokumentów, analizy danych albo wspomagania decyzji dotyczących osób. Są to regulacyjnie różne przypadki.

Przykładowe pola rejestru

Audyt powinien porównać rejestr z licencjami, logowaniem SSO, umowami, usługami chmurowymi, integracjami i rzeczywistą praktyką pracowników.

Największym ryzykiem może być system, którego w rejestrze w ogóle nie ma.

2. Karta kwalifikacji – nie wystarczy „niskie ryzyko”

Dla istotnych przypadków użycia warto zachować tok kwalifikacji:

czy rozwiązanie jest systemem AI → jaka jest rola jednostki → czy występuje art. 5 → czy zastosowanie mieści się w art. 6 lub załączniku III → czy występuje art. 50 → jakie znaczenie ma RODO → czy obowiązują dalsze przepisy sektorowe.

Prawidłowe pytanie audytowe brzmi więc:

Na jakiej podstawie uznano, że dany przypadek użycia nie spełnia przesłanek systemu wysokiego ryzyka?

Kwalifikacja powinna dotyczyć przede wszystkim zamierzonego przeznaczenia i rzeczywistego przypadku użycia, a nie nazwy handlowej produktu.

Role regulacyjne trzeba nazywać precyzyjnie

AI Act definiuje m.in.:

• dostawcę;
• podmiot stosujący;
• producenta produktu;
• upoważnionego przedstawiciela;
• importera;
• dystrybutora.

„Integrator” może być ważną rolą techniczną lub umowną, ale nie jest odrębną kategorią operatora z art. 3 AI Act.

Trzeba również sprawdzić, czy modyfikacja systemu, używanie go pod własną nazwą lub zmiana jego zamierzonego przeznaczenia może doprowadzić do przejęcia obowiązków dostawcy na podstawie art. 25.

3. Macierz obowiązków – pokaż, dlaczego czegoś nie wykonano

Po kwalifikacji przydatna jest macierz:

Taki dokument pozwala odpowiedzieć zarówno:

„Co wykonaliśmy?”

jak i:

„Dlaczego dany obowiązek w tym przypadku nie znajduje zastosowania?”

4. FRIA, DPIA i inne oceny – odrębne testy, nie jeden formularz

DPIA wynika z art. 35 RODO.

FRIA z art. 27 AI Act ma własne przesłanki. Dotyczy m.in. podmiotów stosujących będących podmiotami prawa publicznego oraz określonych innych podmiotów i zastosowań wskazanych w przepisie.

Samo zakwalifikowanie organizacji jako JSFP na podstawie polskiej ustawy o finansach publicznych nie przesądza automatycznie o powstaniu obowiązku FRIA.

Teczka systemu może więc zawierać:

• analizę konieczności DPIA;
• DPIA, jeżeli jest wymagana;
• analizę przesłanek FRIA;
• FRIA, gdy obowiązek znajduje zastosowanie;
• ocenę bezpieczeństwa;
• analizę dopuszczalności użycia AI w konkretnym procesie;
• dodatkowe oceny wymagane prawem sektorowym.

Kluczowy jest udokumentowany wynik testu obowiązku, a nie liczba formularzy.

5. Dokumentacja dostawcy – czego jednostka naprawdę powinna oczekiwać?

Trzeba rozdzielić trzy warstwy informacji.

Informacje potrzebne podmiotowi stosującemu

W przypadku systemu wysokiego ryzyka podmiot stosujący powinien przede wszystkim otrzymać informacje i instrukcję potrzebne do właściwego używania systemu.

Istotne mogą być m.in.:

• zamierzone przeznaczenie;
• możliwości i ograniczenia;
• informacje dotyczące jakości działania i właściwych miar;
• znane ryzyka;
• informacje potrzebne do interpretacji wyniku;
• środki nadzoru człowieka;
• zasady logowania, utrzymania i używania systemu.

Informacje zabezpieczane kontraktowo

W ramach zakupu i należytej staranności JSFP może dodatkowo wymagać m.in.:

• informacji o istotnych podwykonawcach;
• zasad powiadamiania o zmianach;
• współpracy podczas incydentów;
• prawa audytu;
• zasad migracji;
• możliwości eksportu danych i logów;
• określonych informacji dotyczących bezpieczeństwa.

Nie jest to automatycznie katalog informacji należnych podmiotowi stosującemu z jednego przepisu AI Act. Są to przede wszystkim mechanizmy kontraktowe potrzebne do wykonywania własnych obowiązków jednostki.

Dokumentacja utrzymywana przez dostawcę dla organów

Pełna dokumentacja techniczna z art. 11 pozostaje przede wszystkim obowiązkiem dostawcy i ma umożliwiać wykazywanie zgodności wobec właściwych organów oraz – gdy ma to zastosowanie – jednostek uczestniczących w ocenie zgodności.

Nie należy automatycznie zakładać, że JSFP jako podmiot stosujący ma prawo otrzymać całą tę dokumentację.

Pytanie audytowe powinno zatem brzmieć:

Czy jednostka posiada informacje wystarczające do zgodnego i bezpiecznego używania systemu oraz wykonywania własnych obowiązków?

6. Art. 50 – audytuj obowiązek po właściwej stronie

Transparentność dobrze pokazuje, dlaczego określenie roli jest tak ważne.

Audyt nie powinien więc ograniczać się do pytania:

„Czy spełniliśmy art. 50?”

Lepsze pytanie to:

„Kto jest adresatem obowiązku w tym konkretnym wdrożeniu, kto faktycznie go wykonuje i jaki dowód posiada JSFP?”

Przy zakupionym chatbocie odpowiedzialność projektowa za mechanizm informacyjny może spoczywać na dostawcy, ale JSFP powinna sprawdzić, czy komunikat rzeczywiście funkcjonuje w używanym środowisku.

W odniesieniu do technicznego oznaczania syntetycznych treści trzeba również uwzględnić termin przejściowy 2 grudnia 2026 r. z art. 111 ust. 4.

7. Kompetencje – art. 4 to więcej niż lista obecności

Art. 4 jest już stosowany.

Po zmianach z 2026 r. dostawcy i podmioty stosujące mają podejmować środki wspierające rozwój kompetencji w zakresie AI, z uwzględnieniem m.in. wiedzy, doświadczenia, wykształcenia, szkolenia oraz kontekstu stosowania.

Audyt powinien więc sprawdzić:

• kogo objęto działaniami;
• dlaczego wybrano taki zakres;
• czy działania odpowiadają rzeczywiście używanym systemom;
• czy osoby nadzorujące system otrzymały właściwe przygotowanie;
• co dzieje się po zmianie zastosowania lub systemu.

Dowodem mogą być szkolenia, warsztaty, instrukcje, materiały stanowiskowe czy testy wiedzy – zależnie od potrzeb.

8. Uprawnienia – porównaj regulamin z rzeczywistością

Audyt powinien sprawdzić:

• kto ma dostęp do narzędzia;
• kto może wykorzystywać dane wewnętrzne lub osobowe;
• kto może aktywować integracje;
• kto może dodawać źródła danych;
• kto może zmieniać konfigurację;
• kto może publikować wyniki;
• kto zatwierdza nowe zastosowania.

Jeżeli procedura przewiduje dostęp dla konkretnej grupy, a system pokazuje wielokrotnie większą liczbę aktywnych kont, należy wyjaśnić różnicę.

Dokument niezgodny z praktyką zwiększa ryzyko, ponieważ utrwala deklarację, której jednostka faktycznie nie realizuje.

9. System wysokiego ryzyka – dodatkowa checklista dla JSFP objętej obowiązkami podmiotu stosującego

Przed zastosowaniem tej części trzeba ustalić status konkretnej jednostki na potrzeby danego przepisu.

JSFP, „organ publiczny”, „podmiot prawa publicznego” oraz „podmiot prywatny świadczący usługi publiczne” nie są kategoriami, które można automatycznie stosować zamiennie.

Przykładowo:

• art. 26 ust. 8 odnosi się do określonych podmiotów stosujących będących organami publicznymi;
• art. 27 posługuje się m.in. kategorią podmiotów prawa publicznego;
• art. 49 ustanawia szczególne reguły rejestracji;
• art. 111 ust. 2 odnosi się do systemów wysokiego ryzyka przeznaczonych do używania przez organy publiczne.

Zakwalifikowanie jednostki jako JSFP na podstawie prawa krajowego nie przesądza automatycznie jej statusu we wszystkich tych przepisach.

Używanie zgodnie z instrukcją

Czy system jest wykorzystywany zgodnie z instrukcją dostawcy i w granicach jego zamierzonego przeznaczenia?

Nadzór człowieka

Czy nadzór powierzono osobom posiadającym odpowiednie kompetencje, szkolenie, uprawnienia i wsparcie?

Monitoring i zawieszenie używania

Jeżeli używanie systemu zgodnie z instrukcją może prowadzić do ryzyka w rozumieniu art. 79 ust. 1, podmiot stosujący powinien bez zbędnej zwłoki poinformować dostawcę lub dystrybutora oraz właściwy organ nadzoru rynku i zawiesić używanie systemu.

Poważne incydenty

Po zidentyfikowaniu poważnego incydentu podmiot stosujący powinien niezwłocznie poinformować najpierw dostawcę, a następnie importera lub dystrybutora oraz właściwy organ nadzoru rynku, zgodnie z art. 26 ust. 5.

Jeżeli podmiot stosujący nie może skontaktować się z dostawcą, art. 73 stosuje się odpowiednio.

Nie należy więc przedstawiać art. 73 jako standardowego, samodzielnego obowiązku pełnego zgłoszenia każdego poważnego incydentu przez podmiot stosujący. Podstawowy mechanizm dla podmiotu stosującego wynika w tym miejscu z art. 26 ust. 5.

JSFP jako dostawca – odrębny obowiązek z art. 73

Jeżeli w konkretnym wdrożeniu JSFP pełni rolę dostawcy systemu AI wysokiego ryzyka, art. 73 nakłada na nią odrębny obowiązek zgłaszania poważnych incydentów organowi nadzoru rynku państwa członkowskiego, w którym incydent wystąpił. Przepis ten jest stosowany od 2 sierpnia 2026 r.; jego praktyczne uruchomienie wymaga ustalenia, że chodzi o system wysokiego ryzyka objęty właściwym reżimem kwalifikacji.

Zgłoszenia dokonuje się natychmiast po ustaleniu związku przyczynowego albo dostatecznie wysokiego prawdopodobieństwa takiego związku, nie później niż:

• 15 dni – co do zasady;
• 2 dni – w przypadku powszechnego naruszenia albo poważnego incydentu dotyczącego naruszenia obowiązków prawa Unii służących ochronie praw podstawowych;
• 10 dni – jeżeli nastąpiła śmierć osoby.

Gdy jest to potrzebne do dochowania terminu, można przekazać zgłoszenie wstępne, a następnie zgłoszenie kompletne. Po zgłoszeniu dostawca niezwłocznie prowadzi postępowanie wyjaśniające, ocenę ryzyka i działania naprawcze oraz współpracuje z właściwymi organami.

Logi

Automatycznie generowane logi pozostające pod kontrolą podmiotu stosującego mają być przechowywane przez okres odpowiedni do przeznaczenia systemu, co do zasady co najmniej sześć miesięcy, chyba że inne właściwe przepisy przewidują inny okres.

Pracownicy

Jeżeli system wysokiego ryzyka ma być stosowany w miejscu pracy, pracodawca powinien – w przypadkach objętych art. 26 ust. 7 – poinformować przedstawicieli pracowników oraz pracowników objętych stosowaniem systemu.

Rejestracja publicznego podmiotu stosującego

Przed oddaniem do użytku lub rozpoczęciem wykorzystywania systemu AI wysokiego ryzyka wymienionego w załączniku III – z wyjątkiem systemów wskazanych w pkt 2 tego załącznika – podmioty stosujące będące organami publicznymi, wskazanymi podmiotami Unii albo osobami działającymi w ich imieniu muszą spełnić obowiązki rejestracyjne określone w art. 49 ust. 3.

Obejmuje to odpowiednio rejestrację podmiotu, wybór właściwego systemu oraz zarejestrowanie jego wykorzystania w bazie UE.

Odrębny mechanizm przewiduje art. 26 ust. 8.

Jeżeli podmiot objęty tym przepisem ustali, że system wysokiego ryzyka, który zamierza wykorzystywać, nie został zarejestrowany w bazie UE, nie stosuje tego systemu i informuje o tym dostawcę lub dystrybutora.

Trzeba więc rozróżnić:

1. własny obowiązek rejestracyjny podmiotu stosującego z art. 49 ust. 3;
2. obowiązek sprawdzenia rejestracji systemu i powstrzymania się od używania z art. 26 ust. 8.

Decyzje dotyczące osób

Jeżeli system z załącznika III podejmuje albo wspiera podejmowanie decyzji dotyczących osoby fizycznej, trzeba również przeanalizować obowiązki informacyjne wynikające z art. 26 ust. 11.

Dobrze przygotowana jednostka powinna więc posiadać odpowiedź nie tylko na pytanie:

„Jak korzystamy z systemu?”

ale także:

„Co robimy, gdy system przestaje zachowywać się zgodnie z założeniami albo pojawia się ryzyko dla osób?”

10. Nadzór człowieka – pokaż funkcję, nie deklarację

Dla właściwych zastosowań audyt powinien sprawdzić:

• kto nadzoruje wynik;
• jakie ma kompetencje;
• czy rozumie ograniczenia systemu;
• czy widzi informacje potrzebne do własnego osądu;
• czy może odrzucić albo zignorować rekomendację;
• czy może eskalować problem;
• czy może doprowadzić do zatrzymania systemu;
• jak ograniczane jest nadmierne poleganie na wyniku automatycznym (automation bias);
• czy ingerencja człowieka pozostawia adekwatny ślad.

Dowodem nadzoru nie jest samo zdanie:

„ostatecznie decyduje człowiek”.

Znacznie więcej mówi rzeczywista konfiguracja systemu oraz możliwość pokazania przykładowego przebiegu sprawy.

11. Logi i możliwość odtworzenia zdarzenia

Audyt powinien sprawdzić:

• jakie zdarzenia system zapisuje;
• czy można je powiązać z konkretnym użyciem;
• kto ma dostęp;
• czy logi są zabezpieczone przed nieuprawnioną zmianą;
• jak długo są przechowywane;
• czy retencja pozostaje zgodna także z zasadami ochrony danych;
• czy możliwy jest eksport;
• co stanie się z logami po zakończeniu umowy.

Nie należy utożsamiać obowiązku logowania z koniecznością przechowywania pełnej treści każdego promptu, dokumentu albo wszystkich danych wejściowych.

Zakres retencji należy uzgodnić również z zasadą minimalizacji danych.

12. Incydenty i działania korygujące

Audyt powinien badać nie tylko liczbę problemów, lecz sposób reagowania.

Przydatny model:

zdarzenie → ocena wpływu → właściciel → działanie korygujące → termin → weryfikacja skuteczności.

Rejestr może obejmować m.in.:

• błąd systematyczny;
• niedozwolone wykorzystanie danych;
• zmianę modelu lub konfiguracji;
• pogorszenie działania;
• problem bezpieczeństwa;
• skargę osoby;
• nietypowo wysoki poziom odrzucania rekomendacji;
• niezgodność wykrytą podczas audytu.

Dojrzałość organizacji widać nie po braku wpisów, lecz po możliwości wykazania:

wykryliśmy problem → oceniliśmy go → ograniczyliśmy ryzyko → wdrożyliśmy poprawkę → sprawdziliśmy jej skuteczność.

Centralne repozytorium dowodów zgodności

Jednostka nie musi przechowywać wszystkiego w jednym katalogu.

Powinna jednak potrafić szybko wskazać:

Każdy kluczowy dowód powinien mieć:

• właściciela;
• lokalizację;
• datę aktualności;
• termin albo zdarzenie powodujące ponowny przegląd.

Test spójności – najważniejsza część audytu wstępnego

Najbardziej wartościowe pytanie brzmi:

Czy dokumentacja zgadza się z rzeczywistością?

To właśnie ten test przesuwa audyt z poziomu:

„mamy dokument”

na poziom:

„potrafimy wykazać, że mechanizm działa”.

Checklista audytowa JSFP

Poniższa lista jest narzędziem wewnętrznym, a nie formularzem ustanowionym przez Komisję.

Inwentaryzacja i kwalifikacja

• ☐ Czy istnieje aktualny rejestr systemów i przypadków użycia AI?
• ☐ Czy porównano go z rzeczywistymi licencjami, usługami i integracjami?
• ☐ Czy dla istotnych zastosowań wykonano kwalifikację?
• ☐ Czy sprawdzono praktyki zakazane z art. 5?
• ☐ Czy przeanalizowano art. 6 i załącznik III?
• ☐ Czy określono właściwe role regulacyjne?
• ☐ Czy sprawdzono możliwość przejęcia roli dostawcy wskutek modyfikacji, rebrandingu lub zmiany przeznaczenia?

Obowiązki i oceny

• ☐ Czy istnieje macierz obowiązków i terminów?
• ☐ Czy wykonano test konieczności DPIA?
• ☐ Czy oceniono przesłanki FRIA?
• ☐ Czy rozdzielono obowiązki stosowane obecnie od przyszłych planów zgodności?
• ☐ Czy w przypadku starszych systemów przeanalizowano art. 111?

Organizacja

• ☐ Czy każdy istotny system ma właściciela biznesowego?
• ☐ Czy określono zakres dopuszczonego użycia?
• ☐ Czy rzeczywiste uprawnienia odpowiadają procedurom?
• ☐ Czy działania rozwijające kompetencje odpowiadają rolom i przypadkom użycia?

Transparentność

• ☐ Czy ustalono, które obowiązki art. 50 spoczywają na dostawcy, a które na podmiocie stosującym?
• ☐ Czy istnieją dowody wykonania obowiązków już stosowanych?
• ☐ Czy przy art. 50 ust. 2 uwzględniono przepis przejściowy do 2 grudnia 2026 r.?

Dostawcy i zmiany

• ☐ Czy jednostka posiada informacje potrzebne do właściwego używania systemu?
• ☐ Czy umowa zapewnia właściwe mechanizmy współpracy i powiadamiania o zmianach?
• ☐ Czy zidentyfikowano używany model, wersję lub wariant usługi w zakresie, w jakim informacje te są dostępne i istotne dla oceny?
• ☐ Czy istotna zmiana systemu uruchamia ponowną kwalifikację?

Systemy wysokiego ryzyka – gdy obowiązki mają zastosowanie

• ☐ Czy ustalono status JSFP na potrzeby konkretnego przepisu?
• ☐ Czy system jest używany zgodnie z instrukcją?
• ☐ Czy wskazano osoby sprawujące nadzór?
• ☐ Czy mają kompetencje, szkolenie, uprawnienia i wsparcie?
• ☐ Czy określono procedurę zawieszenia używania systemu w przypadku ryzyka?
• ☐ Czy procedura poważnych incydentów odpowiada art. 26 ust. 5?
• ☐ Czy wiadomo, kiedy art. 73 będzie stosowany odpowiednio?
• ☐ Czy w przypadku systemu z załącznika III sprawdzono, czy JSFP podlega obowiązkowi rejestracji z art. 49 ust. 3, z uwzględnieniem przewidzianych tam wyjątków?
• ☐ Czy podmiot objęty art. 26 ust. 8 sprawdził, czy system został prawidłowo zarejestrowany w bazie UE?
• ☐ Czy wykonano obowiązki informacyjne wobec pracowników, jeżeli mają zastosowanie?
• ☐ Czy określono retencję logów?
• ☐ Czy istnieje plan działania w razie zawieszenia, niedostępności albo wycofania systemu?

Dowody i działania korygujące

• ☐ Czy jednostka potrafi wyeksportować potrzebne logi?
• ☐ Czy działa procedura zgłaszania błędów i incydentów?
• ☐ Czy działania korygujące mają właściciela i termin?
• ☐ Czy po wykonaniu korekty badana jest jej skuteczność?
• ☐ Czy dokumentacja jest aktualizowana po zmianach?
• ☐ Czy wiadomo, kto koordynuje działania jednostki podczas kontroli?

Próba kontrolna – najlepszy test gotowości

Warto wybrać jeden rzeczywiście używany system – najlepiej taki, który przetwarza dane osobowe, komunikuje się z mieszkańcami albo wpływa na istotny proces – i wydać zespołowi polecenie:

„Pokażcie pełną ścieżkę zgodności tego zastosowania.”

Powinno być możliwe przejście przez:

rejestr → kwalifikację → role → obowiązki → dane → dostawcę → uprawnienia → kompetencje → transparentność → nadzór → logi → incydenty → zmiany → ostatni przegląd.

Jeżeli zebranie tych informacji wymaga tygodnia i kontaktu z kilkunastoma osobami, organizacja nie jest jeszcze wystarczająco audytowalna.

Pięć pytań kierownika przed kontrolą

Kierownik nie musi znać numerów wszystkich artykułów AI Act.

Powinien jednak otrzymać aktualną odpowiedź na pięć pytań:

1. Jakie systemy AI rzeczywiście wykorzystujemy?
2. Które przypadki użycia mają największy profil ryzyka i dlaczego?
3. Jakie obowiązki dotyczą nas już teraz, a do jakich się przygotowujemy?
4. Czy potrafimy wykazać wykonanie tych obowiązków rzeczywistymi dowodami?
5. Jakie niezgodności pozostają otwarte, kto za nie odpowiada i kiedy zostaną usunięte?

Podsumowanie

Przygotowanie do kontroli AI Act nie polega na stworzeniu pakietu dokumentacji zgodności.

Polega na zbudowaniu łańcucha dowodowego:

wiemy, jakie AI mamy → wiemy, jak je zakwalifikowaliśmy → wiemy, jakie obowiązki mają zastosowanie → wdrożyliśmy środki → mamy dowody ich działania → wykrywamy odstępstwa → korygujemy je → sprawdzamy skuteczność korekty.

Polska ustawa powoduje, że krajowy nadzór nie jest już abstrakcyjnym scenariuszem. Ramy instytucjonalne zostały ustanowione, a szczególny krajowy tryb kontroli zacznie obowiązywać 28 października 2026 r.

Najważniejsza zasada dla JSFP brzmi:

Nie przygotowuj dokumentacji „na kontrolę”. Zorganizuj używanie AI tak, aby dokumentacja była naturalnym śladem rzeczywistych decyzji, zabezpieczeń, kontroli i działań korygujących.

Podstawy prawne

• AI Act – tekst skonsolidowany na 27 lipca 2026 r.
• Rozporządzenie (UE) 2026/1744 zmieniające AI Act
• Ustawa z 3 lipca 2026 r. o systemach sztucznej inteligencji – Dz.U. 2026 poz. 1003
• Pierwotny tekst rozporządzenia (UE) 2024/1689