Monitorowanie agentów AI wymaga interwencji w czasie działania

15 maja 2026 roku Parand A. Alamdari, Toryn Q. Klassen i Sheila A. McIlraith opublikowali artykuł, w którym przekonują, że zarządzanie AI wymaga audytu offline, monitorowania online w czasie działania oraz monitorów zdolnych do interwencji, zanim przewidywane naruszenie faktycznie nastąpi.¹

To ostatnie słowo ma znaczenie.

Monitorowanie, które tylko zapisuje awarię, pomaga w analizie po fakcie. Monitorowanie, które potrafi wstrzymać, zablokować, ograniczyć albo przekierować agenta, zmienia przebieg działania wtedy, gdy wynik pozostaje jeszcze otwarty.

Monitorowanie agentów AI wymaga interwencji w czasie działania. Logi, ślady, panele i zapisy zatwierdzeń dają zespołom materiał dowodowy. Interwencja w czasie działania zamienia ten materiał w decyzję, gdy agent nadal może uniknąć błędnego działania.

TL;DR

Monitorowanie agentów AI zawodzi, gdy działa jak dochodzenie po fakcie. Poważne środowisko wykonawcze agenta powinno obserwować aktywną trajektorię, wykrywać naruszenia zasad oraz decydujące błędy, a następnie wybierać ograniczoną interwencję: kontynuować, ostrzec, wstrzymać, zablokować, ograniczyć, przywrócić poprawny stan albo eskalować.

Najnowsze badania prowadzą w tym samym kierunku z kilku stron. Prace nad metodami formalnymi stosują logikę temporalną do monitorowania w czasie działania i monitorów interweniujących.¹ AgentForesight ujmuje wykrywanie awarii jako audyt online przed zakończeniem trajektorii.² AgentTrust przechwytuje ryzykowne wywołania narzędzi przed ich wykonaniem i zwraca ustrukturyzowane werdykty.³ AIR umieszcza reagowanie na incydenty wewnątrz pętli agenta, aby system mógł wykrywać incydenty, ograniczać ich skutki, przywracać poprawny stan i syntetyzować przyszłe zabezpieczenia.⁴

Praktyczny wniosek brzmi: nie należy zatrzymywać się na obserwowalności. Trzeba zbudować tę część środowiska wykonawczego, która potrafi działać na podstawie obserwacji.

Najważniejsze wnioski

Dla zespołów platform agentowych: - Monitorowanie należy traktować jako pętlę sterowania, nie tylko jako panel. - Działania interwencyjne trzeba zdefiniować, zanim agent dotknie narzędzi wysokiego ryzyka.

Dla zespołów bezpieczeństwa: - Warto przejść od przeglądu po fakcie do wykrywania online w punktach zatwierdzenia. - Każdą interwencję należy logować wraz z regułą, dowodami, decyzją i wynikiem.

Dla zespołów produktowych: - Zdarzenia interwencyjne powinny być pokazywane jako ustrukturyzowane obiekty przeglądu. - Użytkownik powinien widzieć, dlaczego działanie zostało wstrzymane, jakie dowody uruchomiły pauzę i jakie bezpieczne opcje pozostały.

Dla operatorów: - Większe zaufanie budzą ślady, które mogą zmienić zachowanie, niż ślady, które dopiero później tłumaczą szkodę. - Kluczowe pytanie brzmi, czy monitor potrafi zatrzymać następny zły krok, a nie tylko odtworzyć poprzedni.

Dlaczego monitorowanie agentów AI zawodzi zbyt późno?

Większość monitorowania zaczyna się dopiero wtedy, gdy agent już zadziałał.

Log może pokazać, że agent uruchomił polecenie powłoki. Ślad może pokazać, że agent pobrał stronę internetową, wywołał serwer MCP, zapisał plik albo poprosił o zatwierdzenie. Panel może pokazać, że polityka sieciowa zablokowała domenę. Te zapisy są ważne, ale same z siebie nie zmieniają następnego działania.

Wpis OpenAI o bezpieczeństwie Codex opisuje właściwą warstwę dowodową: ograniczone wykonanie, zarządzaną konfigurację, politykę sieciową, zatwierdzenia i telemetrię natywną dla agenta. Codex może eksportować zdarzenia OpenTelemetry dla instrukcji wejściowych użytkownika, decyzji o zatwierdzeniu narzędzi, wyników wykonania narzędzi, użycia serwera MCP oraz zdarzeń zezwolenia lub odmowy w proxy sieciowym.⁵ OpenAI opisuje też używanie logów Codex z agentem do triage’u bezpieczeństwa, aby recenzenci mogli sprawdzić pierwotne żądanie, aktywność narzędzi, zatwierdzenia, wyniki narzędzi i decyzje polityki sieciowej wokół alertów z podejrzanych punktów końcowych.⁵

Ta widoczność jest ważna. Luka pojawia się wtedy, gdy widoczność nie ma mechanizmu wykonawczego.

Jeśli monitor wykrywa, że agent przeczytał niezaufaną treść, a potem próbuje wysłać dane do nowej domeny zewnętrznej, system nie powinien jedynie zapisać tej sekwencji. Powinien wstrzymać działanie albo zablokować żądanie. Jeśli agent programistyczny trzy razy ponawia nieudaną migrację, a następnie proponuje szersze destrukcyjne polecenie, środowisko wykonawcze nie powinno czekać na końcowy przegląd. Powinno przerwać trajektorię.

Monitorowanie agentów AI powinno odpowiadać jednocześnie na dwa pytania:

Drugie pytanie zamienia monitorowanie w interwencję.

Co wnoszą nowe prace o środowisku wykonawczym?

Najnowsza grupa badań daje tej dziedzinie precyzyjniejsze słownictwo.

Artykuł o metodach formalnych skupia się na czasowo rozszerzonych ograniczeniach zachowania: regułach, dla których liczy się kolejność, odległość i sekwencja, a nie tylko pojedyncze zdarzenia. Autorzy łączą metody formalne z uczeniem maszynowym na potrzeby audytu offline i monitorowania online systemów AI typu czarna skrzynka, w tym LLM.¹ Wprowadzają też monitory predykcyjne i interweniujące, które mogą uprzedzać albo łagodzić przewidywane naruszenia w czasie działania.¹

AgentForesight nazywa ten tryb awarii językiem agentów. Artykuł wskazuje, że wieloagentowe systemy o długim horyzoncie mogą zaakceptować jeden decydujący błąd, a następnie kaskadowo przejść w awarię całej trajektorii.² Zamiast diagnozować odpowiedzialny krok po zakończeniu trajektorii, AgentForesight każe audytorowi online badać tylko bieżący prefiks i albo kontynuować, albo podnieść alarm przy najwcześniejszym decydującym błędzie.²

AgentTrust działa na granicy wywołania narzędzia. Przechwytuje wywołania narzędzi agenta przed wykonaniem i zwraca ustrukturyzowany werdykt: zezwól, ostrzeż, zablokuj albo skieruj do przeglądu.³ Ta forma ma znaczenie, ponieważ operacje na plikach, polecenia powłoki, żądania HTTP i zapytania do baz danych wywołują realne skutki uboczne.³

AIR dodaje warstwę reagowania na incydenty. Autorzy twierdzą, że prace nad bezpieczeństwem agentów często koncentrują się na zapobieganiu awariom z wyprzedzeniem, pozostawiając ograniczone możliwości reagowania, ograniczania skutków i przywracania poprawnego stanu po wystąpieniu incydentów.⁴ AIR integruje reagowanie na incydenty z pętlą wykonania agenta: wykrywa incydenty, prowadzi działania ograniczające i naprawcze oraz syntetyzuje reguły zabezpieczające dla przyszłych uruchomień.⁴

Razem te prace przesuwają punkt ciężkości:

Ta zmiana pasuje do rzeczywistej pracy agentów. Skutki uboczne pojawiają się w trakcie działania, a nie dopiero w końcowej odpowiedzi.

Co liczy się jako interwencja w czasie działania?

Interwencja w czasie działania to ograniczone działanie systemu podjęte dlatego, że bieżące dowody przekroczyły próg zasad, bezpieczeństwa, jakości albo ryzyka.

Interwencja powinna być węższa niż panika i silniejsza niż logowanie.

Dobra interwencja nie karci modelu. Zmienia stan środowiska wykonawczego.

Interwencja powinna tworzyć ustrukturyzowany zapis:

Monitor zasługuje na zaufanie wtedy, gdy inny recenzent może obejrzeć zdarzenie i zrozumieć, dlaczego środowisko wykonawcze zmieniło kurs.

Dlaczego ograniczenia temporalne mają znaczenie?

Wiele awarii agentów zależy od kolejności.

„Nie publikuj bez testów” nie jest właściwością jednego polecenia. To relacja między działaniem publikacji a wcześniejszymi dowodami. „Nie wysyłaj ruchu sieciowego na zewnątrz po przeczytaniu niezaufanej treści” zależy od sekwencji. „Nie zapisuj do produkcji po nieudanej migracji” zależy od wcześniejszego stanu awarii. „Nie zatwierdzaj wdrożenia po nieudanej weryfikacji źródła” zależy zarówno od zdarzenia zatwierdzenia, jak i od zdarzenia weryfikacji.

Linear Temporal Logic daje badaczom sposób wyrażania ograniczeń w czasie: przed, po, aż do, w końcu i nigdy. Artykuł z 15 maja podaje, że techniki audytu i monitorowania oparte na LTL skuteczniej niż metody bazowe LLM wykrywały naruszenia czasowo rozszerzonych ograniczeń zachowania.¹ Autorzy informują też, że nawet etykietujące małe modele dorównywały czołowym sędziom LLM albo ich przewyższały w ramach tego podejścia, a rozumowanie temporalne LLM pogarszało się wraz ze wzrostem odległości między zdarzeniami, liczby ograniczeń i liczby zdań atomowych.¹

Lekcja produkcyjna nie wymaga, aby każdy zespół już jutro wdrożył pełny stos metod formalnych.

Bezpośredni wniosek jest prostszy: należy pisać reguły, które rozumieją sekwencję.

Takie ograniczenia wymagają od środowiska wykonawczego pamiętania wystarczającej historii, aby ocenić następny krok. Bezstanowa instrukcja nie zrobi tego niezawodnie.

Gdzie powinno znajdować się monitorowanie w czasie działania?

Monitorowanie w czasie działania powinno znajdować się w punktach zatwierdzenia.

Punkt zatwierdzenia to każdy moment, w którym agent przechodzi od odwracalnej analizy do skutku zewnętrznego: modyfikacji pliku, zapisu w bazie danych, ruchu sieciowego wychodzącego, wdrożenia, wysłania wiadomości, zmiany uprawnień, płatności, usunięcia albo publicznej publikacji.

Dokumentacja chmury OpenAI Codex daje jedną konkretną granicę. Codex domyślnie blokuje dostęp do internetu w fazie agenta, choć skrypty konfiguracji nadal mogą korzystać z internetu do pobierania zależności.⁶ Ta sama dokumentacja ostrzega, że włączenie agentowi dostępu do internetu zwiększa ryzyko, w tym wstrzykiwania instrukcji z niezaufanych treści internetowych, eksfiltracji kodu lub sekretów, złośliwego oprogramowania albo podatnych zależności oraz treści objętych ograniczeniami licencyjnymi.⁶ Zaleca też limity domen i metod HTTP, z dodatkową ochroną wynikającą z ograniczenia żądań do GET, HEAD i OPTIONS.⁶

Taki kształt zasad powinien wykraczać poza dostęp do sieci.

Monitorowanie każdego tokenu marnuje uwagę. Monitorowanie punktów zatwierdzenia chroni te części działania, w których błędy wychodzą poza transkrypt.

Jak agent powinien doświadczyć interwencji?

Agent powinien otrzymać precyzyjną aktualizację stanu, a nie mglistą reprymendę.

Słaba odpowiedź:

Zachowaj ostrożność. To może być niebezpieczne.

Lepsza odpowiedź:

Zablokowano: zewnętrzne POST po odczycie niezaufanej treści. Dozwolone następne działania: podsumować ryzyko, poprosić operatora o zatwierdzenie z domeną docelową i klasą ładunku danych albo kontynuować bez ruchu sieciowego wychodzącego.

Druga odpowiedź daje agentowi bezpieczną przestrzeń planowania. Mówi, co zostało uruchomione, dlaczego działanie nie może zostać wykonane i jakie alternatywy pozostają. Kształt werdyktu AgentTrust wskazuje ten kierunek: zezwól, ostrzeż, zablokuj albo skieruj do przeglądu, wraz z bezpieczniejszymi alternatywami dla ryzykownych poleceń.³

Interwencja w czasie działania powinna zachować sprawczość bez zachowywania zagrożenia.

Agent nadal może naprawić zadanie. Może poprosić o zatwierdzenie. Może zmienić narzędzia. Może rozdzielić pracę na etap tylko do odczytu. Może przygotować pakiet dowodowy. Środowisko wykonawcze usuwa wyłącznie działania, które naruszają bieżący stan zasad.

Co powinien zobaczyć człowiek?

Człowiek powinien zobaczyć kartę interwencji, a nie tajemniczą pauzę.

Taka karta należy do tej samej rodziny produktowej co kolejki zatwierdzeń, osie czasu śladów i pakiety przeglądu. Różnica leży w momencie. Zatwierdzenie pyta, czy planowane działanie może pójść dalej. Interwencja w czasie działania mówi, że monitor zobaczył żywy wzorzec, który zmienił dozwolony następny krok.

Dobry interfejs nie powinien zmuszać użytkownika do czytania całego transkryptu, aby zrozumieć pauzę. Karta powinna wskazywać ten fragment śladu, który ma znaczenie.

Co zespoły powinny zbudować najpierw?

Warto zacząć od prostych reguł monitorowania w wartościowych punktach zatwierdzenia.

1. Zdefiniować punkty zatwierdzenia. Nazwać wywołania narzędzi i zasoby, przy których błędy wychodzą poza lokalne działanie.
2. Utworzyć typowany strumień zdarzeń. Rejestrować narzędzie, argumenty, cel, wynik, wcześniejsze istotne zdarzenia i stan uruchomienia.
3. Napisać reguły świadome sekwencji. Zacząć od relacji kolejności, które często mają znaczenie: test przed wdrożeniem, przegląd przed ruchem wychodzącym, zatwierdzenie przed zapisem.
4. Dodać wąskie interwencje. Preferować wstrzymanie, blokadę albo ograniczenie zamiast szerokiego wyłączenia.
5. Zwracać ustrukturyzowane werdykty. Informować agenta, co zostało uruchomione i jakie działania pozostają dozwolone.
6. Pokazywać karty interwencji. Dać ludziom regułę, dowody, ryzyko i następne opcje.
7. Przeglądać wyniki. Promować trafne wykrycia, dostrajać fałszywe alarmy i usuwać hałaśliwe reguły.

Pierwsza wersja może pozostać nudna. Kilka deterministycznych reguł na granicy narzędzi często wygrywa z szerokim sędzią modelowym obserwującym każde zdanie.

Głębsza wersja może dodać monitorowanie predykcyjne, ograniczenia LTL, uczonych audytorów i pętle reagowania na incydenty. Te warstwy warto budować dopiero wtedy, gdy strumień zdarzeń i semantyka interwencji działają.

Standard godny wdrożenia

Interwencja w czasie działania może stać się teatrem, jeśli każda pauza wygląda poważnie, a każde ostrzeżenie ma tę samą wagę.

Standard powinien pozostać wąski:

• Interweniować tylko tam, gdzie następne działanie może mieć znaczenie.
• Nazwać regułę, która została uruchomiona.
• Pokazać dowody.
• Zachować bezpieczną następną ścieżkę.
• Zapisać wynik.
• Usuwać reguły, które tworzą szum, ale nie zapobiegają szkodom.

Dobre monitorowanie chroni pracę. Złe monitorowanie chroni tylko narrację dostawcy o odpowiedzialności.

Środowisko wykonawcze agenta nie powinno maksymalizować ruchu. Powinno maksymalizować odpowiedzialny postęp. Czasem odpowiedzialny postęp oznacza, że agent kontynuuje bez przerwy. Czasem oznacza odmowę następnego kroku.

Poprzeczka jakości leży w umiejętności odróżnienia jednego od drugiego.

Krótkie podsumowanie

Monitorowanie agentów AI wymaga interwencji w czasie działania, ponieważ awarie agentów dzieją się wewnątrz trajektorii, a nie tylko na końcu. Logi i ślady wyjaśniają, co się stało. Monitory interweniujące mogą zmienić to, co stanie się dalej.

Kierunek obecnych badań jest jasny: formalne ograniczenia temporalne, audytorzy online, werdykty wywołań narzędzi i pętle reagowania na incydenty pchają monitorowanie ku aktywnej kontroli. Zespoły powinny zacząć od typowanych strumieni zdarzeń, reguł w punktach zatwierdzenia, ustrukturyzowanych werdyktów, kart interwencji i przeglądu wyników. Celem nie jest więcej alertów. Celem jest mniej nieodwracalnych błędów.

FAQ

Czym jest interwencja w czasie działania dla agentów AI?

Interwencja w czasie działania oznacza, że system zmienia aktywne uruchomienie agenta, ponieważ bieżące dowody przekroczyły próg zasad, ryzyka, bezpieczeństwa albo jakości. Interwencja może kontynuować, ostrzec, wstrzymać, zablokować, ograniczyć, przywrócić poprawny stan albo eskalować uruchomienie.

Czym interwencja w czasie działania różni się od obserwowalności?

Obserwowalność zapisuje to, co się stało. Interwencja w czasie działania działa, gdy uruchomienie nadal trwa. Ten sam ślad może wspierać jedno i drugie, ale interwencja wymaga decyzji zgodnej z zasadami i dozwolonego następnego działania.

Czy każde działanie agenta powinno przechodzić przez monitor?

Każde znaczące działanie narzędzia powinno tworzyć typowane zdarzenie. Reguł przerywających wymagają tylko wartościowe punkty zatwierdzenia. Zdarzenia tylko do odczytu zwykle można spokojnie logować. Zdarzenia ze skutkami ubocznymi zasługują na ściślejsze monitorowanie.

Czy zespoły potrzebują metod formalnych, aby zacząć?

Nie. Zespoły mogą zacząć od deterministycznych reguł sekwencji: brak wdrożenia przed testami, brak zewnętrznego zapisu po pobraniu niezaufanej treści, brak destrukcyjnego polecenia po powtarzających się nieudanych naprawach i brak końcowego zakończenia bez wymaganych dowodów. Metody formalne stają się przydatne, gdy zestaw reguł rośnie, a relacje temporalne trudno sprawdzać ręcznie.

Co sprawia, że interwencja w czasie działania jest wiarygodna?

Wiarygodna interwencja nazywa regułę, pokazuje dowody, ogranicza następne działanie, zapisuje wynik i daje upoważnionemu człowiekowi ścieżkę przeglądu. Mgliste ostrzeżenie się nie liczy.

Źródła