Von „funktioniert auf meinem Laptop“ zu „kontrollierte Intelligenz im Werk“: Observability und Governance für LLM‑Agenten in der Industrie

Problem zuerst: Ein Agent, der eine E‑Mail schreibt, ist harmlos. Ein Agent, der Bestellungen auslöst, Wartungspläne ändert oder in einem Leitstand Handlungsanweisungen generiert, ist es nicht. In industriellen Umgebungen ist die Hauptfrage nicht „Wie gut ist das Modell?“, sondern „Wodurch stelle ich sicher, dass jede Handlung begründet, beobachtbar und kontrollierbar ist – unter Wahrung der Datensouveränität?“. Genau hier entscheidet sich, ob KI den Sprung vom Demo-Use-Case zur produktiven, verantwortbaren Anwendung schafft.

Ich schreibe aus der Perspektive eines UX/Systems-Engineers für komplexe KI-Systeme. Dort, wo ein Bediener einer Empfehlung vertrauen muss, ist die beste Modell-Architektur wertlos, wenn Observability, Governance und Human‑in‑the‑Loop (HITL) fehlen. Dieser Beitrag zeigt konkrete Muster, Architekturen und Metriken, mit denen LLM‑Agenten in sicherheits- und geschäftskritischen Domänen betrieben werden können – on‑premise, DSGVO‑konform und ohne US‑Cloud-Abhängigkeit. Er ist bewusst meinungsstark: Wir priorisieren Souveränität und Kontrollfähigkeit über „state-of-the-art“ Scores in Benchmarks.

Warum Observability bei LLM‑Agenten anders ist als bei klassischem ML

Klassische ML‑Systeme (z. B. Defekterkennung am Band) folgen einem deterministischeren Pfad: Eingabe → Modell → Schwellenwert → Entscheidung. Observability ist hier häufig Metrik-zentriert (Accuracy, Drift, Latenz). LLM‑Agenten sind anders:

  • Sie sind interaktiv und sequenziell: Ein Task wird in mehrere Schritte zerlegt (Planen, Recherchieren, Toolaufrufe, Validieren).
  • Sie treffen Tool-gestützte Entscheidungen: Datenbankabfragen, ERP‑Aktionen, Dokumentensuche.
  • Sie operieren auf ungewissen, offenen Aufgaben: Keine fixen Labels, sondern semantische Korrektheit und Handlungskontexte.
  • Sie verändern ihren Zustand: Memories, laufende Kontexte, Prompt‑Varianten.

Aus „ein Modell-Log“ wird „ein Handlungsgraph“. Das ist die Einheit, die man beobachten, reproduzieren, prüfen und auditieren muss.

Der „Decision Envelope“: Erst festlegen, was ein Agent darf – dann messen

Bevor Telemetrie fließt, muss die Kontrollgrenze des Agents klar sein. Wir definieren dafür einen Decision Envelope – eine maschinenlesbare Spezifikation des erlaubten Handlungsspielraums:

  • Zulässige Aktionen: Welche Tools/Funktionen dürfen aufgerufen werden? Mit welchen Parametern?
  • Budgets und Schranken: Zeit-/Token‑Budgets, monetäre Limits, Ressourcenquoten.
  • Gating‑Regeln: Wann ist ein Mensch in der Schleife? Wann automatische Ausführung? Wann Abbruch?
  • Kontextquellen: Welche Daten dürfen genutzt werden (Dokumentenklassen, Systeme, Mandanten)?
  • Verifikationspflichten: Welche Validierungschecks sind vor/nach einer Aktion durchzuführen?

Ohne Decision Envelope ist Observability Kosmetik. Mit ihm wird jede Telemetrie einer Verpflichtung gegenübergestellt: Hat der Agent innerhalb seiner Leitplanken gehandelt?

Was muss man messen? Strukturierte Telemetrie für Agenten

Freitext-Logs sind nicht genug. Benötigt werden strukturierte, korrelierte Ereignisse mit Referenzen auf Domänenobjekte. Die erprobten Bausteine:

  • Action Graph
  • Ein gerichteter Graph (DAG) pro Task mit Knoten für Plan, Retrieval, Toolaufrufe, Validierungschecks, menschliche Freigaben.
  • Jeder Knoten trägt Zeitstempel, Eingangsdaten, Ausgangsdaten, Metadaten (Prompt‑Version, Modell‑Version, Policy‑Version).
  • Edges dokumentieren Kausalität und Datenflüsse.
  • Prompt‑Versionierung
  • Jede System-/User‑/Tool‑Prompt‑Vorlage mit ID, Versionshash, Parametern, Diff zur Vorversion.
  • Reproduzierbarkeit: Ein „Replay“ nutzt exakt dieselbe Prompt‑Kombination.
  • Kontext‑ und Datenherkunft (Data Lineage)
  • Für Retrieval: Quellen mit Dokument‑IDs, Abschnittsreferenzen, Checksums, Erstell-/Freigabeständen.
  • Für strukturierte Daten: Query‑Plan/Filter, Zeitpunkt des Snapshots, Rollen-/Mandantenkontext.
  • Policy‑Entscheidungen
  • Welche Regel hat gegriffen (z. B. „Bestellwert > 10k → HITL“)?
  • Wer/was hat sie bestätigt (automatischer Validator, Operator)?
  • Unsicherheits‑ und Risikoindikatoren
  • Verfügbare Modell-Signale (z. B. Token‑Wahrscheinlichkeiten, wenn bereitgestellt).
  • Externe Checks: Schema‑Validierung, Anomalieerkennung gegen historische Aktionen, Domain‑Constraints.
  • Kosten- und Performance‑Metriken
  • Latenzen je Knoten, Tokenverbrauch, Tool‑Erfolgsquoten, Wiederholungsversuche.

Wichtiger Punkt: Wir vermeiden das Speichern und Anzeigen „freier Chain‑of‑Thought“ des Modells. Begründungen werden „by construction“ aus dem Action Graph und den genutzten Evidenzen abgeleitet. Das verhindert Halluzinations‑Erklärungen und schützt IP/PII.

Gating und Guardrails: Kontrolle vor und nach der Aktion

Guardrails sind nicht nur „Content-Filter“. In industriellen Agenten wirken sie auf mehreren Ebenen:

  • Vor der Aktion (Pre‑Action)
  • Schema‑Validierung der Tool‑Parameter (Typen, Wertebereiche).
  • Policy‑Checks gegen den Decision Envelope (Rollen, Limits, Vier‑Augen‑Prinzip).
  • Simulation/Trockenlauf: Kann der Effekt geschätzt werden? Wenn nein → HITL.
  • Nach der Aktion (Post‑Action)
  • Ergebnis‑Validierung: Passen Resultate zu Erwartungsbereichen? Semantische Konsistenz (z. B. Summen stimmen).
  • Cross‑Checks mit unabhängigen Heuristiken oder Business‑Regeln als deterministische Fallback‑Schicht.
  • Quarantäne bei Abweichungen: Automatischer Rollback einleiten, Operator benachrichtigen.
  • Ausführungsmodi zur Risikoreduktion
  • Shadow: Agent schlägt vor, führt nicht aus; wird gegen Ist‑Daten evaluiert.
  • Canary: Begrenzter Anteil realer Aktionen pro Zeit/Risikoklasse.
  • Dual‑Run: Zwei Versionen rechnen parallel; nur die „Primary“ setzt um, Differenzen werden geloggt.

Human‑in‑the‑Loop richtig bauen: Von „Approve/Reject“ zu operabler Evidenz

Ein „Approve“-Button ohne Kontext ist Alibi‑HITL. Bediener müssen eine Entscheidungsoberfläche erhalten, die die tatsächliche kognitive Last reduziert:

  • Evidenz‑zentrische Ansicht
  • Action Graph als Timeline: Welche Schritte wurden durchgeführt? Welche Quellen genutzt?
  • Belegstellen statt Behauptungen: Markierte Textpassagen/Tabellenzellen, auf die sich die Empfehlung stützt.
  • Risikomarker: Warum ist das gerade HITL? Regel, Grenzwert, Abweichung sichtbar machen.
  • Reproduzierbarkeit mit einem Klick
  • „Replay with same context“: Gleiche Prompts, gleiche Datenstände, gleicher Policy‑Satz.
  • „What‑if“-Werkzeuge: Parameter/Prompt minimal anpassen und Outcome vergleichen, ohne Produktionssystem zu verändern.
  • Annotationen als Trainingssignal
  • Operator‑Korrekturen und Kommentare landen strukturiert in einem Feedback‑Store (z. B. „Falsche Quelle“, „Budgetregel falsch interpretiert“).
  • Diese werden in Evaluationsszenarien und Prompt/Policy‑Tuning aktiv genutzt.