KI-Agenten in Produktion: Warum Observability wichtiger wird als das Modell

Produktive KI-Agenten benötigen Tracing, Evaluation und kontrollierte Tool Calls. Architektur, Metriken, Sicherheit und Codebeispiele für den Betrieb.

9. November 2026

Ein gutes Modell allein macht noch keinen zuverlässigen Agenten.
Traces erklären Abläufe; fachliche Evaluation prüft den Erfolg.
Wichtige KPIs sind Erfolgsrate, Tool-Fehler, P95-Latenz und Kosten pro erledigter Aufgabe.
Observability erfordert Datenschutz und ersetzt keine Autorisierung.
Produktive Agenten brauchen Freigaben, Regressionstests und Rückfallpfade.

Ein leistungsfähiges Modell ist noch kein zuverlässiger Agent

Ein KI-Agent beantwortet eine Testfrage überzeugend. Wenig später trifft derselbe Workflow in einem Unternehmen auf eine instabile API, veraltete Stammdaten oder fehlende Berechtigungen. Die Ausgabe klingt weiterhin plausibel, obwohl die Aufgabe fachlich nicht abgeschlossen wurde. Das Modell muss dabei nicht die Fehlerursache sein – häufig liegt sie im Zusammenspiel der Systeme.

Für den produktiven Einsatz reicht es deshalb nicht, die Qualität einer einzelnen Modellantwort zu messen. Teams müssen verfolgen, welche Daten der Agent verwendet, welche Tools er aufruft, was in den Zielsystemen passiert und ob das Ergebnis korrekt ist. Genau dort setzt Observability an.

Traces verbinden die Schritte einer Ausführung. Metriken zeigen Muster über viele Vorgänge. Logs halten relevante technische Ereignisse fest. Hinzu kommen fachliche Evaluation, Versionierung und die Prüfung tatsächlich abgeschlossener Aufgaben. Observability macht Fehler untersuchbar; verhindern müssen sie technische und organisatorische Kontrollen.

Warum das Thema 2026 an Bedeutung gewinnt

Google hat im November 2026 die allgemeine Verfügbarkeit von Observability-Funktionen für BigQuery Data Agents angekündigt. Diese umfassen unter anderem Ausführungstraces, Informationen zu Latenz, Nutzung und Kosten. Damit rückt neben der Entwicklung von Agenten auch deren Verhalten im realen Betrieb stärker in den Mittelpunkt.

Eine Tracing-Funktion allein ist keine Garantie für sichere oder fachlich richtige Ergebnisse. Ein erfolgreiches HTTP-Response kann eine falsche Antwort enthalten; ein vollständig dokumentierter Ablauf kann trotzdem eine unzulässige Aktion auslösen. Unternehmen brauchen neben Telemetrie klare Tool-Grenzen, Evaluation und Verantwortlichkeiten.

Praxisbeispiel: Ein Agent für technische Service-Tickets

Ein Maschinenbauer möchte Service-Tickets effizienter bearbeiten. Der Agent liest die Fehlerbeschreibung, ruft Produkt- und Vertragsinformationen aus dem ERP ab, durchsucht technische Dokumentation und erstellt einen Vorschlag für das Serviceteam. Bei Unsicherheit eskaliert er an eine verantwortliche Person. Kundenkommunikation und Änderungen in operativen Systemen unterliegen gesonderten Freigaben.

Im Pilot funktioniert der Workflow. In Produktion fehlt bei einem Ticket die Seriennummer; bei einem zweiten liefert die Suche eine veraltete Anleitung; bei einem dritten schlägt ein Tool-Aufruf mit Timeout fehl. Das Sprachmodell kann dennoch eine sauber formulierte Empfehlung erzeugen.

Um diese Fehler zu verstehen, muss das Team sehen, welche Dokumentversion verwendet wurde, wann die API reagierte, welcher Tool Call fehlschlug, ob ein Retry stattfand und welche Freigabe vorlag. Das ist ein illustratives Architekturbeispiel und kein behauptetes Valanor-Kundenprojekt.

Wie eine kontrollierte Agentenarchitektur aussieht

Eine Workflow-API nimmt den Auftrag entgegen und vergibt eine Request-ID. Die Orchestrierung steuert Modellaufrufe, Retrieval und Tools. Ein serverseitiger Policy-Layer prüft Identität, Mandant, Berechtigungen und erlaubte Zielressourcen. Kritische Aktionen werden freigegeben, bevor sie ausgeführt werden, und mit einem Idempotenzschlüssel gegen unbeabsichtigte Wiederholungen geschützt.

Jeder wesentliche Schritt erzeugt einen Span: Workflow, Dokumentensuche, Modellaufruf und Tool-Ausführung. Eine gemeinsame Trace-ID verbindet diese Daten. Das Audit-Log dokumentiert zusätzlich, welche Änderung ein Zielsystem tatsächlich bestätigt hat. Ein Trace zeigt den technischen Weg; die fachliche Evaluation bewertet das Resultat.

Nicht jeder Agent benötigt dafür mehrere Microservices. Eine sauber instrumentierte Anwendung mit nachvollziehbaren Tool-Verträgen kann ausreichen. Wichtig ist die Trennung zwischen einem Vorschlag des Modells und einer technisch autorisierten Aktion.

Welche Signale produktive KI-Agenten liefern sollten

Ebene	Metrik oder Signal	Was sich damit klären lässt
Workflow	Erfolgreich abgeschlossene Aufgaben und Eskalationen	Hat der Agent die fachliche Aufgabe tatsächlich gelöst?
Modell	Modellversion, Tokenverbrauch, Inferenzlatenz	Wie beeinflussen Modell und Prompt Qualität, Laufzeit und Kosten?
Retrieval und Daten	Quellenversion, Trefferqualität, leere Ergebnisse	Lag ein Fehler an veralteten oder fehlenden Daten?
Tool Calls	Toolname, Status, Timeout, Retry, Berechtigungsentscheidung	Ist eine Schnittstelle gescheitert oder wurde ein unzulässiger Aufruf blockiert?
Aktionen	Freigabestatus, Idempotenzschlüssel, Ergebnis	Wurde eine schreibende Aktion zulässig und genau einmal ausgeführt?
Qualität	Groundedness, Ergebnisprüfung, Korrekturen durch Menschen	War das Resultat fachlich korrekt und nachvollziehbar?
Betrieb	P95-Latenz, Fehlerrate, verfügbare Kapazität	Wo entstehen Engpässe und wann muss ein Team reagieren?
Kosten	Kosten je erfolgreich erledigter Aufgabe	Was kostet der nutzbare Output einschließlich Wiederholungen?

Tracing zeigt Abläufe, Evaluation beurteilt Ergebnisse

Ein Trace kann erklären, warum ein Workflow langsam wurde: Eine Suchanfrage lieferte keine Treffer, ein Tool-Aufruf brauchte länger als erwartet und das Modell führte daraufhin einen weiteren Schritt aus. Daraus folgt aber nicht, dass das fachliche Ergebnis richtig war.

Evaluation benötigt repräsentative Prüffälle. Im Servicebeispiel sind das korrekte Produktzuordnung, passende Dokumentation, zulässige Tool-Aktionen, angemessene Eskalationen und die Qualität der Handlungsempfehlung. Automatische Bewertungen können helfen, müssen jedoch bei risikoreichen Vorgängen durch deterministische Regeln und menschliche Reviews ergänzt werden.

Bei manchen Geschäftsprozessen liegt die Ground Truth erst später vor, etwa nachdem ein Techniker eine Diagnose bestätigt hat. Deshalb müssen Teams kurzfristige Proxy-Metriken und später verifizierte Fachresultate getrennt betrachten.

Tool-Aufrufe mit OpenTelemetry nachvollziehbar machen

Das TypeScript-Beispiel demonstriert die Instrumentierung eines bereits autorisierten Tool-Aufrufs. Es implementiert bewusst keine Authentifizierung oder Freigabe. Die Autorisierung muss außerhalb der Modellentscheidung serverseitig erfolgen. Produktiv benötigen Teams außerdem Kontextpropagation, Sampling, einen konfigurierten Exporter, Idempotenz und sichere Fehlerbehandlung. Nutzdaten und Zugangsdaten bleiben aus dem Trace.

TypeScript

import {trace, SpanStatusCode} from '@opentelemetry/api'

const tracer = trace.getTracer('service-agent')

export async function callTool<T>(
  name: string,
  requestId: string,
  executeAuthorizedAction: () => Promise<T>
): Promise<T> {
  return tracer.startActiveSpan('agent.tool', async (span) => {
    span.setAttribute('agent.tool.name', name)
    span.setAttribute('agent.request_id', requestId)

    try {
      // Authorization, scopes and approvals must be enforced
      // server-side before this callback executes.
      const result = await executeAuthorizedAction()
      span.setAttribute('agent.tool.status', 'success')
      return result
    } catch (error) {
      span.setStatus({code: SpanStatusCode.ERROR})
      span.setAttribute('agent.tool.status', 'error')
      throw error
    } finally {
      // Never record raw prompts, credentials or customer data.
      span.end()
    }
  })
}

Fünf Metriken für den Einstieg

Task Completion Rate: Messen Sie fachlich überprüfte, abgeschlossene Aufgaben statt erzeugter Antworten. Trennen Sie autonome Erledigung, Eskalation und nachträgliche Korrektur. Ein Agent mit vielen Antworten und ebenso viel Nacharbeit ist nicht zwangsläufig produktiver.

Tool Failure Rate: Unterscheiden Sie API-Timeouts, fehlende Berechtigungen, Validierungsfehler und leere Retrieval-Ergebnisse. So wird erkennbar, ob die Fehlerursache im Modell, in der Datenqualität oder in einer externen Abhängigkeit liegt.

P95 Workflow Latency: Entscheidend ist die Dauer bis zum verwertbaren Ergebnis. Retrieval, Inference, externe APIs, Retries und Freigaben gehören in die Analyse. Eine schnelle Modellantwort kann Teil eines insgesamt langsamen Workflows sein.

Cost per Successful Task: Tokenkosten allein sind irreführend. Berücksichtigen Sie externe Dienste, Infrastruktur, wiederholte Ausführungen und menschliche Nacharbeit. Die wirtschaftlich relevante Einheit ist die erfolgreich erledigte Aufgabe.

Escalation und Correction Rate: Wie oft übergibt der Agent korrekt an Menschen, und wie häufig müssen Fachpersonen seine Vorschläge korrigieren? Beide Werte helfen, die Grenzen sinnvoller Automatisierung zu erkennen.

Evaluation ist eine Aufgabe vor und nach dem Deployment

Offline-Tests sollten Standardfälle, fehlende Eingaben, widersprüchliche Quellen, veraltete Dokumente, Tool-Ausfälle, doppelte Requests und manipulative Instruktionen umfassen. Ergebnisse gehören zu einer konkreten Version von Modell, Prompt, Tool und Datenbasis. Ein Durchschnittsscore darf kritische Einzelrisiken nicht verdecken.

Nach dem Deployment ändern sich Datenquellen, Dokumentation und Nutzerverhalten. Repräsentative, datenschutzkonform aufbereitete Produktionsfälle liefern wertvolle neue Regressionstests. Ein Freigabeprozess muss Verschlechterungen erkennen und bei Bedarf auf eine vorherige Version oder manuelle Bearbeitung zurückschalten.

Beispiel für testbare Release-Gates

Die YAML-Struktur ist ein bewusst vereinfachtes Architekturbeispiel und keine lauffertige CI-Konfiguration. Schwellenwerte sind illustrativ; die realen Grenzen müssen aus Geschäftsprozess, Baseline und Risiko abgeleitet werden. Für kritische Aktionen bleiben technische Kontrollen und Freigaben erforderlich.

YAML

# Illustrative release gates; adapt thresholds to real risk
workflow: service-ticket-agent
dataset: service-tickets-v3
checks:
  - metric: required_field_accuracy
    minimum: 0.98
  - metric: unauthorized_write_actions
    maximum: 0
  - metric: p95_workflow_latency_ms
    maximum: 10000
  - metric: escalation_on_uncertainty
    required: true
release:
  human_approval: true
  rollback_enabled: true

Datenschutz: Telemetrie ist keine Ablage für Kundendaten

KI-Agenten verarbeiten häufig E-Mails, CRM-Einträge, Dokumente oder personenbezogene Daten. Wer vollständige Prompts und Tool-Rückgaben ungefiltert an eine Observability-Plattform sendet, schafft zusätzliche Datenflüsse und Zugriffsrisiken.

Erfassen Sie standardmäßig technische Metadaten wie Trace-ID, Toolname, Status, Dauer, Komponenten-Version und aggregierte Nutzung. Inhaltsdaten sollten nur bei dokumentierter Notwendigkeit und mit geeigneter Grundlage, Zugriffskontrollen und Löschregeln erfasst werden. Pseudonymisierte Daten können weiterhin personenbezogen sein.

Redaction vor dem Export, rollenbasierte Rechte, Verschlüsselung, begrenzte Retention und kontrollierte Debug-Sessions gehören zur Architektur. Prüfen Sie die tatsächliche Konfiguration des SDK: Auch Fehlertexte, Attribute oder Tool-Parameter können sensible Inhalte preisgeben.

Security: Ein beobachteter Angriff ist noch kein verhinderter Angriff

Prompt Injection kann über Dokumente, Webseiten oder Tool-Antworten zum Agenten gelangen. Ein manipulierter Text könnte beispielsweise einen Export von Kundendaten verlangen. Ein Trace kann nachträglich Hinweise auf die Ursache liefern, schützt die Daten aber nicht selbst.

Externe Inhalte dürfen keine vertrauenswürdigen Instruktionen werden. Least Privilege, serverseitige Autorisierung, Tool-Allowlists, Ressourcenprüfungen und Freigaben für riskante Aktionen begrenzen die möglichen Auswirkungen. Das Modell darf nicht allein entscheiden, ob es eine schreibende Aktion ausführen darf.

Auch Retries sind relevant. Nach einem Timeout ist nicht immer klar, ob das Zielsystem eine Änderung ausgeführt hat. Ohne Idempotenz entstehen doppelte Tickets, Bestellungen oder andere Folgeaktionen. Dieses Risiko lässt sich nicht durch einen besseren Prompt beseitigen.

OpenTelemetry, Langfuse oder Herstellerfunktionen?

OpenTelemetry bietet eine herstellerübergreifende Grundlage für Traces und Metriken. Es ist besonders sinnvoll, wenn bereits ein Observability-Stack für Backend-Anwendungen existiert. GenAI Semantic Conventions helfen dabei, Modell- und Tool-Aufrufe einheitlich zu benennen; die konkrete Unterstützung hängt von Version und Instrumentierung ab.

Langfuse ergänzt diese Perspektive um LLM-nahe Traces, Evaluation und Prompt-Versionierung. Teams können einzelne Agentenläufe genauer untersuchen und fachlich bewerten. Hosting, Berechtigungen und Datentransfer müssen gesondert entschieden werden.

Auch das OpenAI Agents SDK und Google Cloud bieten eigene Tracing- und Observability-Funktionen. Sie vereinfachen bestimmte Integrationen, können jedoch an einen konkreten Stack binden. Die Auswahl sollte von den bestehenden Systemen, dem Betriebsmodell und der Datenhoheit abhängen, nicht allein von einer Feature-Liste.

Vom Pilot in den produktiven Prozess

Definieren Sie zuerst eine einzelne, klar abgegrenzte Aufgabe und ein überprüfbares Ergebnis. Danach folgen Datenquellen, Tool-Verträge, Berechtigungsgrenzen, Telemetrie und Fehlerklassen. Testen Sie leere Ergebnisse, Timeouts, doppelte Aufrufe, ungültige Daten und unzulässige Aktionen.

Beginnen Sie bei risikoreichen Prozessen mit lesenden Funktionen oder menschlich freigegebenen Schreibaktionen. Ein kontrollierter Rollout, Alarmierung, Regressionstests und ein Rückfallpfad halten den Prozess auch bei Problemen handlungsfähig.

Valanor verbindet diese Aspekte im Data & AI Engineering: von Datenflüssen und Agentenarchitektur bis zur Integration in operative Anwendungen.

Ergänzend erläutert unser Fachbeitrag zu MLOps im produktiven Einsatz die Betriebsanforderungen von Machine-Learning-Modellen.

Fazit: Das Gesamtsystem entscheidet

Ein leistungsfähigeres Modell kann die Qualität einzelner Antworten verbessern. Es behebt aber keine instabile API, fehlende Berechtigung oder unklare fachliche Freigabe. Für Unternehmen zählt, ob ein Agent eine Aufgabe zuverlässig, kontrollierbar und wirtschaftlich erledigt.

Observability schafft die notwendige Sicht auf sein Verhalten. Zusammen mit Evaluation, Security und klarer Verantwortung wird aus einer überzeugenden Demo eine nutzbare Funktion. Nicht jeder Agent braucht eine große Monitoring-Plattform; jeder produktive Agent benötigt aber nachvollziehbare Ausführung und einen definierten Umgang mit Fehlern.

Häufige Fragen zu KI-Agenten in Produktion

Was ist der Unterschied zwischen Monitoring und Observability?

Monitoring erkennt definierte Abweichungen. Observability ermöglicht darüber hinaus, unbekannte Fehlerursachen mit Traces, Metriken und Ereignissen zu untersuchen. Bei Agenten müssen Modell-, Prompt-, Daten- und Tool-Versionen zugeordnet werden.

Welche Informationen gehören in einen Agent-Trace?

Technische Metadaten wie Toolname, Status, Laufzeit, Versionen und aggregierte Kosten. Personenbezogene Daten, Prompts und Tool-Antworten gehören nicht ungeprüft in die Telemetrie.

Reicht Langfuse für den produktiven Betrieb?

Langfuse unterstützt LLM-bezogene Traces und Evaluation. Zusätzlich können API- und Infrastrukturmonitoring, serverseitige Berechtigungen, Sicherheitskontrollen und fachliche Reviews erforderlich sein.

Wie lässt sich die Qualität eines Agenten messen?

Mit überprüfbaren fachlichen Ergebnissen, fehlerfreien Aktionen, Eskalationen, Korrekturraten, P95-Latenz und Kosten pro erfolgreich abgeschlossenem Vorgang. Automatische Scores allein reichen nicht.

Verhindert Observability Prompt Injection?

Nein. Sie hilft bei der Analyse. Wirksame technische Grenzen sind Least Privilege, serverseitige Autorisierung, Validierung und menschliche Freigaben für kritische Aktionen.

Wann ist ein umfangreicher Observability-Stack sinnvoll?

Wenn Agenten mehrere APIs nutzen, geschäftskritische Workflows steuern oder schreibende Aktionen auslösen, steigen die Anforderungen an Tracing, Auditierbarkeit und Evaluation. Kleine Piloten benötigen nicht automatisch eine große Plattform.

Technische Quellen und Dokumentation

OpenTelemetry: Semantic Conventions für generative KI

OpenAI Agents SDK: Tracing

Langfuse: Dokumentation zur Observability und Evaluation

OWASP: LLM Top 10

Google Cloud: Data Analytics Blog

KI-Agenten produktiv einsetzen

Vom Prototyp zum kontrollierten System

Wir entwickeln KI-Agenten mit nachvollziehbaren Datenflüssen, klaren Tool-Grenzen, Evaluation und Observability. Wir definieren Architektur, Freigaben und Betriebskriterien für die Integration in operative Anwendungen.

KI-Projekt besprechen

Aleksandar Basara

Managing Director

aleks@valanor.co

+49 (0) 711 16 44 6 83

Lindenspürstrasse 22, 70176 Stuttgart

Aleksandar Basara - Managing Director and CTO at VALANOR