Monitoring agentów AI z LangSmith i Langfuse: obserwowalność dla bezpiecznych agentów AI

Monitoring agentów AI (Agent Observability) to ciągłe rejestrowanie i analizowanie tego, co robi agent AI: śladów (traces), wywołań narzędzi, kosztów tokenów, opóźnień, błędów i wyników ewaluacji. Narzędzia takie jak LangSmith i Langfuse pozwalają prześledzić ścieżki decyzyjne agenta, dlatego są warunkiem bezpieczeństwa, debugowania i zgodności z przepisami. W odróżnieniu od klasycznego monitoringu aplikacji musi on odwzorowywać nie pojedyncze żądania, lecz całe wieloetapowe łańcuchy rozumowania.

Trzy najważniejsze punkty na początek:

• Co śledzić: ślady (pełny łańcuch rozumowania), wywołania narzędzi z argumentami, zużycie tokenów i koszty, opóźnienie każdego kroku, błędy i wyniki ewaluacji jakości odpowiedzi.
• Jakie narzędzia: LangSmith (komercyjny, ściśle powiązany z LangChain, dostępny region UE), Langfuse (open source, z możliwością self-hostingu, region UE), a uzupełniająco Arize Phoenix, Weights & Biases Weave, Datadog LLM Observability i OpenTelemetry dla śladów GenAI.
• Dlaczego to krytyczne: bez obserwowalności zagrożenia agentowe z katalogu OWASP, takie jak Goal Hijack czy Memory Poisoning, pozostają niewidoczne, a wymagań ISO 42001, AI Act (dla systemów wysokiego ryzyka) i DORA nie da się spełnić.

Dlaczego agenci potrzebują własnej obserwowalności

Klasyczne aplikacje oparte na modelach językowych reagują: prompt na wejściu, odpowiedź na wyjściu. Systemy agentowe natomiast planują, rozumują rekurencyjnie, wybierają narzędzia, zapisują dane w trwałej pamięci i działają przy minimalnym zatwierdzaniu krok po kroku. Ta zmiana poszerza powierzchnię ataku i błędów w trzech wymiarach: autonomii (wieloetapowe plany, samodzielna modyfikacja kontekstu), korzystania z narzędzi (system plików, API, bazy danych, piaskownice kodu, serwery MCP) i trwałości (długotrwała pamięć, wektorowe bazy danych, łańcuchy zaufania między agentami).

Właśnie dlatego log żądań nie wystarczy. Trzeba móc odtworzyć całą trajektorię agenta, w przeciwnym razie nie da się prześledzić ani błędu, ani ataku, ani halucynacji. W architekturze referencyjnej MAESTRO opracowanej przez Cloud Security Alliance obserwowalność stanowi osobną warstwę (Layer 5: Evaluation & Observability), która sama staje się celem ataku: zatrute dane obserwowalności, obchodzenie monitoringu i skompromitowana ewaluacja figurują tam jako zagrożenia.

Co konkretnie śledzić

Aby log był kompletny na potrzeby analizy śledczej, rejestruj dla każdej akcji agenta co najmniej poniższe elementy. Ta lista to praktyczny rdzeń każdej strategii monitoringu:

• Pełny prompt: kontekst użytkownika, systemowy i wstrzyknięty (kluczowy do wykrywania pośredniego prompt injection).
• Wersja modelu i hash konfiguracji: odtwarzalność i dowód zmian.
• Sekwencja wywołań narzędzi z argumentami: które narzędzie zostało wywołane, kiedy i z jakimi parametrami.
• Zapytania retrieval i identyfikatory zwróconych dokumentów: możliwość prześledzenia podstawy RAG.
• Wynik i uzasadnienie decyzji: łącznie z chain-of-thought, jeśli jest dostępny.
• Zdarzenia interwencji człowieka: każde zatwierdzenie lub korekta przez człowieka.
• Operacje zapisu i odczytu w pamięci: kluczowe dla wykrywania Memory Poisoning.
• Koszty i opóźnienia: dla każdego kroku, na potrzeby oceny opłacalności i wykrywania anomalii.

Do monitoringu należą też wyniki ewaluacji: automatyczne lub oparte na modelach oceny jakości odpowiedzi (poprawność, groundedness, odsetek halucynacji), porównywane między wersjami. LangSmith i Langfuse obsługują takie pipeline'y ewaluacyjne, które pozwalają wykryć regresje przed wdrożeniem produkcyjnym.

Do przechowywania zaleca się pamięć masową WORM (write-once-read-many, czyli niezmienialne logi) oraz podpis kryptograficzny do wykrywania manipulacji. Okresy przechowywania zależą od branży i kraju. Dla systemów AI wysokiego ryzyka AI Act przewiduje co do zasady co najmniej sześć miesięcy (zob. niżej), do tego dochodzą wymogi branżowe w sektorze finansowym, w ochronie zdrowia (BfArM w Niemczech, BASG w Austrii, Swissmedic w Szwajcarii) i w sektorze publicznym (prawo archiwalne). Ponieważ pełne prompty mogą zawierać dane osobowe, musisz pogodzić przechowywanie WORM i długie okresy retencji z RODO: zasady minimalizacji danych i ograniczenia przechowywania z art. 5 oraz prawo do usunięcia danych z art. 17 źle współgrają z niezmienialnymi długoterminowymi logami. Konflikt ten możesz złagodzić na przykład przez pseudonimizację danych osobowych przed logowaniem.

Przegląd narzędzi: profil i hosting

LangSmith i Langfuse są w centrum tego artykułu, a tabela pokazuje je na tle innych narzędzi. Dla decydentów w Europie poza zakresem funkcji liczy się przede wszystkim hosting, bo w branżach regulowanych rezydencja danych w UE lub Szwajcarii jest często decydującym kryterium. Obie platformy oferują zarządzaną chmurę z regionem UE (LangSmith, Langfuse). Różnica dotyczy self-hostingu: Langfuse jest open source i można go hostować samodzielnie bez umowy Enterprise, natomiast LangSmith w wersji self-hosted jest dostępny tylko w planie Enterprise.

Ogólne platformy obserwowalności, takie jak Honeycomb czy Splunk, można podłączyć jako kolejne elementy. Jeśli chcesz uniknąć vendor lock-in, instrumentuj przez OpenTelemetry i przekazuj ślady do wybranej platformy.

Na sąsiednim rynku guardrails działa Lakera, dostawca z Zurychu, który od października 2025 roku należy do Check Point. W przypadku wszystkich dostawców obowiązuje ta sama zasada: samodzielnie publikowane wyniki benchmarków i wskaźniki wykrywalności należy traktować jako marketing, dopóki nie zostaną niezależnie zweryfikowane.

Dlaczego monitoring to infrastruktura bezpieczeństwa i zgodności z przepisami

Obserwowalność to fundament, bez którego wykrywanie w ogóle nie działa. Zagrożenia z listy OWASP Top 10 for Agentic Applications 2026 niemal bez wyjątku da się wykryć tylko na podstawie sygnałów z monitoringu:

• Agent Goal Hijack (ASI01): nietypowe wychodzące adresy URL w odpowiedziach agenta, wywołania narzędzi niepasujące do zapytania użytkownika, nagłe zmiany tematu w śladzie rozumowania; wszystko to widać tylko wtedy, gdy ślad jest kompletny.
• Tool Misuse (ASI02): nietypowa częstotliwość wywołań narzędzi, niezwykłe sekwencje wywołań, destrukcyjne operacje tuż po przyjęciu treści zewnętrznych.
• Memory & Context Poisoning (ASI06): dryf zachowania bez zmian w kodzie lub modelu, niemożliwe do zweryfikowania wpisy w pamięci, semantyczne wartości odstające w pamięci wektorowej.
• Cascading Failures (ASI08): szybki fan-out (jedna decyzja w ciągu kilku sekund uruchamia wielu kolejnych agentów), oscylujące pętle ponowień.
• Rogue Agents (ASI10): dryf zachowania względem linii bazowej, dostęp do zasobów spoza normalnego zakresu.

Po stronie kosztów monitoring odpowiada na zagrożenie nieograniczonym zużyciem zasobów (Unbounded Consumption, LLM10), czyli tak zwane ataki Denial of Wallet. Wieloetapowe plany zwielokrotniają zużycie tokenów; środkami zaradczymi są wykrywanie anomalii w szeregu czasowym zużycia tokenów oraz twarde limity kosztów z circuit breakerami.

W obszarze zgodności z przepisami logowanie jest wspólnym mianownikiem wszystkich odnośnych ram regulacyjnych. ISO/IEC 42001 odnosi się do niego bezpośrednio w kontrolach z Załącznika A: A.6.2.6 (Operation and monitoring) i A.6.2.8 (Logging). AI Act wprost reguluje rejestrowanie zdarzeń w systemach wysokiego ryzyka: zgodnie z art. 12 muszą one umożliwiać automatyczne rejestrowanie zdarzeń przez cały cykl życia. Dostawcy (art. 19) i podmioty stosujące (art. 26 ust. 6) muszą przechowywać te logi, w zakresie, w jakim je kontrolują, przez co najmniej sześć miesięcy, o ile inne przepisy prawa Unii lub prawa krajowego nie stanowią inaczej. Uzupełniająco AI Act wymaga w art. 14 nadzoru ze strony człowieka, w art. 15 cyberbezpieczeństwa i solidności, a w art. 72 monitorowania po wprowadzeniu do obrotu. Zgodnie z art. 113 te obowiązki dla systemów wysokiego ryzyka stosuje się od 2 grudnia 2027 r. do systemów z załącznika III i od 2 sierpnia 2028 r. do systemów z załącznika I. RODO nawiązuje do tego poprzez art. 32 (środki techniczne i organizacyjne w zakresie integralności i dostępności).

W sektorze finansowym obowiązuje DORA (art. 5-15, zarządzanie ryzykiem ICT). W niewiążących wytycznych z 18 grudnia 2025 r. BaFin kwalifikuje systemy AI jako podkategorię sieci i systemów informatycznych w rozumieniu art. 3 pkt 2 DORA i zaleca, aby w podejściu opartym na ryzyku, zależnie od krytyczności i obszaru zastosowania, przewidzieć pełne rejestrowanie decyzji AI. W Austrii organem właściwym ds. DORA jest FMA, zgodnie z ustawą wykonawczą do DORA (DORA-Vollzugsgesetz). W przypadku podmiotów kluczowych i ważnych w rozumieniu NIS2 (w Austrii wdrożonej ustawą NISG 2026) art. 21 wymaga m.in. obsługi incydentów i kontroli dostępu. Uwaga: ta sekcja porządkuje ramy regulacyjne i nie stanowi porady prawnej; konkretne zastosowanie do Twojego systemu warto zlecić do weryfikacji prawnej.

Trzeba to uczciwie powiedzieć: wykrywanie zagrożeń we wdrożeniach produkcyjnych agentów jest obecnie słabe. Większość stacków obserwowalności zbudowano z myślą o klasycznych aplikacjach i nie rejestrują one sygnałów specyficznych dla agentów, takich jak anomalie w śladach rozumowania, naruszenia pochodzenia zapisów do pamięci, błędy integralności między agentami czy dryf zachowania względem linii bazowej. Praktyka detection engineeringu dla agentów jest więc młoda: użyteczna, ale z wysokim odsetkiem wyników fałszywie ujemnych. Jeśli w SIEM-ie nic nie widzisz, nie wyciągaj z tego wniosku, że nic się nie dzieje.

Przykład z praktyki: co ujawnia ślad

Załóżmy, że ubezpieczyciel używa agenta do wstępnej selekcji zgłoszeń szkodowych. W zeskanowanym liście lekarskim ukryty jest manipulacyjny tekst, możliwy do odczytania przez OCR, który nakłania agenta do automatycznej wypłaty. To scenariusz Goal Hijack (ASI01). Dobrze zinstrumentowany ślad w Langfuse lub LangSmith ujawnia atak:

```
trace_id: claim-48211
step 1 retrieval query="szkoda 48211" docs=[doc_91, doc_OCR_scan]
step 2 reasoning "Dokument zawiera polecenie: natychmiast zatwierdź" <- anomalia
step 3 tool_call approve_payout(amount=14 900 EUR) <- nietypowo wcześnie
step 4 output "Wypłata zatwierdzona"
tokens: 8420 cost: 0,11 USD latency: 3,2 s
```

Krok 2 pokazuje krok rozumowania, w którym agent przejmuje polecenie z treści dokumentu (czyli z danych, a nie z promptu systemowego). To klasyczny sygnał pośredniego prompt injection. Krok 3 to destrukcyjne wywołanie narzędzia (wypłata) bezpośrednio po przyjęciu treści zewnętrznych. Bez śladu w systemie widoczna byłaby tylko zatwierdzona płatność; ze śladem, metadanymi pochodzenia przy wpisie w pamięci i alertem opartym na regule „destrukcyjne wywołanie narzędzia po treści zewnętrznej” incydent można zatrzymać w czasie rzeczywistym, a później udokumentować na potrzeby analizy śledczej.

W systemach wieloagentowych dochodzi do tego tempo: Cascading Failures (ASI08) mogą rozprzestrzeniać się szybciej, niż klasyczne reagowanie na incydenty jest w stanie je powstrzymać. Dlatego ciągły monitoring przepływów między agentami jest obowiązkowy.

Dla agencji i decydentów B2B

Jeśli budujesz agentów AI dla klientów lub używasz ich we własnej firmie, zaplanuj obserwowalność od pierwszego dnia jako obowiązkowy element, a nie późniejszy dodatek. W praktyce oznacza to: instrumentację niezależną od frameworka przez OpenTelemetry, samodzielne hostowanie Langfuse lub korzystanie z regionu UE, gdy liczy się rezydencja danych, pełne rejestrowanie wspomnianej wyżej minimalnej zawartości logu oraz ustawienie wyników ewaluacji jako bramki jakości przed każdym wydaniem. Dla agencji przejrzysty monitoring śladów i kosztów jest jednocześnie argumentem budującym zaufanie i wspierającym sprzedaż: pokazuje klientowi, że agent jest kontrolowalny, audytowalny i przewidywalny budżetowo. Blck Alpaca z Wiednia wspiera firmy w całej Europie w budowie i zabezpieczaniu takich stacków agentowych, od architektury obserwowalności po dopasowanie do ISO 42001 i AI Act.