AI Observability und LLM-Evaluation: KI-Qualität im Betrieb messen

AI Observability entscheidet 2026 darüber, ob KI-Anwendungen den Schritt aus dem Pilotbetrieb in den Alltag schaffen. Denn die Nutzung wächst schneller als die messbare Wirkung: Der Stanford AI Index 2026 zählt 88 % Organisationen mit KI-Einsatz und 70 % mit generativer KI in mindestens einer Geschäftsfunktion (Bezugsjahr 2025). Laut Bitkom-KI-Studie vom 14. September 2026 nutzen 57 % der deutschen Unternehmen ab 20 Beschäftigten KI, aber keines schöpft das Potenzial nach eigener Einschätzung voll aus.

Zwischen Pilot und Betrieb fehlt selten das bessere Modell, meist fehlt die Messung. Wer nicht weiß, wie gut eine Anwendung antwortet, was sie kostet und wann sie kippt, kann sie weder verbessern noch verantworten.

Dieser Leitfaden erklärt AI Observability und LLM-Evaluation, vergleicht Werkzeuge (Stand: September 2026), ordnet den Rechtsrahmen ein und zeigt einen 90-Tage-Plan, mit dem der erste Use Case vom Pilot in die Produktion kommt.

AI Observability ist die laufende Messung dessen, was eine KI-Anwendung im Betrieb tut: welche Modelle mit welchen Eingaben aufgerufen werden, wie lange Antworten dauern, wie viele Tokens sie verbrauchen und welche Werkzeuge ein Agent aufruft. LLM-Evaluation ist die Prüfung, wie gut die Antworten sind, gemessen an Testfällen, Quellen und fachlichen Kriterien.

Observability ist damit das Gegenstück zum klassischen Application Performance Monitoring (APM). Sie liefert Traces, also die Spur einer Anfrage durch Prompt, Datenabruf, Modell und Werkzeuge, dazu Logs und Metriken. Einen gemeinsamen Standard beschreiben die OpenTelemetry-Konventionen für generative KI; sie haben noch den Status „Development“ und werden laufend erweitert, etwa um Agenten und MCP.

LLM-Evaluation läuft auf zwei Zeitachsen. Vor dem Deployment prüft eine Testsuite neue Prompts oder Modelle gegen ein Golden Set, also eine kuratierte Sammlung von Testfällen mit erwarteten Ergebnissen. Im Betrieb bewerten Stichproben aus echtem Verkehr, ob die Qualität hält. Eine dritte Schicht bilden Guardrails: Filter, die einzelne Antworten vor der Auslieferung prüfen, etwa auf personenbezogene Daten oder Jailbreaks.

Die praktische Folge: Observability allein zeigt, dass etwas passiert, aber nicht, ob es gut ist. Evaluation allein zeigt, dass ein System im Test funktioniert, aber nicht, wann es im Betrieb kippt. Erst die Kombination liefert die Aussage, die Fachbereich, IT-Sicherheit und Geschäftsführung brauchen.

Drei Entwicklungen machen Messbarkeit vom Entwicklerthema zur Führungsaufgabe: Modelle wechseln schneller, KI-Kosten wachsen mit der Nutzung, und Kunden, Prüfer und Aufsicht verlangen Nachweise.

1. Modelle wechseln im Abstand weniger Monate. Die großen Anbieter bringen in kurzen Abständen neue Modellgenerationen heraus und stellen ältere Versionen ein. Nach einem Wechsel antwortet dieselbe Anwendung anders, kostet anders und reagiert anders auf dieselben Prompts. Ohne Eval-Suite wird jeder Modellwechsel zum Blindflug.

2. KI-Kosten wachsen mit der Nutzung. Token-Kosten entstehen pro Anfrage, nicht pro Lizenz. Wer sie nicht je Anwendung, Team und Modell erfasst, hat nach dem Go-live keine Grundlage für Budgets und Modellentscheidungen. Wie Sie das organisieren, beschreibt der Leitfaden FinOps für KI: Token-Kosten kontrollieren.

3. Nachweise werden verlangt. Für Hochrisiko-Systeme schreibt die KI-Verordnung Protokollierung, Genauigkeitsangaben und Überwachung im Betrieb vor. Auch außerhalb dieser Kategorie fragen Kunden, Wirtschaftsprüfer und Betriebsräte, wie Qualität und Datenschutz gesichert sind. Ohne Messdaten bleibt jede Antwort darauf eine Behauptung.

Produktive KI-Anwendungen brauchen Kennzahlen auf vier Achsen: Qualität, Sicherheit, Kosten und Performance. Wer eine davon auslässt, erkennt Probleme erst, wenn Nutzer sie melden.

Zwei Hinweise aus der Praxis. Antwortzeiten von Sprachmodellen streuen stark, Alarme auf den Mittelwert führen deshalb in die Irre. Sinnvoll sind Schwellen auf P95 oder P99 und bei gestreamten Antworten die Zeit bis zum ersten Token. Außerdem sollten Rabatte für Cache-Treffer und Batch-Verarbeitung korrekt in die Kostenberichte einfließen, sonst führen zu hohe Werte zu falschen Modellentscheidungen.

Der Markt teilt sich in fünf Lager: selbst betreibbare Plattformen, Eval-orientierte SaaS-Anbieter, an Frameworks gebundene Werkzeuge, Erweiterungen klassischer APM-Suiten und KI-Gateways. Welches passt, hängt vor allem von Datenresidenz, vorhandenem Monitoring und der gewünschten Tiefe der Evaluation ab.

• Langfuse gehört zu ClickHouse. ClickHouse hat das Berliner Unternehmen am 16. Januar 2026 übernommen. Die Kernfunktionen bleiben laut ClickHouse unter MIT-Lizenz und selbst betreibbar, das Team entwickelt Langfuse weiter (Langfuse). ClickHouse nennt 19 der Fortune 50 als Nutzer.
• Helicone läuft im Wartungsmodus. Nach der Übernahme durch Mintlify am 3. März 2026 kommen noch Sicherheitsupdates, Fehlerbehebungen und neue Modelle; Mintlify begleitet Kunden beim Wechsel auf eine andere Plattform (Mintlify). Für neue Projekte ist Helicone keine naheliegende Wahl mehr.
• Braintrust hat 80 Mio. US-Dollar eingesammelt. Die Series B vom 17. Februar 2026 führte ICONIQ an; als Kunden nennt Braintrust unter anderem Notion, Replit und Cloudflare (Braintrust).
• LangChain ist mit 1,25 Mrd. US-Dollar bewertet. Der Anbieter von LangSmith sammelte am 20. Oktober 2025 125 Mio. US-Dollar ein (LangChain).

Für viele Mittelständler ist Langfuse ein pragmatischer Ausgangspunkt: quelloffen, in der EU selbst betreibbar und mit integrierten Evals. In der Cloud-Variante klären Sie vorab Datenregion und Auftragsverarbeitungsvertrag.

Für LLM-Evaluation haben sich einige Open-Source-Bibliotheken etabliert, allen voran DeepEval, Ragas, Promptfoo und TruLens. Sie unterscheiden sich vor allem darin, ob sie Tests in der CI, die Qualität von RAG-Anwendungen oder Sicherheitstests in den Mittelpunkt stellen.

Die wichtigste Veränderung betrifft OpenAI: Bestehende Evals der hauseigenen Plattform sind ab dem 31. Oktober 2026 nur noch lesbar, Dashboard und API enden am 30. November 2026 (OpenAI, Deprecations). Als Migrationspfad empfiehlt OpenAI Promptfoo, das seit März 2026 zu OpenAI gehört; das Open-Source-Projekt wird laut Promptfoo fortgeführt. Wer Modelle mehrerer Anbieter vergleicht, sollte diese Nähe kennen.

Öffentliche Benchmarks helfen bei der Vorauswahl von Modellen. Tests mit Ihren eigenen Daten ersetzen sie nicht.

• LMArena (früher Chatbot Arena) vergleicht Modelle über anonyme Paarvergleiche von Nutzern und zeigt vor allem die Qualität im Dialog.
• Stanford HELM ist ein transparenter, szenarienbasierter Benchmark aus der Forschung und eignet sich als etablierte Referenz.
• Vectara Hallucination Leaderboard misst, wie oft Modelle beim Zusammenfassen vorgegebener Texte Inhalte hinzuerfinden, auf Basis von über 7.700 Texten und Vectaras Bewertungsmodell HHEM-2.3.

Eine Auswahl aus dem Leaderboard (Stand 11. Mai 2026):

Zwei Lehren daraus: Kleine Modelle halluzinieren beim Zusammenfassen nicht zwingend häufiger, gpt-5.4-nano liegt mit 3,1 % vor gpt-5.5 mit 9,3 %. Und die jüngsten Modellgenerationen der großen Anbieter (Stand September 2026) sind noch nicht gelistet; wer sie einsetzt, braucht eigene Tests. Wie Sie das Risiko im Alltag begrenzen, zeigt der Leitfaden KI-Halluzinationen kontrollieren.

LLM-as-Judge bezeichnet die Bewertung von Antworten durch ein zweites Sprachmodell. Das Verfahren skaliert gut und liefert brauchbare Ergebnisse, wenn Sie seine bekannten Verzerrungen ausgleichen und das Urteil regelmäßig an menschlichen Bewertungen eichen.

Methodisch geht der Ansatz unter anderem auf G-Eval zurück (Liu et al., 2023). Mit GPT-4 als Bewerter erreichte G-Eval bei Zusammenfassungen eine Spearman-Korrelation von 0,514 mit menschlichen Urteilen und übertraf damit frühere Verfahren deutlich. Schon die Autoren wiesen darauf hin, dass solche Bewerter von Sprachmodellen erzeugte Texte bevorzugen können.

Drei Verzerrungen sind gut dokumentiert, unter anderem in der Studie zu MT-Bench und Chatbot Arena (Zheng et al., 2023):

1. Selbstbevorzugung: Ein Bewerter bevorzugt Antworten, die seinem eigenen Stil entsprechen, besonders aus derselben Modellfamilie.
2. Positionseffekt: Bei A/B-Vergleichen gewinnt oft die zuerst genannte Antwort. Gegenmittel: Reihenfolge zufällig tauschen und die Ergebnisse mitteln.
3. Längeneffekt: Längere Antworten werden tendenziell besser bewertet, unabhängig von ihrer Qualität. Gegenmittel: Bewertungsraster mit ausdrücklicher Längenkontrolle.

In der Praxis haben sich zwei Regeln bewährt. Der Bewerter stammt aus einer anderen Modellfamilie als das produktive Modell. Und ein Kalibrierset aus manuell bewerteten Beispielen prüft den Bewerter selbst; als Erfahrungswert sind rund 100 Beispiele je Use Case ein guter Start.

Für Hochrisiko-KI-Systeme verlangt die KI-Verordnung automatische Protokollierung (Art. 12), dokumentierte Genauigkeitswerte (Art. 13 und 15) und Überwachung im Betrieb (Art. 26). Nach dem Digital Omnibus gelten diese Pflichten ab dem 2. Dezember 2027 für Systeme nach Anhang III und ab dem 2. August 2028 für KI in Produkten nach Anhang I.

Art. 12, Protokollierung. Hochrisiko-Systeme müssen Ereignisse über ihre gesamte Lebensdauer automatisch aufzeichnen können (Art. 12). Die Protokolle sollen Risikosituationen erkennbar machen und die Überwachung nach dem Inverkehrbringen sowie durch den Betreiber ermöglichen. Betreiber bewahren sie mindestens sechs Monate auf, soweit andere Vorschriften nichts anderes bestimmen (Art. 26 Abs. 6).

Art. 13 und 15, Genauigkeit und Robustheit. Hochrisiko-Systeme müssen über ihren Lebenszyklus ein angemessenes Maß an Genauigkeit, Robustheit und Cybersicherheit erreichen und gegen Angriffe wie Data Poisoning oder manipulierte Eingaben widerstandsfähig sein (Art. 15). Genauigkeitsgrade und Metriken gehören in die Betriebsanleitung (Art. 15 Abs. 3), wo relevant auch die Leistung für bestimmte Personengruppen (Art. 13). Wer heute keine Metriken und Protokolle sammelt, kann den Nachweis später kaum nachholen.

Art. 4, KI-Kompetenz. Seit dem Digital Omnibus verlangt Art. 4 Maßnahmen, um die KI-Kompetenz der Beschäftigten zu fördern, aber keinen Pflichtkurs und kein Zertifikat. Für Eval-Teams bleibt dokumentierte Weiterbildung sinnvoll, weil sie Qualität und Nachweisführung stützt.

NIST AI RMF und NIST AI 600-1. Das NIST AI Risk Management Framework gliedert Risikomanagement in Govern, Map, Measure und Manage. Das Profil für generative KI (NIST AI 600-1, Juli 2024) beschreibt zwölf Risiken, darunter Konfabulation, also Halluzinationen. Für Unternehmen in der EU ist beides freiwillig, aber eine gute gemeinsame Sprache mit Prüfern.

ISO/IEC 42001. Die Norm von Dezember 2023 beschreibt ein zertifizierbares Managementsystem für KI. Wie jede Managementsystemnorm verlangt sie, Leistung zu überwachen, zu messen und zu bewerten; Observability- und Eval-Daten liefern dafür die Grundlage.

Datenschutz und Protokollierung. Protokollpflicht und Datenminimierung nach Art. 5 DSGVO stehen in Spannung. Die OpenTelemetry-Konventionen führen Prompt- und Antwortinhalte deshalb nur als Opt-in und warnen, dass sie personenbezogene Daten enthalten können. Bewährt hat sich: Metadaten wie Modell, Tokens, Latenz und Kosten immer protokollieren, Inhalte nur, wo es dokumentiert nötig ist, dann geschwärzt und kürzer aufbewahrt.

In 90 Tagen lässt sich ein produktiver Use Case durchgängig instrumentieren: mit Traces, einer Eval-Suite in der CI, Dashboards für Qualität und Kosten und dokumentierten Datenflüssen. Der folgende Plan ist ein Vorschlag, den Sie an Ihre Ausgangslage anpassen.

Nicht jede Phase wird in zwölf Wochen perfekt. Entscheidend ist, dass ein Use Case durchgängig messbar ist; weitere lassen sich auf dieser Grundlage deutlich schneller anschließen.

Die häufigsten Fehler sind Observability ohne Evaluation, Messung erst im Störfall, blindes Vertrauen in LLM-Bewerter, zu viel protokollierter Inhalt und die Suche nach einem Werkzeug für alles.

1. Observability als APM-Erweiterung behandeln. APM-Suiten liefern solides Tracing, aber keine Faithfulness-Messung und keine LLM-as-Judge-Pipeline. Behalten Sie APM für die Infrastruktur und ergänzen Sie ein LLM-natives Werkzeug für Qualität und Evals.
2. Erst messen, wenn es brennt. Nachträglich eingebaute Telemetrie ist erfahrungsgemäß deutlich aufwendiger als von Anfang an mitgeplante, und ohne Traces dauert jede Fehlersuche länger.
3. LLM-as-Judge für die Wahrheit halten. Ohne Bewerter aus einer anderen Modellfamilie und ohne Kalibrierset entstehen schöne, aber unzuverlässige Statistiken.
4. Alles mit Inhalt protokollieren. Vollständige Prompts und Antworten aus dem Kundenverkehr sind datenschutzrelevant. Erfassen Sie Inhalte nur, wo es dokumentiert nötig ist, und dann geschwärzt.
5. Ein Werkzeug für alles suchen. Tracing, Evals, Kostensteuerung und Guardrails löst selten ein Produkt gleich gut. Pragmatisch ist die Kombination aus Observability-Plattform, Eval-Framework, vorhandenem APM und bei Bedarf Guardrails.

Plotdesk verbindet eine KI-Plattform mit einem Umsetzungsteam für den Mittelstand. Die Plattform liefert die Steuerungsebene für Modelle, Nutzung und Kosten, das Team verankert Kennzahlen und Evals im jeweiligen Use Case.

Plotdesk läuft als dedizierte Instanz in der EU oder im eigenen Tenant und bündelt mehr als 100 Modellvarianten aus zehn Provider-Typen. Für messbare KI im Betrieb sind vor allem diese Funktionen relevant:

• Nutzungs- und Kostenanalysen: Verbrauch und Kosten je Team, Bereich und Modell als Grundlage für Budgets und Modellentscheidungen.
• Modell- und Kostensteuerung: Welche Teams welche Modelle nutzen, legen Sie je Team oder Bereich fest.
• Audit-Logs und Rechte: SSO, Rollen und mehr als 40 Berechtigungen machen Zugriffe und Änderungen nachvollziehbar.
• Protokollierte Werkzeugaufrufe: Aufrufe angebundener MCP-Server werden protokolliert, neue Werkzeuge sind erst nach Freigabe nutzbar.

Ehrlich eingeordnet: Für tiefe Trace- und Eval-Analysen einzelner Anwendungen, etwa die Faithfulness-Messung einer RAG-Pipeline in der CI, bleiben spezialisierte Werkzeuge wie Langfuse oder DeepEval sinnvoll. Plotdesk ersetzt sie nicht, sondern schafft den gesteuerten Rahmen, in dem Modelle, Daten und Kosten zusammenlaufen.

Die Zusammenarbeit folgt vier Schritten:

1. KI-Potenzialanalyse: Welche Anwendungen laufen, wo fehlen Messung und Evals, welcher Use Case lohnt sich zuerst?
2. Proof of Value: Ein priorisierter Use Case geht mit echten Daten in Betrieb, mit Kennzahlen und Ausgangswerten von Anfang an.
3. Produktive Lösung: Der Use Case läuft stabil, mit klaren Zuständigkeiten, Alarmen und Kostenrahmen.
4. Systematischer Ausbau: Weitere Use Cases folgen auf derselben Messgrundlage.

Ein erstes Ergebnis im Betrieb steht in der Regel nach rund vier Wochen. Für die Wahl des Einstiegs greift das Team auf 1.200+ Use Cases in 15 Branchen zurück.

Die Lücke zwischen breiter KI-Nutzung und messbarer Wirkung ist vor allem ein Messproblem. Wer nicht weiß, wie gut die eigenen KI-Antworten sind, wie zuverlässig Agenten arbeiten und was jeder Use Case kostet, kann weder gegenüber der Geschäftsführung noch gegenüber Controlling oder IT-Sicherheit steuern.

Die Werkzeuge dafür sind ausgereift, von Langfuse und Arize Phoenix über DeepEval und Ragas bis zu den LLM-Modulen der APM-Anbieter. Zu entscheiden bleibt, welche Schichten Sie einkaufen und welche Sie selbst betreiben.

Beginnen Sie mit einem Use Case, machen Sie ihn in 90 Tagen durchgängig messbar und bauen Sie auf dieser Grundlage aus. Für Hochrisiko-Systeme verschafft der Digital Omnibus Zeit bis Dezember 2027. Nutzen Sie diese Zeit, um saubere Messdaten aufzubauen.