Observability für KI-Agenten: Logs, Traces, Kosten und Fehler

Ein KI-Agent trifft während eines Laufs mehrere Entscheidungen: welches Tool er aufruft, mit welchen Parametern, in welcher Reihenfolge, und wann er den Lauf beendet. Ohne Aufzeichnung dieser Schritte ist im Nachhinein nicht mehr nachvollziehbar, warum eine bestimmte Aktion gewählt wurde – bei einem fehlerhaften Ergebnis bleibt nur Rätselraten. Observability schließt genau diese Lücke: Sie macht sichtbar, was ein Agent tatsächlich getan hat, nicht nur, was er tun sollte.

Dieser Artikel beantwortet die zentralen Fragen dazu: Was gehört ins Log, wie verfolgst du Modell- und Tool-Schritte, wie misst du Kosten und Latenz, was darf aus Datenschutzgründen nicht geloggt werden, und wie analysierst du Fehler systematisch. Eingeordnet ins Cluster KI-Agenten, das Grundbegriffe, Architekturen und Kontrollmechanismen für agentische Systeme in KMU behandelt.

Das Problem: Agenten sind keine Skripte

Ein klassisches Skript oder ein starrer Workflow tut bei gleicher Eingabe immer dasselbe – Fehler sind meist deterministisch reproduzierbar. Ein KI-Agent nicht: Er entscheidet auf Basis eines Sprachmodells, welchen Schritt er als Nächstes geht, welches Tool er aufruft und wann er aufhört. Dieselbe Eingabe kann an unterschiedlichen Tagen zu unterschiedlichen Pfaden führen. Das ist der eigentliche Nutzen agentischer Systeme – Flexibilität statt starrer Regeln – und gleichzeitig ihr größtes Betriebsrisiko.

Ohne Beobachtbarkeit stehst du bei einem Vorfall vor drei Problemen gleichzeitig: Du weißt nicht, welcher Schritt im Ablauf fehlgeschlagen ist, du kannst den Zustand zum Zeitpunkt des Fehlers nicht rekonstruieren, und du hast keine Vergleichsbasis, um zu sehen, ob es sich um einen Einzelfall oder ein Muster handelt. Für ein internes Experiment mag das tolerierbar sein. Sobald ein Agent Aktionen mit echten Konsequenzen ausführt – eine E-Mail verschickt, einen Datensatz ändert, eine Bestellung auslöst – wird Beobachtbarkeit zur Voraussetzung für kontrollierten Betrieb, nicht zur Kür.

Dieser Artikel richtet sich an Geschäftsführung, Operations, IT und Fachbereiche in KMU, die einen ersten Agenten produktiv betreiben oder kurz davor stehen und wissen wollen, welches Minimum an Beobachtbarkeit dafür nötig ist – ohne gleich eine komplette Observability-Plattform aufzubauen.

Begriffe kurz geklärt

Vier Begriffe werden oft synonym benutzt, meinen aber unterschiedliche Dinge:

• Logging hält einzelne Ereignisse fest – eine Zeile pro Vorkommnis, etwa „Tool X wurde mit Parameter Y aufgerufen, Ergebnis Z”. Logs sind die Rohdaten.
• Monitoring beobachtet vorab definierte Kennzahlen über die Zeit, etwa Fehlerrate oder durchschnittliche Latenz, meist mit Schwellenwerten und Alarmen.
• Tracing verbindet die Einzelereignisse eines konkreten Laufs zu einer zusammenhängenden Kette: welcher Schritt hat welchen Folgeschritt ausgelöst, wie lange hat jeder Schritt gedauert, wo lag der Ausgangspunkt.
• Observability ist die Fähigkeit, aus der Kombination von Logs, Traces und Metriken auch unbekannte Fragen zu beantworten – nicht nur „ist der Fehlerwert über dem Schwellenwert”, sondern „warum genau ist dieser eine Lauf gescheitert”.

Für Agenten kommt eine weitere Ebene hinzu, die klassisches Anwendungs-Monitoring nicht abdeckt: der Entscheidungspfad des Modells selbst – welcher Prompt, welche Zwischenschritte, welche Tool-Auswahl, welche Begründung, sofern das Modell eine liefert. Der offene Standard OpenTelemetry hat dafür 2026 eigene semantische Konventionen für generative KI definiert (GenAI Semantic Conventions), die das Vokabular für Agent-Spans, Modellaufrufe und Tool-Aufrufe festlegen, damit Traces zwischen unterschiedlichen Tools vergleichbar bleiben.

Was sollte geloggt werden?

Die kurze Antwort steht in der Direktantwort oben. Ausführlicher, pro Agentenlauf:

• Run-ID: ein eindeutiger Bezeichner, der alle Schritte eines Laufs verknüpft. Ohne ihn lässt sich kein zusammenhängender Trace bilden.
• Eingabe und Kontext: die auslösende Anfrage oder das Ereignis, plus die System-Instruktion, mit der der Agent gestartet wurde.
• Jeder Tool-Aufruf: Name des Tools, übergebene Parameter, zurückgegebenes Ergebnis, Zeitstempel und Dauer.
• Jeder Modellaufruf: welches Modell, wie viele Eingabe- und Ausgabe-Token, der Finish-Reason (regulär beendet, wegen Tool-Aufruf abgebrochen, wegen Längenlimit gekappt, wegen Fehler abgebrochen).
• Zwischenzustände bei mehrstufigen Läufen: bei Multi-Step-Agenten der Zustand nach jedem Schritt, nicht nur Start und Ende.
• Endstatus: erfolgreich abgeschlossen, mit Fehler abgebrochen, durch einen Menschen gestoppt oder durch ein Zeit- beziehungsweise Kostenlimit beendet.

Die OpenTelemetry-GenAI-Konventionen bilden genau diese Struktur in standardisierten Attributen ab: gen_ai.request.model für das verwendete Modell, gen_ai.usage.input_tokens und gen_ai.usage.output_tokens für den Tokenverbrauch, gen_ai.response.finish_reasons für den Abschlussgrund. Wichtig für die Praxis: Standardmäßig werden dabei keine Prompt- oder Antwortinhalte erfasst, sondern nur Metadaten wie Modellname, Tokenzahlen und Dauer – die eigentlichen Inhalte (gen_ai.input.messages, gen_ai.output.messages) müssen explizit aktiviert werden. Das ist eine bewusste Sicherheitsentscheidung des Standards, auf die der Abschnitt zu sensiblen Daten weiter unten zurückkommt.

Wenn du eine Automatisierungsplattform statt eigenem Code nutzt, bringt die Plattform oft schon Grundlogging mit. n8n etwa protokolliert seit den 2.x-Versionen Workflow-Ausführungen inklusive Status, Dauer und Knotenzahl und hat mit den Versionen 2.16 bis 2.20 gezielt Telemetrie für KI-Agenten-Knoten ergänzt – node-level Spans, Workflow-Versions-IDs und ab Version 2.20 explizite Agent-Telemetrie. Für audit-relevante Ereignisse wie Aktivierung, Deaktivierung oder Änderungen an Variablen gibt es seit Version 2.2.0 zusätzliche Log-Streaming-Ereignisse mit granularer Parameter-Nachverfolgung. Wer eine solche Plattform nutzt, sollte prüfen, was davon standardmäßig aktiv ist und was manuell eingeschaltet werden muss – Grundlogging heißt nicht automatisch vollständiges Tracing.

Wie verfolgt man Modell- und Tool-Schritte?

Einzelne Logzeilen reichen nicht, um einen Agentenlauf zu verstehen – du brauchst den Zusammenhang. Genau das leistet Tracing: Ein Trace bildet den gesamten Lauf als Baum aus Spans ab. In der Struktur, die sich mit den OpenTelemetry-GenAI-Konventionen als gemeinsamer Standard etabliert hat, sieht das so aus:

• Ein übergeordneter invoke_agent-Span für den gesamten Lauf.
• Darunter je ein chat-Span pro Modellaufruf, mit Attributen wie Modell, Tokenverbrauch und Finish-Reason.
• Ebenfalls darunter je ein execute_tool-Span pro Tool-Aufruf, mit Werkzeugname, Parametern und Ergebnis.

Jeder Span trägt Start- und Endzeitpunkt, sodass sich Latenz pro Schritt und für den Gesamtlauf direkt ablesen lässt. Der Vorteil gegenüber isolierten Logs: Du siehst nicht nur, dass ein Tool-Aufruf fehlgeschlagen ist, sondern auch, welcher Modellaufruf ihn ausgelöst hat und was danach passierte – ob der Agent den Fehler erkannt und einen alternativen Pfad gewählt hat oder blind weitergelaufen ist.

Technisch lässt sich das mit gängiger Observability-Infrastruktur umsetzen, ohne proprietäre Exporter zu bauen: n8n etwa sendet OpenTelemetry-Traces für Workflow-Ausführungen an kompatible Backends wie Jaeger, Grafana Tempo, Honeycomb, Datadog, New Relic oder Splunk – aktiviert über zwei Umgebungsvariablen (N8N_OTEL_ENABLED und die Endpunkt-Adresse des Collectors). Wer eigenen Agenten-Code betreibt (etwa mit LangChain oder einem vergleichbaren Framework), kann auf dieselbe offene Instrumentierung setzen, statt sich an ein einzelnes Anbieter-Dashboard zu binden.

Für den Einstieg reicht ein einzelner Trace-Baum pro Lauf, sichtbar in einem beliebigen OTel-kompatiblen Tool. Erst wenn mehrere Agenten oder Teams beteiligt sind, lohnt sich zusätzlich ein Feld für Trace-übergreifenden Kontext (z. B. welcher Geschäftsprozess, welcher Kunde, welche Umgebung), damit sich Traces filtern und vergleichen lassen.

Wie misst man Kosten und Latenz?

Kosten entstehen bei den meisten Agenten fast ausschließlich durch Modellaufrufe, abgerechnet nach Token. Die Grundrechnung: Eingabe-Token plus Ausgabe-Token pro Modellaufruf, multipliziert mit dem jeweiligen Preis des Anbieters für Eingabe und Ausgabe getrennt (die unterscheiden sich meist deutlich). Diese Zahlen liefert dir das Tracing ohnehin mit, wenn du gen_ai.usage.input_tokens und gen_ai.usage.output_tokens pro Span erfasst. Aggregierst du das pro Run-ID, bekommst du die Kosten eines einzelnen Agentenlaufs; aggregierst du über einen Zeitraum oder einen Geschäftsprozess, siehst du die laufenden Betriebskosten. Wichtig für die Zuordnung im Betrieb: Kosten sollten nicht nur auf Cloud-Konto-Ebene sichtbar sein, sondern auf den Geschäftsprozess herunterbrechbar, der sie verursacht – sonst lässt sich der Nutzen eines Agenten seinem Aufwand nie gegenüberstellen.

Latenz misst du auf zwei Ebenen: pro Einzelschritt (ein Modellaufruf, ein Tool-Aufruf) und für den Gesamtlauf. Beides ergibt sich direkt aus den Start- und Endzeitstempeln der Spans, ohne zusätzliche Instrumentierung. Für die Praxis ist die Aufschlüsselung nach Schritt entscheidend: Ein insgesamt langsamer Lauf kann an einem einzelnen langsamen externen Tool liegen (zum Beispiel einer angebundenen API) statt am Sprachmodell selbst – das siehst du nur, wenn Latenz pro Span erfasst wird, nicht nur als eine Gesamtzahl.

Zwei Metriken decken diese beiden Größen meist ab: eine Latenz-Verteilung pro Aufrufart (Histogramm) und eine Tokenverbrauchs-Verteilung, optional gefiltert nach Eingabe- oder Ausgabe-Token. Beide lassen sich, sobald Tracing eingerichtet ist, mit Standard-Observability-Werkzeugen darstellen – eigene Dashboards musst du dafür in der Regel nicht bauen.

Was darf nicht ins Log?

Das ist die Kehrseite eines guten Logging-Setups: Je detaillierter du protokollierst, desto eher landen sensible Inhalte im Log. Drei Kategorien gehören nicht ungeschützt ins Standardlog:

1. Zugangsdaten und Geheimnisse. API-Schlüssel, Passwörter, Zugriffstoken – wenn ein Tool-Aufruf solche Werte als Parameter enthält, dürfen sie im Log nicht im Klartext erscheinen. Das ist keine KI-spezifische Regel, gilt aber für Agenten besonders, weil Tool-Parameter oft automatisch aus vorherigen Schritten übernommen werden und leicht unbemerkt mitgeloggt werden.
2. Personenbezogene Daten in Prompts und Antworten. Wenn ein Agent mit Kundendaten arbeitet, landen diese potenziell im Prompt, in Zwischenergebnissen und in der Modellantwort. Das BSI weist in seiner Publikation zu generativen KI-Modellen darauf hin, dass generierte Inhalte unbeabsichtigt personenbezogene oder geschützte Daten reproduzieren können, und ordnet dies neben Risiken durch bestimmungsgemäßen Gebrauch auch als Angriffsfläche ein (sogenannte Privacy Attacks, bei denen sensible Trainings- oder Kontextdaten rekonstruiert werden – nicht nur mit Personenbezug, auch Geschäftsgeheimnisse können betroffen sein). Genau deshalb ist die Standardeinstellung der OpenTelemetry-GenAI-Konventionen bewusst restriktiv: Prompt- und Antwortinhalte werden nur bei explizitem Opt-in erfasst, nicht automatisch.
3. Unstrukturierte Rohdaten ohne Zweckbindung. Selbst wenn keine offensichtlich sensiblen Daten enthalten sind, gilt für personenbezogene Daten grundsätzlich das Prinzip der Datenminimierung: Was du nicht für die Fehleranalyse brauchst, solltest du nicht dauerhaft speichern.

Praktisch heißt das für den Betrieb: Metadaten (Modell, Tokenzahl, Dauer, Tool-Name, Status) können großzügig geloggt werden – sie sind für Observability wertvoll und in aller Regel unkritisch. Inhalte (tatsächlicher Prompt-Text, tatsächliche Modellantwort, tatsächliche Tool-Parameter mit Nutzdaten) brauchen eine bewusste Entscheidung: maskieren (z. B. bekannte Muster wie E-Mail-Adressen oder IBANs vor dem Log entfernen), stichprobenartig statt vollständig erfassen, oder nur in einer separat abgesicherten Umgebung mit kurzer Aufbewahrungsfrist speichern. Für Details zur konkreten DSGVO-Bewertung eures Setups – Rechtsgrundlage, Auftragsverarbeitung, Aufbewahrungsfristen – ist das Thema Sache eurer Datenschutzbeauftragten oder Rechtsberatung; dieser Artikel ersetzt das nicht (Stand Juli 2026).

Wie analysiert man Fehler?

Fehleranalyse bei Agenten unterscheidet sich von klassischem Debugging, weil es meist keinen einzelnen reproduzierbaren Fehlerpfad gibt. Ein sinnvolles Vorgehen in drei Schritten:

1. Den vollständigen Trace des fehlgeschlagenen Laufs lesen, nicht nur die letzte Fehlermeldung. Welcher Schritt in der Kette war der letzte, der noch normal lief? Was war die Eingabe an genau dieser Stelle – nicht die ursprüngliche Anfrage, sondern der Zwischenzustand? Welches Ergebnis kam vom Modell oder vom aufgerufenen Tool zurück, und entspricht der Finish-Reason einem regulären Abschluss oder einem Abbruch?

2. Mit erfolgreichen Läufen vergleichen. Ein einzelner fehlgeschlagener Trace zeigt, was passiert ist. Der Vergleich mit Traces ähnlicher, erfolgreicher Läufe zeigt, wo genau der Unterschied liegt – oft an einer Stelle, die auf den ersten Blick unauffällig wirkt, etwa einer leicht abweichenden Tool-Antwort, die der Agent anders interpretiert.

3. Muster statt Einzelfälle suchen. Ein einzelner Fehler ist ein Vorfall; drei ähnliche Fehler in derselben Woche sind ein Muster, das eine Ursache hat – ein instabiles externes Tool, ein Prompt, der bei bestimmten Eingaben unzuverlässig wird, ein Grenzfall in der Datenlage, den niemand bedacht hat. Ohne aggregierte Sicht über mehrere Traces bleibt jede Analyse Einzelfallarbeit. Schon eine einfache Tabelle mit Fehlerart, betroffenem Schritt und Häufigkeit pro Woche macht wiederkehrende Muster sichtbar, ganz ohne dedizierte Analytics-Software.

Wichtig: Nicht jeder Abbruch ist ein „Fehler” im technischen Sinn. Ein Agent, der eine Aktion abbricht, weil ein vorher definiertes Limit erreicht ist (Kosten, Zeit, Anzahl Schritte) oder weil eine Freigabe durch einen Menschen fehlt, arbeitet korrekt – das gehört in eine eigene Kategorie „kontrollierter Abbruch”, nicht in dieselbe Statistik wie technische Fehler. Wie Freigabeschritte für Agenten konkret aussehen, behandelt der Cluster-Artikel zu Human-in-the-Loop-Freigaben.

Umsetzung: ein Reifegradmodell für den Einstieg

Nicht jedes KMU braucht ab Tag eins eine vollständige Observability-Plattform mit eigenem Dashboard. Sinnvoller ist ein stufenweiser Ausbau, der sich am tatsächlichen Risiko des Agenten orientiert – ein interner Rechercheassistent ohne Schreibrechte braucht weniger als ein Agent, der Bestellungen auslöst. Aus meiner Arbeit mit KMU-Agentenprojekten hat sich folgendes dreistufiges Modell bewährt:

Stufe	Was ist vorhanden	Typischer Aufwand	Ausreichend für
1. Minimal	Run-ID, strukturiertes Log pro Schritt (Tool, Status, Dauer), Endstatus	Wenige Stunden, meist mit Bordmitteln der genutzten Plattform	Interne Prototypen und Piloten ohne kritische Aktionen
2. Basis-Tracing	Zusätzlich vollständiger Trace-Baum (Agent-, Modell-, Tool-Spans), Tokenverbrauch, Latenz pro Schritt, Anbindung an ein OTel-kompatibles Backend	Ein bis mehrere Tage Einrichtung, laufende Kosten für Speicherung	Agenten mit begrenzten, aber echten Auswirkungen (z. B. interne Freigaben, Vorsortierung)
3. Fortgeschritten	Zusätzlich Kosten-Aggregation pro Geschäftsprozess, systematische Fehlermuster-Auswertung, definierte Aufbewahrungs- und Maskierungsregeln für Inhalte, Alarmierung bei Anomalien	Laufende Pflege, meist eine benannte Zuständigkeit	Agenten mit Aktionen nach außen oder mit Zugriff auf sensible Daten

Eigenes Reifegradmodell Philogic Labs, abgeleitet aus Beratungs- und Umsetzungsprojekten mit KI-Agenten in KMU.

Die praktische Reihenfolge beim Aufbau: zuerst Tracing (du musst sehen können, was passiert ist), dann Kosten-Zuordnung (du musst wissen, was es kostet), erst danach systematische Fehleranalyse und Alarmierung (du kannst erst Muster erkennen, wenn genug Traces vorliegen). Wer versucht, alle drei Ebenen gleichzeitig einzuführen, verzettelt sich meist in der Tool-Auswahl, bevor überhaupt ein einziger Trace vorliegt.

Ein praktischer Hinweis aus eigener Erfahrung: Der größte Stolperstein ist selten die Technik. Standardisierte Instrumentierung nach dem OpenTelemetry-GenAI-Modell lässt sich in bestehende Infrastruktur einbinden, ohne dass jedes Team ein eigenes Format erfindet. Der größere Aufwand liegt darin, vorher festzulegen, was überhaupt als „normaler” Lauf gilt – ohne diese Referenz bleibt jede Fehleranalyse Bauchgefühl, egal wie viele Daten du sammelst.

Risiken & Grenzen

Observability löst nicht jedes Problem, und sie hat eigene Grenzen:

• Beobachtbarkeit verhindert keine Fehler, sie macht sie sichtbar. Ein Trace erklärt im Nachhinein, warum ein Agent falsch entschieden hat – er verhindert die Fehlentscheidung selbst nicht. Dafür braucht es zusätzlich Prüfschritte, Freigabegrenzen und gute Tests vor dem produktiven Einsatz.
• Mehr Logging ist nicht automatisch besser. Vollständige Inhaltserfassung erhöht das Datenschutzrisiko und die Speicherkosten, ohne notwendigerweise mehr Nutzen zu bringen. Die bewusste Standardeinstellung „keine Inhalte ohne Opt-in” der OpenTelemetry-GenAI-Konventionen ist ein guter Ausgangspunkt, kein Hindernis.
• Traces sind kein Ersatz für Evaluierung. Ein Trace zeigt, was passiert ist – nicht, ob das Ergebnis inhaltlich gut war. Für die Qualität der Agentenantworten braucht es zusätzlich eigene Prüfkriterien und, je nach Kritikalität, stichprobenartige menschliche Bewertung.
• Ohne Zuständigkeit verfällt jedes Setup. Ein Tracing-Dashboard, das niemand regelmäßig ansieht, bringt im Ernstfall nichts. Genau wie beim Betrieb des Agenten selbst braucht auch die Beobachtung eine benannte, wiederkehrende Verantwortung – nicht nur eine einmalige Einrichtung.
• Rechtliche Bewertung ist Einzelfallsache. Ob und in welchem Umfang Logging personenbezogener Daten zulässig ist, hängt vom konkreten Use Case, der Rechtsgrundlage und der Aufbewahrungsdauer ab. Dieser Artikel beschreibt technische Praxis, keine Rechtsberatung (Stand Juli 2026).

Wenn du unsicher bist, wo dein geplanter oder bestehender Agent auf dem Reifegradmodell stehen sollte – und welches Maß an Beobachtbarkeit angesichts seiner tatsächlichen Aktionen angemessen ist – lohnt sich ein strukturierter Blick von außen. Unser Beratungsangebot für kontrollierte KI-Agenten und Systemintegrationen findest du auf der Startseite, ein kostenloses Erstgespräch klärt in 45 Minuten, wo ihr steht.

Checkliste: KI-Agent-Observability einführen

1. Jeder Agentenlauf hat eine eindeutige Run-ID, die alle Schritte verknüpft.
2. Jeder Modellaufruf wird mit Modellname, Tokenverbrauch (Eingabe/Ausgabe) und Finish-Reason erfasst.
3. Jeder Tool-Aufruf wird mit Name, Parametern, Ergebnis, Zeitstempel und Dauer erfasst.
4. Die Schritte eines Laufs sind als zusammenhängender Trace sichtbar, nicht nur als isolierte Logzeilen.
5. Latenz wird pro Schritt und für den Gesamtlauf gemessen, nicht nur als eine Gesamtzahl.
6. Kosten lassen sich pro Lauf und pro Geschäftsprozess aggregieren, nicht nur pro Cloud-Konto.
7. Prompt- und Antwortinhalte werden standardmäßig nicht oder nur maskiert geloggt; volle Inhaltserfassung ist eine bewusste, begründete Ausnahme.
8. Zugangsdaten und Geheimnisse in Tool-Parametern werden vor dem Log ausgefiltert oder maskiert.
9. Es gibt eine Vergleichsbasis für „normale” Läufe, gegen die sich auffällige Traces einordnen lassen.
10. Fehlerbilder werden über die Zeit ausgewertet (Muster), nicht nur einzeln behoben.
11. Kontrollierte Abbrüche (Limits, fehlende Freigabe) sind von technischen Fehlern unterschieden.
12. Es gibt eine benannte Zuständigkeit, die Traces und Kennzahlen regelmäßig ansieht – nicht nur bei Störungen.

Wie du Tool-Zugriffe für Agenten grundsätzlich absicherst und welche Freigabeschritte für kritische Aktionen sinnvoll sind, vertiefen die weiteren Artikel im Cluster KI-Agenten.