LLM-Observability im Unternehmensbetrieb: Welche Signale KI-Teams vor dem ersten echten Incident brauchen

Viele interne KI-Projekte sehen in der Pilotphase besser aus, als sie im Regelbetrieb wirklich sind. Im Demo-Termin liefert der Assistent plausible Antworten, das Retrieval wirkt schnell genug und die Fachseite ist zufrieden. Erst nach dem Go-live zeigen sich die eigentlichen Betriebsfragen: Warum steigen die Kosten in einzelnen Mandanten sprunghaft? Weshalb liefert derselbe Use Case unter Last plötzlich schwächere Antworten? Warum ruft der Agent ein Tool zweimal auf, obwohl ein Schritt reichen müsste? Und warum merkt der Service Desk den Qualitätsabfall früher als das Plattformteam?

Genau hier beginnt LLM-Observability. Sie ist kein Luxus für sehr große AI-Programme, sondern die betriebliche Voraussetzung dafür, dass Teams Qualität, Kosten, Sicherheit und Störungen überhaupt steuern können. NIST beschreibt im AI Risk Management Framework und im zugehörigen Playbook ausdrücklich, dass KI-Risiken nicht nur vor dem Rollout bewertet, sondern im laufenden Betrieb gemessen und gemanagt werden müssen. OpenTelemetry übersetzt das inzwischen in konkrete semantische Konventionen für GenAI-Metriken, Events und Spans. Microsoft Foundry nennt für den operativen Betrieb dieselben Grundbausteine sehr direkt: Evaluation, Monitoring und Tracing.

Für IT- und KI-Teams ist die praktische Konsequenz klar: Wer produktive LLM-Anwendungen betreibt, braucht nicht nur Logs, sondern ein kleines, diszipliniertes Set an Signalen, das Diagnose und Steuerung wirklich ermöglicht.

1. Ohne End-to-End-Tracing bleibt jede Störung eine Interpretationsdebatte

Der häufigste Fehler ist ein Monitoring, das nur den Modellaufruf misst. Damit sieht das Team vielleicht Antwortzeiten und Fehlerraten des Providers, aber nicht den tatsächlichen Ablauf der Anwendung. In produktiven Assistenten besteht eine Nutzeranfrage meist aus mehreren Schritten: Prompt-Vorbereitung, Retrieval, Modellaufruf, Tool-Nutzung, eventuell ein zweiter Modellschritt und erst dann die Antwort. Wenn davon nur der eigentliche LLM-Call sichtbar ist, beginnt im Incident sofort das Rätselraten.

OpenTelemetry adressiert genau dieses Problem. Die GenAI-Spezifikation beschreibt eigene Spans für Inference, Retrievals und Tool-Ausführung sowie zusätzliche Agent-Spans für komplexere Workflows. Praktisch heißt das: Jede produktive Anfrage sollte als nachvollziehbarer Ablauf sichtbar sein, inklusive Modell, Operation, Gesprächskontext, Fehlerklasse und den beteiligten externen Komponenten.

Für den Betrieb bringt das drei direkte Vorteile. Erstens lässt sich eingrenzen, ob ein Problem im Modell, im Vektor-Store, im Tooling oder in der Orchestrierung entsteht. Zweitens werden Latenzspitzen nicht pauschal dem Modell zugeschrieben, obwohl oft das Retrieval oder ein langsamer Drittservice bremst. Drittens können Teams Wiederholungsmuster erkennen, etwa doppelte Tool-Calls oder unnötige Re-Queries, die Kosten und Antwortzeit zugleich treiben.

Wer nur eine einzige Maßnahme sofort umsetzen kann, sollte mit genau diesem End-to-End-Trace anfangen.

2. Token, Dauer und Time-to-First-Response müssen pro Pfad sichtbar sein, nicht nur als Monatswert

Im klassischen Applikationsmonitoring reicht oft eine Gesamtansicht auf CPU, Fehlerraten oder Response Time. Bei LLM-Anwendungen ist das zu grob. OpenTelemetry führt deshalb eigene Metriken wie gen_ai.client.token.usage, gen_ai.client.operation.duration und gen_ai.client.operation.time_to_first_chunk. Genau diese Perspektive ist operativ wichtig.

Ein Monatsreport mit Gesamtkosten hilft kaum, wenn einzelne Prompts, Mandanten, Modelle oder Agentpfade aus dem Ruder laufen. Teams sollten Tokenverbrauch, Gesamtdauer und erste sichtbare Antwort daher mindestens entlang von vier Dimensionen schneiden: Use Case, Modellversion, Anwendungspfad und Tenant oder Nutzergruppe. Sonst bleiben Kosten und Performance zwar „gemessen“, aber nicht steuerbar.

Besonders relevant ist die erste sichtbare Antwort. Nutzer bewerten KI-Services nicht nur nach der Gesamtdauer, sondern danach, ob schnell erkennbar ist, dass das System arbeitet. Bei Streaming-Antworten kann eine gute time to first chunk die wahrgenommene Qualität deutlich verbessern, selbst wenn die komplette Antwort etwas länger braucht. Umgekehrt verdecken gute Mittelwerte oft, dass einzelne Tool- oder Retrieval-Pfade viel zu spät anspringen.

Für Service Owner ist das die Basis für sinnvolle SLOs. Nicht „das Modell war durchschnittlich schnell“, sondern zum Beispiel: 95 Prozent der Antworten im Support-Assistenten beginnen innerhalb von zwei Sekunden, und 95 Prozent bleiben unter einem definierten Token-Budget pro Falltyp.

3. Qualitätsmetriken gehören in den Regelbetrieb, nicht nur in den Abnahmetest

Viele Teams prüfen Antwortqualität intensiv vor dem Go-live und verlassen sich danach zu stark auf Stichproben. Gerade bei LLM-Anwendungen reicht das nicht. Datenquellen ändern sich, Prompts werden angepasst, Modelle werden aktualisiert, Retrieval-Indizes wachsen und Nutzer bringen neue Fragestellungen mit. Ohne laufende Qualitätsmessung wird Verschlechterung oft erst sichtbar, wenn Beschwerden auftauchen.

Microsoft Foundry beschreibt Observability deshalb nicht nur als Technikmonitoring, sondern ausdrücklich als Kombination aus Evaluation, Monitoring und Tracing. Interessant ist dabei der operative Zuschnitt der Evaluatoren: Neben allgemeinen Qualitätsmaßen nennt Microsoft RAG-spezifische Kriterien wie Groundedness und Relevanz sowie agentenspezifische Messgrößen wie Tool-Call-Accuracy und Task-Completion.

Genau daraus lässt sich ein praxistaugliches Minimalset ableiten. Für interne Wissensassistenten sollten Teams laufend messen, ob Antworten auf die tatsächlich referenzierten Quellen gestützt sind, ob die gefundenen Dokumente zur Frage passen und ob Antworten in kritischen Prozessen einen definierten Qualitätsgrenzwert halten. Für Agenten mit Aktionen oder API-Aufrufen kommt hinzu, ob das richtige Werkzeug im richtigen Schritt und mit plausiblen Parametern verwendet wurde.

Wichtig ist dabei eine nüchterne Betriebslogik: Qualitätsmetriken müssen nicht perfekt sein, aber stabil genug, um Trends und Ausreißer sichtbar zu machen. Ein schwächeres, konsequent angewandtes Bewertungsset ist im Alltag nützlicher als ein theoretisch ideales Evaluationsmodell, das nie regelmäßig läuft.

4. Retrieval und Tool-Nutzung brauchen eigene Fehlersicht, sonst landet jede Eskalation beim Modellteam

Je stärker KI-Anwendungen mit Wissensquellen und Tools arbeiten, desto seltener liegt das Kernproblem allein im Modell. Ein veralteter Index, eine falsche Chunking-Strategie, Berechtigungsfehler im Dokumentenzugriff, eine instabile API oder eine schleichend schlechtere Tool-Auswahl können die Servicequalität massiv senken, obwohl das Modell selbst korrekt funktioniert.

OpenTelemetry trägt diesem Umstand Rechnung, indem Retrievals und Tool-Ausführung nicht als versteckte Details, sondern als eigene beobachtbare Schritte modelliert werden. Für den Betrieb bedeutet das: Teams sollten getrennt sehen können, welche Datenquelle abgefragt wurde, wie lange der Zugriff dauerte, wie oft kein brauchbarer Kontext zurückkam, welches Tool aufgerufen wurde und mit welcher Fehlerklasse der Aufruf endete.

Das ist nicht nur für die Diagnose wichtig. Es verändert auch Verantwortlichkeiten. Sobald Retrieval und Tools sauber sichtbar sind, lassen sich Incidents gezielter an Knowledge-Verantwortliche, API-Owner oder Plattformteams routen, statt jede Eskalation reflexhaft dem AI-Team zuzuschieben. Gerade in größeren Organisationen ist das ein echter Reifegewinn.

5. Gute Observability endet nicht im Dashboard, sondern in Alarmen, Fallbacks und Change-Disziplin

NIST betont im AI RMF und im Playbook, dass Risiken nicht nur identifiziert, sondern aktiv gemanagt werden müssen. Für den Unternehmensbetrieb heißt das: Beobachtbarkeit ist erst dann wirksam, wenn aus Signalen konkrete Reaktionen folgen. Ein hübsches Dashboard ersetzt keinen Betriebsmechanismus.

Praktisch sollten Teams deshalb für produktive KI-Dienste klare Schwellen definieren, die echte Aktionen auslösen. Beispiele sind ungewöhnliche Tokenanstiege pro Anfrage, fallende Groundedness-Werte in einem sensiblen Wissensassistenten, steigende Fehlerraten bei Tool-Calls oder Antwortpfade, die ein Budget- oder Latenzlimit reißen. Die Reaktion kann je nach Kritikalität unterschiedlich aussehen: Alarm an den Bereitschaftskanal, automatischer Wechsel auf ein robusteres Modell, Abschalten eines riskanten Tools, Rückfall auf reine Suche oder Übergabe an einen menschlichen Bearbeiter.

Ebenso wichtig ist die Verbindung zu Change und Release. Wenn Modellversion, Systemprompt, Retrieval-Strategie oder Tool-Berechtigungen geändert werden, müssen Teams die relevanten Qualitäts- und Betriebsmetriken vor und nach dem Change vergleichen. Sonst bleibt unklar, ob eine Verschlechterung durch externes Nutzungsverhalten oder durch die eigene Änderung entstanden ist. Genau an dieser Stelle wird LLM-Observability vom Technikdetail zur Führungsinformation.

Fazit

LLM-Observability ist kein Zusatzmodul für später, sondern Teil des eigentlichen Betriebsmodells. Wer produktive KI-Anwendungen ernst nimmt, braucht nachvollziehbare Traces über den gesamten Anfragepfad, belastbare Metriken für Token und Latenz, laufende Qualitätsmessung, getrennte Sicht auf Retrieval und Tooling sowie Reaktionsmechanismen für Abweichungen.

Der entscheidende Punkt ist dabei nicht maximale Messfülle, sondern betriebliche Brauchbarkeit. Ein kleines Set sauber definierter Signale hilft mehr als ein überladenes Dashboard ohne Konsequenzen. Erst wenn Teams sehen, wo Qualität, Kosten und Risiko tatsächlich entstehen, wird aus einer faszinierenden Demo ein steuerbarer Service.

Quellen

• NIST: AI Risk Management Framework
• NIST AIRC: AI RMF Playbook
• OpenTelemetry: Semantic conventions for generative AI systems
• OpenTelemetry: Semantic conventions for generative AI metrics
• OpenTelemetry: Semantic conventions for generative client AI spans
• OpenTelemetry: Semantic conventions for GenAI agent and framework spans
• Microsoft Foundry: Observability in Generative AI