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.
Zwei Arten zu scheitern
---
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. 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.
Eine Trajektorie, Span für Span
---
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.
---
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: [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)
Nächster Schritt
Passt das auf Ihren Fall?
30-Min-Erstgespräch, kostenfrei und unverbindlich. Wir gehen Ihren konkreten Fall durch — und sagen ehrlich, wenn nichts passt.