Mensch-in-der-Schleife statt Blindflug: Wie wir industrielle KI nutzbar machen – mit erklärbaren Modellen, kontrollierten LLM-Agenten und klarer Governance

In sicherheits- und geschäftskritischen Umgebungen scheitern KI-Projekte nicht an der Modellgüte, sondern an der Interaktion zwischen Mensch und System. Wenn ein Bediener eine Empfehlung nicht versteht oder ihr nicht traut, bleibt der Not-Aus gedrückt – im übertragenen wie im wörtlichen Sinn. Unser Grundsatz lautet: Souveränität ermöglicht Intelligenz. Wer die Datenflüsse, Entscheidungsgrenzen und Betriebsprozesse nicht kontrolliert, bekommt keine robuste Wertschöpfung aus KI.

In diesem Beitrag zeige ich praxisnahe Muster für Human-in-the-Loop (HITL), wirkungsvolle Explainability, Observability für LLM-Agenten und eine Governance, die Verantwortlichkeit nicht an „die KI“ delegiert. Keine Heilsversprechen, sondern konkrete Architektur- und Betriebsentscheidungen, die in der Industrie funktionieren – on-premise, DSGVO-konform und ohne US-Cloud-Abhängigkeit.

Wann muss der Mensch entscheiden? Ein technischer Rahmen statt Bauchgefühl

Nicht jede Entscheidung gehört zur Maschine, und nicht jede zur Leitwarte. Wir etablieren eine einfache, aber strikte Einordnung entlang von vier Achsen. Sie wird im Code, in Policies und in der UI verankert:

  • Kritikalität: Sicherheitsrelevanz, regulatorische Folgen, Reputationsschaden.
  • Kosten und Reversibilität: Ist die Entscheidung rückgängig zu machen? Mit welchem Aufwand?
  • Unsicherheit: Kann das System seine Unsicherheit quantifizieren? Wie gut ist die Kalibrierung?
  • Neuartigkeit: Erkennt das System, wenn es außerhalb seines Trainings-/Betriebsraums operiert?

Daraus ergeben sich drei Betriebsmodi:

  • Autonom mit Audit: Niedrige Kritikalität, niedrige Kosten, gut kalibrierte Unsicherheit. Entscheidung geht automatisiert durch, wird aber revisionssicher geloggt.
  • Vorschlag mit Mensch als Gate: Mittlere Kritikalität oder erhöhte Unsicherheit. System liefert Entscheidung + Begründung + Evidenz, Mensch bestätigt oder korrigiert.
  • Nur Mensch: Hohe Kritikalität, hohe Kosten, OOD-Anzeichen (Out-of-Distribution), widersprüchliche Sensordaten. System liefert nur strukturierte Evidenzen und keine Autonomie.

Konkrete technische Trigger für den Mensch-Call sind u. a.:

  • Unsicherheits- oder Konfidenzschwellen (klassische Modelle: kalibrierte Wahrscheinlichkeiten, Konformalitätsintervalle; LLM-Agenten: Abdeckungsgrad der Retrieval-Evidenz, Tool-Call-Erfolgsquote).
  • OOD-Erkennung: Embedding-Drift, ungewöhnliche Fehlercodes, Sensorinkonsistenzen.
  • Policy-Verletzungen: PII-Anzeichen, Exportkontroll-Schlüsselwörter, Regelkonflikte zwischen Tools.
  • Neuheitsindikatoren: Häufen sich „First-of-its-kind“-Muster, greift Lernhistorie nicht?

Dieser Rahmen wird explizit in einer Policy-Engine abgebildet, nicht als implicit im Kopf des Entwicklers. Technisch heißt das: Wir implementieren Abbruch- und Eskalationspfade im Orchestrator (z. B. Zustandsmaschine/Graph), nicht als monolithische if-else-Kaskaden.

Human-in-the-Loop-UI: Von „KI sagt“ zu „Evidenz-basiertes Entscheiden“

Eine HITL-Oberfläche ist kein Dashboard für hübsche Kurven. Sie ist ein Entscheidungswerkzeug mit klarer Verantwortung. Ein robustes Muster:

  • Entscheidungskontext zuerst: Was ist zu entscheiden? Welche Stellhebel gibt es? Welche Folgen haben Optionen?
  • Evidenz statt Orakel: Zeigen, was das System gesehen, gelesen oder abgeleitet hat – inklusive Herkunft (Quelldokumente, Sensorkanäle, Zeitstempel). Keine reinen Fließtexte, sondern verlinkte, prüfbare Artefakte.
  • Erklärbare Empfehlung, nicht bloß Score: Knapp, strukturiert (Top-Treiber, Gegenargumente, Confounder). Keine Pseudogenauigkeit.
  • Handlungsoptionen mit Standardwert: Akzeptieren, Ablehnen, Zurückstellen, Eskalieren. Default sollte konservativ sein (Fail-Safe), z. B. „Zur Prüfung“.
  • Begründungspflicht bei Override: Kurze strukturierte Felder („Grund des Overrides“, „zusätzliche Beobachtungen“). Das ist Gold für späteres Re-Training und Prozessverbesserungen.
  • Zeitbudgets und SLAs: Anzeige, wie lange eine Entscheidung warten darf, wer On-Call ist, was nach Ablauf geschieht.
  • Feedback ohne Friktion: Markierungen direkt in Bildern/Signalen, Korrektur der extrahierten Fakten, Kennzeichnung von falscher Evidenz.

Anti-Pattern: „Blackbox mit grünem Haken“. Operatoren folgen dann der Automationsverlockung („Automation Bias“), bis es knallt. Besser: Eine gestaltete Friktion, die bei unsicheren Fällen zwingt, die Evidenz anzusehen.

Explainability, die der Bediener akzeptiert

Erklärbarkeit ist kein Selbstzweck und keine bunte Heatmap-Show. Sie muss die Arbeitswirklichkeit abbilden:

  • Visuelle Qualitätskontrolle: Segmentierungen/Bounding-Boxes mit Konfidenzen, alternative Hypothesen (z. B. „Kratzer“ vs. „Schmutz“), und ein „Warum nicht“-Panel (warum andere Fehlerklassen verworfen wurden). Ergänzend: Stabilität der Entscheidung über mehrere Frames.
  • Anomalieerkennung: Rekonstruktionsfehler als differenzierte Karte; Grenzwerte, die am Prozess orientiert sind (µm, mm, dB), nicht am Modellverlust.
  • Tabellarische / Zeitreihen-Prozesse: Feature-Beiträge pro Zeitschritt, Gegenfaktische („Wäre Temperatur -5%, dann …“), und Wechselwirkungshinweise (z. B. Druck x Temperatur).
  • Text-/Dokumentenbegriffe: Passage-basierte Attribution („diese Textstelle stützt die Antwort“), Zitierquoten, Konsistenz über mehrere Quellen.

Wichtig ist die Erklärungsgüte entlang dreier Kriterien:

  • Fideliät: Spiegelt die Erklärung wirklich die Entscheidungslogik des Systems wider?
  • Nützlichkeit: Hilft sie bei der Entscheidung in der Leitwarte – in 30 Sekunden?
  • Revisionsfestigkeit: Lässt sich später nachvollziehen, warum die Entscheidung so getroffen wurde?

Deshalb definieren wir vorab einen „Erklärungs-Vertrag“ zwischen Modell, UI und Betreiber:

  • Welche Erklärungsartefakte liefert das System für welche Entscheidungstypen?
  • Wo sind die Grenzen (z. B. plausible, aber nicht kausale Attributionen)?
  • Wie werden Erklärungen versioniert und auditiert?

LLM-Agenten: Ohne Observability bleibt es Trial-and-Error

LLM-Agenten sind keine REST-Endpunkte, sondern verteilte Systeme mit nicht-deterministischer Komponente. Wer sie ohne Observability betreibt, bekommt unvorhersehbare Ausfälle, schleichende Qualitätsdrifts und Governance-Lücken. Die technischen Bausteine, die wir standardmäßig einziehen:

Instrumentierung auf Run-Ebene

  • Trace pro Agentenlauf mit korreliertem Trace-ID: Prompt-Generationen, Tool-Aufrufe, Antworten, Kontext-Retrievals, Policy-Entscheidungen – als Spans mit Zeitstempeln.
  • Artefakt-Speicherung on-prem: Prompts, Modelleinstellungen (Temperatur, Seed), verwendete Wissensschnipsel, Tool-I/O, Zwischenergebnisse. PII wird vor Persistierung geschwärzt oder ersetzt.
  • Deterministische Modi für Tests: Temperatur 0, gesetzte Seeds, pinned Model-Versionen. Im Betrieb werden Input/Output für spätere Reproduktionen geloggt.

Metriken, die über „Token-Kosten“ hinausgehen