Mensch-in-der-Schleife, erklärbare KI und kontrollierte LLM-Agenten: Wie Sie industrielle KI betreiben, der der Bediener wirklich vertraut

Die beste KI ist wertlos, wenn der Mensch ihr nicht vertraut. In sicherheits- und geschäftskritischen Umgebungen ist Vertrauen keine Frage eines hübschen Dashboards, sondern von Technik: Wie zuverlässig ist die Entscheidung? Woran erkenne ich Ausreißer? Kann die KI abstimmen („Ich weiß es nicht“)? Und wer stoppt sie, wenn sie etwas Falsches tun will?

Dieser Beitrag ist kein „KI ist wichtig“-Plädoyer. Er ist ein Blueprint aus der Praxis für CTOs und technische Leiter in Industrieunternehmen, die KI-Systeme betreiben müssen, ohne Souveränität zu verlieren. Wir betrachten vier Aspekte, die über Erfolg oder Scheitern entscheiden:

  • Human-in-the-Loop: wann der Mensch entscheiden muss – und wie man das technisch erzwingt

  • Explainability: Erklärungen, die in der Leitwarte, im Cockpit oder an der Linie tatsächlich verwendet werden

  • Observability und Kontrolle für LLM-Agenten – inklusive konkreter Metriken und Eingriffsmechanismen

  • KI-Governance: Wer trägt Verantwortung, wenn die KI falsch liegt – und wie man das beweisfest macht

Unsere Grundhaltung: Souveränität ermöglicht Intelligenz. Wer Daten, Ausführung und Protokolle unter eigener Kontrolle hält, kann KI aggressiver und sicherer einsetzen. Deshalb: on-premise, DSGVO-konform, keine Abhängigkeit von US-Clouds – weil Sie Eingriff, Audit und Haftung nicht outsourcen können.

1) Human-in-the-Loop: Der Mensch entscheidet – aber systematisch, nicht ad hoc

Die erste Frage lautet nie „Welches Modell?“, sondern „Welche Entscheidungsklassen dürfen automatisiert werden – und unter welchen Bedingungen?“. Ein praktikables Muster in industriellen Systemen:

  • Entscheidungsklassen definieren
  • A: Automatisierbar (niedriges Risiko, klare Regeln)
  • B: Menschliche Freigabe erforderlich (mittleres/hohes Risiko)
  • C: Nur Empfehlung (Handbuch der Operateure; keine Autonomie)
  • Unsicherheitsgating einbauen
  • Das Modell darf nur für Klasse A automatisch handeln, wenn es innerhalb eines kalibrierten Vertrauensintervalls liegt. Außerhalb: Abstimmung („reject option“) und Eskalation zu B/C.
  • „Abstain“-Pfad als Feature, nicht als Fehler
  • Ein Modell, das kontrolliert schweigt, ist wertvoller als eines, das rät. Designen Sie aktiv einen „weiß nicht“-Zweig mit dedizierter UX (Rückfrage mit evidenzbasierten Hinweisen, nicht bloß ein rotes „X“).
  • Kalibrierte Scores statt roher Wahrscheinlichkeiten
  • Setzen Sie Score-Kalibrierung (z. B. temperatur- oder platt-skalierte Logits) oder konforme Prognosen ein, damit ein 0,8-Score in der Realität auch ca. 80% Präzision bedeutet. Ohne Kalibrierung sind Unsicherheitsgates blind.
  • Latenzbudget vs. Sicherheit
  • Definieren Sie, wo eine menschliche Freigabe unter harten Latenzanforderungen praktikabel ist (z. B. HMI-Stop in <300 ms unmöglich? Dann nur Klasse A zulassen; B/C nur als Empfehlung).
  • Degradation-by-Design
  • Wenn Sensorik ausfällt oder Drift erkannt wird: automatischer Rückfall auf konservativere Modelle/Heuristiken oder manuellen Betrieb. „Fail Open“ ist in der Industrie selten akzeptabel – planen Sie „Fail Safe“.

Praktischer Ablauf zur Einführung:

  • Risiko- und Gefährdungsanalyse der Zielprozesse

  • Mapping der Entscheidungsklassen A/B/C

  • Kalibrierung des Modells auf relevanten Slices (Schicht, Maschine, Materialcharge)

  • Definition von Unsicherheits-Schwellen und operativer SOP pro Schwelle

  • Implementierung eines technischen Freigabegates: Der Autonomiepfad ist eine explizite Check-Funktion, nicht eine stille Annahme

2) Explainability, die im Betrieb funktioniert

Viele „XAI“-Ansätze sind für Paper gut, aber für den Schichtführer nutzlos. Was in der Praxis zählt: erklärbare Evidenz entlang der Entscheidungskette und Erklärungen, die den mentalen Modellen der Nutzer entsprechen.

Anwendungsorientierte Muster:

  • Tabular/Timeseries (z. B. vorausschauende Wartung)
  • Lokale Feature-Attributionen pro Entscheidung (Top-3 Einflussgrößen mit Richtungen), aber kalibriert gegen plausible Wertebereiche. Ein reiner Balkenchart „Feature X: 0.73“ hilft nicht. Ergänzen Sie Standardbereiche („normal“, „kritisch“), damit Operatoren Abweichungen erkennen.
  • Kontrastive Erklärung: „Warum NICHT Zustand OK?“ – zeigen Sie die minimalen Featureänderungen, die die Entscheidung kippen würden.
  • Computer Vision (z. B. Oberflächenfehler)
  • Pixelhitze allein erzeugt Misstrauen. Nutzen Sie:
  • Segment-Overlays mit Defektklassen und lokaler Konfidenz
  • Region-of-Interest-Historie: Wurde eine ähnliche Stelle in den letzten N Chargen auffällig?
  • Gegenbeispiele aus der Datenbank: „3 visuell ähnliche Fälle – 2x echter Defekt, 1x Fehlalarm“
  • Wichtig: Erkennbar machen, was das System NICHT gesehen hat (abgedeckte Bereiche, Bewegungsunschärfe).
  • Retrieval-gestützte LLMs (RAG) im Betrieb
  • Erklären Sie nicht die Token-Logik. Erklären Sie die Quelle:
  • Welche Dokumente wurden herangezogen (Versionsstand, Prüfsumme)?
  • Welche Tool-Aufrufe wurden durchgeführt (z. B. „ERP.SearchWorkOrder“, Parameter, Erfolg/Fehlschlag)?
  • Welche Guardrails griffen ein (Redaktion, Policy-Hinweise)?
  • Benutzer wollen „Woraus schließt du das?“ statt „Wie kam dein Decoder zur nächsten Silbe?“. Zeigen Sie Zitate auf Absatzebene und markieren Sie die Deckung zwischen Antwort und Quelle.
  • UI-Patterns, die Vertrauen aufbauen
  • Unsicherheits-Badge mit kurzer, normierter Semantik („hoch“, „mittel“, „niedrig“, verbunden mit SOP).
  • Evidence Panel: Gulliver-Ansicht der genutzten Daten und Tools, inklusive Datenstand und Vertraulichkeitsstufe.
  • Why/Why-not-Toggle: Switch zwischen stützenden Evidenzen und minimalen Gegenannahmen.
  • Feedback als strukturierter Prozess: „Akzeptiert/Abgelehnt“ mit Grundcodes statt Freitext – direkt verwertbar für Re-Training und Schwellenkalibrierung.

3) LLM-Agenten: Observability und Kontrolle statt Bauchgefühl

Sobald LLMs Tools aufrufen (Agenten), verlagert sich das Risiko vom Modell zur Orchestrierung. Ohne Observability über Kette und Kontext steuern Sie im Blindflug.

Architektur-Bausteine, die wir in der Praxis etabliert haben:

  • Instrumentierungsbus
  • Jeder Schritt (Prompt, Toolaufruf, Ergebnis, Entscheidung) emittiert strukturierte Events mit Korrelation-ID. Kein Telemetrieversand in Fremd-Clouds, sondern on-prem Log-Pipeline (z. B. gRPC/HTTP, append-only Speicher).
  • Policy-Engine „im Pfad“
  • Policies-as-Code (z. B. OPA/Rego) bewerten vor jeder Toolausführung:
  • Dürfen diese Parameter an dieses Tool?
  • Ist das Budget (Tokens/Calls) noch im Limit?
  • Greifen Data-Loss-Prevention-Regeln (PII, Geheimhaltungsstufen)?
  • Entscheidet die Policy negativ, wird der Call verworfen oder in den Review-Queue gestellt.