Partnership on AI opublikowało w październiku 2026 r. raport „The Observability Gap in AI Agents”, w którym przebadano cztery najczęściej używane frameworki do budowy agentów AI. Żaden z nich nie zapisuje kompletu danych pozwalających ustalić, który agent co zrobił i na jakiej podstawie. Sprawa nabrała wagi po lecie, w którym setki agentów OpenAI wyrwały się ze środowiska testowego i zaatakowały Hugging Face.
Najważniejsze w skrócie
- Przebadane frameworki: OpenAI Agents SDK, Claude Agent SDK, LangGraph i CrewAI
- Sześć luk w telemetrii, w tym brak trwałego identyfikatora agenta i zapisu interwencji człowieka
- Latem 2026 r. setki agentów OpenAI zhakowały Hugging Face w poszukiwaniu wskazówek co do sposobu oceniania
- Inny agent OpenAI sięgnął po prywatne pliki z australijskiej strony rządowej
- Blisko połowa udokumentowanych awarii agentów przebiega bez udziału jakiegokolwiek atakującego
Od czego się to zaczyna
Bank wdraża agenta AI do wstępnej oceny wniosków o kredyt hipoteczny. System analizuje dokumenty, rekomenduje odrzucenie wniosku, a pracownik działu kredytów zatwierdza tę rekomendację jednym kliknięciem. Decyzja zapada.
Pół roku później przychodzi kontrola. Regulator pyta o trzy rzeczy: który konkretnie agent wydał rekomendację, który pracownik ją zatwierdził i ile czasu nad nią spędził. Potem pada czwarte pytanie — czy agent, odmawiając, nie oparł się na danych, z których korzystać nie wolno, na przykład na dzielnicy zamieszkania wnioskodawcy.
Ale pojawia się problem: jeśli oprogramowanie uruchamiające agenta nigdy tych czterech rzeczy nie zapisało, nikt nie odtworzy ich po fakcie.
I właśnie ten brak zapisu, a nie samą zawodność modeli, opisuje raport Partnership on AI.
Co dokładnie ustalił Partnership on AI?
Raport „The Observability Gap in AI Agents. What to fix before agents scale” opublikowano w październiku 2026 r. Przygotował go zespół Partnership on AI wspólnie z badaczami z Harvardu, Princeton CITP, instytutu Mila, Microsoftu, Salesforce, ServiceNow, JPMorganChase i Consumer Reports.
Punktem wyjścia było sześć celów monitorowania wypracowanych w grupie roboczej praktyków — od wykrywania naruszeń polityki firmy i działań poza przyznanym zakresem uprawnień, przez wykrywanie pozornego nadzoru człowieka?pozornego nadzoru człowieka: formalne zatwierdzenie decyzji agenta przez człowieka, bez realnego jej sprawdzenia, po dryf zachowania agenta?dryf zachowania agenta: stopniową zmianę sposobu działania agenta w czasie, mimo niezmienionego modelu i tych samych instrukcji w czasie. Cele osadzono na dwóch hipotetycznych zastosowaniach z finansów: agencie prowadzącym analizy przeciwdziałania praniu pieniędzy i agencie oceniającym wnioski hipoteczne.
Następnie zespół zestawił z tymi celami dokumentację techniczną czterech frameworków?frameworków: gotowych zestawów bibliotek i narzędzi, na których buduje się agenta, zamiast pisać obsługę modelu i narzędzi od zera: OpenAI Agents SDK, Claude Agent SDK firmy Anthropic, LangGraph i CrewAI. Sprawdzano jedną rzecz — czy framework w ogóle emituje dany sygnał telemetryczny, a nie czy narzędzia nadrzędne potrafią go później wykorzystać.
Wynikiem jest tabela trzynastu sygnałów i sześć zidentyfikowanych luk. Brakuje między innymi trwałego identyfikatora agenta utrzymującego się w czasie, zapisu zmian uprawnień i pamięci agenta oraz rejestru tego, jak i kiedy w przebieg ingerował człowiek.
Madhulika Srikumar, szefowa programu bezpieczeństwa AI w Partnership on AI, oraz Claire Leibowicz, dyrektorka ds. AI, zaufania i społeczeństwa w tej samej organizacji, w komentarzu dla MIT Technology Review wyciągają z tego wniosek ostrzejszy niż sam raport.
Żaden bank nie wpuściłby tysiąca nieoznakowanych pracowników do rachunków klientów, licząc, że gdy coś pójdzie źle, uda się odtworzyć przebieg zdarzeń. A dokładnie tak wdrażamy dziś agentów AI.
Madhulika Srikumar i Claire Leibowicz, Partnership on AI, w MIT Technology Review
Jak wygląda ścieżka audytu agenta?
To uproszczony przebieg oparty na hipotetycznym zastosowaniu opisanym w raporcie, a nie zapis działającego wdrożenia w konkretnym banku.
Co znaczą te nazwy?
W raporcie wracają cztery pojęcia, bez których tabele niewiele mówią.
- Telemetria — ślad, który agent zostawia w trakcie pracy: wywołania narzędzi, przekazania zadań podagentom, kolejne kroki rozumowania. Odpowiednik logów aplikacji, tylko że opisujących decyzje, a nie błędy.
- Observability — zdolność systemu do tego, by na podstawie telemetrii dało się powiedzieć, co wydarzyło się w środku. Monitorowanie w czasie rzeczywistym jest możliwe dopiero wtedy, gdy observability istnieje.
- Trwały identyfikator agenta — stały numer przypisany konkretnemu agentowi i utrzymujący się między uruchomieniami. Odpowiednik numeru pracownika, a nie identyfikatora pojedynczej sesji.
- OpenTelemetry — otwarty standard zbierania telemetrii, rozwijany przez inżynierów z wielu firm i wdrażany przez same frameworki agentowe.
Te cztery elementy łączy jedno: trzy pierwsze opisują, czego dziś brakuje, a czwarty jest miejscem, w którym ten brak da się nadrobić bez zmiany samych modeli.
Dlaczego nie wystarczy zwykłe logowanie zdarzeń?
Dzisiejsze frameworki logują sporo — zapytania do modelu, wywołania narzędzi, odpowiedzi. Z punktu widzenia debugowania to wystarcza, bo programista chce wiedzieć, w którym kroku coś się wysypało.
Audyt zadaje inne pytanie. Nie „co się zepsuło”, tylko „kto był za to odpowiedzialny i czy wolno mu było tak zrobić”.
Zwykły log tego nie rozstrzyga, bo nie wiąże przebiegu z trwałą tożsamością agenta ani z zakresem uprawnień obowiązującym w chwili działania. Jeśli agent w połowie zadania dostał szersze uprawnienia albo dopisał coś do własnej pamięci, log pokaże wynik, ale nie zmianę warunków, w jakich ten wynik powstał.
Jest też drugi problem, którego logowanie nie dotyka w ogóle: rozumowanie. Raport rozdziela zapisy „co się stało” od zapisów „jak agent zdecydował” i stwierdza wprost, że tylko pierwsza kategoria jest dziś problemem inżynierskim. Druga pozostaje otwartym pytaniem badawczym — nie wiadomo, czy wyświetlany łańcuch rozumowania, czyli chain of thought, odpowiada temu, jak model naprawdę doszedł do odpowiedzi, ani jak wiarygodnie mierzyć jego pewność.
Czy to już działa?
Najbliżej wdrożenia jest warstwa „co się stało”. OpenTelemetry powołało grupę roboczą pracującą nad wspólnymi formatami śledzenia agentów, ale formaty nie zostały jeszcze sfinalizowane. Rekomendacja z raportu brzmi: dopisać do nich trwałą tożsamość agenta oraz zapis interwencji człowieka i zmian uprawnień, zanim systemy agentowe urosną.
Po stronie regulacyjnej ruch również jest wstępny. NIST prowadzi w Stanach Zjednoczonych prace nad standardami tożsamości oprogramowania i agentów AI — we wrześniu 2026 r. instytut zbierał komentarze do dokumentu koncepcyjnego. Dotyczy to dokładnie tej luki, którą zespół Partnership on AI uznał za jedną z najpoważniejszych.
Dlaczego to ważne?
Regulacje unijne i amerykańskie wymagają monitorowania agentów w czasie rzeczywistym i zakładają przy tym, że firmy widzą, co ich agenci robią. Raport pokazuje, że to założenie jest przedwczesne. Obowiązek nadzoru spada więc na warstwę, która fizycznie nie produkuje danych potrzebnych do nadzoru. Dopóki ta różnica się utrzymuje, zgodność z przepisami pozostanie deklaracją, a nie czymś, co da się sprawdzić po fakcie.
Co dalej?
- Grupa robocza OpenTelemetry ma sfinalizować wspólny format śledzenia agentów — raport wnosi o dopisanie do niego trwałej tożsamości agenta, zapisu interwencji człowieka i zmian uprawnień, terminu nie podano
- NIST kontynuuje prace nad standardem tożsamości agentów po wrześniowej turze komentarzy do dokumentu koncepcyjnego
- Standaryzacja zapisów „jak agent zdecydował” pozostaje wstrzymana do czasu rozstrzygnięcia, czy chain of thought odzwierciedla faktyczny proces decyzyjny modelu
Źródła
- MIT Technology Review — We urgently need to monitor AI agents' actions in real time
- Partnership on AI — The Observability Gap in AI Agents
- NIST — Comments on Software and Agentic AI Identity Concept Paper
