Incident response dla AI: co zrobić, gdy model zawodzi

# Incident response dla AI: co zrobić, gdy model zawodzi

Incydent AI nie wygląda jak klasyczna awaria systemu. Często wszystko "działa", API odpowiada, dashboard świeci na zielono, a mimo to firma traci: model zwraca szkodliwe rekomendacje, eskaluje halucynacje, narusza politykę danych albo systematycznie faworyzuje jedną grupę klientów. Dlatego incident response dla AI musi łączyć perspektywę techniczną, operacyjną i reputacyjną.

Najgroźniejszy błąd to traktowanie incydentów AI jak jednorazowych usterek. W AI źródło problemu bywa strukturalne: drift danych, zmiana kontekstu biznesowego, nieaktualne guardraile, niedostateczny nadzór człowieka albo wadliwa integracja modelu z procesem. Jeśli organizacja naprawia tylko objaw, incydent wróci.

Czym jest incydent AI

Incydent AI to każde zdarzenie, w którym działanie modelu lub systemu AI powoduje albo realnie może spowodować istotną szkodę biznesową, prawną, operacyjną lub reputacyjną.

Typowe klasy incydentów: - **Jakość i trafność:** model generuje błędne treści wpływające na decyzję lub komunikację. - **Bezpieczeństwo danych:** dochodzi do ujawnienia, nieuprawnionego przetwarzania lub niewłaściwej retencji. - **Zgodność i etyka:** wynik narusza politykę firmy, regulacje lub standardy fairness. - **Operacje:** degradacja modelu powoduje przerwanie workflow i wzrost ręcznego obciążenia. - **Zaufanie:** incydent obniża wiarygodność firmy u klientów, pracowników lub regulatora.

Takie zdefiniowanie incydentu pozwala reagować wcześnie, zanim problem stanie się kryzysem.

Co odróżnia response AI od response IT

W klasycznym IT często szukamy binarnej przyczyny: serwer padł, usługa nie działa. W AI zdarzenie bywa probabilistyczne i kontekstowe: ta sama prośba raz przechodzi poprawnie, raz nie. To wymaga innej metodologii dowodowej.

Po drugie, skutki incydentu AI mogą być odroczone. Błąd modelu nie zawsze widać od razu, ale może wpłynąć na serię decyzji w kolejnych tygodniach.

Po trzecie, response musi angażować więcej funkcji: ownera biznesowego, risk/compliance, legal, security, zespół modelowy i operacje procesu. Brak jednego z tych ogniw wydłuża czas reakcji i zwiększa koszt.

Minimalny playbook reagowania: model Triage-Contain-Fix-Learn

Skuteczny playbook można oprzeć na czterech krokach.

### Triage

Pierwsza decyzja to klasyfikacja istotności. Zespół powinien ocenić: - skalę potencjalnego wpływu (klienci, wolumen, krytyczność procesu), - typ naruszenia (jakość, dane, compliance, reputacja), - odwracalność skutku.

W praktyce warto mieć 3 poziomy: krytyczny, wysoki, umiarkowany. Każdy poziom ma zdefiniowany czas reakcji i listę obowiązkowych ról.

### Contain

Celem jest ograniczenie szkody zanim zakończy się pełna analiza. Działania mogą obejmować: - wyłączenie konkretnego use case'u, - przełączenie na fallback manualny, - zaostrzenie progów confidence lub reguł walidacji, - blokadę określonych typów danych wejściowych.

Containment musi mieć właściciela biznesowego i technicznego. Bez tego działania są niespójne i trudne do odtworzenia.

### Fix

Dopiero po opanowaniu sytuacji zespół wdraża poprawki źródłowe: modyfikację promptów i guardraili, zmianę danych referencyjnych, kalibrację progów, przebudowę punktów kontroli człowieka lub aktualizację procesu.

Kluczowe jest rozdzielenie "quick fix" od "root fix". Quick fix przywraca stabilność, root fix obniża ryzyko nawrotu.

### Learn

Każdy incydent powinien kończyć się post-incident review z trzema pytaniami: - co wykryliśmy za późno i dlaczego, - które zabezpieczenie nie zadziałało, - co zmieniamy w monitoringu, polityce i procesie.

Bez fazy Learn organizacja powtarza te same incydenty pod nową nazwą.

Monitoring, który wykrywa incydenty przed eskalacją

System monitoringu AI powinien obejmować nie tylko uptime, lecz także sygnały jakości i ryzyka: - wzrost odsetka odpowiedzi korygowanych przez człowieka, - skok liczby eskalacji do supportu, - anomalie w strukturze zapytań i danych wejściowych, - spadek trafności na próbkach kontrolnych, - wzrost użycia wyjątków procesowych.

Te sygnały należy powiązać z progami alertowania. "Obserwujemy trend" to za mało - potrzebne są progi, które uruchamiają konkretne działania.

Rola human-in-the-loop podczas incydentu

W czasie incydentu human-in-the-loop nie może być hasłem. Musi działać jako mechanizm kontroli: - kto podejmuje decyzję o zatrzymaniu modelu, - kto zatwierdza komunikację do klienta, - kto autoryzuje powrót do normalnego trybu.

Jeśli te role nie są zdefiniowane przed incydentem, decyzje zapadają ad hoc i rośnie ryzyko błędu wtórnego.

Komunikacja: jak nie pogłębić kryzysu

Przy incydencie AI komunikacja jest częścią response, nie dodatkiem PR. Wewnętrznie zespoły muszą wiedzieć, co wolno robić, czego nie wolno oraz jaki jest status przywracania. Zewnętrznie komunikat powinien być prawdziwy, konkretny i proporcjonalny do skali zdarzenia.

Najgorszy wzorzec to dwa skrajne podejścia: całkowite milczenie albo nadmiar obietnic. Odpowiedzialna komunikacja pokazuje fakty, działania ochronne i plan dalszych kroków.

Praktyczny runbook na pierwsze 24 godziny

0-2 godziny: klasyfikacja incydentu, uruchomienie właścicieli, decyzja containment.

2-6 godzin: ograniczenie ekspozycji, przejście na fallback, zabezpieczenie logów i materiału dowodowego.

6-12 godzin: analiza przyczyny wstępnej, decyzja o komunikacji, plan quick fix.

12-24 godziny: wdrożenie quick fix, testy bezpieczeństwa i jakości, decyzja o częściowym lub pełnym przywróceniu.

Ten runbook warto ćwiczyć jak fire drill. W incydencie nie ma czasu na tworzenie procesu od zera.

Najczęstsze błędy organizacyjne

Błąd 1: brak jednego ownera incydentu AI. Kilka zespołów działa równolegle, ale bez wspólnej osi decyzyjnej.

Błąd 2: zbyt wąska definicja incydentu ograniczona do awarii technicznej.

Błąd 3: brak fallbacku manualnego dla krytycznych procesów.

Błąd 4: monitorowanie tylko infrastruktury, bez monitorowania jakości decyzji.

Błąd 5: brak wymuszonego post-incident review i aktualizacji kontroli.

Co powinien zrobić AI Risk Committee

Komitet ryzyka AI powinien zatwierdzić klasyfikację incydentów, minimalny zestaw progów alertowych, role i czasy reakcji. Powinien też regularnie przeglądać trendy incydentów, nie tylko pojedyncze przypadki.

Drugie zadanie komitetu to powiązanie incydentów z decyzjami inwestycyjnymi. Jeśli dany use case generuje powtarzalne incydenty, odpowiedzią może być nie tylko "więcej kontroli", ale też zmiana zakresu, architektury albo modelu sourcingu.

Trzecie zadanie to wymuszanie fazy Learn: każda lekcja z incydentu musi przełożyć się na zmianę polityki, procesu lub monitoringu.

Executive Takeaway

Co się zmieniło? Incydenty AI stały się zjawiskiem operacyjnym, które dotyczy jakości decyzji i zaufania, a nie wyłącznie dostępności systemu. Dlaczego to ważne? Reakcja opóźniona lub źle skoordynowana zwiększa stratę biznesową i reputacyjną, a także podważa wiarygodność całego programu AI. Co liderzy powinni zrobić? Wdrożyć playbook Triage-Contain-Fix-Learn, ustawić progi monitoringu jakości oraz ćwiczyć runbook 24h z jasno przypisanymi rolami biznesu, technologii i ryzyka.