• Allow/Deny-Listen pro Tool und Ressource. Beispiel: “Bestellung > 5.000 EUR erfordert menschliche Freigabe.”
  • Capability-Tokens: Der Agent handelt nur in vorab freigegebenen Fähigkeiten. “Write” ist getrennt von “Read”.
  • Safety Budgets: Maximal erlaubte Anzahl an Tool-Calls, Token, Retries, externe API-Zugriffe pro Run. Überschreitung → Stopp, eskalieren.
  • Sealed Prompts: Kritische Systeminstruktionen sind signiert und zur Laufzeit überprüfbar, damit sich der Agent nicht selbst umkonfiguriert.

4.3 Validatoren und Contracts

  • Schema-Validator: Antworten müssen strenge Schemata erfüllen (z. B. JSON-Schema, regex-beschränkte Grammatik).
  • Domain-Validatoren: Fachliche Checks (Einheiten, Plausibilitäten, Kreuzvalidierung mit Stammdaten, Abweichungsprüfung).
  • Tool-Feedback-Loop: Eine Aktion wird erst wirksam, wenn ein unabhängiger Check sie bestätigt (z. B. Bestellung simulieren → Budgetprüfung → freigeben).

4.4 On-Prem Observability und DSGVO-feste Protokolle

  • PII-Scrubbing vor Persistenz: Maskieren/Hashen, Feldweise Minimierung.
  • Tamper-evident Storage: Append-only Log mit Hash-Ketten; Zeitstempel via interne Zeitquelle.
  • Air-gapped Betrieb: Keine Daten laufen in externe APM/LLM-Log-Clouds. Alle Dashboards und Analysen laufen lokal oder im Kundennetz.

4.5 Closed-Loop Governance

  • Metriken → Regeln → Maßnahmen. Beispiel: Steigt die Abstentionsrate auf einem Slice, löst das einen Datenerfassungsjob und einen aktiven Lernzyklus aus; Policies werden temporär verschärft (mehr HITL).
  • Runbooks: Für wiederkehrende Vorfälle existiert eine automatisierte Abfolge (z. B. Netzwerkausfall → Offline-Toolset aktivieren → Agent in “Read-only”-Modus → Operator-Alert).

Diese Prinzipien spiegeln sich in unserer Plattform-Architektur für Agent-Observability und Governance wider: On-Prem, mit Trace-Graph, Policy-Engine, Validator-Layer und DSGVO-tauglicher Persistenz. Entscheidend ist nicht das Tool, sondern die Disziplin, die es erzwingt.

5) Beispiel: Visuelle Qualitätskontrolle mit HITL

Ausgangslage: Ein Kamerasystem erkennt Montagefehler. Fehlerhafte Automatisierung führt zu unnötigen Stopps (False Positives) oder zu Ausschleusungen durchs System (False Negatives).

Architektur:

  • Acquisition: Industrie-Kameras, deterministische Preprocessing-Pipeline (Farbkalibrierung, Entzerrung), Versionierung der Kameraparameter.
  • Inferenz: CNN/Transformer-Modell mit Konfidenzschätzung (z. B. Deep Ensemble), OOD-Detector (z. B. Embedding-Dichte), Slice-Labels (Bauteiltyp, Beleuchtung).
  • Decision Layer: Gated Automation mit drei Pfaden:
  • Auto-Pass: conf > T_pass, kein OOD, keine Policy-Verletzung.
  • Human-Review: T_block < conf ≤ T_pass oder OOD auf niedrigem Level.
  • Block: conf ≤ T_block oder Safety/Compliance-Flag.
  • Explainability: Region-Overlays, exemplarische Positiv-/Negativfälle aus derselben Bauteilfamilie, Gegenfaktische (“Wäre die Schraube 0.2 mm tiefer, wäre es ok?”).
  • Feedback: Der Operator klassifiziert Fehlalarme/echte Fehler; aktive Auswahl unklarer Fälle für Retraining.
  • Observability: Jede Entscheidung bekommt eine Trace-ID, die Kamera-, Modell-, Threshold- und UI-Version einfriert.

Metriken:

  • Acceptance Rate: Anteil Auto-Pass + menschliche Bestätigungen.
  • Disagreement Rate: Mensch widerspricht KI.
  • Abstention Rate: Fälle, die zurückgestellt wurden.
  • Calibration Error: Differenz zwischen vorhergesagter und empirischer Fehlerwahrscheinlichkeit.
  • Slice-Drift: Embedding-Shift pro Bauteil/Schicht.

Typische Stolpersteine:

  • Heatmap-Overtrust: Operator vertraut bunten Bildern. Lösung: Stabilität der Erklärungen messen; instabile Erklärungen nicht anzeigen.
  • Unkalibrierte Thresholds: Eine globale Schwelle passt selten. Lösung: pro-Slice-Kalibrierung und dynamische Anpassung basierend auf Schicht und Umgebungsparametern.
  • Feedback-Falle: Nur offensichtliche Fälle werden gelabelt. Lösung: gezieltes Sampling unklarer Fälle.

6) Beispiel: LLM-Agent für Instandhaltung – sicher an das CMMS angebunden

Use Case: Ein Agent beantwortet Wartungsfragen, schlägt Arbeitsanweisungen vor und kann im CMMS (Computerized Maintenance Management System) Aufträge anlegen – aber nur unter strengen Auflagen.

Architektur:

  • Kontext: On-Prem Vektorindex mit freigegebenen Dokumenten (SOPs, Handbücher, Störungsberichte), Quellenversionen sind Teil der Trace.
  • Tools: Read-Tools (Datenbank, Sensor-Historie), Write-Tools (CMMS-Ticket, Ersatzteilreservierung) strikt getrennt, jeweils mit Policy-Gates.
  • Plan-Require-Explain: Jeder Run beginnt mit “Plan erkläre in Schritten” (Chain-of-Thought intern, aber zusammengefasste Begründung für den Nutzer). Dann Tool-Calls gemäß Plan.
  • Validatoren:
  • Schema-Validator für strukturierte Outputs (JSON),
  • Unit-Checks (Drehmoment, Temperaturbereiche),
  • Cross-Checks mit Stammdaten (Bauteil existiert, Lagerbestand verfügbar),
  • Budget/Compliance-Prüfung vor Write.
  • Policy-Engine:
  • “Write”-Aktionen > definierter Schwelle verlangen menschliche Freigabe,
  • Zeitfenster-Regeln (keine stilllegenden Maßnahmen zur Produktionsspitze),
  • Safety Budget (max. 3 Write-Versuche).
  • Observability: Trace-Graph, Token/Latency-Metriken, Fehlerkatalog (z. B. ToolNotFound, ValidationFailed, PolicyDenied).

Betrieb:

  • On-Prem Deployment des LLM (oder isolierter Zugriff auf ein EU-konformes Modell), alle Prompt-/Kontextdaten bleiben im Netzwerksegment.
  • Modelle und Tools werden versioniert; Rollback ist eine Operation, keine Hoffnung.
  • Runbooks für Störungen: Fällt das LLM aus, wechselt der Agent in Retrieval-only Modus; Write-Tools gesperrt, Operator erhält Instruktionen zur manuellen Buchung.

Ergebnis: Der Agent beschleunigt Routinearbeit, aber jede “riskante” Aktion ist durch Regeln und menschliche Freigaben abgesichert. Die Traceability ermöglicht Audits ohne Datenabfluss.

7) Governance heißt Zuweisung von Verantwortung, nicht nur Policies schreiben

Ohne klare Verantwortlichkeiten verkommen Policies zu Folklore. Ein praxistaugliches Governance-Setup enthält:

  • RACI für Entscheidungen: Wer ist Responsible (führt aus), Accountable (trägt Verantwortung), Consulted (liefert Input), Informed (erhält Info) – auf Ebene konkreter Aktionen (z. B. “Agent legt Auftrag > 5.000 EUR an”).
  • Change Control: Modell-/Policy-Änderungen sind Changes mit Ticket, Impact-Beschreibung, Rollback-Plan und Freigabe.
  • Safety Cases: Für kritische Funktionen existiert eine nachvollziehbare Argumentationskette, warum das Risiko vertretbar ist (inkl. Metriken, Tests, Monitoring).
  • Auditierbare Protokolle: Append-only, hashverkettet, Zeitquellen gesichert. Nur was man später zeigen kann, “existiert” im Audit.
  • KPIs und Schwellen: Nicht nur Modell-Accuracy, sondern Betriebsmetriken (Override-Rate, Mean Time to Human Decision, Anteil verweigerter Tool-Calls, Drift-Indikatoren). Schwellen führen zu automatischen Maßnahmen (z. B. “Override-Rate > 10% → Thresholds anheben, Retraining anstoßen, HITL ausweiten”).

8) Anti-Pattern, die wir in der Praxis vermeiden