System sztucznej inteligencji wygenerował błędny wynik, firma zatrzymała jego działanie, poprawiła ustawienia i uruchomiła go ponownie. Przy zwykłej usterce taka reakcja może okazać się wystarczająca. AI Act wyodrębnia jednak kategorię poważnych incydentów, po których samo usunięcie problemu technicznego nie zamyka sprawy. Znaczenie mają skutki zdarzenia, związek pomiędzy działaniem systemu a powstałą szkodą oraz rola firmy w łańcuchu dostarczania i wykorzystywania AI.
- Poważny incydent AI a zwykły błąd systemu
- Pośredni związek pomiędzy AI a powstałą szkodą
- Obowiązek zgłoszenia poważnego incydentu AI
- Terminy 2, 10 i 15 dni po zdarzeniu z AI
- Niepełna wiedza o przyczynach incydentu AI
- Firma korzystająca z AI z własnymi obowiązkami
- Logi systemu AI potrzebne do wyjaśnienia incydentu
- Wyłączenie wadliwej AI bez zakończenia sprawy
- Zgłoszenie incydentu bez automatycznego przyznania odpowiedzialności
W przypadku systemów wysokiego ryzyka mogą uruchomić się obowiązki dotyczące przekazania informacji, analizy incydentu, zabezpieczenia danych i zgłoszenia zdarzenia. Przepisy określają również terminy, które w najpoważniejszych przypadkach są krótsze niż standardowe 15 dni.
Poważny incydent AI a zwykły błąd systemu
Nie każda pomyłka AI jest poważnym incydentem. System może wygenerować nieprawidłową odpowiedź, źle sklasyfikować dokument albo chwilowo przestać działać bez uruchamiania szczególnego mechanizmu raportowania. AI Act określa konkretne grupy skutków, które decydują o poważnym charakterze zdarzenia.
Do tej kategorii należą zdarzenia prowadzące bezpośrednio lub pośrednio do śmierci człowieka albo poważnego uszczerbku na zdrowiu. Przepisy obejmują również poważne i nieodwracalne zakłócenie zarządzania infrastrukturą krytyczną lub jej działania, naruszenie obowiązków prawa Unii chroniących prawa podstawowe oraz poważną szkodę w mieniu lub środowisku.
Pośredni związek pomiędzy AI a powstałą szkodą
Poważny incydent nie musi polegać na tym, że system samodzielnie wykonał niebezpieczne działanie. AI może wygenerować wynik wykorzystany następnie przez pracownika albo inny system. Dopiero kolejna decyzja prowadzi do poważnych konsekwencji.
Dlatego analiza zdarzenia może wymagać odtworzenia całego procesu. Trzeba ustalić, jakie dane otrzymała AI, jaki wynik wygenerowała, kto go zobaczył, jak został zinterpretowany i jakie działania podjęto później. Ta sama techniczna pomyłka może mieć niewielkie znaczenie w procesie pomocniczym i bardzo poważne skutki w zastosowaniu wpływającym na zdrowie, bezpieczeństwo lub prawa ludzi.
Obowiązek zgłoszenia poważnego incydentu AI
Podstawowy obowiązek raportowania przewidziany w art. 73 AI Act spoczywa na dostawcach systemów AI wysokiego ryzyka wprowadzonych na rynek Unii. Zgłoszenie powinno trafić do organów nadzoru rynku właściwych dla państw członkowskich, w których doszło do zdarzenia.
Znaczenie ma moment ustalenia związku przyczynowego pomiędzy systemem a incydentem albo stwierdzenia, że taki związek jest racjonalnie prawdopodobny. Przepisy nie wymagają więc czekania do chwili, w której każda wątpliwość zostanie usunięta. Jeżeli zebrane informacje wskazują, że system mógł odegrać istotną rolę, dostawca musi odpowiednio zareagować.
Terminy 2, 10 i 15 dni po zdarzeniu z AI
W przypadku szczególnie poważnego incydentu lub powszechnego naruszenia zgłoszenie powinno nastąpić natychmiast, nie później niż w ciągu dwóch dni od uzyskania informacji o zdarzeniu. Jeżeli incydent wiąże się ze śmiercią człowieka, dostawca powinien przekazać informację niezwłocznie po ustaleniu lub podejrzeniu związku z systemem wysokiego ryzyka, najpóźniej w ciągu 10 dni od uzyskania wiedzy o zdarzeniu.
Pozostałe poważne incydenty podlegają zasadniczemu maksymalnemu terminowi 15 dni. Te okresy pokazują, dlaczego organizacja nie powinna budować procedury dopiero w chwili wystąpienia problemu. W pierwszych godzinach konieczne może być jednoczesne zabezpieczenie danych, ustalenie wersji systemu, skontaktowanie się z dostawcą, ograniczenie dalszego ryzyka i rozpoczęcie analizy.
Niepełna wiedza o przyczynach incydentu AI
Ustalenie źródła problemu może wymagać znacznie więcej czasu niż przewidziane terminy. Trzeba czasami przeanalizować logi, konfigurację systemu, dane wejściowe, aktualizacje, sposób działania pracowników i informacje od innych podmiotów.
Przepisy przewidują możliwość przekazywania raportów etapami. Pierwsze zgłoszenie nie musi zawierać pełnej odpowiedzi na każde pytanie, jeżeli ustalenie przyczyn wymaga dalszego dochodzenia. Możliwe jest przekazywanie informacji uzupełniających, a następnie raportu końcowego.
Firma korzystająca z AI z własnymi obowiązkami
Formalny obowiązek zgłoszenia wynikający z art. 73 dotyczy przede wszystkim dostawcy systemu wysokiego ryzyka. Nie oznacza to jednak, że przedsiębiorstwo korzystające z rozwiązania może wyłączyć program i zakończyć sprawę.
Podmiot stosujący system ma obowiązki dotyczące monitorowania jego działania. Jeżeli istnieją podstawy do uznania, że korzystanie z AI zgodnie z instrukcją może stwarzać ryzyko dla zdrowia, bezpieczeństwa lub praw podstawowych, powinien bez zbędnej zwłoki poinformować właściwe podmioty. Reakcja jest potrzebna również po wykryciu poważnego incydentu.
Logi systemu AI potrzebne do wyjaśnienia incydentu
Po poważnym zdarzeniu kluczowe mogą okazać się informacje istniejące tuż przed jego wystąpieniem. Trzeba ustalić, jaka wersja systemu działała, jakie dane otrzymała AI, jaki wynik wygenerowała i jak zareagował człowiek. Znaczenie może mieć także to, czy podobne anomalie pojawiały się wcześniej.
Bez takich informacji ustalenie związku między systemem a skutkiem może być znacznie trudniejsze. Dlatego wymogi dotyczące rejestrowania zdarzeń i monitorowania systemów wysokiego ryzyka mają praktyczne znaczenie. Logi mogą być podstawowym materiałem potrzebnym do odtworzenia procesu.
Wyłączenie wadliwej AI bez zakończenia sprawy
Natychmiastowe zatrzymanie systemu może być konieczne, aby ograniczyć dalsze ryzyko. Nie zastępuje jednak badania zdarzenia. Trzeba ustalić, czy problem dotyczył pojedynczego przypadku, określonej wersji oprogramowania, konkretnej konfiguracji czy większej grupy użytkowników.
Konieczne może być również sprawdzenie, czy podobne nieprawidłowości występowały wcześniej, ale nie zostały rozpoznane jako niebezpieczne. Pojedynczy incydent może być sygnałem szerszego problemu wymagającego działań naprawczych.
Zgłoszenie incydentu bez automatycznego przyznania odpowiedzialności
Przepisy przewidują, że samo zgłoszenie poważnego incydentu nie powinno być traktowane jako przyznanie odpowiedzialności za zdarzenie. Ma to ograniczać sytuacje, w których obawa przed skutkami prawnymi opóźnia przekazanie informacji.
Nie oznacza to zwolnienia z dalszej analizy. Po zdarzeniu trzeba ustalić jego przyczynę, ocenić rolę systemu i podjąć potrzebne działania naprawcze. Dlatego procedura powinna istnieć przed wystąpieniem pierwszego poważnego problemu.
ŹRÓDŁA
- Rozporządzenie Parlamentu Europejskiego i Rady UE 2024/1689, art. 3, art. 26, art. 72, art. 73
- Komisja Europejska, materiały dotyczące poważnych incydentów AI
- Komisja Europejska, materiały dotyczące systemów AI wysokiego ryzyka
- Rada Unii Europejskiej, AI Omnibus