Pierwsza godzina incydentu z agentem

Prędzej czy później agent zrobi coś, czego nikt nie zamierzał. Wyśle dokument niewłaściwej stronie, zamknie paczkę zgłoszeń, które miały pozostać otwarte, albo zmieni rekordy, których nie miał prawa ruszać. Czasem dlatego, że źle zrozumiał zadanie, czasem dlatego, że kazało mu to coś, co przeczytał.

Pierwsze pytania są zawsze te same. Co zrobił? Dlaczego? W czyim imieniu? Czego jeszcze dotknął? Czy to nadal trwa? Przy wielu agentach działających dziś na produkcji odpowiedź zajmuje dni, bo logi zapisują wywołania HTTP, a nie decyzje, a agent działa na tożsamości, którą dzieli z czymś innym.

Co log musi zawierać, zanim cokolwiek się wydarzy

Wejścia w takiej postaci, w jakiej były. Nie tylko prośbę użytkownika, ale każdy dokument, wiadomość, stronę i wynik narzędzia, które trafiły do kontekstu — przechowane albo wskazane razem z wersją, żeby było widać, co agent przeczytał, zanim zadziałał. Jeśli incydent wywołało wstrzyknięte polecenie, to jedyne miejsce, w którym je znajdziecie.

Każde wywołanie z parametrami. Każde wywołanie narzędzia z dokładnymi argumentami i wynikiem, użyta wersja modelu i promptu oraz krok zadania, który je wygenerował.

Łańcuch uprawnień. Który agent, w imieniu którego użytkownika, z jakim poświadczeniem, zatwierdzone przez kogo. Bez tego log mówi, że konto serwisowe coś zrobiło — a to jest zdanie, nie odpowiedź.

Poza zasięgiem agenta. Zapisywany w miejscu tylko do dopisywania, którego agent nie może edytować ani usuwać. System, który potrafi uporządkować własne zapisy, ma zapisy, na których nikt nie może polegać.

Przechowywany tak długo, jak mogą wracać pytania. Retencja wyznaczona przez to, jak długo działania agenta mogą wrócić jako reklamacja, spór albo pytanie audytora, a nie przez domyślne ustawienie narzędzia do logów.

Dla systemów, które wpadają w kategorię wysokiego ryzyka według EU AI Act, automatyczne logowanie jest obowiązkiem, a nie wyborem. Dla wszystkich pozostałych to po prostu jedyny sposób, żeby odpowiedzieć na pięć pytań powyżej.

Kolejność pierwszych ruchów

Infografika

Pierwsze ruchy, po kolei

1. 01OgraniczyćOdwołać albo zawęzić poświadczenia i wstrzymać narzędzia wychodzące. Niczego nie usuwać.
2. 02ZabezpieczyćKopia logów, kontekstu i stanu piaskownicy, zanim ktoś zacznie naprawiać.
3. 03OdtworzyćPrześledzić decyzję: co przeczytał, co wywołał i dla kogo.
4. 04Określić zasięgZnaleźć każdą inną sesję, która czytała tę samą treść albo szła tą samą ścieżką.
5. 05NaprawićNaprawić granicę, która zawiodła, potem odwrócić to, co odwracalne.
6. 06Wyciągnąć wnioskiWejście, które wywołało incydent, staje się stałym przypadkiem testowym.

Ograniczajcie przez tożsamość, a nie przez wyciągnięcie wtyczki. Jeśli agent ma własną tożsamość, ograniczenie oznacza odwołanie albo zawężenie jego poświadczeń i wyłączenie narzędzi wychodzących: sekundy, odwracalnie, a reszta firmy pracuje dalej. Jeśli działa na koncie człowieka albo na wspólnym, ograniczenie odcina też ludzi. Dlatego zespoły się wahają — a wahanie jest najdroższą częścią.

Najpierw zabezpieczcie, potem naprawiajcie. Odruch każe poprawić prompt i wdrożyć ponownie. To zastępuje dowód tego, co agent wykonywał, czymś, czego nikt jeszcze nie zbadał. Najpierw zróbcie kopię logów, kontekstu i stanu piaskownicy.

Odtwarzajcie z zapisu, a nie z modelu. Zapytany, dlaczego coś zrobił, agent poda płynne wyjaśnienie napisane po fakcie, a to nie jest dowód. Odpowiedź leży w zalogowanych wejściach i wywołaniach: w tym, co było w kontekście w chwili każdej decyzji.

Zakładajcie, że to nie była jedna sesja. Jeśli przyczyną była treść, którą agent przeczytał — zatruty dokument na wspólnym dysku, strona, zgłoszenie — podejrzana jest każda sesja, która przeczytała to samo. Log wejść pozwala je znaleźć. Bez niego zgadujecie, a zgadywanie w trakcie incydentu zwykle zaniża skalę.

Naprawiajcie granicę, a nie sformułowanie. Nowa linijka w promptcie, każąca agentowi więcej tego nie robić, jest nadzieją. Trwała naprawa to uprawnienie, reguła ruchu wychodzącego, limit albo krok zatwierdzania, który by to zatrzymał. Wejście, które wywołało incydent, trafia potem do zestawu ewaluacyjnego, żeby luka nie otworzyła się po cichu ponownie.

Przećwiczcie to raz

W środowisku testowym podłóżcie polecenie w dokumencie, który agent przeczyta, i pozwólcie mu działać. Potem poproście zespół, żeby w ciągu godziny odpowiedział na pięć pytań. To, na co nie odpowie, jest listą prac — a znacznie taniej znaleźć ją na ćwiczeniu niż z klientem na linii.

Na takim procesie incydentu opiera się utrzymanie systemów AI: pierwsza reakcja zawęża to, co agent może robić bez nadzoru, rejestr decyzji pozwala odtworzyć incydent, a jego przebieg zostaje potem spisany. Gdy przejmujemy agenta zbudowanego przez kogoś innego, jedną z pierwszych rzeczy, które sprawdzamy, jest to, czy jego logi odpowiedziałyby na te pięć pytań.