Mensch-in-der-Schleife ist kein UI-Checkbox: Wie wir KI in der Industrie erklärbar, beobachtbar und beherrschbar machen

Das reale Problem, nicht die Technik:
Am Ende einer Fertigungslinie markiert ein Bildverarbeitungsmodell ein Bauteil als „defekt“. Der Bediener hat 15 Sekunden, um zu entscheiden: aussortieren oder freigeben. Ein Fehl-Positiv stoppt die Linie und kostet Taktzeit. Ein Fehl-Negativ wandert in den Markt und erzeugt Wochen später eine Rückrufwelle. „90 % Genauigkeit“ hilft dem Bediener in dieser Sekunde exakt gar nicht. Er braucht begründete, überprüfbare Evidenz – und ein einfaches, belastbares Verfahren, um Verantwortung zu tragen, zu dokumentieren und im Zweifel zu eskalieren.

Dieser Artikel beschreibt konkrete Architekturen, Patterns und Trade-offs, die sich in industriellen Umgebungen bewährt haben:

  • Wann gehört der Mensch in die Entscheidungsschleife – und wie implementiert man das so, dass Durchsatz und Sicherheit stimmen?

  • Welche Form von Erklärbarkeit unterstützt reale Bedienhandlungen, statt nur KPIs zu schmücken?

  • Wie beherrscht man LLM-Agenten produktiv: Observability, Governance, Reproduzierbarkeit?

  • Wer ist verantwortlich, wenn die KI falsch liegt – und wie belegt man das im Betrieb?

  • Warum Souveränität (on-prem, ohne US-Cloud-Abhängigkeit) keine Ideologie ist, sondern eine Betriebsbedingung.

1) Wann muss der Mensch entscheiden? Ein Gating-Framework für Produktionsumgebungen
Die Frage „Human-in-the-Loop: ja/nein?“ ist zu grob. Wir brauchen eine risikobasierte Entscheidung darüber, wie stark wir den Menschen einbinden. Drei Achsen genügen für den Start:

  • Auswirkungsgrad: Was passiert im Worst Case? Sicherheitsrelevant, regulatorisch relevant, teuer, oder nur kosmetisch?

  • Reversibilität: Lässt sich die Entscheidung später kostengünstig revidieren?

  • Unsicherheit: Wie kalibriert ist das Modell in diesem Kontext? Liegen Signale für Out-of-Distribution, schwache Evidenz, knappe Margin vor?

Daraus leiten sich vier Gating-Modi ab:

  • Autonom: Vollautomatisches Handeln bei niedrigem Risiko, hoher Reversibilität, hoher Modellkalibrierung. Beispiel: Sortierung von eindeutig defekten Teilen mit hoher Konfidenz und eindeutiger Bildsignatur.

  • Vorschlag + Bestätigung: Die KI liefert eine Handlungsempfehlung mit erklärter Evidenz, der Mensch bestätigt. Einsatz bei mittlerem Risiko oder unvollständiger Evidenz. Wichtig: Ein-Klick-Workflow mit klarer Begründung, kein Rätselraten.

  • Mensch entscheidet mit KI-Evidenz: Die KI liefert strukturierte Evidenz und Optionen, aber keine Empfehlung. Gut bei neuen, explorativen Fällen oder geringer Kalibrierung.

  • Eskalation/Abstention: Die KI enthält sich aktiv (Abstain), wenn OOD/Unsicherheitssignale oder Policy-Grenzen erreicht sind, und triggert eine Eskalationskette (z. B. Senior-Review, zusätzliche Messung).

Technische Bausteine für dieses Gating:

  • Unsicherheits-Signale: Konfidenzskalen, Margin-basierte Heuristiken, Ensembles, Abstandsmaße zu Trainingsrepräsentationen. Der konkrete Algorithmus ist zweitrangig; wichtiger ist die durchgängige Verfügbarkeit als maschinenlesbares Signal im Laufzeitkontext.

  • OOD-Erkennung: Ein einfaches aber wirksames Pattern ist der „Provenance-Check“: Nur wenn die Evidenz (z. B. ähnliche, historisch verifizierte Fälle) ausreichend nah ist, wird autonom gehandelt – sonst Abstention.

  • Entscheidungsdomäne (ODD) definieren: Explizite Betriebsbedingungen, in denen das Modell gelten darf (z. B. Kameraeinstellungen, Licht, Bauteiltypen). Außerhalb der ODD –> Abstention oder Degradierung auf Regeln.

  • Fallback-Strategien: Sauber definierte degradierte Modi (z. B. Heuristiken, feste Grenzwerte, manuelle Messung), die deterministisch sind und auditiert werden können.

  • UI-Interaktion: Ein „OK/Not OK“-Dialog ist zu wenig. Der Bediener braucht die wenigen, richtigen Signale: Was ist die Evidenz? Wie sicher ist das? Was passiert jeweils downstream?

2) Erklärbarkeit, die Operatoren wirklich nutzen
Es gibt keine universelle Erklärbarkeit. Was zählt, ist „Decision Support“ für die konkrete Aufgabe. Drei typische Muster:

a) Computer Vision in der Fertigung

  • Lokalisation > Attribution: Zeigen Sie präzise, wo der vermutete Defekt ist (Pixel- oder Kontur-Overlay), und legen Sie eine quantitative Messung daneben (z. B. Kratzerlänge in mm).

  • Prototyp-basierte Evidenz: Zeigen Sie 3–5 ähnlich bewertete, verifizierte Beispiele aus der Historie (Nearest-Neighbor-Retrieval auf Feature-Ebene). Menschen vertrauen Wiedererkennbarkeit.

  • Konfidenz vs. Qualität der Aufnahme: Separieren Sie „Modellsicherheit“ und „Signalqualität“ (Fokus, Belichtung, Occlusion). Schlechte Aufnahme? –> erst Bildqualität beheben, dann klassifizieren.

  • Kontrafaktische Hinweise: „Wenn dieser Bereich nicht über Schwellwert X läge, wäre die Entscheidung ‘OK’.“ Das ist für Bediener oft handlungsleitend (nochmal reinigen, neu positionieren).

b) Zeitreihen/Prediktive Instandhaltung

  • Treibende Kanäle explizit machen: Zeigen Sie die 2–3 Sensoren/Kanäle, die den Score dominieren, mit Zeitfenstern und Schwellwerten. Verlinken Sie zur letzten Wartung/Anomalie.

  • Physikbezug wahren: Wo möglich, korrelieren Sie ML-Indikatoren mit bekannten physikalischen Größen oder Regelwerken. „Anstieg der RMS-Vibration bei 120 Hz (Lagerschaden-Indiz)“ ist belastbarer als ein nackter Score.

  • Was-wenn-Fragen: „Wenn Lagertemperatur < 75 °C geblieben wäre, läge der Score im grünen Bereich.“ Das ist in der Instandhaltung oft die entscheidende Einsicht.

c) LLMs für Dokumente/Prozesse

  • Evidenz statt Narrative: Zeigen Sie extrahierte Claims mit präzisen Quellen (Dokument, Seite, Absatz). Keine „Chain-of-Thought“-Romane – sie sind nicht prüfbar. Besser: Claim-Evidence-Paare.

  • Abdeckung und Lücken: „90 % der relevanten Kapitel gescannt; Kapitel 4.2 fehlt (Scanfehler).“ Vollständigkeit schlägt Eloquenz.

  • Tool-Aktionen transparent: Wenn der Agent externe Tools nutzt (Suche, Berechnungen, Datenbankabfragen), gehören die Aufrufe, Parameter und Ergebnisse in eine sichtbare, klickbare Spur.

Wichtig: Erklärbarkeit ist eine Schnittstelle, nicht nur ein Modell-Attribut. Sie muss in Daten, UI, Logging und Governance konsistent sein.

3) Observability und Kontrolle für LLM-Agenten
Klassische MLOps-Logs (Requests, Latenzen, Fehlerraten) reichen bei Agenten nicht. Wir brauchen Tracing auf Entscheidungs- und Tool-Ebene. Eine robuste Architektur sieht so aus:

  • Event-Sourcing für Agentenläufe:
  • Trace-ID: globale Sitzung
  • Spans: einzelne Agentenschritte (Prompting, Tool-Call, Parsing, Entscheidung)
  • Inputs/Outputs: promptierte Kontexte, zensierte Nutzereingaben (PII-frei), Tool-Resultate
  • Policy-Entscheide: welche Regeln griffen (z. B. „externe E-Mail verboten“)
  • Metriken: Token, Latenz, Kosten, Score/Abdeckung
  • Evidenz-Links: Quellen mit Hash/Checksumme und Versions-ID