Mensch-KI-Interaktion in der Industrie: Wann der Mensch entscheiden muss – und wie wir LLM-Agenten wirklich kontrollieren

Problem zuerst: In sicherheits- und geschäftskritischen Umgebungen ist eine KI nur so nützlich wie das Vertrauen, das Bediener, Instandhalter und Führungskräfte in ihre Empfehlungen setzen. Eine einzelne Fehlentscheidung kann Maschinen stoppen, Lieferketten stören oder Sicherheitsmargen unterschreiten. Das verschärft die Anforderungen gegenüber Consumer-AI erheblich: Vorhersagen müssen nicht nur gut aussehen – sie müssen nachvollziehbar, überprüfbar und beherrschbar sein. Und sie müssen in Umgebungen laufen, in denen Datenhoheit und On-Premise-Betrieb nicht verhandelbar sind.

Dieser Beitrag beschreibt, wie wir als Ingenieure Human-in-the-Loop (HITL) richtig einsetzen, welche Erklärbarkeitsmuster in der Praxis tragfähig sind, und wie man LLM-Agenten mit Observability und Governance so aufsetzt, dass sie in regulierten, DSGVO-sensiblen Industrien tragfähig sind. Alles aus der Perspektive: Souveränität ermöglicht Intelligenz. Ohne Kontrolle keine produktive KI.

1) Human-in-the-Loop: Ein Architekturthema, kein UI-Schalter

HITL ist kein “Bitte bestätigen”-Popup. Es ist eine architektonische Entscheidung, welche Teile der Entscheidungskette:

  • vollautomatisch laufen dürfen,
  • vom Menschen freigegeben werden müssen,
  • oder bewusst verweigert werden (Selective Prediction Abstention: “Ich weiß es nicht”).

Wir verwenden drei Leitfragen, bevor irgendein Code geschrieben wird:

  • Reversibilität: Lässt sich die Entscheidung folgenlos zurückrollen? Wenn nicht, Mensch rein.
  • Sicherheitsmarge: Führt ein Fehler zu Sicherheitsverletzungen oder Compliance-Verstößen? Wenn ja, Mensch rein und Logging verschärfen.
  • Beobachtbarkeit: Können wir die Entscheidung ex post rekonstruieren? Wenn nein, Prozess anhalten bis Observability steht.

Daraus ergeben sich wiederkehrende Muster:

  • Gated Automation: Das Modell liefert eine Entscheidung + Unsicherheit + Begründung. Nur wenn Unsicherheit unter einem kalibrierten Schwellwert liegt und keine Policy-Regel verletzt wird, läuft die Aktion durch. Sonst landet der Fall in einer Freigabeschlange mit klarer SLA.
  • Abstention-Option: Das Modell darf sagen “unbekannt”. In der Industrie ist 85% Abdeckung mit 1% Fehler oft wertvoller als 99% Abdeckung mit 5% Fehler – wenn der Rest zuverlässig an den Menschen abgegeben wird.
  • Zwei-Personen-Integrität: Für irreversible Aktionen braucht es die Kombination “Modell empfiehlt” + “Operator bestätigt”. Best Practice: Die Bestätigung erfordert einen zweiten Blick, nicht denselben Nutzer.
  • Request-for-Help: Der Agent kann aktiv um Hilfe bitten, wenn er OOD (Out-of-Distribution) erkennt oder sein Tool-Call wiederholt fehlschlägt. Das ist besser als stures Retries-Spammen.

Technische Konsequenzen:

  • Unsicherheitsquantifizierung ist Pflicht. Das kann temperaturkalibrierte Softmax-Outputs, Deep Ensembles, MC-Dropout, oder für LLM-Agenten Heuristiken wie Tool-Call-Konsistenz, Self-Check-Protokolle und Validator-Ergebnisse umfassen.
  • OOD-Erkennung vor der Entscheidung. Besser früh abgeben als kaputt automatisieren.
  • UI/Workflow-Design muss Entscheidungen sortieren: “Auto-OK”, “Bitte prüfen”, “Blockiert – Safety/Compliance”.

2) Datenhoheit und Deployment: On-Prem ist mehr als “wir installieren das lokal”

Wenn Datenräume sensibel sind, genügt es nicht, eine Cloud-Lösung “irgendwie” zu tunneln. Die Architektur ändert sich:

  • Edge/On-Prem-First: Inferenz läuft dort, wo die Daten entstehen – Werkhalle, Fahrzeug, abgesicherte Rechenzelle. Keine latente Abhängigkeit zu US-Clouds. Artefakte (Modelle, Container) stammen aus einer internen Registry mit geprüftem SBOM (Software Bill of Materials).
  • Offline-fähige MLOps: Trainingspipelines können in einer isolierten Umgebung laufen. Artefakt-Promotion erfolgt über freigegebene Kanäle (Weißlisten, signierte Pakete, Vier-Augen-Prinzip).
  • Deterministische Builds: Image-Digests statt “latest”. Jede Entscheidung wird einem exakten Modell- und Codezustand zugeordnet.
  • Daten-Mindesthaltung: Nur was für Inferenz/Erklärung nötig ist, wird geladen. Sensible Rohdaten bleiben im Segment, Logs werden vorpersistiert (PII-Scrubbing, Pseudonymisierung) und erst dann in den Observability-Tier geschrieben.

Warum das zählt: Ohne Kontrolle über Rechenort, Modellversionen und Datenflüsse lässt sich Verantwortung nicht zuweisen – und Vertrauen nicht herstellen.

3) Explainability, die der Operator tatsächlich nutzt

In der Industrie wollen Nutzer nicht “die Wahrheit über neuronale Netze” – sie wollen wissen, ob sie einer Aktion zustimmen können. Drei Ebenen haben sich bewährt:

  • Global: Was kann das System, wofür ist es nicht gebaut? Dokumente wie Model Cards und Datensheet-derivierte Beschreibungen klären Geltungsbereich, Datenquellen, Performance pro Slice (z. B. Materialtyp, Beleuchtung, Temperaturbereich).
  • Regional: Welche Slices sind aktuell riskant (Drift, Ausreißer, Datenlücken)? Hier helfen Slice-Metriken, OOD-Rate, Kalibrationsfehler, Fehlertyp-Taxonomien.
  • Lokal: Warum diese konkrete Empfehlung? Für Vision: Overlays (Heatmaps nur, wenn sie stabil sind), exemplarische Gegenbeispiele, Entscheidungsregeln in verständlicher Form (z. B. “Schraubenkopfexzentrizität > 0.3 mm bei 2200 lx”). Für LLM-Agenten: Schrittweiser Plan, aufgerufene Tools, verwendete Quellen, Validierergebnisse.

Wichtige Trade-offs:

  • Feature-Attribution vs. Stabilität: Saliency-Maps können täuschen. Besser sind robuste Konzepte (Concept Activation Vectors), Gegenfaktische (“Was hätte die Entscheidung geändert?”) und vor allem: Validatoren, die unabhängig vom Modell prüfen.
  • “Gute Erklärung” schlägt “wahre Erklärung”: Operatoren müssen Fehler antizipieren können. Eine klar formulierte Regel plus Ablagetext für Ausnahmen ist wirksamer als eine schwer interpretierbare Attributionsvisualisierung.
  • Erklärungen sind Teil des Contracts: Jede Model-API liefert neben ŷ auch conf, reason, evidence. Ohne evidence keine Automation.

4) LLM-Agenten unter Kontrolle: Observability und Governance als Systemfunktion

LLM-Agenten sind keine deterministischen Microservices. Ohne Sichtbarkeit und Regeln eskalieren sie von “hilfreich” zu “unkontrollierbar”. Ein tragfähiger Ansatz besteht aus fünf Bausteinen:

4.1 Trace-Graph statt Logfile

  • Jede Ausführung erzeugt einen gerichteten Azyklischen Graphen: Prompt → Kontextquellen → Tool-Calls → Zwischenergebnisse → endgültige Aktion/Antwort.
  • Knoten enthalten: Eingaben (nach PII-Scrubbing), Modell-/Version, Sampling-Parameter, Policies, Validierergebnisse, Metriken (Token, Latenz, Kosten), Exit-Status.
  • Damit ist Reproduzierbarkeit gegeben: Gleiches Modell, gleicher Kontext, gleiche Tools → identischer oder eng begrenzter Outcome (bei deterministischen Seeds/Temperature).

4.2 Policy-Engine als Laufzeit-Wächter