Mensch-in-der-Schleife ist kein UX-Feature: So bauen wir KI-Systeme, denen Operatoren wirklich vertrauen

Wer industrielle KI ernsthaft betreiben will, muss mit einem unbequemen Fakt starten: Die beste Modellgüte ist wertlos, wenn der Bediener den Vorschlag nicht übernimmt. In sicherheits-, qualitäts- oder prozesskritischen Umgebungen trägt der Mensch die Haftung – nicht der Optimizer. Deshalb ist Human-in-the-Loop keine hübsche UI-Option am Ende des Projekts, sondern eine durchgängige Betriebsarchitektur: von Datenerfassung und Modellierung über Entscheidungslogik, UI und Rückkopplung bis zu Audit und Governance.

In diesem Beitrag zeige ich, wie wir Mensch-KI-Interaktion in der Praxis als System entwerfen – problemorientiert, mit konkreten Mustern, Architekturen und Trade-offs. Und ich erkläre, warum Observability und Governance für LLM-Agenten die eigentliche Hebelwirkung haben, nicht der nächste Prompt-Trick. Kontext sind reale industrielle Domänen: Fertigung, Bahn, Bau, Textil, Verteidigung, Luftfahrt. Die Beispiele sind repräsentativ für wiederkehrende technische Situationen dort, nicht für hypothetische Demos.

1) Wann entscheidet die KI, wann der Mensch? Eine Betriebsarchitektur, keine Bauchentscheidung

Die Kernfrage lässt sich nicht mit “Vertrauen” beantworten, sondern mit Risiko und Zeit. Zwei Achsen reichen als Start:

  • Kosten eines Fehlers: von reversibel (Korrektur möglich, geringe Folgekosten) bis irreversibel (Sicherheitsvorfall, Schaden, Rechtsfolge)
  • Kosten der Verzögerung: von tolerierbar (Batch, Warteschlange) bis kritisch (Echtzeit, Taktzeit, SLA)

Daraus ergeben sich vier Betriebsmodi:

  • Informieren (low error cost, low delay cost): KI liefert Hinweise, Mensch kann übernehmen. Beispiel: visuelle Vorselektion möglicher Defekte, die der Prüfer bestätigt oder verwirft.
  • Verifizieren (low delay cost, high error cost): KI schlägt vor, Mensch muss bestätigen. Beispiel: Freigabe einer abweichenden Prozessparameter-Einstellung in der Fertigung.
  • Delegieren mit Rückruf (high delay cost, moderate error cost): KI handelt autonom, Mensch wird bei Unsicherheit oder Policy-Verstoß eingebunden. Beispiel: Echtzeit-Routing von Service-Tickets, mit Eskalation an Dispatcher bei Widersprüchen.
  • Genehmigen (high error cost, high delay cost): Mensch setzt Ziel und Schranken, KI bereitet Entscheidung vor, Ausführung erst nach Freigabe. Beispiel: Bestellung eines Ersatzteils jenseits definierter Budgetgrenzen.

Diese Modi sind nicht statisch. Dieselbe Pipeline kann je nach Kontext schalten: Nachtschicht mit dünner Personaldecke → mehr Autonomie; hochkritischer Produktionsanlauf → mehr Gatekeeping. Deshalb braucht es eine Entscheidungslogik, die Zustände, Risiken und Budgets zur Laufzeit berücksichtigt – nicht nur “Konfidenz > 0.8”.

Bewährte Muster für diese Logik:

  • Risikobewusstes Routing: Score = f(Konfidenz, Daten-Drift, Neuheit der Situation, Kostenmodell). Route je nach Score in Autonomie, Review, oder Blockade.
  • Interlocks: Harte Regeln, die Autonomie unabhängig von Konfidenz verhindern (z. B. Materialfreigabe nur für bekannte Lieferanten; Sicherheitsrelais-Logik).
  • Stufenweise Freigaben: Kleine, reversible Schritte automatisch; größere Schritte gated. Beispiel: Diagnose autonom, Teilebestellung ab 500 EUR mit Genehmigung, Maschinenstillstand nur mit doppelter Freigabe.
  • Zeitbudgets: Wenn das Zeitfenster zu knapp ist, fällt die Entscheidung auf den sichersten definierten Fallback zurück. Kein “KI hängt noch, bitte warten”, sondern deterministische Degradierung.

2) Was muss der Mensch sehen, um entscheiden zu können? – Evidence over Explanations

Eine Erklärung ist kein Marketing-Text, sondern ein prüfbares Beweisstück. Der Bediener braucht keine abstrakte “Transparenz”, sondern genau die Artefakte, die seine Entscheidung stützen:

  • Claim: “Defekt: Haarriss im Segment C3”
  • Evidence: Bildausschnitt mit Overlay, Konfidenzintervall, Vergleich zu referenzierten Positiven, Messwertverlauf vor dem Ereignis, Bedingungen (Beleuchtung, Kamera-ID), gültige Grenzwerteversion.
  • Boundaries: Gültigkeitsbereich des Modells (Kameramodelle, Temperaturbereich, Materialtyp).
  • Alternatives: Nächstbeste Hypothesen und ihr Abstand. Ein knapper Abstand ist ein Eskalationsgrund.

Für verschiedene Datenarten sind unterschiedliche Evidenz-Artefakte sinnvoll:

  • Computer Vision:
  • Pixel-weise Masken/Bounding-Boxes mit Unsicherheits-Overlays (z. B. Kontur-Heatmaps).
  • Patch-basierte Gegenbeispiele: “So sieht derselbe Bereich ohne Defekt in vergleichbaren Bedingungen aus.”
  • Datenstempel: Objektivlinse, Brennweite, Belichtung, Liniengeschwindigkeit, Beleuchtungsprofil.
  • Zeitreihen/Anomalieerkennung:
  • Residualplots und erklärende Features (z. B. saisonale Komponenten vs. Trend).
  • Event-Korrelationen: “Anomalie korreliert mit Temperaturspike und Start/Stop-Zyklen.”
  • Konfidenz als Intervall, nicht als Single-Score.
  • Tabular/Regression/Klassifikation:
  • Lokale Faktorenbeiträge (nur wenn stabil interpretierbar), plus globale Feature-Stabilität über Zeit.
  • Kontrafaktische Szenarien: “Wäre Schwelle X um 5% höher, wäre Klassifikation Y.”

Wichtig: Erklärungen sind Hypothesenhilfen, keine Wahrheiten. Deshalb bauen wir “Erklärungstests” in die QA:

  • Challenge-Sets: Explizite Fälle, bei denen wir wissen, dass eine bestimmte Begründung falsch wäre. Wenn die Erklärung trotzdem “plausibel” wirkt, ist sie wertlos.
  • Konsistenzprüfungen: Änderung eines irrelevanten Inputs darf die Erklärung nicht signifikant verändern. Andernfalls: Flag als nicht vertrauenswürdig.
  • Claim-Evidence-Contract: Jede Darstellung in der UI muss ein zugrunde liegendes, abrufbares Artefakt haben (Daten, Parameter, Codeversion). Keine “schwarzen Kästen im weißen UI”.

3) LLM-Agenten in der Produktion: Observability und Kontrolle zuerst, Prompt später

Sobald ein LLM nicht nur textet, sondern Tools ansteuert (RAG, ERP, Ticketing, Code-Ausführung), ist es ein verteiltes System. Für verteilte Systeme gelten die alten Gesetze: Ohne Telemetrie, Budgets und Policies brennt es. Observability ist hier kein Batch-Log, sondern die Lebensader des Sicherheitskonzepts.

Minimal-Architektur für beobachtbare LLM-Agenten: