Titel: Vom Proof-of-Concept zum beherrschbaren Betrieb: Observability und Kontrolle für LLM‑Agenten in industriellen Umgebungen

Einleitung
Wer LLM‑Agenten ernsthaft in der Industrie betreiben will, landet schnell jenseits von “Chatbot mit Wissensbasis”. Die Agenten planen, rufen Tools auf, greifen auf ERP/PLM zu, schreiben Tickets, generieren Arbeitsanweisungen oder bestellen Teile. In diesem Umfeld zählt nicht, ob eine Demo beeindruckt, sondern ob der Betrieb kontrollierbar, auditierbar und sicher bleibt. Ohne systematische Observability und explizite Kontrollpunkte werden diese Systeme zu Blackboxes mit unklarem Risikoprofil. Das ist in verteidigungsnahen, bahn‑ oder produktionskritischen Kontexten inakzeptabel.

Ich formuliere das bewusst problem‑first: Das Kernproblem ist nicht, dass LLMs „halluzinieren“. Das Kernproblem ist, dass Agenten als nichtdeterministische, nebenläufige Planer mit externen Seiteneffekten agieren, während klassische Softwarekontrollen (Tests, Typen, Compile‑Zeit‑Sicherheit) kaum greifen. Diese Lücke schließt man nicht mit “mehr Kontext” oder “besserem Prompt”, sondern mit einer Betriebsebene, die jeden Schritt bewertet, erklärt, begrenzt und im Zweifel an Menschen übergibt. Souveränität ist die Voraussetzung dafür – funktional (Kontrolle), technisch (on‑prem) und organisatorisch (Governance).

Was LLM‑Agenten fundamental von klassischer Software unterscheidet

  • Nichtdeterminismus: Gleiche Eingaben können verschiedene Ausgaben erzeugen. Reine Re‑Runs sind keine reproduzierbaren Belege.

  • Verborgene Zustände: Gesprächskontext, Gedächtnis, Zwischenergebnisse, abgeleitete Ziele. Ohne lückenlose Traces bleibt unklar, warum ein Tool‑Call erfolgte.

  • Externe Seiteneffekte: Tool‑Aufrufe können reale Systeme verändern (Ticket, Bestellung, Maschinenbefehl).

  • Modell‑ und Datendrift: Updates am Modell, geänderte Vektordatenbanken oder Tool‑APIs verändern das Verhalten – oft subtil.

  • Kosten- und Latenzstreuung: Laufzeit und Tokenverbrauch schwanken je nach Pfad; Budgets sind erforderlich.

  • Angriffsfläche: Prompt‑Injection, Jailbreaks, Datenexfiltration, Tool‑Missbrauch – besonders kritisch bei Unternehmenszugriffen.

Daraus resultieren drei Anforderungen:
1) Observability: Jede Entscheidung und jeder Seiteneffekt müssen nachvollziehbar sein – in Echtzeit und rückwirkend.
2) Kontrollpunkte: Automatische und menschliche Gates begrenzen Reichweite, Zeit und Schaden.
3) Governance: Versionen, Verantwortlichkeiten, Freigaben und Audits müssen in den Prozess eingebettet sein.

Human‑in‑the‑Loop, wo er Wirkung entfaltet
Nicht jeder Schritt braucht einen Menschen. Aber bestimmte Entscheidungen sind im industriellen Kontext zu folgenschwer, um sie zu automatisieren. Sinnvolle Muster:

  • Genehmigung vor externem Seiteneffekt: Wenn ein Agent Workorders erstellt, Bestellungen auslöst oder Konfigurationen ändert, werden konkrete Vorschläge inklusive Begründung und Evidenz vorgelegt. Ein Bediener genehmigt, ändert oder verwirft.

  • Triage nach Unsicherheit oder Domänenabweichung: Bei geringer Groundedness (Antwort stützt sich schwach auf die bereitgestellten Belege), Out‑of‑Distribution‑Erkennung oder konflikthaltigen Quellen wird an einen Fachexperten eskaliert.

  • Optionen statt Orakel: Agenten liefern 2–3 begründete Handlungsoptionen mit klarer Gegenüberstellung von Annahmen, Kosten, Risiken. Mensch wählt aus.

  • Erzwungenes “Absehen vom Handeln”: Agenten müssen formalisierte Wege kennen, Aufgaben abzulehnen („insufficient information“, „policy violation“, „unbounded risk“) statt zu raten.

  • Evidenz‑UI: Bediener sehen nicht “Gedankengänge” (die sind nicht belastbar), sondern: genutzte Tools, Eingaben/Ausgaben, verwendete Dokumente mit Zitatstellen, Scores, erkannte Restrisiken, Policy‑Prüfungen. Ziel: schnelle Plausibilisierung.

Explainability, die in der Praxis hilft
Im Agentenkontext ist “XAI” weniger die Offenlegung interner Token‑Wahrscheinlichkeiten, sondern die nachvollziehbare Kausalkette:

  • Tool‑Trace statt “Chain‑of‑Thought”: Zeigen Sie die Abfolge: Plan → Tool‑Call(s) → Zwischenergebnis → Plananpassung → Endergebnis. Jeder Schritt hat Input/Output‑Hashes, Laufzeit, Fehler, Policy‑Checks.

  • Quellen‑Provenienz: Bei RAG: Welche Dokumente (IDs, Versionen, Hashes) wurden herangezogen? Wo genau wird zitiert? Wie hoch war der Retrieval‑Score?

  • Gegenargumente sichtbar machen: “Warum nicht X?” – Lassen Sie den Agent systematisch alternative Routen prüfen und die verworfenen Pfade mit Begründung dokumentieren.

  • Politische Erklärungen: Welche Richtlinien griffen? Z. B. “PII‑Maskierung angewendet”, “Budgetlimit erzwungen”, “Dangerous‑Tool call verweigert”.

  • Abgrenzung: Erklären Sie offen, dass generative “Erklärungen” keine Beweise sind. Entscheidungsgrundlagen sind die Traces, Belege und Policies, nicht eloquente Narrative.

Architektur für Observability: Ereignismodell zuerst
Ohne ein sauberes Ereignismodell wird Observability zum Loghaufen. Wir modellieren Agenten als gerichtete Acyclic Graphs (DAG) mit verknüpften “Steps”. Jeder Step emittiert ein strukturiertes Ereignis. Minimale Felder:

  • Korrelation: trace_id, span_id, parent_span_id, session_id, user_id, tenant_id

  • Zeit: ts_start, ts_end, duration_ms

  • Identität & Versionen: model_id, model_commit, prompt_id, prompt_version, tool_id, tool_version, policy_bundle_id, embedding_model_version, retrieval_index_version

  • Inhalte (gehasht/gefasst): input_hash, output_hash, retrieval_doc_ids+hashes, tool_input_schema_id, tool_output_schema_validation_result

  • Qualität/Signale: token_usage_prompt/response, cost_estimate, retrieval_scores, groundedness_proxy, ood_flag, pii_detected_flag, guardrail_flags

  • Nebenwirkungen: external_system, resource_id, action, idempotency_key, dry_run_flag, result_status

  • Umgebung: node_id, region/zone (on‑prem), container_image_digest

Erfassungsmechanismus:

  • SDK‑Interceptor in der Agent‑Runtime, die LLM‑Calls und Tool‑Aufrufe instrumentieren.

  • Ereignisbus on‑prem (event stream). Persistenz in einem append‑only Store plus Index für Ad‑hoc‑Analysen.

  • Tracing über den gesamten Graph: Jeder Tool‑Call ist ein Span; Konversation ist ein Stream verknüpfter Spans.

  • WORM‑Speicher für Audit‑Rekonstruktion; kryptografische Verkettung (optional) für Manipulationssicherheit.

Laufende Überwachung (SLIs/SLOs, ohne Pseudo‑Gewissheit):

  • Stabilität: Tool‑Fehlerrate, Timeout‑Quote, Rate limit breaches.

  • Qualität: Anteil Antworten mit geringer Groundedness (z. B. geringer Similarity zwischen Antwort und Kontext), Override‑Rate durch Bediener, Abstentionsrate.

  • Sicherheit: Geblockte exfiltration-ähnliche Muster, Prompt‑Injection‑Treffer, Policy‑Verstöße.

  • Kosten/Leistung: Tokens/Task, Latenz/Step, Step‑Budget‑Überschreitungen.

  • Datenpfad: Retrieval‑Recall‑Proben, Index‑Verteilung, verwaiste Dokumente, Version Drift.

Wichtig: Diese Metriken sind Proxys, keine Wahrheitsdetektoren. Ihre Stärke liegt in Trends, Alarmen und der gezielten Eskalation – nicht in binären Urteilen.