KI-Observability: Warum nur Logs zu schreiben ein teures Blindflug-Risiko ist

KI-Systeme sind keine klassischen Webdienste – und doch behandeln viele Entwickler ihre API-Aufrufe wie gewohnt. Eine einfache Funktion, die ein Sprachmodell nutzt, endet oft in einer Kostenfalle: 8.000 versteckte Reasoning-Tokens für eine 40-Token-Antwort kosten plötzlich vierstellige Beträge pro Monat. Doch die meisten Teams erkennen das Problem erst, wenn die Rechnung kommt. Der Grund? Sie beobachten nur die Antwort des Modells – nicht jedoch, was wirklich passiert ist.

Die vier kritischen Observability-Signale

Jedes KI-System lässt sich entlang von vier Schlüsseldimensionen überwachen. Die meisten Teams erfassen jedoch nur ein oder zwei davon – und fliegen damit blind in Bezug auf die anderen Achsen:

• Logs – Standardmäßig werden Anfragen, Antworten, Fehler und Latenz protokolliert. Doch das reicht nicht aus, um den tatsächlichen Zustand eines KI-Workflows zu verstehen.

• Prompts – Sämtliche Eingaben und Ausgaben müssen im Originaltext gespeichert werden, inklusive System-Prompts, Tool-Definitionen und Gesprächsverlauf. Ohne diese Daten wird die Fehlersuche zur Ratespielerei.

• Tool-Aufrufe – Welche Tools wurde vom Modell ausgewählt? Mit welchen Parametern? In welcher Reihenfolge? Werden Retries durchgeführt? Diese Informationen sind entscheidend, um Fehler wie falsche Flugbuchungen zu analysieren.

• Kosten – Input-Tokens, Output-Tokens, Caching-Tokens, Reasoning-Tokens sowie der Preis pro Million Tokens pro Modell. Diese Daten müssen pro Nutzer, Feature und Anfrage nachvollziehbar sein. Fehlt diese Transparenz, endet es im Slack-Kanal der Finanzabteilung.

Verliert man eines dieser Signale, arbeitet man im Blindflug. Ohne Kosten-Tracking erwischt man die Rechnung zu spät. Ohne Prompt-Protokollierung bleibt die Ursache eines fehlerhaften Verhaltens unklar. Und ohne Logs hat man nicht einmal mitbekommen, dass ein Problem überhaupt aufgetreten ist.

Warum ein „200 OK“ eine Täuschung ist

Die meisten Teams reduzieren ihre Observability auf HTTP-Statuscodes wie „200 OK“. Doch dieser Code sagt nichts über den Erfolg eines KI-Anrufs aus. Entscheidend ist der finish_reason:

• stop – Das Modell hat die Antwort abgeschlossen.
• length – Die Antwort wurde aufgrund einer Token-Limitierung abgebrochen.
• content_filter – Die Antwort wurde von Sicherheitsfiltern blockiert.
• tool_calls – Das Modell fordert weitere Aktionen und die Konversation ist noch nicht beendet.

Ein 200 OK bedeutet also keineswegs, dass das Modell die Frage korrekt beantwortet hat. Selbst ein HTTP-Statuscode verschleiert potenzielle Probleme. Besonders bei Streaming-Antworten wird dies deutlich: Ein Stream kann mit einem 200 OK beginnen, nach einigen Token jedoch abbrechen. Der Erfolg eines Anrufs lässt sich erst nach Abschluss des Streams bewerten.

Ein weiterer kritischer Faktor ist die Zeit bis zum ersten Token (Time-to-first-token). Sie korreliert stärker mit der Nutzererfahrung als die Gesamtlatenz. Ein Modell, das nach 600 Millisekunden den ersten Token liefert – auch wenn die vollständige Antwort erst nach acht Sekunden eintrifft – fühlt sich für den Nutzer schneller an als eines, das nach vier Sekunden noch gar keine Antwort zeigt. Für die Nutzerwahrnehmung ist dieser Wert entscheidend, für die Abrechnung hingegen die Gesamtlaufzeit.

Prompts speichern – aber sensibel

Ein klassischer Fehler im Observability-Ansatz ist das Speichern von Prompt-Längen statt der tatsächlichen Texte. Doch genau diese Informationen sind unverzichtbar, wenn ein Fehler auftritt:

• Ein Nutzer beschwert sich über eine falsche Antwort des Assistenten.
• Die Logs zeigen nur eine Länge von 4.720 Zeichen – nicht den Inhalt.
• Die Ursache? Ein veralteter Speicherauszug eines anderen Nutzers hat sich in den System-Prompt eingeschlichen.

Ohne den originalen Prompt-Text bleibt die Fehlersuche reine Spekulation. Die Lösung: Speichern Sie den vollständigen Payload. Die Kosten für Speicherplatz sind gering im Vergleich zum Zeitaufwand für die Fehleranalyse. Allerdings gibt es zwei wichtige Einschränkungen:

1. PII muss vor dem Verlassen des Netzwerks bereinigt werden. Prompts enthalten oft unstrukturierte Nutzerdaten wie Namen, E-Mails, Adressen oder Kreditkartennummern. Werden diese an externe Observability-Tools übermittelt, entsteht ein Datenschutzrisiko – insbesondere im Hinblick auf GDPR. Der OpenTelemetry GenAI-Arbeitskreis hat hierfür Lösungen entwickelt: Ein PII-Redaktionsprozessor kann sensible Token vor dem Versand an den Collector entfernen. Tools wie Datadogs LLM Observability bieten standardmäßig Scans für E-Mails und IP-Adressen an.

2. System-Prompts müssen versioniert werden. Jede Änderung am System-Prompt ist eine Programmänderung. Behandeln Sie sie wie ein git-versioniertes Artefakt: Weisen Sie jeder Version eine eindeutige Kennung zu und speichern Sie diese in jeder Anfrage. So können Sie bei A/B-Tests oder Fehlern gezielt nachvollziehen, welche Prompt-Version zu welchem Verhalten geführt hat.

Ein typischer Prompt-Eintrag in der Observability-Pipeline sollte folgende Felder enthalten:

{
  "prompt_id": "req_12345",
  "version": "v2.1.0",
  "system_prompt": "Du bist ein hilfreicher Assistent...",
  "messages": [
    {"role": "user", "content": "Wie buche ich einen Flug nach Berlin?"},
    {"role": "assistant", "content": "Hier sind die Optionen..."}
  ],
  "tools": ["flight_search", "price_comparison"]
}

Tool-Aufrufe und Kosten: Die unsichtbaren Treiber

Tool-Aufrufe sind oft der Grund für unerwartetes Verhalten. Ein Agent, der stundenlang versucht, den falschen Flug zu buchen, liefert keine Fehlermeldung im klassischen Sinne – sondern führt einfach immer wieder denselben falschen Aufruf aus. Um solche Fehler zu erkennen, müssen Sie protokollieren:

• Welches Tool wurde ausgewählt?
• Welche Parameter wurden übergeben?
• In welcher Reihenfolge erfolgten die Aufrufe?
• Wurde ein Tool-Retry durchgeführt?
• Welche Antwort wurde vom Tool zurückgegeben?

Fehlt diese Transparenz, bleibt der Fehler unsichtbar – bis die Nutzerbeschwerden eintreffen.

Ebenso kritisch ist die Kostenverfolgung. Sprachmodelle berechnen nicht nur Input- und Output-Tokens, sondern auch Reasoning-Tokens und Caching-Tokens. Ein einziger Anruf kann schnell mehrere tausend Token verbrauchen, selbst wenn die sichtbare Antwort kurz ist. Ohne detaillierte Token- und Kostenprotokollierung pro Nutzer und Feature wird aus einem kleinen Experiment ein teures Produktionsproblem.

Die gute Nachricht: Seit 2026 gibt es einen Standard für die Erfassung aller vier Observability-Signale. Die schlechte Nachricht: Die meisten Teams bauen ihre eigenen Lösungen und erfassen dabei nur die Hälfte der notwendigen Daten.

Der Weg zu einer wirklich beobachtbaren KI-Infrastruktur beginnt mit der Erkenntnis, dass Sprachmodelle keine klassischen Webdienste sind. Sie erfordern eine erweiterte Observability, die über Logging hinausgeht. Wer diese vier Signale konsequent erfasst, vermeidet nicht nur teure Überraschungen – sondern schafft auch die Grundlage für zuverlässige, skalierbare und nutzerfreundliche KI-Anwendungen.

Die Zukunft der KI-Entwicklung wird nicht nur durch leistungsfähigere Modelle bestimmt, sondern auch durch die Fähigkeit, ihre komplexen Abläufe transparent und steuerbar zu machen. Wer heute in Observability investiert, spart morgen Zeit, Geld und Nerven.