Im März 2023 produzierte GPT-4 bei einer Coding-Aufgabe in 52,0 Prozent der Fälle direkt ausführbaren Code. Drei Monate später, im Juni 2023, waren es 10,0 Prozent. Gleicher Modellname, gleicher Provider, gleicher Prompt. Bei der Erkennung von Primzahlen fiel die Trefferquote im selben Zeitraum von 84,0 auf 51,1 Prozent. GPT-3.5 bewegte sich in genau diesem Fenster auf denselben Aufgaben in die Gegenrichtung. Das ist die Studie von Chen, Zaharia und Zou aus Stanford und UC Berkeley (arXiv:2307.09009).
Wenn dein Monitoring-Stack auf 99,9 Prozent Uptime, p95-Latenz und Fehlerquote basiert, hast du davon nichts gesehen. Deine API hat geantwortet. Die Latenz war im Korridor. Der HTTP-Status war 200. Und deine App ist trotzdem still degradiert.
Die Lücke heißt Prompt-Drift
Klassisches DevOps misst, ob ein Service erreichbar ist und wie schnell er antwortet. Beides ist bei einer LLM-Anwendung das uninteressante Drittel. Die anderen zwei Drittel fallen aus dem Raster: Antwortqualität bei realem Nutzerverhalten, und semantische Stabilität über die Zeit.
Drei Dinge ändern sich kontinuierlich, ohne dass du eine Zeile Code anfasst. Erstens: Nutzer formulieren ihre Fragen anders, je länger ein Produkt im Markt ist. Saisonale Themen kommen rein, Slang verschiebt sich, neue Edge Cases tauchen auf. Zweitens: Provider routen Requests still auf andere Backend-Varianten desselben Modells, ohne Versionsnummer-Wechsel. Drittens: Retrieval-Quellen bei RAG-Systemen werden befüllt, aktualisiert, neu indexiert. Jede dieser drei Achsen kann die effektive Antwortqualität verschieben, ohne dass dein Datadog-Dashboard auch nur zuckt.
Genau das hat die Stanford/Berkeley-Gruppe in den GPT-4-Zahlen gemessen. Es war kein Bug, kein Outage, kein Modellwechsel mit großer Versionsnummer. Es war Drift im laufenden Betrieb.
Was Air Canada den Unterschied gekostet hat
Die teuersten Ausfälle einer LLM-App sind keine 500er. Sie sind 200er mit falschem Inhalt.
Im Verfahren Moffatt v. Air Canada (2024 BCCRT 149) hat das BC Civil Resolution Tribunal im Februar 2024 Air Canada wegen fahrlässiger Falschaussage durch den eigenen Chatbot zur Zahlung verurteilt. Der Bot hatte dem Kunden Jake Moffatt erzählt, er könne einen Bereavement-Rabatt rückwirkend beantragen. Die Tarife der Airline sahen das nicht vor. Air Canada argumentierte, der Chatbot sei “a separate legal entity”. Das Tribunal wischte das vom Tisch und sprach 812 CAD inklusive Zinsen und Gebühren zu.
Der Geldbetrag ist die Fußnote. Das Urteil ist die Schlagzeile, weil es ein Präzedenzmuster festschreibt: Was dein Bot in deinem Namen sagt, gilt rechtlich als Aussage deines Unternehmens. Egal, ob das Modell halluziniert, ob ein Retrieval-Hit veraltet ist oder ob ein Prompt-Update vor zwei Wochen die Persona verändert hat. Air Canada hat vor Launch getestet. Was gefehlt hat, war eine Schicht, die sieht, was der Bot tatsächlich in der Produktion sagt.
DPD und Klarna zeigen die zwei Failure-Modes
Am 18. Januar 2024 fing der DPD-Chatbot nach einem System-Update an, Kunden anzupöbeln. Er schrieb Gedichte über die eigene Nutzlosigkeit. Er nannte DPD “the worst delivery service in the world”. Ashley Beauchamps Screenshots erreichten auf X 1,3 Millionen Views. DPD hat den AI-Anteil sofort deaktiviert. Das war kein Drift. Das war ein klar identifizierbares Update, das ein klassischer Post-Deploy-QA-Test gefangen hätte.
Der Klarna-Fall liegt anders. Klarna hatte zwischen 2022 und 2024 rund 700 Stellen abgebaut und durch ein OpenAI-basiertes System ersetzt, das nach Unternehmensangaben 75 Prozent der Kundenchats übernahm: 2,3 Millionen Konversationen in 35 Sprachen. Im Mai 2025 hat CEO Sebastian Siemiatkowski die Rolle rückwärts kommuniziert: Rückkehr zu menschlichem Kundenservice. Sein Zitat: “From a brand perspective… I just think it’s so critical that you are clear to your customer that there will always be a human if you want.” Die Belegschaft war zu diesem Zeitpunkt um 22 Prozent auf 3.500 geschrumpft.
Die zwei Fälle umreißen das Problem. DPD ist der Failure, den ein vernünftiger CI/CD-Test fängt. Klarna ist der Failure, den keiner deiner Tests fängt: eine Qualitätsdrift, die du erst über Beschwerdeaggregate und Tonalitäts-Reports bemerkst, sechs bis zwölf Monate zu spät.
Das Gegenargument hält genau zwei Wochen
Die ehrliche Variante: Mit strukturierter Test-Suite und niedriger Release-Kadenz reicht manuelles QA nach jedem Deploy. Der LangChain State of AI Agents Report 2024 liefert dafür Rückenwind: 39,8 Prozent der Teams nennen Offline-Evaluation als primäre Strategie, nur 32,5 Prozent setzen auf Online-Evaluation. Die Mehrheit der Praktiker hält Pre-Deploy-Tests also für ausreichend.
Das Argument trägt unter einer Bedingung: stabile Inputs. Genau das hat eine produktive LLM-App nicht. Was Nutzer in Woche 7 nach Launch tippen, hat dein Pre-Deploy-Test in Woche 0 nicht gesehen. Was der Provider stillschweigend am Routing dreht, steht in keinem Changelog. Was Chen, Zaharia und Zou gemessen haben, war nichts anderes als drei Monate Realbetrieb auf demselben Modellnamen. Air Canada hatte vor Launch getestet. Es hat nichts genutzt.
Pre-Deploy-Tests beweisen, dass dein Code sich richtig verhält. Sie beweisen nichts über das Verhalten des Modells unter realen Inputs zwei Monate später.
Was im LLM-Stack tatsächlich überwacht werden muss
Die Metriken, die für eine produktive LLM-App zählen, stehen nicht im Standard-APM. BLEU und ROUGE kannst du gleich vergessen. Beide messen lexikalische Überlappung, nicht semantische Korrektheit. Was du brauchst:
- Faithfulness: Steht die Antwort wirklich auf den Quellen, die das RAG-System geliefert hat, oder hat das Modell drumherum fabuliert?
- Answer Relevance: Wie semantisch nah ist die Antwort an der Nutzerfrage?
- Context Precision: Wie viel des retrievten Kontexts war für die Antwort tatsächlich relevant?
Entweder läuft das über LLM-as-judge oder über Embedding-basierte Distanzmaße. Idealerweise auf jedem Production-Trace, nicht nur auf einem Test-Set vor dem Release.
Der Open-Source-Standard, an dem sich das aktuell konsolidiert, sind die OpenTelemetry GenAI Semantic Conventions. Attribute wie gen_ai.operation.name, gen_ai.provider.name, gen_ai.request.model, gen_ai.response.model, gen_ai.usage.input_tokens und gen_ai.usage.output_tokens standardisieren, was du tracen sollst. Wichtig: Stand Mai 2026 sind diese Attribute mit Status “Development” markiert, nicht “Stable”. Arize hat mit OpenInference einen eigenen Standard auf OTel-Basis nachgelegt. Wer jetzt baut, sollte auf OTel setzen und damit rechnen, dass sich Attributnamen noch verschieben.
Warum Datadog hier nicht reicht
LLM-Observability hat sich im Januar 2026 als eigene Infrastruktur-Kategorie etabliert. ClickHouse hat Langfuse als Teil der 400-Millionen-Dollar-Serie-D übernommen. Langfuse zählte zum Akquisitionszeitpunkt 26 Millionen SDK-Installationen pro Monat und war bei 63 Fortune-500-Unternehmen im Einsatz.
Trace-Analyse über Millionen von LLM-Calls braucht Sub-Sekunden-Latenz auf großen Datenmengen. Genau dafür ist klassisches APM-Tooling wie Datadog oder New Relic nicht gebaut. Die Cardinality eines LLM-Trace, mit Prompt-Hashes, Token-Strömen und Tool-Call-Bäumen, sprengt das Datenmodell. Langfuse läuft seit der Übernahme auf nativem ClickHouse-Backend. LLM-Observability ist Datenbank-Infrastruktur geworden, kein Plugin mehr.
Der August 2026 verschiebt das Spielfeld
Wer das Thema noch als Engineering-Hygiene abtut, hat ein Datum vor sich. Am 2. August 2026 greifen die Hochrisiko-Vorgaben des EU AI Act für Annex-III-Systeme: Artikel 12 schreibt automatische Event-Logging-Mechanismen vor, Artikel 13 verlangt Transparenz gegenüber Betreibern, Artikel 9 fordert ein kontinuierliches Risikomanagement-System. Verstöße kosten bis zu 15 Millionen Euro oder 3 Prozent des weltweiten Jahresumsatzes.
“Continuous Risk Management” lässt sich nicht aus quartalsweisen QA-Reports nachweisen. Es braucht laufende Trace-Aufzeichnung, versionierte Prompts mit nachvollziehbarem Diff zu Vorgängern, Faithfulness-Scoring auf Production-Traffic. Was im Mai 2026 noch freiwillige Engineering-Reife ist, wird ab August Compliance-Voraussetzung für jede Hochrisiko-Anwendung.
Was du diese Woche aufsetzen solltest
Drei konkrete Schritte, in dieser Reihenfolge: Trace-Logging für jeden LLM-Call mit OTel-GenAI-Konventionen, idealerweise in Langfuse oder einem äquivalenten LLM-nativen Backend. Darüber ein laufendes Faithfulness-Scoring auf einem statistisch relevanten Sample der Production-Traces, mit Alerting bei Verschiebung des Median-Scores um mehr als zwei Prozentpunkte über sieben Tage. Und schließlich ein Prompt-Versioning-System, das jede Änderung mit dem zugehörigen Trace-Korpus verknüpft, sodass Vorher-Nachher-Vergleiche reproduzierbar sind.
Wenn dein Stack diese drei Dinge nicht hat, betreibst du eine LLM-App im Blindflug. Das ist im April vielleicht kein Problem. Im Juli wird es eines, weil die Drift bis dahin Wochen Zeit hatte. Im August, wenn der EU AI Act in der Hochrisiko-Stufe greift, wird daraus ein Compliance-Befund.
Wer früher als der Markt sieht, welche Engineering-Praxis als nächstes zur Compliance-Pflicht wird, welche Tool-Kategorie still vom Plugin zur Pflicht-Infrastruktur wandert und welche Annahmen aus der DevOps-Welt im LLM-Stack nicht mehr tragen: Der KI-Syndikat Newsletter ordnet diese Verschiebungen einmal pro Woche ein, mit Quellen und ohne Schaumschlägerei.