Zarządzanie incydentami AI

Wykrywanie, klasyfikacja, reakcja i raportowanie incydentów związanych z systemami AI. Także tymi, których "ogarnięcia" wymaga AI Act

Czym są incydenty? Zrozumieć ich znaczenie i umiejscowienie

Incydent AI to zdarzenie, w którym system AI (lub model - zależy to od podejścia) zachowuje się niezgodnie z założeniami i powoduje (lub może spowodować) szkodę dla użytkownika, organizacji lub osób trzecich. Wymaga osobnego procesu, bo klasyczne zarządzanie incydentami IT nie do końca wystarcza.

Przykładami incydentów będą niewłaściwe "działania" agentów AI czy źle dobrane dane do modelu, które skutkują jakąś formą dyskryminacji. Oczywiście to jak klasyfikujemy incydenty AI zależy od tego jak taka klasyfikacja została opracowana w naszej organizacji.

Incydenty dość dobrze zostały "rozpisane" w przepisach dotyczących cyberbezpieczeństwa (NIS2) i zarządzania ryzykiem ICT (DORA), gdzie obsługa incydentów jest w zasadzie wpisana w działalność.

Najczęściej mówimy o incydentach:

Te priorytety odnoszą się do tego jak szybko należy rozwiązać problem i np. przywrócić system do działania.

Dodatkowo wyróżniamy też incydenty podlegające raportowaniu, które wynikają z aktów prawnych i regulacji i muszą być obsłużone w nieco inny sposób. Przykładami będą tutaj poważne incydenty w rozumieniu AI Act.

Incydenty AI Przykładowa klasyfikacja

Klasy incydentów (bez prawnego aspektu)

To rzecz jasna przykłady, a do tego dochodzą też bardziej standardowe incydenty, których wystąpienie może być niezależne i niepowiązane z ich AI'ową charakterystyką.

Odrębną kategorią są "poważne incydenty" w rozumieniu AI Act, które rozumiemy tak:

„poważny incydent” oznacza incydent lub nieprawidłowe działanie systemu AI, które bezpośrednio lub pośrednio prowadzą do któregokolwiek z poniższych zdarzeń:

a) śmierci osoby lub poważnego uszczerbku na zdrowiu osoby;

b) poważnego i nieodwracalnego zakłócenia w zarządzaniu infrastrukturą krytyczną lub jej działaniu;

c) naruszenia obowiązków przewidzianych w prawie Unii, których celem jest ochrona praw podstawowych;

d) poważnej szkody na mieniu lub poważnej szkody dla środowiska.

Tutaj pojawia się dodatkowe obowiązki, ale poświęcimy temu zagadnieniu odrębną sekcję. Możecie jednak znaleźć trochę wyjaśnień w projektowanych wytycznych w tej sprawie ; ) Do czego zachęcam! klik!

Proces reakcji

  1. Wykrycie (monitoring, zgłoszenie użytkownika, alert) - tutaj bardzo ważne jest, aby ludzie wiedzieli do kogo i kiedy powinni się zgłosić, a także jakieś przesłanki muszą być spełnione.
  2. Triage (szybka ocena) i klasyfikacja (powaga, zasięg, kategoria). Niekiedy trzeba będzie sięgnąć np. do AI Act czy DORA lub NIS2; tam znajdziemy konkretne "thresholdy", ale w organizacji raczej powinno być to jasno rozpisane w stosownej procedurze.
  3. Powstrzymanie (rollback modelu, wyłączenie funkcji, fallback do człowieka), czyli generalnie powstrzymanie ewentualnych skutków niewłaściwego działania tak, aby smród się nie rozłał na więcej systemów i nie zrobił jeszcze większej szkody.
  4. Analiza przyczyny źródłowej i co ważne zapisanie tego na potrzeby kontroli i audytu, ale także dalszej nauki - czasem będzie to wymóg prawnyc lub regulacyjny.
  5. Naprawa i wdrożenie kontroli, czyli wyciągnięcie wniosków na podstawie "nauczki".
  6. Raportowanie zewnętrzne — AI Act art. 73 (poważne incydenty), UODO (jeżeli dotyczy danych osobowych), CSIRT (jeżeli cyber). Ogólnie jest to temat dość złożony, więc warto poświęcić temu trochę czasu.
  7. Lekcje i aktualizacja rejestru ryzyk.

I tak ciągle, bo to proces, który nie utaje.

Operacjonalizacja: incydenty AI

Jak ułożyć proces zgłaszania i obsługi incydentów AI: kategoryzacja, eskalacja, lekcje wyciągnięte i obowiązki raportowania z AI Act i NIS2.

Aktualizacja: