AI Observability: Was nach dem Deploy passiert
KI-Systeme können scheitern, ohne kaputt auszusehen. 200 OK bedeutet nicht, dass die KI funktioniert. Drei Schichten — Tracing, Evals, Drift Detection —, vier Golden Signals und ein Incident-Response-Rahmen für Teams, die KI-Produktion ernst nehmen.
Abgrenzung: MLOps (CI/CD, Model Registry, Feature Store) decken wir auf eigener Seite ab. Pre-Deployment-Testing und Evaluierung auf AI Testing & Evaluation. Security-Monitoring auf AI Security Operations. Diese Seite fokussiert auf die betriebliche Observability nach dem Deploy.
Warum AI Observability kein IT-Monitoring ist
Traditionelles Monitoring trackt CPU, Memory, Latenz und HTTP-Statuscodes. KI-Systeme scheitern anders: sie liefern weiter 200 OK, während die Qualität stumm von 95% auf 70% fällt. Das geht über Wochen unbemerkt — kein Stack Trace, kein Log-Eintrag, kein Dashboard-Alarm.
| Traditionelles Monitoring | AI Observability |
|---|---|
| HTTP-Statuscodes (2xx, 4xx, 5xx) | Semantische Korrektheit der Outputs — ein 200-OK heißt gar nichts |
| CPU/Memory/Latency golden signals | Quality Score, Halluzinationsrate, Refusal Rate — Metriken auf Modellebene |
| Deterministische, wiederholbare Ergebnisse | Non-deterministische Outputs — selber Input kann verschiedene Antworten liefern |
| Logs, Metrics, Traces (drei Säulen) | Vier Säulen: Logs + Metrics + Traces + Semantic Evaluation |
| Kosten-Attribution nach Ressource | Token-Consumption, Model-Routing-Costs, pro-Request-Ökonomie |
Die Konsequenz: 73% der Unternehmen benötigen AI-Agent-Monitoring, aber 63,4% geben an, dass ihnen die adequate Observability-Tooling fehlt (MLflow Enterprise LLM Survey 2026). Wer heute kein Monitoring hat, hat keine Ahnung, was seine KI in Produktion tut.
Drei-Schichten-Stack für AI Observability
Jede Schicht beantwortet eine andere Frage und baut auf der vorherigen auf. Ohne Layer 1 (Tracing) sind Layer 2 (Evals) und Layer 3 (Drift) blind.
Tracing
Jeder Request End-to-EndHat dieser Request funktioniert?
Input, Prompt, Modell + Version, Token-Count, Latenz, Tool-Calls, Retrievals — alles in einem Trace. Das ist die höchste Hebelwirkung in LLMOps, weil LLM-Failures ohne Tracing unsichtbar bleiben. OpenTelemetry GenAI standardisiert das Format.
Beispiel
Ein Kunde beschwert sich über eine falsche Antwort. Im Trace siehst du: Der RAG-Retrieval hat das falsche Dokument gefunden (Embedding-Score = 0.52 unter Threshold), also war der Kontext unvollständig.
Evals
Laufende automatisierte QualitätsprüfungRegrediert die Gesamtqualität?
Automatisierte Evaluierung gegen Qualitätsmetriken: Halluzinationsrate, Toxizität, Richtigkeit, Vollständigkeit. Pre-Deployment-Evals und Post-Deployment-Evals sind komplementär — wer nur vor dem Deploy testet, übersieht Production-Drift.
Beispiel
Nach einem Modell-Update sinkt der Quality Score von 92% auf 84%. Der Eval-Alarm triggert ein Playbook: Rollback oder Prompt-Anpassung? Entscheidung in < 15 Minuten.
Drift Detection
Stille Fehler sichtbar machenSind die Inputs heute noch die gleichen wie beim Test?
Data Drift (Input-Verteilung ändert sich) und Concept Drift (Zusammenhang Input→Output ändert sich) sind die häufigsten Ursachen für stille Fehler. Beide treten ohne Fehlermeldung auf — das System antwortet weiter mit 200 OK, während die Qualität unbemerkt sinkt.
Beispiel
Ein KI-Prognosemodell für Lagerbestände, trainiert auf 2024-Daten, produziert nach einer Lieferkettenkrise stille Fehler. Kein Stack Trace, kein Log-Eintrag — der Quality Score sinkt von Tag zu Tag.
Vier Golden Signals für LLMs
Aufbauend auf dem Three-Layer-Stack: vier Metriken, die jedes KI-System in Produktion messen muss.
| Signal | Was | Messen | Alarm |
|---|---|---|---|
| Quality Score | Semantische Korrektheit der Outputs | LLM-as-Judge, ROUGE/BLEU, Embedding-Similarity | Abweichung >5% von Baseline → Evaluation triggern |
| p95 Latency | Antwortzeit des Modells unter realistischer Last | Trace-basierte Latenz-Messung pro Modell/Version | p95 über SLO (z.B. 5s) → Capacity Review oder Prompt-Optimierung |
| Error & Refusal Rate | Fehlgeschlagene oder verweigerte Requests | HTTP-Errors + Safety-Refusals + Empty-Outputs | Refusal Rate steigend → Guardrail- oder Safety-Drift-Prüfung |
| Cost per Request | Token-Verbrauch modelliert als Kostenmetrik | Input/Output Tokens × Model-Preis pro Token | Cost/Request über Budget → Model Routing oder Optimierung |
Data Drift vs. Concept Drift
Die zwei häufigsten Ursachen für stille Degradation — und warum sie ohne Drift Detection unsichtbar bleiben.
Data Drift
Die Verteilung der Input-Daten ändert sich gegenüber dem Training.
Beispiel:
Ein KI-Chatbot für Kundenservice bekommt plötzlich technische Fachfragen statt Standard-Anfragen. Die Antworten werden ungenauer, aber das Modell ist intakt — die Input-Verteilung hat sich geändert.
Concept Drift
Der Zusammenhang zwischen Input und Output ändert sich, weil sich die Welt verändert.
Beispiel:
Ein KI-Prognosemodell für Lagerbestände, trainiert auf 2024-Daten, funktioniert nach einer Lieferkettenkrise 2025 nicht mehr — die alten Muster gelten nicht mehr, obwohl die Eingaben gleich sind.
Wichtig: Beide Drift-Arten treten ohne Fehlermeldung auf. Das System liefert weiter 200 OK, die Metriken sind grün — nur der Quality Score sinkt. Ohne statistische Baseline ist jede Drift-Messung wertlos. Die Baseline muss jährlich neu berechnet und bei jedem Modell-Update aktualisiert werden.
Guardrails: Preventive, Detective, Corrective
Guardrails sind kein Ersatz für Observability. Observability liefert die Daten, Guardrails setzen die Aktion. Beide brauchen einander.
Preventive
Wasserventil — unterbricht den Fluss, bevor Schaden entstehtVerhindern schädliche Outputs vor der Ausgabe
- ▹Input/Output-Filter (Regex, Keywords, Embeddings)
- ▹Topic-Restrictions (Themenbereich eingrenzen)
- ▹PII-Redaction (personenbezogene Daten entfernen)
- ▹Rollenbasierte Zugriffskontrollen (wer darf was fragen)
Detective
Rauchmelder — alarmiert, ohne zu löschenErkennen Probleme im laufenden Betrieb
- ▹Halluzinationserkennung per LLM-as-Judge
- ▹Jailbreak-Detection (Prompt Injection erkennen)
- ▹Toxizitäts-Scoring der Outputs
- ▹Drift-Alarme auf Quality-Score-Basis
Corrective
Feuerlöscher — greift ein, wenn der Alarm ausgelöst wurdeReagieren auf erkannte Probleme
- ▹Automatischer Retry bei unsicheren Outputs
- ▹Fallback-Modell bei Degradation
- ▹Request-Blocking bei wiederholten Attacken
- ▹Automatische Eskalation an menschliche Prüfer
Cost Observability: Token-Tracking als Standard
KI-Kosten skalieren anders als Server-Kosten. Ohne Request-Level-Token-Abrechnung bleiben Kosten-Ausreißer unsichtbar, bis die Rechnung kommt.
Token Cost Accounting
Jeder Request wird auf Input/Output/Embedding/ Caching-Token heruntergebrochen. Ohne das sind Ausreißer nicht identifizierbar.
Model Routing Intelligence
Teure Frontier-Modelle nur für komplexe Anfragen, OS-Modelle für Standard-Fälle. Senkt Kosten um bis zu 60%.
Budget-Alarme
Drei Ebenen: Per-Request-Cap, Tagesbudget mit Soft/Hard-Limit, Monatsbudget mit Eskalation. Jede hat eine andere Aktion.
Empfehlung: Cost Observability sollte auf dem gleichen Niveau betrieben werden wie Infrastructure-Monitoring. Die Top-LLMOps-Teams 2026 haben reaktive Abrechnung durch proaktive Cost-Governance abgelöst — mit Budget-Alarmen, Modell-Routing und monatlichen Cost-Reviews.
Incident Response für KI: Drei Playbooks
Vom ad-hoc Debugging zum standardisierten Prozess. Jeder Incident endet mit dokumentiertem Post-Mortem und aktualisiertem Playbook.
Halluzination Incident
Trigger: Quality Score fällt unter Baseline- 1.Automatische Evals-Trigger: Betroffene Requests identifizieren
- 2.Outputs mit niedrigem Confidence-Score flaggen
- 3.Ursachenanalyse: Prompt-Problem, Modell-Drift oder Context-Leak?
- 4.Entscheidung: Rollback, Prompt-Update oder Modell-Wechsel
- 5.Post-Mortem: Warum hat kein Guardrail gegriffen?
Jailbreak Incident
Trigger: Detective Guardrail schlägt Alarm- 1.Request und Payload sichern (für Forensik)
- 2.Betroffenes System isolieren (read-only-Modus)
- 3.Input-Pattern analysieren — bekannter Jailbreak-Vektor?
- 4.Guardrail-Regeln nachschärfen
- 5.Post-Mortem: Warum hat der Preventive Guardrail nicht gegriffen?
Drift Incident
Trigger: Drift-Detection-Schwelle überschritten- 1.Aktuelle Data-Statistiken gegen Baseline ploten
- 2.Root-Cause: Data Drift oder Concept Drift?
- 3.RAG: Context-Quellen wechseln oder erweitern
- 4.Fine-Tuning: Modell nachtrainieren
- 5.Adjustieren: Neue Baseline berechnen oder akzeptieren
OpenTelemetry GenAI: Der Standard für AI-Tracing
Seit 2026 haben die GenAI Semantic Conventions von OpenTelemetry einheitliche Span-Attribute für LLM-Anwendungen definiert. Kein Vendor-Lock-in mehr beim Tracing.
// OpenTelemetry GenAI Span Attributes
gen_ai.request.model = "gpt-5"
gen_ai.request.prompt = "..."
gen_ai.response.completion = "..."
gen_ai.usage.input_tokens = 142
gen_ai.usage.output_tokens = 89
gen_ai.tool.name = "search_documents"
gen_ai.tool.arguments = {"query": "..."}
gen_ai.agent.thought = "..."
Nach OpenTelemetry-Standard instrumentierte Systeme können mit jedem Observability-Backend visualisiert werden — Datadog, Grafana, New Relic, SigNoz. Für Agentic Workflows werden Tool-Calls und Reasoning-Spuren als separate Spans abgebildet.
Production Readiness Checklist
Sechs Fragen, die jedes Team mit KI in Produktion beantworten können muss.
Frage 1: End-to-End-Tracing für jeden Request?
Spans für Prompt, RAG-Retrieval, Tool-Call, Model-Response. Trace-Explorer existiert und wird aktiv genutzt — nicht nur in Entwicklung, sondern auch in Produktion.
Frage 2: Mindestens ein automatisierter Eval in Produktion?
Halluzinationsrate wird gemessen. Quality Score hat eine Baseline und alarmiert bei Abweichung. Pre-Deployment-Evals allein reichen nicht.
Frage 3: Data Drift und Concept Drift aktiv überwacht?
Monitoring-Baseline existiert und ist aktuell. Der letzte Drift-Vorfall wurde analysiert — war es Data- oder Concept-Drift? Die Antwort liegt im Post-Mortem.
Frage 4: Alle vier Golden Signals haben Alarme mit Playbooks?
Alarme lösen nicht nur E-Mail-Benachrichtigungen aus, sondern definierte Playbooks. Wer nur dashboards baut, aber keine Playbooks hat, betreibt Monitoring ohne Handlungskette.
Frage 5: Mindestens ein KI-Incident wurde durchgespielt?
Playbooks für Halluzination, Jailbreak und Drift existieren schriftlich. Ein Incident-Response-Training für KI wurde durchgeführt — Gaming-theorie trifft auf Produktion.
Frage 6: Guardrails sind nicht nur deployed, sondern werden gemessen?
Preventive Guardrails aktiv. Detective Guardrails überwachen die Preventive (Metaguardrails). Corrective Guardrails sind getestet und haben dokumentierte Auslöseschwellen.
Tool-Landschaft: Wer macht was?
Die Observability-Tool-Landschaft für KI hat sich 2026 in drei Kategorien ausdifferenziert:
All-in-One Observability Plattformen
Beispiele: Datadog LLM Observability, New Relic AI Monitoring, Dynatrace AI Observability, Grafana + OpenTelemetry
Teams, die bereits eine Observability-Plattform betreiben und AI-Tracing als Feature dazubuchen wollen.
Spezialisierte AI Observability Tools
Beispiele: Fiddler AI, DataRobot AI Observability, Comet Opik (OS), MLflow Tracing, Arize AI, WhyLabs
Teams, die tiefe AI-spezifische Insights brauchen: Drift Detection, Bias Monitoring, LLM-as-Judge Evals.
Guardrails & Safety Plattformen
Beispiele: NVIDIA NeMo Guardrails, Guardrails AI, Lakera Guard, Brex CrabTrap (OS), Giskard
Teams, die Preventive/Detective/Corrective Guardrails als eigenständige Schicht betreiben wollen.
Quellen
- ValueStream AI (2026): AI Monitoring in Production — LLM Observability & Drift Detection (Three-Layer Stack, 4 Golden Signals) valuestreamai.com
- Optivulnix (2026): An AI Observability Stack for Production — Tracing, Evals, and Drift Detection for Mid-Market Teams optivulnix.com
- Nova AI Ops (2026): LLMOps: The Definitive Guide to Running LLM Apps in Production (4 Gold Signals, Cost Observability) novaaiops.com
- New Relic (2026): Guide to AI Observability — Core Components, Tools, and Best Practices newrelic.com
- Swept AI (2026): LLM Observability — The Complete Guide to Monitoring LLMs in Production swept.ai
- MLflow (2026): Top LLM Observability Tools — Enterprise Survey und Tool-Vergleich (73% benötigen Agent-Monitoring) mlflow.org
- OpenObserve (2026): LLM Monitoring Best Practices — Complete Guide openobserve.ai
- OpenTelemetry (2026): GenAI Semantic Conventions — Standard-Span-Attributes für LLM-Anwendungen und Agentic Workflows opentelemetry.io
- Comet Opik (2026): Open-Source Plattform für LLM Evaluation und Observability — Tracing, Evals, Dashboards github.com/comet-ml/opik
Verwandte Seiten auf EnableChange
Stand: Juni 2026 — Die Observability-Tool-Landschaft für KI entwickelt sich rapide. OpenTelemetry GenAI Semantic Conventions sind der vielversprechendste Standard.
Hinweis: Dieser Artikel bietet Orientierung, keine Tool-Empfehlung. Die Auswahl der Observability-Plattform hängt vom bestehenden Tech-Stack und der Team-Größe ab.