Stan prawny na dzień: 16 października 2026 r.
W systemach bezpieczeństwa można precyzyjnie wskazać cztery elementy architektury ułatwiające nadzór nad AI: logi, rzeczywista kontrola człowieka, dokumentacja i ocena ryzyka przed uruchomieniem. W systemach wysokiego ryzyka wiążą się z nimi konkretne obowiązki dostawcy i podmiotu stosującego. W pozostałych zastosowaniach mogą one stanowić dobrą praktykę, która ułatwia analizę incydentów i wyjaśnienie działania systemu. Warto uwzględnić je już w projekcie, ponieważ późniejsze uzupełnianie architektury może być trudniejsze i generować dodatkowe koszty.
Obowiązek czy dobra praktyka?
Opisane wymagania pochodzą z rozdziału III AI Act, określającego zasady kwalifikacji systemów wysokiego ryzyka. Art. 6 odsyła do załącznika III (wykaz zastosowań) i załącznika I (prawodawstwo harmonizacyjne). Wymagania sekcji 1–3 stosuje się od 2 grudnia 2027 r. dla systemów z art. 6 ust. 2, a od 2 sierpnia 2028 r. - dla systemów z art. 6 ust. 1.
Nie każdy system z załącznika III jest systemem wysokiego ryzyka - art. 6 ust. 3 przewiduje wyjątek wymagający braku znaczącego ryzyka szkody i spełnienia co najmniej jednej z przesłanek z tego przepisu; wyjątek nie obejmuje systemów profilujących osoby fizyczne.
Zmiana funkcji, przeznaczenia lub warunków użycia może wymagać ponownej oceny, a logi, procedury i dokumentacja przydają się także przy incydencie, audycie RODO, reklamacji lub sporze. Spełnienie wymagań AI Act nie zastępuje obowiązków wynikających z przepisów o ochronie danych ani innych przepisów mających zastosowanie do organizacji.
1. Rejestrowanie zdarzeń i wyników
Logi powinny odtwarzać przebieg zdarzeń zarejestrowanych lub analizowanych przez system. Art. 12 wymaga, aby system wysokiego ryzyka technicznie umożliwiał automatyczne rejestrowanie zdarzeń przez cały okres działania — to nie oznacza obowiązku zapisywania wszystkich danych wejściowych ani przechowywania wszystkich logów przez cały okres działania systemu.
Podmiot stosujący przechowuje automatycznie wygenerowane logi, w zakresie pozostającym pod jego kontrolą, co najmniej sześć miesięcy, chyba że inne przepisy stanowią inaczej (art. 26 ust. 6). To nie oznacza automatycznej sześciomiesięcznej retencji wszystkich nagrań — zakres i okres retencji ustala się odrębnie.
W praktyce projektowej warto zadbać o:
- wspólny czas — zsynchronizowane zegary kamer, kontrolerów i platformy,
- wynik z kontekstem — alarm wraz z regułą i wersją konfiguracji,
- reakcja operatora — kto i kiedy potwierdził, odrzucił albo pominął alarm,
- integralność — ochrona logów przed zmianą i usunięciem,
- retencja zgodna z RODO — okres dopasowany do celu zbioru.
2. Rzeczywisty udział człowieka
Nadzór wymaga określonej roli, uprawnień, dostępu do informacji i procedury — nie wystarczy obecność przy konsoli ani bezkrytyczne zatwierdzanie alarmów. Czynność nadzorcza powinna być świadoma, zgodna z ustaloną procedurą i proporcjonalna do ryzyka, autonomii i kontekstu użycia.
Art. 14 wymaga, aby system wysokiego ryzyka umożliwiał skuteczny nadzór: rozumienie możliwości i ograniczeń systemu, poprawną interpretację wyników, świadomość ryzyka nadmiernego polegania na nich oraz możliwość pominięcia lub zmiany wyniku, interwencji albo zatrzymania systemu w sposób prowadzący do bezpiecznego stanu. Moduły rozwijające tę umiejętność obejmują szkolenia Akademii Technologii C&C Partners.
W systemach wysokiego ryzyka służących zdalnej identyfikacji biometrycznej identyfikację muszą oddzielnie zweryfikować i potwierdzić co najmniej dwie osoby posiadające wymagane kompetencje, przeszkolenie i uprawnienia, zanim stanie się ona podstawą działania lub decyzji. Art. 14 ust. 5 przewiduje szczególne wyjątki dla określonych zastosowań związanych ze ściganiem przestępstw, migracją, kontrolą graniczną i azylem, na warunkach wskazanych w przepisie.
Z tego wynikają pytania:
- Czy operator widzi, dlaczego pojawił się alarm — strefę, regułę, poziom pewności?
- Czy obciążenie pozwala na realną weryfikację, czy sprzyja zatwierdzaniu bez sprawdzania?
- Czy uprawniona osoba może odrzucić wynik, przejąć kontrolę lub bezpiecznie zatrzymać funkcję zgodnie z procedurą?
- Czy procedura mówi, co zrobić z alarmem niepewnym, sprzecznym lub nietypowym?
3. Opis działania systemu
AI Act rozróżnia dokumentację techniczną dostawcy (art. 11, załącznik IV), sporządzaną przed wprowadzeniem systemu do obrotu lub oddaniem do użytku i aktualizowaną, oraz instrukcję użytkowania (art. 13) z informacjami dla podmiotu stosującego o właściwym użyciu i nadzorze.
Gdy komponenty pochodzą od różnych producentów, kluczowa jest dokumentacja integracji: włączone funkcje, reguły i odpowiedzialność za konfigurację.
Integrator może przejąć obowiązki dostawcy, jeżeli dokona istotnej zmiany systemu wysokiego ryzyka, który po zmianie nadal należy do tej kategorii. Zgodnie z art. 3 pkt 23 chodzi o zmianę nieprzewidzianą w pierwotnej ocenie zgodności, wpływającą na zgodność z wymaganiami albo zmieniającą oceniane przeznaczenie. Art. 25 obejmuje też zmianę przeznaczenia systemu wcześniej niekwalifikowanego jako wysokiego ryzyka, jeżeli staje się on takim systemem — dlatego warto dokumentować zakres zmian i sprawdzać ich zgodność z dokumentacją dostawcy.
4. Ocena przed wdrożeniem
Przed uruchomieniem trzeba ustalić, które mechanizmy oceny mają zastosowanie.
W uproszczeniu: FRIA (art. 27) dotyczy wpływu na prawa podstawowe, DPIA (art. 35 RODO) — ryzyk dla prywatności i danych; nie są zamienne, choć mogą współdzielić ustalenia. Pełna lista zobowiązanych podmiotów i wyłączeń jest w art. 27.
Dobra ocena odpowiada na cztery pytania:
- Fałszywy alarm - kto zostanie zatrzymany, sprawdzony albo niewpuszczony?
- Niewykryte zdarzenie - jakie zabezpieczenie działa niezależnie od AI?
- Złe dane - co przy zasłoniętej kamerze, mgle albo w nocy?
- Odpowiedzialność - kto odpowiada za decyzję podjętą na podstawie wyniku i czy o tym wie?
Dlaczego nazywamy to podejście „accountability by design”
„Accountability by design” to przyjęta w artykule nazwa podejścia projektowego — nie odrębny wymóg z AI Act czy RODO. Art. 86 w określonych przypadkach przyznaje prawo do wyjaśnienia roli systemu AI w decyzji i jej głównych elementów — nie ogólne prawo do wyjaśnienia każdego wyniku.
Nie warto odkładać projektowania nadzoru do czasu zakończenia prac normalizacyjnych. Odniesienie do EN 18286:2026, dotyczącej systemu zarządzania jakością na potrzeby art. 17 AI Act, opublikowano w Dzienniku Urzędowym UE 14 października 2026 r. Stosowanie normy może ułatwić wykazanie zgodności z wymaganiami, które obejmuje, ale nie zastępuje oceny zgodności całego systemu z pozostałymi obowiązkami AI Act.
W systemach wysokiego ryzyka mechanizmy nadzoru, rejestrowania zdarzeń i dokumentowania należy uwzględnić już na etapie projektowania. Późniejsze aktualizacje mogą je rozwijać, ale nie zastępują wymagań obowiązujących przy wprowadzeniu systemu do obrotu lub oddaniu go do użytku. W pozostałych systemach podobne podejście może być dobrą praktyką.
Już w kolejnym artykule: dlaczego infrastruktura krytyczna wymaga szczególnej uwagi. Jeśli chcesz omówić architekturę swojego systemu już teraz, porozmawiaj z naszym zespołem.
FAQ - Najczęstsze pytania
Co to znaczy „system AI gotowy do audytu”?
To system, którego logi, dokumentacja i procedury pozwalają w odpowiednim zakresie odtworzyć przebieg zdarzenia oraz wyjaśnić rolę AI w decyzji.
Czy logi systemu wystarczą do wykazania zgodności z AI Act?
Nie. Logi to jeden z elementów. Znaczenie mają też dokumentacja, rzeczywisty nadzór człowieka i ocena ryzyka przed uruchomieniem systemu.
Od kiedy obowiązują te wymagania?
Wymagania dla systemów wysokiego ryzyka z załącznika III stosuje się od 2 grudnia 2027 r. Inne obowiązki AI Act, w tym zakazy z art. 5, mają odrębne terminy stosowania.
Jak długo przechowywać logi systemu AI?
Podmiot stosujący przechowuje automatycznie wygenerowane logi, w zakresie, w jakim pozostają pod jego kontrolą, co najmniej sześć miesięcy, chyba że właściwe przepisy przewidują inaczej. Nie oznacza to automatycznie sześciomiesięcznej retencji wszystkich nagrań.
Uwaga: artykuł ma charakter informacyjny i nie stanowi porady prawnej. Kwalifikacja systemu wymaga analizy konkretnej funkcji, celu, architektury i środowiska wdrożenia. Przy redakcji tekstu korzystaliśmy z narzędzi AI; treść została zweryfikowana przez zespół C&C Partners.
Źródła i dalsza lektura
Autor
