Ihr Dashboard zeigt Grün. Die Latenz liegt innerhalb des SLA, die Fehlerrate im Promillebereich, die Verfügbarkeit bei 99,9 Prozent. Jede Infrastrukturmetrik sagt Ihnen, dass das System gesund ist.
Und trotzdem liefert Ihr KI-System einem Teil Ihrer Kunden falsche Auskünfte — souverän formuliert, sauber formatiert, sachlich daneben. Niemand bemerkt es, weil niemand danach sucht.
Klassisches Application Performance Monitoring (APM) misst, ob das System läuft. KI-Observability misst, ob das System korrekt arbeitet. Das sind zwei verschiedene Fragen — und die Lücke dazwischen ist genau der Ort, an dem Unternehmens-KI still und leise versagt. Für DACH-Unternehmen ist das nicht nur ein Betriebsthema. Mit der EU-KI-Verordnung wird kontinuierliche Beobachtung von Hochrisiko-Systemen zur Rechtspflicht: Artikel 72 verlangt von Anbietern ein dokumentiertes Post-Market-Monitoring über die gesamte Lebensdauer, Artikel 12 automatische Protokollierung. Wer KI in Produktion betreibt, braucht Observability ohnehin — die Verordnung macht aus der guten Praxis eine Verpflichtung.
Was klassisches Monitoring übersieht
APM-Tools messen Infrastrukturmetriken: CPU, Speicher, Latenz, Durchsatz, Fehlerraten. Für eine klassische API reicht das. Wenn der Dienst innerhalb des SLA antwortet und einen 200-Statuscode zurückgibt, funktioniert er — der Output einer Bestellung-anlegen-API ist entweder korrekt oder löst einen Fehler aus.
KI-Systeme versagen anders. Ein Sprachmodell kann in 200 Millisekunden antworten, einen 200-Statuscode zurückgeben und dabei eine vollständig erfundene Antwort liefern. Genau das ist die Eigenheit, die klassisches Monitoring blind macht: Der gefährlichste Fehlermodus produziert keinen Fehler. Er produziert eine plausible, gut aussehende Antwort, die schlicht falsch ist. Es braucht deshalb eine zusätzliche Schicht, die die Qualität des Erzeugten bewertet — nicht nur, ob überhaupt etwas erzeugt wurde.
Sechs Dinge, die Sie messen müssen
Sechs Kategorien decken die Fehlermodi ab, die für KI-Systeme spezifisch sind und die klassisches APM nicht sieht.
Ausgabequalität. Die wichtigste und am häufigsten fehlende Metrik. Statt jede Antwort zu prüfen, ziehen Sie eine kleine Stichprobe der Produktionsausgaben und bewerten sie. Bei Klassifizierungsaufgaben gegen bekannte korrekte Labels. Bei generativen Aufgaben über das LLM-as-Judge-Muster: Ein zweites Modell bewertet anhand einer festen Rubrik, ob die Antwort durch das Quellmaterial gedeckt ist — die zentrale Anti-Halluzinations-Metrik, in der Praxis als „Faithfulness" geführt. Dass ein LLM einen anderen LLM-Output bewertet, klingt zirkulär, funktioniert aber, weil Bewerten leichter ist als Erzeugen. Wichtig ist nur: Der Judge selbst muss validiert sein, sonst tauschen Sie ein unbeobachtetes Risiko gegen ein anderes. Halten Sie die Zahl der automatischen Bewerter klein und hochsignifikant — zu viele Judges machen das Monitoring teuer, verrauscht und unlesbar.
Entscheidend ist die Frequenz. Qualität gehört in eine kontinuierliche Pipeline, nicht in ein vierteljährliches Audit. Ein wöchentlicher Batch-Review erkennt eine Regression erst, wenn sie eine Woche lang Schaden angerichtet hat. Eine tägliche automatisierte Bewertung mit menschlicher Sichtung der markierten Fälle fängt das Problem ab, bevor es sich anhäuft.
Kosten pro Aufgabe, nicht pro Token. Eine einzelne Kundenanfrage löst oft drei Modellaufrufe, zwei Retrieval-Abfragen und einen Verifizierungsschritt aus. Ihre Kosten sind mehr als die Summe der Token. Brauchbare Dashboards zeigen Kosten pro Geschäftsvorfall — pro gelöstem Ticket, pro verarbeitetem Dokument, pro generierter Empfehlung. Erst diese Einheit verbindet das KI-Budget mit dem Geschäftswert.
Richten Sie Alerts für Kostenanomalien ein, denn die teuersten Regressionen sind unsichtbar. Eine geänderte Prompt-Vorlage, die das Modell geschwätziger macht, kann den Token-Verbrauch über Nacht verdoppeln. Eine Retrieval-Anpassung, die zu viele Dokumente in den Kontext zieht, kann das Kontextfenster verdreifachen. Im Infrastrukturmonitoring sieht beides aus wie ein gesundes System — die Rechnung kommt erst am Monatsende.
Drift. Überwachen Sie die Eingabeverteilungen auf statistische Verschiebungen, etwa über den Population Stability Index oder KL-Divergenz. Wenn sich die Eingaben verschieben — saisonale Sprache, ein neues Produktsegment, eine veränderte Kundengruppe —, verschlechtert sich die Ausgabequalität, oft schleichend und unbemerkt. Drift-Erkennung ist die Frühwarnung, die anschlägt, bevor die Genauigkeit messbar sinkt. Bei generativen Systemen lohnt zusätzlich der Blick auf die semantische Ähnlichkeit der Ausgaben über die Zeit: Verschiebt sich plötzlich Vokabular oder Struktur, deutet das auf Modelldrift — oder darauf, dass Ihr API-Anbieter im Hintergrund ein neues Modell ausgerollt hat.
Latenzverteilung, nicht Durchschnitt. Der Mittelwert lügt. Überwachen Sie p50, p95 und p99 getrennt. Ein System mit 200 Millisekunden bei p50 und fünf Sekunden bei p99 hat ein Tail-Latency-Problem, das genau ein Prozent der Anfragen trifft — bei 10.000 Anfragen am Tag sind das 100 schlechte Erlebnisse, jeden Tag, unsichtbar im Durchschnitt. Bei Streaming-Anwendungen unterscheiden Sie zusätzlich Time-to-First-Token von der Gesamtgenerierungszeit: Erstere bestimmt die gefühlte Reaktionsschnelligkeit, Letztere die Last auf nachgelagerten Pipelines.
Prompt Injection und Sicherheit. Die OWASP Top 10 für LLM-Anwendungen führen Prompt Injection in der zweiten Ausgabe in Folge auf Platz 1 — nicht als patchbaren Bug, sondern als strukturelle Eigenschaft: Sprachmodelle verarbeiten Anweisung und Daten im selben Kanal und können beides nicht zuverlässig trennen. Besonders heikel ist die indirekte Variante, bei der die Schadanweisung nicht vom Nutzer kommt, sondern in einer Webseite, einem PDF oder einem Bild versteckt ist, das Ihr System verarbeitet — gefährlich für jedes RAG-System, das Fremddokumente einliest. Praktisch heißt das: Eingaben auf instruktionsähnliche Muster und Extraktionsversuche von System-Prompts protokollieren und alarmieren, Ausgaben auf Anomalien prüfen, und für riskante Aktionen eine menschliche Freigabe verlangen.
Ressourcenauslastung. Verfolgen Sie GPU-Auslastung, Speicher und Token-Durchsatz über die Zeit. Dauerhaft niedrige GPU-Auslastung signalisiert überdimensionierte Infrastruktur — verschwendetes Geld. Dauerhaft hohe Auslastung signalisiert Kapazitätsrisiko: Eine einzige Lastspitze kann das System über die Kante kippen. Bei API-basierten Deployments verfolgen Sie den Token-Verbrauch gegen das Monatsbudget und alarmieren bei 80 Prozent — eine Budgetüberschreitung bei Modell-APIs ist fast immer eine Frage des fehlenden Monitorings, nicht der echten Nachfrage.
Den Stack aufbauen, ohne zu überbauen
Die typische Überreaktion ist der Kauf einer dedizierten KI-Observability-Plattform, bevor klar ist, was überhaupt zu beobachten wäre. Für ein Mittelstandsunternehmen mit einer Handvoll produktiver KI-Workflows ist das die falsche Reihenfolge. Der Stack soll auf dem bestehenden Monitoring aufsetzen, nicht es ersetzen.
Bestehendes APM erweitern. KI-spezifische Metriken — Qualitätsscores, Kosten pro Aufgabe, Drift-Indikatoren — sind im Kern Custom Metrics mit Standard-Alerting. Sie lassen sich in Datadog, Grafana oder das vorhandene Tool einspeisen. In den meisten Häusern braucht es keine neue Plattform, sondern ein paar zusätzliche Metriken auf der vorhandenen.
Qualitäts-Sampling als geplanten Job. Ein täglicher Job zieht 50 bis 100 Ausgaben, lässt sie über LLM-as-Judge bewerten und schreibt die Ergebnisse ins Metriksystem. Die laufenden Kosten liegen im Bereich weniger Euro pro Tag an API-Aufrufen. Der Gegenwert ist die Fähigkeit, eine Qualitätsverschlechterung zu erkennen, bevor Ihre Kunden sie erkennen — und im Hochrisiko-Fall der Verordnung ein nachvollziehbarer Protokollnachweis, dass Sie genau das tun.
Kosten-Dashboards ergänzen. Die Billing-Daten jedes Anbieters lassen sich über dessen API auf einzelne Workflows umlegen. Eine wöchentliche 15-Minuten-Sichtung der Kosten pro Workflow verhindert Budgetüberraschungen und legt offen, wo sich Optimierung wirklich lohnt.
Der Punkt ist nicht, alles zu messen. Der Punkt ist, die sechs Fehlermodi abzudecken, die klassisches Monitoring strukturell übersieht — und dabei so schlank zu bleiben, dass das System gepflegt wird, statt nach drei Monaten zu verwaisen.
Ein Diagnostic prüft Ihr bestehendes Monitoring gegen diese sechs Kategorien — bevor ein stiller Qualitätsausfall Ihre Kunden erreicht oder ein Prüfer nach Ihrem Post-Market-Monitoring-Plan fragt. Wir zeigen Ihnen, welche KI-spezifischen Lücken offen sind, und entwerfen einen Observability-Plan, der auf Ihrem vorhandenen Stack aufsetzt, statt ihn zu ersetzen.
Referenzen: OWASP, „Top 10 for LLM Applications," 2025 (https://owasp.org/www-project-top-10-for-large-language-model-applications/assets/PDF/OWASP-Top-10-for-LLMs-v2025.pdf); Evidently AI, „LLM-as-a-judge: a complete guide," 2025 (https://www.evidentlyai.com/llm-guide/llm-as-a-judge); EU-KI-Verordnung, Art. 72 (Post-Market-Monitoring) und Art. 12 (Protokollierung) (https://artificialintelligenceact.eu/article/72/, https://artificialintelligenceact.eu/article/12/).