Ihr Datadog-Dashboard zeigt Grün. Die Latenz liegt innerhalb des SLA. Die Fehlerrate beträgt 0,1 Prozent. Die Verfügbarkeit liegt bei 99,9 Prozent.

Ihr KI-System produziert in 5 Prozent der Fälle fehlerhafte Ausgaben, und niemand bemerkt es.

Klassisches Application Performance Monitoring (APM) misst, ob das System läuft. KI-Observability misst, ob das System korrekt arbeitet. Das sind unterschiedliche Dinge — und die Lücke dazwischen ist der Ort, an dem Unternehmens-KI still und leise versagt.

Was klassisches Monitoring übersieht

APM-Tools messen Infrastrukturmetriken: CPU, Speicher, Latenz, Durchsatz, Fehlerraten. Für eine klassische API reicht das aus — wenn der Dienst innerhalb des SLA antwortet und einen 200-Statuscode zurückgibt, funktioniert er.

KI-Systeme versagen anders. Ein Modell kann in 200ms antworten, einen 200-Statuscode zurückgeben und eine souverän formulierte, sauber formatierte, vollkommen falsche Antwort liefern. Infrastrukturmonitoring wird das niemals erkennen. Es braucht eine zusätzliche Observability-Schicht, die die Qualität dessen misst, was das System produziert — nicht nur, ob es etwas produziert.

Der KI-Observability-Stack

Sechs Monitoring-Kategorien decken die für KI-Systeme spezifischen Fehlermodi ab.

1. Ausgabequalitäts-Monitoring. 1 bis 5 Prozent der Produktionsausgaben werden stichprobenartig evaluiert. Bei Klassifizierungsaufgaben wird gegen bekannt korrekte Labels verglichen. Bei generativen Aufgaben kommen LLM-as-Judge-Muster zum Einsatz — ein separates Modell bewertet, ob die Ausgabe dem Quellmaterial treu ist, korrekt formatiert und faktisch konsistent. Laut dem Galileo-AI-MLOps-Leitfaden berichten Organisationen, die LLM-as-Judge zusammen mit menschlicher Überprüfung einsetzen, von 40 Prozent besserer Gesamtsystemqualität.

Qualitätsbewertung sollte als kontinuierliche Pipeline implementiert werden, nicht als regelmäßiges Audit. Wöchentliche Batch-Reviews erkennen Probleme zu spät. Tägliche automatisierte Bewertung mit menschlicher Überprüfung markierter Ausgaben erkennt Probleme, bevor sie sich anhäufen.

2. Kostenmonitoring. Kosten pro Aufgabe erfassen, nicht nur Kosten pro Token. Eine Kundenservice-Interaktion, die drei Modellaufrufe, zwei Retrieval-Abfragen und einen Verifizierungsschritt erfordert, kostet mehr als die Summe ihrer Token. Dashboards sollten Kosten pro Geschäftsaktion zeigen — Kosten pro gelöstem Ticket, Kosten pro verarbeitetem Dokument, Kosten pro generierter Empfehlung.

Alerts für Kostenanomalien einrichten. Eine Prompt-Regression, die unnötige Ausschweifigkeit hinzufügt, kann den Token-Verbrauch über Nacht verdoppeln. Eine Änderung in der Retrieval-Pipeline, die zu viele Dokumente zurückgibt, kann die Nutzung des Kontextfensters verdreifachen. Diese Kostenspitzen sind im Infrastrukturmonitoring unsichtbar.

3. Drift-Erkennung. Eingabeverteilungen auf statistische Verschiebungen überwachen, mittels PSI (Population Stability Index) oder KL-Divergenz. Wenn sich Eingaben verschieben, verschlechtert sich die Ausgabequalität — aber die Verschlechterung ist möglicherweise nicht sofort sichtbar. Drift-Erkennung liefert eine Frühwarnung, bevor die Genauigkeit sinkt.

Für LLM-basierte Systeme empfiehlt die StackPulsar-Analyse 2026 zur Drift-Erkennung, die semantische Ähnlichkeit von Ausgaben über die Zeit zu überwachen. Eine plötzliche Veränderung der Ausgabemuster — anderes Vokabular, andere Struktur, anderes Konfidenzniveau — deutet entweder auf Modelldrift oder anbieterseitige Änderungen hin.

4. Latenzverteilung. Durchschnittliche Latenz ist irreführend. p50, p95 und p99 separat überwachen. Ein System mit 200ms p50 und 5 Sekunden p99 hat ein Tail-Latency-Problem, das 1 Prozent der Nutzer betrifft — und in der Produktion sind 1 Prozent von 10.000 täglichen Anfragen 100 schlechte Erfahrungen.

Für LLM-Systeme zwischen Time-to-First-Token (TTFT) und Gesamtgenerierungszeit unterscheiden. TTFT beeinflusst die wahrgenommene Reaktionsschnelligkeit bei Streaming-Anwendungen. Die Gesamtgenerierungszeit beeinflusst nachgelagerte Verarbeitungspipelines.

5. Prompt-Injection- und Sicherheitsmonitoring. Eingaben auf Prompt-Injection-Versuche überwachen — adversariale Eingaben, die darauf abzielen, das Modellverhalten zu manipulieren. Eingaben, die instruktionsähnliche Muster, Rollenspiel-Prompts oder Versuche zur Extraktion von System-Prompts enthalten, protokollieren und alarmieren. Für kundenseitige KI-Systeme ist dies eine Sicherheitsanforderung.

Die OWASP Top 10 für LLM-Anwendungen (Ausgabe 2025) identifizieren Prompt Injection als die Schwachstelle mit dem höchsten Risiko. Die Überwachung erfolgt durch Mustererkennung auf Eingaben und Anomalieerkennung auf Ausgaben.

6. Token- und Ressourcenauslastung. GPU-Auslastung, Speicherverbrauch und Token-Durchsatz über die Zeit verfolgen. Niedrige GPU-Auslastung (unter 40 Prozent) signalisiert überdimensionierte Infrastruktur — verschwendetes Geld. Hohe Auslastung (über 90 Prozent) signalisiert Kapazitätsrisiko — eine einzige Lastspitze bis zur Verschlechterung.

Bei API-basierten Deployments den Token-Verbrauch gegen das Budget verfolgen. Alerts bei 80 Prozent des Monatsbudgets setzen. Überschreitung des Budgets bei Modell-APIs ist häufig, wenn Monitoring fehlt.

Den Stack aufbauen, ohne zu überbauen

Für Mittelstandsunternehmen mit 3 bis 10 KI-Workflows sollte der Observability-Stack auf dem bestehenden Monitoring aufsetzen, statt es zu ersetzen.

Bestehendes APM erweitern. Benutzerdefinierte Metriken zu Datadog, Grafana oder dem vorhandenen Monitoring-Tool hinzufügen. KI-spezifische Metriken — Ausgabequalitätsbewertungen, Kosten pro Aufgabe, Drift-Indikatoren — sind benutzerdefinierte Metriken mit Standard-Alerting. Keine neue Plattform erforderlich.

Qualitäts-Sampling hinzufügen. Ein geplanter Job, der täglich 50 bis 100 Ausgaben stichprobenartig nimmt, eine LLM-as-Judge-Evaluierung durchführt und die Ergebnisse im Metriksystem protokolliert. Gesamtkosten: wenige Dollar pro Tag an API-Aufrufen. Gesamtnutzen: Qualitätsverschlechterung erkennen, bevor Nutzer es bemerken.

Kosten-Dashboards ergänzen. API-Nutzungsdaten (verfügbar über die Billing-API jedes Anbieters) in eine workflowbezogene Kostenansicht zusammenführen. Eine wöchentliche 15-minütige Überprüfung der Kosten pro Workflow verhindert Budgetüberraschungen und identifiziert Optimierungspotenziale.

Führen Sie ein Diagnostic durch, um Ihre KI-Observability-Lücken zu identifizieren. Wir prüfen Ihr aktuelles Monitoring gegen das Sechs-Kategorien-Framework und erstellen einen Observability-Plan, der KI-spezifische Ausfälle erkennt, ohne zu überdimensionieren. Diagnostic starten →

Referenzen: Galileo AI, „The MLOps Guide to Transform Model Failures Into Production Success," 2026; StackPulsar, „LLM Model Drift Detection 2026: Monitoring AI Behavior Degradation"; OWASP, „Top 10 for LLM Applications," Ausgabe 2025; Evidently AI, „Model Monitoring for ML in Production," 2026; Acceldata, „Scaling AI with Confidence: The Importance of ML Monitoring," 2026; OvalEdge, „Top AI Observability Tools for Model Monitoring," 2026.