AI Observability: Vertrauen und Kontrolle bei KI in der Produktion

Wenn künstliche Intelligenz den Kundensupport, Finanzanalysen, Compliance-Workflows oder Führungsentscheidungen beeinflusst, stellt eine fehlerhafte Ausgabe ein Geschäftsrisiko dar. Dennoch bieten die meisten KI-Implementierungen in Unternehmen erstaunlich wenig Transparenz darüber, warum ein System eine bestimmte Antwort generiert hat oder was zu tun ist, wenn etwas schiefgeht.

Die Observability von künstlicher Intelligenz bietet Unternehmen die Möglichkeit, das Verhalten von KI-Systemen zu überprüfen, nachdem sie die kontrollierte Umgebung eines Prototyps verlassen haben – wo die Ausgaben nicht nur vom Modell selbst abhängen, sondern auch von Prompts, Richtlinien, Tool-Aufrufen, Latenz und den kontrollierten Daten, die zum Zeitpunkt der Anfrage verfügbar sind. Observability hilft Teams, dieses Verhalten zu verstehen und die Fragen zu beantworten, die darüber entscheiden, ob man sich auf ein KI-System verlassen kann: Was macht das System eigentlich? Warum? Können wir ihm vertrauen?

Observability verwandelt KI von einer Blackbox in ein System, das kontinuierlich und in großem Maßstab beobachtet, gemessen, hinterfragt und geregelt werden kann. Für Unternehmen, die KI mit geschäftskritischen Daten betreiben, ist sie das Fundament, auf dem vertrauenswürdige Unternehmens-KI aufbaut.

AI Observability ist die Praxis der Instrumentierung, Auswertung und des Tracings von KI-Systemen, damit Teams deren Verhalten über den gesamten Pfad von der Eingabe bis zur Ausgabe nachvollziehen können. Bei einer Anwendung mit generativer KI kann dieser Pfad den Benutzer-Prompt, abgerufene Dokumente, die Modellantwort, Tool-Aufrufe, logische Zwischenschritte, Latenz, Token-Nutzung, Kosten und Auswertungsergebnisse umfassen. Bei einem Agentic-System kann er auch die Abfolge der vom Agenten durchgeführten Aktionen, die ausgewählten Tools und die Daten umfassen, auf die er dabei zugegriffen hat.

AI Observability stützt sich in der Regel auf vier Fähigkeiten:

• Transparenz: Teams benötigen Einblick in das Verhalten des KI-Systems, um zu erkennen, wie Prompts, abgerufener Kontext, Modellantworten, Tool Calls und Anwendungslogik im gesamten Workflow zusammenwirken. Transparenz bringt ans Licht, wo ein Problem seinen Ursprung hat und was getan werden muss, um es zu beheben.
• Messbarkeit: Organisationen benötigen eine konsistente Methode, um zu bewerten, ob KI-Ausgaben für den von ihnen unterstützten Workflow präzise, relevant, fundiert, sicher, zeitgerecht und kosteneffizient sind. Messbarkeit bietet Teams die Möglichkeit, Prompts, Modelle, Abrufstrategien und Konfigurationen anhand von Fakten statt Vermutungen zu vergleichen.
• Regelbarkeit: KI-Systeme müssen innerhalb der Kontrollmechanismen des Unternehmens agieren. Das bedeutet, dass Zugriffsrichtlinien eingehalten, genehmigte Datenquellen verwendet, Auswertungen aufgezeichnet und ausreichend Trace-Daten aufbewahrt werden müssen, um Fehler zu untersuchen. Da KI in regulierte Workflows integriert wird und sensible Daten verarbeitet, muss Observability ein Teil der Governance werden und darf kein separates technisches Anliegen bleiben. Für Unternehmen, die unter den EU AI Act fallen, ist Regelbarkeit keine optionale Eigenschaft: Hochrisiko-KI-Systeme müssen gemäß Art. 9, 13 und 17 über ein Risikomanagementsystem, Transparenznachweise und ein Qualitätsmanagementsystem verfügen – Anforderungen, die ohne systematische Observability nicht erfüllbar sind.
• Erklärbarkeit: Fachanwender:innen, Prüfer:innen, Entwickler:innen und Führungskräfte müssen verstehen, wie ein Output zustande gekommen ist, bevor sie ihm vertrauen können. Erklärbarkeit (Explainability) erfordert nicht, dass jedes interne Detail eines Modells offengelegt wird. Es müssen jedoch die Eingaben, der Kontext, der Entscheidungspfad und die Evaluierungsnachweise aufgezeigt werden, die es einem Team ermöglichen, Untersuchungen durchzuführen, Fehler zu beheben und Verbesserungen vorzunehmen.

AI Observability überschneidet sich zwar mit Modell-Monitoring und ML-Monitoring, ist aber umfassender.

• Modell-Monitoring konzentriert sich auf ein bereitgestelltes Modell: Teams verfolgen, ob die Vorhersagen des Modells weiterhin präzise sind, ob es bei den Eingabedaten zu einem Drift gekommen ist, ob sich die Latenz ändert und ob das Modell weiterhin die erwarteten Service-Level-Ziele erfüllt. Dies ist der Kern des Monitorings für viele überwachte Systeme für Machine Learning (ML), insbesondere für solche mit einer klaren Ground Truth wie Betrugserkennung, Abwanderungsprognosen oder Nachfragevorhersagen.
• ML-Monitoring erweitert diese Perspektive auf die gesamte Pipeline: Die Modellperformance kann sich verschlechtern, weil Features zu spät eintreffen, Labels verzögert sind, Schemaänderungen eine Transformation unterbrechen oder ein Batch-Job fehlende Werte einführt. ML-Monitoring überwacht den operativen Pfad rund um das Modell, einschließlich Datenqualität, Aktualität der Features, Zustand der Pipeline und Vorhersageverhalten.
• AI Observability deckt das gesamte KI-System ab: In einer Anwendung mit einem Large Language Model (LLM) ist das Modell nur eine Komponente in einer größeren Kette. Eine RAG-App könnte fünf Dokumente abrufen, drei davon an den Prompt übergeben, ein LLM aufrufen, einen Guardrail anwenden und die Antwort in einen Workflow schreiben. Ein Agent könnte eine Aufgabe planen, ein Such-Tool aufrufen, eine Tabelle abfragen, Ergebnisse zusammenfassen, ein weiteres Tool aufrufen und dann eine Empfehlung ausgeben. Observability muss den gesamten Trace erfassen, nicht nur die finale Antwort.

Lesen Sie unseren Leitfaden zu MLOps, um zu erfahren, wie Teams den ML-Lebenszyklus operationalisieren – von der Modellentwicklung und Deployment bis hin zu Monitoring und Management in der Produktion.

Die klassischen Säulen der Observability sind Logs, Metriken und Traces. Sie gelten nach wie vor für KI-Systeme, aber die beobachteten Objekte sind andere. Anstatt nur auf Servicefehler, CPU-Auslastung oder API-Latenz zu achten, müssen Teams auch Prompts, abgerufene Dokumente, Modellantworten, Embedding-Verhalten, Token-Nutzung, Tool-Aufrufe, Groundedness-Scores und menschliches Feedback untersuchen.

Protokolle (Logs)

Auf Ereignisebene können Logs die Prompt-Vorlage, die Benutzerabfrage, den Modellnamen, die Antwort-Metadaten, die Retrieval-Abfrage, ausgewählte Dokumente, Tool-Aufrufe, Richtlinienentscheidungen, Fehlermeldungen und Feedback erfassen. In einem Unternehmensumfeld benötigen diese Datensätze eine eigene Governance. Prompts und Antworten können proprietäre Daten, regulierte Informationen oder internen Geschäftskontext enthalten, weshalb Aufbewahrung, Schwärzung und rollenbasierter Zugriff Teil des Designs sein sollten.

Ein nützlicher Log-Eintrag liefert dem Team genügend Details für Untersuchungen, ohne dass Observability zu einer weiteren Quelle für unverwaltete sensible Daten wird. Für einige Workflows kann dies bedeuten, dass standardmäßig Metadaten gespeichert werden und während genehmigter Untersuchungen nur begrenzter Zugriff auf den vollständigen Inhalt von Prompts und Antworten gewährt wird.

Metriken

Im Laufe der Zeit zeigen Metriken, ob das System stabil bleibt. Latenz, Durchsatz, Fehlerrate, Anfragevolumen, Token-Nutzung und Kosten pro Anfrage erfassen die operative Seite. Groundedness, Antwortrelevanz, Kontextrelevanz, sachliche Richtigkeit, Verweigerungsrate, Toxizität, Vollständigkeit und Konsistenz erfassen eher die Seite der KI-Qualität.

In ML-Workflows helfen Data Drift, Prediction Drift und Concept Drift den Teams zu verstehen, ob das Modell noch unter vertrauten Bedingungen arbeitet. Der Population Stability Index (PSI), Feature-Attribution und SHAP-Werte können diese Analyse unterstützen, wenn ein Modell von strukturierten Features und bekannten Ergebnissen abhängt. Im Bereich der Generative AI — wo sprachbasierte Outputs eher im logischen Gesamtkontext als gegen ein einzelnes Label evaluiert werden — müssen Evaluierungsmetriken flexibel bewerten, wie präzise eine Antwort die abgerufenen Informationen nutzt oder ob sie eine vordefinierte, aufgabenspezifische Rubrik erfüllt.

Traces

Innerhalb einer einzelnen Anfrage folgt ein Trace dem System von einem Schritt zum nächsten. Bei einem einfachen Chatbot kann das den Prompt, den Modellaufruf und die Antwort umfassen. In einer RAG-Anwendung kann der Trace die ursprüngliche Frage, die Retrieval-Abfrage, gerankte Chunks, die Prompt-Zusammensetzung, den Inferenzaufruf, die Evaluierungsergebnisse und die finale Antwort umfassen. Innerhalb eines Agentic Workflows können Spans die Planung, die Tool-Auswahl, die Tool-Antworten, Wiederholungsversuche und Zwischenergebnisse abdecken.

Der Wert des Traces liegt darin, dass er die Reihenfolge beibehält. Wenn eine Antwort die falsche Richtlinie zitiert, kann das Team sehen, ob das falsche Dokument abgerufen wurde, ob das richtige Dokument abgerufen, aber ignoriert wurde, oder ob das Modell trotz des richtigen Kontexts nicht unterstützten Text generiert hat. Wenn ein Agent 45 Sekunden benötigt, um eine einfache Frage zu beantworten, kann der Trace zeigen, ob die Zeit für die Modellinferenz, ein langsames Tool, wiederholtes Retrieval oder eine Schleife im Plan des Agenten aufgewendet wurde.

Sehen Sie sich an, wie Anahita Tafvizi, Chief Data & Analytics Officer bei Snowflake, die Architektur hinter vertrauenswürdiger GenAI erläutert:

Da KI-Systeme strukturierte Daten, unstrukturierte Dokumente, Embeddings und Laufzeitkontext kombinieren, kann Drift an verschiedenen Stellen auftreten.

• Data Drift: Eingabedaten ändern sich im Laufe der Zeit. Ein Klassifikator für den Kundensupport, der mit den Tickets des letzten Jahres trainiert wurde, wird möglicherweise mit neuen Produktkategorien, neuer Terminologie oder neuen Eskalationsmustern konfrontiert.
• Concept Drift: Die Beziehung zwischen Eingaben und Ergebnissen ändert sich. Ein Betrugsmodell lernt vielleicht aus einem bestimmten Missbrauchsmuster und wird dann mit einer neuen Taktik konfrontiert, die alte Korrelationen weniger zuverlässig macht.
• Prediction Drift: Ausgabeverteilungen ändern sich. Zum Beispiel stuft ein Modell, das früher 10 % der Fälle als hohes Risiko einstufte, nun 35 % so ein, obwohl das Unternehmen eine solche Verschiebung nicht erwartet hat.
• Embedding Drift: Vektordarstellungen ändern sich, wenn sich Daten, Modelle oder Embedding-Strategien ändern. In einem RAG-System kann sich dies darauf auswirken, welche Dokumente abgerufen werden und wie ähnlich zwei Inhalte dem System erscheinen.
• Data Quality Drift: Fehlende Werte, verzögerte Aktualisierungen, Schemaänderungen und doppelte Datensätze wirken sich auf die vom System verwendeten Daten aus, selbst wenn sich das Modell selbst nicht geändert hat.
• Fairness- und Bias-Drift: Das Modellverhalten kann sich über Nutzergruppen, Regionen, Produktlinien oder Sprachmuster hinweg unterschiedlich verändern. Observability hilft Teams zu erkennen, ob Qualität, Verweigerungsverhalten oder Fehlerraten ungleichmäßig verteilt sind.

LLM-Observability fokussiert sich auf das Verhalten von Systemen, die Large Language Models nutzen, einschließlich Chatbots, Dokumentenassistenten, Zusammenfassungs-Workflows, Coding-Assistenten, Text-to-SQL-Schnittstellen und RAG-Anwendungen. In solchen komplexen Systemen hängt die Gesamtqualität von weitaus mehr Faktoren ab als nur von der reinen Model Response. Teams müssen wissen, ob die Anwendung den richtigen Kontext abgerufen, den richtigen Prompt zusammengestellt, die richtigen Kontrollen befolgt und eine Antwort generiert hat, die nützlich, fundiert und regelkonform war.

Tracing der RAG-Pipeline

In einer RAG-Pipeline wird die Antwort geformt, bevor das Modell eine Response generiert. So kann bereits die Suchanfrage (Query) unpräzise sein, der Retrieval Layer irrelevante Dokumente liefern oder der Prompt zwar die korrekte Datenbasis enthalten, jedoch die explizite Anweisung zur Quellenangabe auslassen. Das Modell generiert möglicherweise eine Antwort, die plausibel klingt, aber nicht durch den abgerufenen Kontext gestützt wird.

Ein automatisierter Groundedness Score hilft dabei, solche Fehler im Output direkt zu kennzeichnen, aber der Trace zeigt, wo er in das System gelangt ist. Durch die Erfassung von Abfrage, abgerufenen Dokumenten, gerankten Chunks, Prompt-Zusammenstellung, Modellantwort und Evaluierungsergebnis können Teams erkennen, ob das Problem beim Retrieval, bei der Kontextauswahl, beim Prompt-Design oder beim Modellverhalten begann.

Monitoring von Prompts, Antworten, Kosten und Latenz

Das Tracing von Prompts und Antworten bietet Entwickler:innen eine Möglichkeit, den Anfragepfad zu überprüfen. Spans können Retrieval, Modellaufrufe, Tool-Aufrufe und andere Operationen innerhalb eines einzigen Traces erfassen, sodass Teams jeden Schritt untersuchen können, ohne den Workflow aus separaten Protokollen rekonstruieren zu müssen.

Das Monitoring der Token-Nutzung hilft Teams, Kosten und Performance zu verstehen, insbesondere wenn eine Anwendung lange Prompts sendet, zu viel Kontext abruft oder wiederholte Tool-Aufrufe durchläuft. Latenzmetriken zeigen, ob langsame Antworten vom Retrieval, von der Inferenz, von der Orchestrierung oder von einem externen Dienst stammen. Zusammen helfen diese Signale den Teams, die Anwendung zu optimieren, ohne Qualität, Geschwindigkeit und Kosten als separate Probleme zu behandeln.

Erfassung von Agenten-Schritten und Tool-Aufrufen

Observability für Agentic AI fügt eine weitere Ebene hinzu, da Agenten nicht einfach nur einen Prompt beantworten. Ein Agent kann eine ganze Reihe von Aktionen ausführen: ein Such-Tool aufrufen, eine strukturierte Tabelle abfragen, ein Dokument öffnen, Ergebnisse zusammenfassen und entscheiden, ob eine Folgefrage gestellt werden soll.

Observability muss diese Sequenz erfassen, damit Teams sehen können, ob der Agent die richtigen Tools ausgewählt, auf die richtigen Daten zugegriffen und am richtigen Punkt angehalten hat. Ohne diese schrittweise Aufzeichnung kann die endgültige Antwort eines Agenten akzeptabel aussehen, selbst wenn der dahinter liegende Workflow ineffizient, nicht unterstützt oder außerhalb der vorgesehenen Richtliniengrenzen lag.

GenAI-Telemetrie standardisieren

OpenTelemetry wird zu einem wichtigen Standardisierungspunkt für die Observability von LLMs und Agentic AI. Die semantischen Konventionen für generative KI definieren, wie GenAI-Operationen aufgezeichnet werden können, einschließlich Modellaufrufe, Token-Anzahlen und – wenn Unternehmen zustimmen – Prompt-Inhalte, Vervollständigungen, Tool-Aufrufe und Tool-Ergebnisse.

Da KI-Anwendungen oft mehrere Frameworks, Modelle und Infrastrukturschichten umfassen, ist ein gemeinsames Telemetriemodell unerlässlich, um das Verhalten systemübergreifend zu vergleichen, Instrumentierungsmuster wiederzuverwenden und einen fragmentierten Observability-Stack zu vermeiden.

Vor der Instrumentierung einer KI-Anwendung sollten Teams exakt definieren, welche Nachweise das System in der Production erbringen können muss. Zum Beispiel muss ein Kundensupport-Assistent möglicherweise nachweisen, dass seine Antwort aus aktuellen Richtlinieninhalten stammt, während ein Finanzassistent möglicherweise zeigen muss, welche Tabellen, Metrikdefinitionen und Berichtszeiträume eine Abweichungserklärung geprägt haben.

Die Anforderungen des Workflows bestimmen, was erfasst werden soll. In Workflows mit geringerem Risiko können schlankes Feedback, stichprobenartige Traces und grundlegende Qualitätsprüfungen ausreichen. In regulierten oder geschäftskritischen Workflows benötigt die Anwendung wahrscheinlich tiefergehendes Tracing, strengere Evaluierungs-Datasets, zugriffskontrollierte Datensätze und klare Freigabekriterien, bevor eine Änderung an Prompt, Modell oder Retrieval die Produktion erreicht.

Instrumentieren Sie den Ausführungspfad mit Telemetrie

Die Instrumentierung erfasst die Logs, Metriken und Traces, die das System beobachtbar machen. Für KI-Systeme bedeutet das, den Anwendungspfad rund um das Modell zu instrumentieren: Prompts, Retrieval, Tool-Aufrufe, Modellantworten, Evaluierungsergebnisse, Latenz, Token-Nutzung und Nutzerfeedback.

Bei einer RAG-Anwendung umfasst dies den User-Prompt, die Retrieval-Abfrage, den abgerufenen Kontext, die Prompt-Erstellung, die Modellantwort, Evaluierungsergebnisse, Latenz und Kosten. Bei einem Agenten gehören dazu auch Planung, Tool-Aufrufe, Zwischenergebnisse, Wiederholungsversuche und Abbruchbedingungen.

Etablieren Sie Baselines und Alerts

Sobald Traces und Metriken fließen, bieten Baselines den Teams einen Normalbereich für Qualität und Performance, einschließlich Latenz, Kosten, Groundedness, Ablehnungsrate, Antwortrelevanz, Drift-Metriken und weiteren Signalen. Diese Baselines variieren je nach Workflow, daher sollte die Baseline eher die jeweilige Aufgabe als einen generischen Standard widerspiegeln.

Alerts sollten sich auf bedeutsame Änderungen konzentrieren und nicht auf jede Abweichung. Ein leichter Anstieg der Token-Nutzung nach dem Hinzufügen von umfangreicherem Kontext ist möglicherweise zu erwarten, während ein plötzlicher Abfall der Groundedness nach einer Prompt-Änderung eine Untersuchung erfordert.

Bauen Sie Feedbackschleifen auf

AI Observability sollte als Grundlage für Verbesserungen dienen. Evaluierungsergebnisse können als Richtschnur für Prompt-Änderungen, Retrieval-Anpassung, Modellauswahl, Guardrail-Anpassungen und die Behebung von Datenqualitätsproblemen dienen. Nutzerfeedback kann dabei helfen, Lücken in den Testdaten zu identifizieren. Trace-Analysen können zeigen, wo ein Agent Arbeitsschritte wiederholt, das falsche Tool wählt oder abgerufenen Kontext nicht nutzt.

Diese Schleife ist für generative KI besonders wichtig, da Qualität oft auf Vergleichen basiert. Teams müssen wissen, ob ein neuer Prompt, ein neues Modell, eine neue Embedding-Strategie oder eine neue Inferenzkonfiguration die Anwendung für die vorgesehene Aufgabe verbessert hat. Die AI Observability von Snowflake unterstützt den direkten Vergleich von Evaluierungen über LLMs, Prompts und Inferenzkonfigurationen hinweg, was Teams dabei hilft, die Antwortqualität zu beurteilen, bevor eine Konfiguration in die Produktion überführt wird.

Standardisieren Sie, wo immer möglich

Da sich KI-Anwendungen über verschiedene Teams hinweg ausbreiten, kann die Observability schnell fragmentieren. Ein Team protokolliert Prompts in einer Anwendungsdatenbank, ein anderes verfolgt die Kosten in einem Dashboard und wieder ein anderes speichert Evaluierungsergebnisse in Notebooks. Die Standardisierung von Telemetrie, Evaluierungs-Datasets, Metriken und Trace-Formaten hilft dem Unternehmen, Systeme zu vergleichen und Betriebsmuster wiederzuverwenden.

OpenTelemetry kann bei der Telemetrie-Schicht helfen, während geregelte Datenplattformen bei Evaluierungsdaten, Zugriffskontrollen, Monitoring-Datensätzen und der Trace-Speicherung unterstützen können. Das Ziel ist nicht, jede KI-Anwendung in dasselbe Design zu zwingen. Es geht vielmehr darum, sicherzustellen, dass jedes produktive KI-System genügend Nachweise hinterlässt, damit Teams es evaluieren und verbessern können.

Bei Enterprise-KI sollten die Daten, die zur Generierung einer Antwort verwendet werden, und die Nachweise, die zur Evaluierung dieser Antwort erforderlich sind, nah beieinander bleiben. Wenn Quelldaten, Prompts, Traces, Evaluierungen und Zugriffsrichtlinien in voneinander getrennten Systemen liegen, beginnt jede Untersuchung mit einer Rekonstruktion: Welche Version wurde ausgeführt, welcher Kontext wurde abgerufen, welche Richtlinie wurde angewendet und welche Konfiguration wurde geändert?

Innerhalb der Snowflake AI Data Cloud bietet Snowflake Cortex AI Teams Zugriff auf generative KI-Funktionen für geregelte Unternehmensdaten, während die AI Observability von Snowflake die systematische Evaluierung, den Vergleich und das Tracing für generative KI-Anwendungen und -Agenten unterstützt.

Da KI-Systeme immer tiefer in Geschäftsprozesse vordringen, wird das Vertrauen von der Fähigkeit des Unternehmens abhängen, den Pfad hinter jeder Ausgabe zu überprüfen. Ein Trace, ein Evaluierungsergebnis, ein abgerufenes Dokument und eine Modellkonfiguration sind keine nachträglichen technischen Details. Sie sind die Aufzeichnungen, die es Teams ermöglichen, KI-Systeme zu verbessern, ohne die Kontrolle über die Daten, Richtlinien und Workflows zu verlieren, auf die sich diese Systeme stützen.