Agent powiedział, że skończył. Baza danych miała inne zdanie.

W środowiskach wieloagentowych pojawia się problem, który na pierwszy rzut oka wygląda banalnie, ale w praktyce potrafi narobić sporej szkody. Agent wykonuje zadanie, zgłasza ukończenie, a potem okazuje się, że operacja na bazie danych się nie powiodła, rekord nie został zapisany albo dokument trafił w złe miejsce. Agent nie kłamał celowo. Po prostu nie sprawdził stanu faktycznego systemu po wykonaniu polecenia. Zaraportował to, czego się spodziewał, nie to, co rzeczywiście zaszło.

To różni się od klasycznej halucynacji. Tutaj model działa na żywym systemie, wywołuje realne operacje i nie ma wbudowanego mechanizmu, który po każdej z nich potwierdza: "tak, zmiana naprawdę nastąpiła." Wystarczy chwilowa niedostępność usługi, przekroczony timeout albo cichy błąd zapisu, a agent idzie dalej, jakby wszystko poszło zgodnie z planem.

Co to oznacza dla polskich urzędów i instytucji publicznych

Dla instytucji publicznych ten problem jest szczególnie niekomfortowy, bo konsekwencje błędnego raportu nie znikają same. Jeśli agent obsługujący obieg dokumentów zgłosił wysłanie pisma, a pismo faktycznie nigdy nie wyszło, ktoś czeka na decyzję, której nie dostanie. Jeśli system rejestracji zgłosił zaktualizowanie danych, a aktualizacja cicho padła, kolejne operacje mogą operować na nieaktualnych danych bez żadnego ostrzeżenia.

Trzy sytuacje, które w urzędach zdarzają się częściej niż myślimy:

• Zapisy do bazy podczas dużego obciążenia. Agent inicjuje zapis, dostaje odpowiedź zwrotną, że "przyjęto do kolejki", i interpretuje to jako sukces. Zapis nigdy nie trafia do bazy docelowej.
• Integracje z zewnętrznymi rejestrami. Agent wysyła dane do systemu zewnętrznego. API odpowiada kodem 200, ale walidacja po stronie odbiorcy odrzuca rekord. Agent o tym nie wie.
• Wieloetapowe procesy z rozgałęzieniami. Agent raportuje zakończenie procesu po wykonaniu ostatniego kroku, który sam w sobie się powiódł. Ale jeden z wcześniejszych kroków miał błąd, który nigdy nie przerwał wykonania.

Rozwiązanie nie leży w samym modelu AI. Leży w architekturze wokół niego. Agenty powinny mieć wbudowane mechanizmy weryfikacji stanu po każdej operacji zapisu, a nie tylko po całym przepływie. Tam gdzie to niemożliwe technicznie, musi być ludzki punkt kontrolny albo automatyczny reconciliation, który cyklicznie porównuje to, co agent twierdzi, że zrobił, z tym, co faktycznie jest w systemie.

Bez tego raport agenta staje się dokumentem opartym na optymizmie, a nie na faktach. W administracji publicznej, gdzie każda operacja może mieć skutki prawne, to zdecydowanie za mało.

Jeśli wdrażacie lub planujecie agenty AI do procesów, które dotykają danych operacyjnych, zapraszamy na bezpłatny audyt. Sprawdzimy, gdzie w waszym procesie może brakować takiej weryfikacji i co konkretnie warto dodać.