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

Das Wichtigste in Kürze:

• Logge pro Agentenlauf Run-ID, Prompt, Tool-Aufrufe, Tokenverbrauch, Latenz und Endstatus.
• Tracing verbindet alle Schritte eines Laufs zu einem Baum aus Spans, standardisiert über die OpenTelemetry-GenAI-Konventionen.
• Kosten ergeben sich aus den geloggten Token mal Anbieterpreis, aggregiert pro Lauf oder Geschäftsprozess.
• Prompt- und Antwortinhalte bleiben standardmäßig draußen; sie werden nur maskiert oder mit klarer Rechtsgrundlage erfasst.

Ein KI-Agent trifft während eines Laufs mehrere Entscheidungen. Er wählt Tools, Parameter und Reihenfolge, und er entscheidet, wann der Lauf endet. Ohne Aufzeichnung dieser Schritte bleibt später unklar, warum eine Aktion gewählt wurde. Dann 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 ist das Ganze 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 zugleich ihr größtes Betriebsrisiko.

Ohne Beobachtbarkeit stehst du bei einem Vorfall vor 3 Problemen gleichzeitig. Du weißt nicht, welcher Schritt im Ablauf fehlgeschlagen ist. Du kannst den Zustand zum Zeitpunkt des Fehlers nicht rekonstruieren. Und dir fehlt die Vergleichsbasis, um Einzelfall von Muster zu unterscheiden. Für ein internes Experiment mag das tolerierbar sein.

Sobald ein Agent Aktionen mit echten Konsequenzen ausführt, ändert sich das. Er verschickt eine E-Mail, ändert einen Datensatz, löst eine Bestellung aus. Dann 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. Gemeint sind Teams, die einen ersten Agenten produktiv betreiben oder kurz davor stehen. Sie erfahren, 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. Gemeint sind 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 Logs, Traces und Metriken auch unbekannte Fragen zu beantworten. Also nicht nur „ist der Fehlerwert über dem Schwellenwert“, sondern „warum genau ist dieser eine Lauf gescheitert“.

Für Agenten kommt eine Ebene hinzu, die klassisches Anwendungs-Monitoring nicht abdeckt: der Entscheidungspfad des Modells selbst. Dazu zählen der Prompt, die Zwischenschritte, die Tool-Auswahl und die 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). Sie legen das Vokabular für Agent-Spans, Modellaufrufe und Tool-Aufrufe fest, 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 steht für das verwendete Modell.

• gen_ai.usage.input_tokens und gen_ai.usage.output_tokens erfassen den Tokenverbrauch.

• gen_ai.response.finish_reasons hält den Abschlussgrund fest.

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, also die Eingabe- und Ausgabe-Messages, müssen explizit aktiviert werden. Das ist eine bewusste Sicherheitsentscheidung des Standards; der Abschnitt zu sensiblen Daten weiter unten kommt darauf zurück.

Wenn du eine Automatisierungsplattform statt eigenem Code nutzt, bringt sie oft schon Grundlogging mit. n8n etwa protokolliert seit den 2.x-Versionen Workflow-Ausführungen inklusive Status, Dauer und Knotenzahl.

Mit den Versionen 2.16 bis 2.20 kam gezielt Telemetrie für KI-Agenten-Knoten hinzu: 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 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. Die OpenTelemetry-GenAI-Konventionen haben sich dafür als gemeinsamer Standard etabliert. Die Struktur sieht so aus:

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

Jeder Span trägt Start- und Endzeitpunkt. Damit lässt sich Latenz pro Schritt und für den Gesamtlauf direkt ablesen. 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. Hat der Agent den Fehler erkannt und einen alternativen Pfad gewählt, oder ist er blind weitergelaufen?

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 wird das über 2 Umgebungsvariablen (N8N_OTEL_ENABLED und die Endpunkt-Adresse des Collectors). Mehr braucht es nicht. 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, zum Beispiel Geschäftsprozess, Kunde oder Umgebung. So lassen sich Traces filtern und vergleichen.

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 Anbieterpreis für Eingabe und Ausgabe getrennt. Mehr steckt nicht dahinter. Die beiden Preise unterscheiden sich meist deutlich. Diese Zahlen liefert dir das Tracing ohnehin mit, wenn du die beiden Token-Attribute 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 verursachenden Geschäftsprozess herunterbrechbar. Sonst lässt sich der Nutzen eines Agenten seinem Aufwand nie gegenüberstellen.

Latenz misst du auf 2 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.

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

Was darf nicht ins Log?

Das ist die Kehrseite eines guten Logging-Setups. Je detaillierter du protokollierst, desto eher landen sensible Inhalte im Log. 3 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 für Agenten aber besonders. Tool-Parameter werden oft automatisch aus vorherigen Schritten übernommen und leicht unbemerkt mitgeloggt.

2. Personenbezogene Daten in Prompts und Antworten. Arbeitet ein Agent mit Kundendaten, 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. Es ordnet dies auch als Angriffsfläche ein: sogenannte Privacy Attacks, bei denen sensible Trainings- oder Kontextdaten rekonstruiert werden. Betroffen sind nicht nur Daten mit Personenbezug, auch Geschäftsgeheimnisse.

3. Unstrukturierte Rohdaten ohne Zweckbindung. Selbst ohne offensichtlich sensible Inhalte gilt für personenbezogene Daten das Prinzip der Datenminimierung. Was du nicht für die Fehleranalyse brauchst, solltest du nicht dauerhaft speichern.

Genau deshalb ist die Standardeinstellung der OpenTelemetry-GenAI-Konventionen bewusst restriktiv: Prompt- und Antwortinhalte werden nur bei explizitem Opt-in erfasst, nicht automatisch.

Praktisch heißt das für den Betrieb: Metadaten wie Modell, Tokenzahl, Dauer, Tool-Name und Status können großzügig geloggt werden. Sie sind für Observability wertvoll und in aller Regel unkritisch. Inhalte wie der tatsächliche Prompt-Text, die Modellantwort oder Tool-Parameter mit Nutzdaten brauchen dagegen eine bewusste Entscheidung. Drei Wege haben sich bewährt. Erstens maskieren, also bekannte Muster wie E-Mail-Adressen oder IBANs vor dem Log entfernen. Zweitens stichprobenartig statt vollständig erfassen, drittens Inhalte nur in einer separat abgesicherten Umgebung mit kurzer Aufbewahrungsfrist speichern.

Die konkrete DSGVO-Bewertung eures Setups (Rechtsgrundlage, Auftragsverarbeitung, Aufbewahrungsfristen) ist 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. Meist gibt es keinen einzelnen reproduzierbaren Fehlerpfad. Das ist normal. Ein sinnvolles Vorgehen hat 3 Schritte.

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, also der Zwischenzustand statt der ursprünglichen Anfrage? Welches Ergebnis kam vom Modell oder Tool zurück, und zeigt der Finish-Reason einen regulären Abschluss oder einen 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 ist es eine Stelle, die auf den ersten Blick unauffällig wirkt: etwa eine leicht abweichende Tool-Antwort, die der Agent anders interpretiert.

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

Wichtig: Nicht jeder Abbruch ist ein „Fehler“ im technischen Sinn. Ein Agent, der wegen eines definierten Limits (Kosten, Zeit, Anzahl Schritte) oder einer fehlenden menschlichen Freigabe stoppt, arbeitet korrekt. Solche Fälle gehören 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 ein Modell mit 3 Stufen bewährt.

Stufe 1, Minimal: Run-ID, strukturiertes Log pro Schritt (Tool, Status, Dauer) und Endstatus. Der Aufwand liegt bei wenigen Stunden, meist mit Bordmitteln der genutzten Plattform. Das reicht für interne Prototypen und Piloten ohne kritische Aktionen.

Stufe 2, Basis-Tracing: Zusätzlich ein vollständiger Trace-Baum (Agent-, Modell- und Tool-Spans), Tokenverbrauch, Latenz pro Schritt und die Anbindung an ein OTel-kompatibles Backend. Die Einrichtung dauert einen bis mehrere Tage, dazu kommen laufende Kosten für Speicherung. Das reicht für Agenten mit begrenzten, aber echten Auswirkungen, etwa interne Freigaben oder Vorsortierung.

Stufe 3, Fortgeschritten: Zusätzlich Kosten-Aggregation pro Geschäftsprozess, systematische Fehlermuster-Auswertung, definierte Aufbewahrungs- und Maskierungsregeln für Inhalte sowie Alarmierung bei Anomalien. Das erfordert laufende Pflege und meist eine benannte Zuständigkeit. Nötig ist diese Stufe für 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, denn du musst sehen können, was passiert ist. Dann folgt die Kosten-Zuordnung, denn du musst wissen, was es kostet. Erst danach kommen systematische Fehleranalyse und Alarmierung, denn Muster erkennst du erst, wenn genug Traces vorliegen. Wer alle drei Ebenen gleichzeitig einführen will, 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. Sie hat eigene Grenzen.

• Beobachtbarkeit verhindert keine Fehler, sie macht sie sichtbar. Ein Trace erklärt im Nachhinein, warum ein Agent falsch entschieden hat; die Fehlentscheidung selbst verhindert er 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 zwingend 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 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. Auch die Beobachtung braucht 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 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, lohnt sich ein strukturierter Blick von außen. Das gilt besonders für die Frage, welches Maß an Beobachtbarkeit zu seinen tatsächlichen Aktionen passt. 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

Diese 12 Punkte fasst die Checkliste für den Einstieg zusammen.

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.