KI-Agenten-Observability: Wenn der Agent leise lügt

TL;DR: Klassisches Monitoring fragt „Läuft das System noch?". Bei KI-Agenten ist das die falsche Frage. Ein Agent kann zu 100 % verfügbar, unter 200 ms Latenz, HTTP-200-grün sein — und seit Dienstag systematisch falsche Rückgabefristen bestätigen. Uptime ist gelöst, Wahrheit nicht. Wer KI-Agenten in Produktion betreibt, braucht eine andere Disziplin: semantische Observability — Tracing pro Trajektorie, Eval-in-Production mit kalibriertem Judge, Drift-Erkennung als Regressionstest, plus harte Guardrails an den teuren Stellen. Dieser Text ist das HOW zu der Betriebslücke, in der Piloten sterben.

---

Die unbequeme These: Ein Crash ist ein Glücksfall

Ein KI-Agent, der crasht, ist ein Glücksfall. Ein Crash ist laut. Er hat ein Stacktrace, einen 500er, einen Alert um drei Uhr nachts. Jemand wird geweckt, jemand fixt es. Laut kaputt findet jeder Junior.

Das eigentliche Risiko ist der Agent, der ruhig weiterläuft und systematisch danebenliegt — plausibel formuliert, syntaktisch sauber, semantisch falsch. Das ist der Bruch mit allem, was uns Application Performance Monitoring beigebracht hat. Software, die wir kennen, scheitert laut: Sie kippt Latenzkurven, wirft Exceptions. KI-Systeme scheitern plausibel. Sie liefern eine wohlgeformte, selbstbewusste, grammatikalisch makellose falsche Antwort.

Datadog, New Relic, Prometheus, Grafana — sie messen, ob der Dienst antwortet. Sie messen nicht, ob die Antwort stimmt. P99-Latenz von 1,2 Sekunden sagt Ihnen nichts darüber, dass Ihr Support-Agent seit Dienstag Kunden in die falsche Rückgaberichtlinie schickt. Uptime 99,99 %, Wahrheitsgehalt unbekannt.

Still falsch findet niemand — weil niemand dafür zuständig ist.

---

Das ist keine Technik-, sondern eine Org-Frage

Bevor wir über Tools reden, die ehrliche Stelle, an der sich der Mittelstand entscheidet: Wer owned die Trajektorie eines Agenten im Betrieb?

Die Data-Scientists haben nach dem Piloten weitergezogen. Das Ops-Team hat Runbooks für CPU und Disk, nicht für „Modell halluziniert Bestätigungen". Der Fachbereich merkt es zuerst — über eine Beschwerde, drei Wochen zu spät. Im Mittelstand heißt die ehrliche Antwort selten „24/7-SRE-Team", sondern: ein Tech-Lead, zwei Entwickler.

Daraus folgt eine harte Konsequenz für die Architektur: Observability muss ins Produkt eingebaut sein, nicht an ein Team delegiert, das es nicht gibt. Genau hier endet der Pilot und beginnt die Arbeit — die Lücke zwischen „funktioniert in der Demo" und „funktioniert in sechs Monaten noch".

---

Hebel 1: Tracing pro Trajektorie — Reasoning, nicht Requests

Ein Agent ist keine Funktion mit Input und Output. Er ist eine Kette von Entscheidungen: planen, Tool aufrufen, Ergebnis beobachten, neu planen, antworten. Wer nur Anfang und Ende loggt, debuggt blind.

Und die Kette ist das Problem. Wenn jeder einzelne Schritt zu 95 % stimmt, klingt das gut — bis Sie multiplizieren. Sieben unabhängige Schritte zu je 0,95 ergäben rund 70 % Gesamtzuverlässigkeit. In der Praxis sind die Fehler natürlich nicht unabhängig — mal heben sie sich auf, mal schaukeln sie sich hoch — und die genaue Zahl variiert; die Logik bleibt: Jedes Glied sieht gesund aus, die Kette reißt trotzdem. (Diesen Punkt vertieft der Eval-Post zur Ketten-Zuverlässigkeit.)

Deshalb: ein Span pro Schritt — pro Tool-Call, pro Retrieval, pro LLM-Aufruf — verschachtelt zu einer Trace. Nicht Request-Tracing, sondern Reasoning-Tracing. Sie wollen sehen, an welchem Schritt die Trajektorie kippte, nicht nur dass sie kippte. Ohne Trace debuggen Sie eine Tool-Call-Schleife wie eine Nachricht aus dem Jenseits: Sie sehen, dass Geld brennt, nicht warum.

OpenTelemetry hat sich hier als Substrat durchgesetzt. Die GenAI-Semantic-Conventions — Modell, Token-Count, Prompt und Completion als Span-Attribute — sind die unspektakuläre Standardisierung, die das Feld erwachsen macht (formal allerdings noch in Entwicklung — dazu unten mehr). Für den eben genannten Mittelständler mit Tech-Lead und zwei Entwicklern ist der pragmatische Default-Pfad konkret: OpenTelemetry-Spans → Langfuse, self-hosted in der EU. Open Source, Datenkontrolle im eigenen Haus, kein neuer SaaS-Vertrag. Phoenix, LangSmith oder OpenLLMetry sind Alternativen auf demselben OTel-Fundament — der Punkt ist nicht das Tool, sondern die Granularität.

---

Hebel 2: Eval-in-Production — und kalibrieren Sie den Judge

Offline-Benchmarks vor dem Launch sind Pflicht. Aber das Pre-Release-Benchmark gewinnen alle — und es altert in der Sekunde, in der echte Nutzer echte Eingaben schicken.

Online-Evals heißen: Sie sampeln laufenden Traffic. Nicht alles bewerten — das ist zu teuer — sondern eine stratifizierte Stichprobe, mit Übergewicht auf Fällen nahe der Entscheidungsgrenze. Ein LLM-as-Judge bewertet die Masse. Braintrust und Phoenix bauen genau diese Pipelines.

Hier wird es ehrlich: Der Judge ist selbst ein Modell mit Bias. Ein Judge, der nie gegen eine menschliche Referenzstichprobe geeicht wird, ist ein Orakel, das sich selbst zustimmt — ein zweiter Agent, der ebenfalls leise lügt. Die nicht-offensichtliche Einsicht: Behandeln Sie Ihren Judge wie ein Messinstrument, das kalibriert werden muss. Wöchentlich labelt ein Mensch 50 Fälle; Sie messen die Übereinstimmung Judge-vs-Mensch (Cohen's Kappa). Sinkt dieses Kappa, ist nicht der Agent das Problem, sondern Ihr Messgerät.

Der praktische Kern darunter ist ein lebendes Goldset: kein Datensatz, den Sie einmal vor dem Launch schreiben und dann vergessen, sondern ein wachsender Referenzbestand, gespeist aus echten Produktionsfällen. Jeder Incident, jede menschliche Korrektur, jeder Edge-Case wandert zurück hinein.

Und messen Sie das Richtige. Gute Online-Metriken sind die, die der Nutzer fühlt: Korrekturrate, Eskalation an Menschen, Task-Completion, Tool-Fehlerrate. Schlechte Metriken sind die, die schmeicheln: durchschnittliche Antwortlänge, „Sentiment", die Selbstbewertungs-Scores des Modells.

---

Hebel 3: Drift als Regressionstest — der Failure-Mode, den niemand testet

Der gefährlichste Moment ist nicht der Bug, sondern der stille Wechsel. Ein Anbieter aktualisiert ein Modell hinter derselben API-Bezeichnung. Jemand „verbessert" einen Prompt um eine Zeile. Und eine Fähigkeit verschwindet stillschweigend, die niemand getestet hat — ohne ein einziges rotes Log. Das ist Regression, die sich als Verbesserung tarnt. Wer keine fixe Eval-Suite gegen jede Modellversion fährt, merkt es am Quartalsumsatz.

Daneben gibt es die semantische Drift, die kein CPU-Graph je liefert: Die Eingabeverteilung verschiebt sich — neue Produktlinie, Saison, ein viraler Sonderfall — und der Agent gerät auf Terrain, für das er nie evaluiert wurde. Die Embedding-Distanz zwischen Referenz- und Live-Verteilung ist hier das Frühwarnsignal. Konkret: Sie messen den Abstand zwischen dem Centroid eines rollierenden Live-Batches und dem Centroid Ihres Goldsets; reißt dieser Abstand über einen festgelegten Schwellwert, triggert das automatisch eine Re-Evaluation — bevor die Qualität sichtbar fällt. Das Signal läuft Ihrem Goldset voraus und sagt Ihnen: Hier kommt gleich etwas, das du nie gesehen hast.

---

Drumherum: Guardrails als Gates, nicht als Bitte

Tracing, Eval und Drift sehen zu. Guardrails greifen ein. Sie gehören zur selben Architektur:

• Deterministische Checks für das, was nie passieren darf — Regex, Schema-Validierung, Erlaubnislisten. Kein Modell entscheidet, ob eine IBAN valide ist.
• Human-in-the-loop-Gates für irreversible Aktionen — Zahlung, Löschung, verbindliche Zusage, E-Mail nach außen, Vertragstext. Ein Agent darf vorschlagen; ein Mensch bestätigt, wo es weh tut. Dieselben Gates sind die Hauptverteidigung gegen gekaperte Agenten (Prompt-Injection) — derselbe Reflex, zwei Bedrohungen.
• Kosten- und Latenz-Budgets pro Lauf als Sicherheitsventil, nicht als Buchhaltung. Ein Agent, der in eine Tool-Schleife gerät, frisst Budget, bevor er Schaden anrichtet — das Budget-Alert ist oft das erste ehrliche Signal, bevor er 400 Tool-Calls macht.

Und eine Architekturnotiz, kein Compliance-Häkchen: Traces enthalten Kundeninhalte. Sie sind Geschäftsgeheimnisse. Wo diese Spans liegen und wer sie sieht, ist eine DSGVO-Frage, die man am Tag eins beantwortet, nicht beim Audit — und genau deshalb ist die Self-hostbarkeit eines Langfuse in der EU eine Architekturentscheidung, keine Fußnote. Datenkontrolle ist hier ein Designparameter, kein nachträgliches Häkchen. Wie wir das im Mittelstand aufsetzen, ist Teil unserer KI-Beratung und folgt der Linie aus The Azena Way.

---

Werkzeuge 2026: Agenten-Traces statt Call-Logger

Die Tool-Frage entscheidet sich an einer Linie, die in Vergleichstabellen gern verschwimmt: Kann das Werkzeug Trajektorien — oder loggt es nur einzelne LLM-Calls? Ein Proxy wie Helicone sieht jeden Request „at the wire" und ist stark bei Kosten und Latenz pro Call; die Agent-Schleife dazwischen — planen, Tool aufrufen, beobachten, neu planen — bleibt unsichtbar. PostHogs LLM-Analytik behandelt jeden Call als Event für Funnels. Beides sind Call-Logger, keine Agenten-Observability.

Echte Agenten-Tracer müssen vier Dinge können: verschachtelte Spans über Multi-Step-Läufe inklusive Sub-Agents, Tool-Call-Ein- und -Ausgaben im Trace, Kosten-Aggregation pro Trajektorie (nicht pro Call) und den Weg vom Production-Trace zurück ins Eval-Set. Auf dieser Seite der Linie stehen 2026 vor allem Langfuse, LangSmith, Arize Phoenix, Braintrust, OpenLLMetry und — als APM-Erweiterung — Datadog.

Der Markt professionalisiert sich dabei sichtbar: ClickHouse hat Langfuse im Januar 2026 übernommen (der Kern bleibt MIT-lizenziert und self-hostbar; die stabile Self-Host-Linie ist 3.x), LangChain hat im März eine Enterprise-Partnerschaft mit NVIDIA geschlossen, Braintrust eine große Series B eingesammelt. Für die Auswahl im Mittelstand hat sich eine brauchbare Faustlogik herausgebildet: Langfuse self-hosted als Default — framework-agnostisch, volle Datenkontrolle, Multi-Step-Kosten nativ pro Trace. LangSmith, wenn der Stack tief in LangGraph steckt (node-genaue State-Diffs, Trajectory-Replay gegen neue Modellversionen). Braintrust, wenn Evals das Zentrum sind — dort ist die Judge-Kalibrierung gegen Human-Labels, die Hebel 2 fordert, als expliziter Workflow eingebaut. Datadog, wenn Datadog ohnehin läuft: Seit die Plattform OTel-GenAI-Spans nativ per OTLP ingestiert (ab Conventions v1.37, ohne eigenes SDK), ist die APM-Route real — mit dem bekannten Kostenrisiko bei Telemetrie-Volumen und der US-SaaS-Frage.

Für DACH bleibt der belastbare DSGVO-Pfad: Langfuse oder Phoenix self-hosted auf eigener Infrastruktur (keine Drittlandübermittlung, kein AVV mit US-Anbieter), alternativ OpenLLMetry mit einem eigenen OTLP-Backend wie Grafana. Wichtig fürs Kleingedruckte: Auch Langfuse-Cloud-EU liegt in Irland, nicht in Deutschland — wer Datenresidenz verspricht, meint Self-Hosting. Den vollständigen Fünf-Tool-Vergleich mit Bewertungsmatrix führt unser Werkzeug-Guide zur AI-Observability; hier zählt der Filter: erst Trajektorien-Fähigkeit, dann Feature-Listen.

Der Standard darunter: OTel-GenAI bleibt offiziell unversioniert

Wer jetzt instrumentiert, sollte den Zustand des Standards kennen, auf dem alle diese Tools aufsetzen. Mit semconv v1.42.0 (12. Juni 2026) hat OpenTelemetry sämtliche gen_ai.*-Konventionen aus dem Haupt-Repository in ein eigenes Repo ausgelagert; v1.43.0 vom 3. Juli ist das erste Haupt-Release ganz ohne GenAI. Das dedizierte GenAI-Repo hat Stand Mitte Juli noch kein einziges Release — Changelog „Unreleased", Schema-URL „TODO". Die Agent-Konventionen, die dort definiert sind — Lifecycle-Spans wie create_agent und invoke_agent, Tool-Ausführung als execute_tool, dazu MCP-Konventionen — sind also genau das, was ein Trace heute braucht, und zugleich formal unversionierte Baustelle.

Gleichzeitig ist OpenTelemetry am 21. Mai 2026 zum CNCF-Graduated-Project aufgestiegen, und Vendoren behandeln GenAI-Semconv-Parität längst als Kaufkriterium — Datadogs SDK-loser Ingest ist der deutlichste Beleg, dass der Development-Standard de facto Produktionsstandard wird. Die praktische Konsequenz ist unspektakulär: Trotzdem auf OTel instrumentieren — es ist die eine Entscheidung, die jeden späteren Backend-Wechsel offenhält — aber Attribut-Namen zentral kapseln statt über die Codebasis verstreuen, damit das nächste Rename ein Einzeiler bleibt. Die Detailgeschichte, warum „stable" hier eine Falschbehauptung vieler Dritt-Blogs ist, steht in unserer OTel-GenAI-Analyse.

FAQ: Agenten-Observability in der Praxis

Welche Tools eignen sich 2026 für KI-Agenten-Observability? Die mit Trajektorien-Fähigkeit: Langfuse (self-hostbar, MIT-Kern), LangSmith (LangGraph-Tiefe), Arize Phoenix (Eval-Rigorosität), Braintrust (Eval-first inkl. Judge-Kalibrierung), OpenLLMetry als OTel-native OSS-Instrumentierung, Datadog als APM-Erweiterung. Call-Logger wie Helicone oder PostHog-LLM-Analytik ergänzen bei Kosten pro Request, ersetzen aber kein Trajectory-Debugging.

Reicht unser bestehendes APM (Datadog, Grafana) nicht aus? Klassisches APM beantwortet „Läuft der Dienst?" — nicht „Stimmt die Antwort?". Beide Häuser haben nachgerüstet: Datadog ingestiert OTel-GenAI-Spans nativ, Grafana trackt Agenten-Konversationen im LGTM-Stack. Das löst die Trace-Granularität, aber nicht die semantische Ebene: Eval-in-Production, Judge-Kalibrierung und Drift-Erkennung (Hebel 2 und 3) muss man weiterhin bewusst dazubauen.

Wie betreiben wir generative KI-Observability DSGVO-konform? Traces enthalten Kundeninhalte — also gilt: Self-Hosting auf eigener Infrastruktur (Langfuse, Phoenix, OpenLLMetry + eigenes Backend) vermeidet Drittlandübermittlung komplett. Bei SaaS-Optionen genau hinsehen, wo die EU-Region wirklich liegt und ob ein AVV mit US-Bezug nötig wird. Retention und Zugriffsrechte auf Traces gehören in dieselbe Entscheidung.

Was unterscheidet agentenbasierte KI-Observability von klassischem LLM-Logging? Die Einheit der Beobachtung. LLM-Logging misst einzelne Aufrufe (Latenz, Token, Kosten pro Call). Agentenbasierte Observability misst Trajektorien: die verschachtelte Kette aus Planung, Tool-Calls und Re-Planung — inklusive der Frage, an welchem Schritt eine Kette kippte, was der Lauf insgesamt gekostet hat und ob das Endergebnis stimmt. Erst auf dieser Ebene werden leise Fehler sichtbar.

---

Die Pointe

Diese Arbeit gewinnt keine Demo. Sie steht in keinem Pitch. Sie ist die Kanalisation unter der schönen Stadt — unsichtbar, bis sie fehlt, und dann riecht es jeder.

Der Pilot war die Demo. Die Observability ist das Produkt. Firmen, die nur das Erste feiern, betreiben einen Agenten, den niemand mehr versteht — und nennen das Erfolg, bis die erste Beschwerde zeigt, dass er seit Wochen höflich lügt.

Software, die crasht, weckt Sie nachts. Software, die lügt, lässt Sie schlafen — bis der erste Kunde anruft. Klassisches Monitoring fragt „Lebt das System noch?". Die richtige Frage bei KI-Agenten lautet: „Lügt es gerade überzeugend?" — und auf diese Frage hat kein Uptime-Dashboard je geantwortet.

---

Weiterlesen im Cluster: [Werkzeug-Guide AI-Observability mit OTel-Deep-Dive](/blog/ai-observability-tools-mittelstand-2026) · [Warum KI-Piloten in der Betriebslücke sterben](/blog/ki-piloten-mittelstand-produktion) · [Evals und Ketten-Zuverlässigkeit in Produktion](/blog/ki-agenten-produktion-evals) · [Generative UI — die Zukunft der Software](/blog/generative-ui-zukunft-der-software) · [KI-Beratung für den Mittelstand](/ki-beratung-mittelstand)

Erstveröffentlichung 28. Juni 2026, aktualisiert am 17. Juli 2026 (Tool-Landschaft, OTel-GenAI-Repo-Split, CNCF-Graduation).

Teil der Landkarte: [KI-Agenten in Produktion — vom Piloten zum verlässlichen Betrieb](/blog/ki-agenten-produktion-landkarte).