KI-Observability und Agent-Tracing: Wie Unternehmen autonome Workflows auditierbar und compliant betreiben

17.09.2026

Autonome KI-Agenten und mehrstufige Modellketten transformieren Geschäftsprozesse in europäischen Unternehmen, bringen jedoch eine fundamentale Kontrolllücke mit sich: Stochastische Entscheidungen lassen sich mit herkömmlichen APM-Werkzeugen nicht rekonstruieren. Wer komplexe Agenten-Workflows produktiv einsetzt, benötigt lückenloses Tracing jeder Prompt-Generierung, jedes Tool-Aufrufs und aller externen Schnittstellen.

Warum klassisches Monitoring bei autonomen Agenten versagt

In der traditionellen Softwareentwicklung liefern Metriken wie HTTP-Statuscodes, Fehlerraten und Antwortzeiten ein klares Bild über den Zustand eines Dienstes. Bei autonomen Agenten, die auf grossen Sprachmodellen basieren, greift diese traditionelle Sichtweise zu kurz. Ein Aufruf an einen Agenten kann technisch mit dem Statuscode 200 erfolgreich beendet werden, inhaltlich jedoch eine gravierende Halluzination, eine Endlosschleife oder eine unautorisierte Parameterübergabe an ein Backendsystem enthalten.

Autonome Agenten zeichnen sich durch dynamische Ausführungspfade aus, bei denen das Modell selbstständig über den nächsten Schritt entscheidet. Eine einzige Benutzeranfrage kann Dutzende Zwischenschritte auslösen: von der Zerlegung des Ziels über Vektordatenbank-Abfragen bis hin zu wiederholten Tool-Aufrufen über Schnittstellen wie das Model Context Protocol. Schlägt ein Teilschritt fehl oder liefert unerwartete Daten, muss das Gesamtsystem den Fehler isolieren und korrigieren können. Ohne spezialisiertes Tracing bleibt der innere Zustand des Agenten eine undurchsichtige Blackbox.

KI-Observability erweitert das traditionelle Logging um semantische Ebenen. Es verknüpft die eingehenden Prompts, die Systeminstruktionen, die abgerufenen Kontextdokumente und die generierten Funktionsaufrufe zu einem zusammenhängenden Graphen. Entwickler und Betriebsverantwortliche sehen nicht nur, dass ein Fehler aufgetreten ist, sondern exakt, welche Zwischenüberlegung des Modells zu der Fehlentscheidung geführt hat.

Der OpenTelemetry-Standard für Generative KI

Um herstellerunabhängig zu bleiben und Vendor-Lock-in bei Observability-Plattformen zu vermeiden, setzt sich der offene Standard des Cloud Native Computing Foundation Projekts OpenTelemetry durch [1]. Die OpenTelemetry Semantic Conventions für Generative KI definieren ein einheitliches Namens- und Datenschema für Traces, Spans, Metriken und Ereignisse in Sprachmodell-Anwendungen [1].

Im Kern unterscheidet die Spezifikation drei hierarchische Ebenen. Der Trace bildet den gesamten Geschäftsprozess über Systemgrenzen hinweg ab.

Die Spans stehen für diskrete Arbeitsschritte wie eine Modellanfrage oder eine Vektorsuche. Die Events halten feingranulare Ereignisse fest, etwa Token-Streaming oder Zwischenevaluierungen. Zentrale Attribute wie gen_ai.system (beispielsweise vLLM, Ollama oder OpenAI), gen_ai.request.model und gen_ai.response.model sorgen für eine lückenlose Erfassung der eingesetzten Modellversionen [1].

Besonderes Augenmerk liegt auf der standardisierten Erfassung von Token-Metriken über gen_ai.usage.input_tokens und gen_ai.usage.output_tokens [1]. Diese Daten ermöglichen eine präzise Kostenallokation auf Mandanten-, Projekt- oder Abteilungsebene. Ergänzt wird dies durch Attribute für Hyperparameter wie temperature und top_p, wodurch sich Qualitätsunterschiede im Zeitverlauf exakt auf Konfigurationsänderungen zurückführen lassen.

Drei Ebenen, eine Spur: Trace, Span, Event.

Architekturvergleich: Self-Hosted versus Managed Cloud Observability

Für Unternehmen im DACH-Raum stellt sich bei der Einführung von KI-Observability primär die Frage nach dem Bereitstellungsmodell. Während US-amerikanische SaaS-Plattformen eine schnelle Inbetriebnahme versprechen, erfordert die Übermittlung vollständiger Prompts und Kundeninteraktionen an externe Cloud-Anbieter eine sorgfältige datenschutzrechtliche Prüfung. Open-Source-Plattformen wie Langfuse [4] oder Arize Phoenix ermöglichen dagegen einen vollständig autarken Betrieb im eigenen Rechenzentrum oder in einer Schweizer Private Cloud.

Die folgende Entscheidungsmatrix vergleicht die architektonischen und betrieblichen Eigenschaften beider Ansätze für den Enterprise-Einsatz:

Kriterium	Self-Hosted (Langfuse / Phoenix)	Managed Cloud (SaaS)
Datensouveränität	Vollständig im eigenen VPC, keine Datenübertragung an Dritte	Abhängig von Serverstandort und Auftragsverarbeitung
Latenzeinfluss	Minimal (unter 2 ms bei lokalem OTLP-Collector)	Netzwerklatenz zum Cloud-Endpoint (20 bis 80 ms)
TCO bei hohem Volumen	Fixe Infrastrukturkosten (PostgreSQL, ClickHouse), planbar	Variable Kosten pro Million Traces, oft Kostenfalle bei Skalierung
Wartungsaufwand	Eigenverantwortliche Updates, Backups und Skalierung	Zero-Ops, sofort einsatzbereit, automatische Upgrades

Insbesondere bei datenkritischen Anwendungen im Finanz-, Rechts- und Gesundheitssektor bietet die Self-Hosted-Variante entscheidende Vorteile. Daten verbleiben innerhalb der definierten Sicherheitszone, und hochvolumige Workflows erzeugen keine unvorhersehbaren API-Kosten auf Abrechnungsbasis.

Praktische Implementierung: Asynchrones Tracing mit OpenTelemetry

Die technische Integration von Tracing in bestehende Agenten-Workflows muss zwei Anforderungen erfüllen: Sie darf die Latenz der Benutzeranfrage nicht spürbar erhöhen und muss bei Netzwerkunterbrüchen robust reagieren. Dies gelingt durch den Einsatz eines asynchronen Batch-Processors, der Telemetriedaten sammelt und im Hintergrund über das OpenTelemetry-Protokoll (OTLP) versendet.

Das folgende Implementierungsbeispiel zeigt die saubere Instrumentierung eines Agenten-Schritts unter Verwendung von Umgebungsvariablen für Endpunkte und Zugangsdaten [1][4]:

import os
from opentelemetry import trace
from opentelemetry.sdk.trace import TracerProvider
from opentelemetry.sdk.trace.export import BatchSpanProcessor
from opentelemetry.exporter.otlp.proto.grpc.trace_exporter import OTLPSpanExporter
from opentelemetry.sdk.resources import Resource

resource = Resource.create({"service.name": "kunden-agent-service"})
provider = TracerProvider(resource=resource)

otlp_endpoint = os.getenv("OTEL_EXPORTER_OTLP_ENDPOINT", "https://otel-collector.internal:4317")
exporter = OTLPSpanExporter(endpoint=otlp_endpoint, insecure=True)
provider.add_span_processor(BatchSpanProcessor(exporter))
trace.set_tracer_provider(provider)
tracer = trace.get_tracer("agent.workflow.tracer")

def execute_agent_step(query: str, user_id: str):
    with tracer.start_as_current_span("agent.reasoning_step") as span:
        span.set_attribute("gen_ai.system", "vllm")
        span.set_attribute("gen_ai.request.model", "Qwen3.8-27B")
        span.set_attribute("enduser.id", user_id)
        
        result = {"status": "success", "tokens": 342}
        span.set_attribute("gen_ai.usage.output_tokens", result["tokens"])
        return result

Durch die Entkopplung von Aufruflogik und Telemetrietransport über BatchSpanProcessor bleibt der Anwendungsthread blockierungsfrei. Sollte der Observability-Collector temporär überlastet oder unerreichbar sein, verwirft der Puffer ältere Traces, ohne den eigentlichen Produktionsprozess zu stoppen.

Regulatorische Anforderungen im DACH-Raum: revDSG und EU KI-Verordnung

Für Unternehmen in der Schweiz und der Europäischen Union ist Tracing nicht nur eine technische Best Practice, sondern ein wesentliches Instrument zur Einhaltung gesetzlicher Vorschriften. Artikel 12 der europäischen KI-Verordnung (Verordnung EU 2024/1689) verpflichtet Betreiber von Hochrisiko-Systemen zur automatischen Aufzeichnung von Ereignissen («Logs») über die gesamte Lebensdauer des Systems [2]. Diese Protokolle müssen die Überwachung des Betriebs ermöglichen, Risiken erkennbar machen und wesentliche Veränderungen nachvollziehbar dokumentieren [2].

Auch das revidierte Schweizer Datenschutzgesetz (revDSG) stellt klare Anforderungen an Transparenz und Nachvollziehbarkeit [3]. Gemäss Artikel 21 revDSG muss die betroffene Person über eine automatisierte Einzelentscheidung informiert werden, wenn diese für sie mit rechtlichen Folgen verbunden ist oder sie erheblich beeinträchtigt [3]. Um diesem Auskunftsrecht nachzukommen, müssen Unternehmen genau darlegen können, auf welcher Datengrundlage und mit welchen Zwischenschritten ein Agent zu einem bestimmten Ergebnis gelangt ist.

Ohne unveränderliche Audit-Trails laufen Organisationen Gefahr, bei rechtlichen Prüfungen oder Kundenbeschwerden in Beweisnot zu geraten. Ein strukturiertes Tracing-System fungiert hierbei als technischer Nachweis, dass Guardrails eingehalten, Sicherheitsfilter ausgelöst und keine unzulässigen Datenquellen herangezogen wurden.

Nachweisen, ohne mehr zu speichern als nötig.

Grenzen, Risiken und praxiserprobte Fallback-Pfade

Der Betrieb einer umfassenden Observability-Infrastruktur birgt eigene Risiken, die Architekturteams proaktiv adressieren müssen. Das gravierendste Problem ist die unabsichtliche Speicherung sensibler personenbezogener Daten (PII) in den Traces. Wer ungefiltert Prompts protokolliert, speichert unter Umständen Passwörter, Kreditkartennummern oder vertrauliche Geschäftsgeheimnisse in Klartext in der Telemetrie-Datenbank.

Zur Risikominderung muss vor dem Export eine automatisierte Maskierungsschicht (Redaction Pipeline) geschaltet werden. Reguläre Ausdrücke und lokale Erkennungsmodelle filtern sensible Muster heraus, bevor die Daten den lokalen Speicher verlassen. Ergänzend dazu verhindert ein selektives Sampling von Standard-Traces ein übermässiges Anwachsen der Datenmengen (Trace-Bloat), während fehlerhafte Läufe oder Eskalationen stets mit 100 Prozent Detailtiefe protokolliert werden.

Für den Fall eines Totalausfalls des Observability-Backends muss ein klarer Fallback-Pfad greifen: Ein Circuit Breaker trennt die Telemetrie-Pipeline ab, sodass der operative Agentenbetrieb ohne Unterbrechung weiterläuft. Ein Logging-Ausfall darf niemals einen Stillstand des Kernsystems erzwingen.

Fazit und nächste Schritte für Technologieverantwortliche

Die Einführung autonomer KI-Agenten markiert den Übergang von einfacher Textgenerierung zu handlungsfähigen Softwaresystemen. Wer diesen Schritt ohne begleitendes Tracing geht, riskiert Sicherheitslücken, unkontrollierte Kosten und Compliance-Verstösse. Mit offenen Standards wie OpenTelemetry [1] und selbst gehosteten Observability-Plattformen [4] existieren heute praxiserprobte Werkzeuge, um Agenten-Workflows transparent und kontrollierbar zu gestalten.

Beginne bei neuen Projekten nicht erst nach dem Rollout mit der Fehleranalyse. Integriere semantische Spans bereits in der Prototypenphase, definiere klare Maskierungsregeln für sensible Daten und etabliere Dashboards für Kosten und Latenzen. Nur wer das Verhalten seiner Agenten in Echtzeit versteht, kann autonome KI erfolgreich und sicher skalieren.

Stand: 17. September 2026

Möchtest du weitere architektonische Leitfäden für deine unternehmensweite KI-Infrastruktur erhalten? Abonniere den Beirat-Newsletter.

Was zeigt ein Trace, das ein HTTP-Statuscode nicht zeigt?