Souveräne Mensch-KI-Interaktion in der Industrie: Wie wir Vertrauen, Kontrolle und Verantwortung konkret bauen

Die härteste Hürde für KI in industriellen Systemen ist nicht die nächste Modell-Architektur, sondern die Interaktion mit dem Menschen, der am Ende die Konsequenzen trägt. In Sicherheits- und Qualitätskritik liegt der Maßstab nicht in Benchmarks, sondern in Nachvollziehbarkeit, steuerbarer Autonomie und klarer Verantwortlichkeit. Genau dort entscheidet sich, ob KI im Betrieb wirklich wirkt oder in Pilotinseln steckenbleibt.

In diesem Beitrag geht es nicht um allgemeine KI-Versprechen. Es geht um die konkrete technische Gestaltung: Wann muss der Mensch entscheiden? Welche Architektur macht Explainability für Bediener wirklich brauchbar? Wie beherrschen wir LLM-Agenten mit Observability und Governance? Und wer ist verantwortlich, wenn die KI falsch liegt? Wir beschreiben Muster, Trade-offs und Referenzarchitekturen – on-premise, DSGVO-konform, ohne US-Cloud-Abhängigkeit.

1) Wann der Mensch entscheiden muss: Von Kostenprofilen zu Autonomie-Gating

Die zentrale Engineering-Frage ist nicht, ob der Algorithmus gut ist, sondern wie hoch die Kosten des Fehlers versus die Kosten der Verzögerung sind. Daraus leiten wir ab, wo der Mensch zwingend in der Schleife bleibt.

Ein einfaches, robustes Raster:

  • Kosten des Fehlers (hoch/mittel/niedrig): Sicherheitsrelevant? Regulatorisch sanktionierbar? Irreversibel?

  • Kosten der Verzögerung (hoch/mittel/niedrig): Prozessstillstand? Kunde wartet? Echtzeitsteuerung?

  • Beobachtbarkeit der Entscheidung: Können wir nachträglich prüfen, warum die Entscheidung getroffen wurde und ob sie richtig war?

  • Umkehrbarkeit: Ist eine Entscheidung reversibel oder erzeugt sie Folgewirkungen?

Aus diesem Raster ergibt sich eine Gating-Policy für Autonomiegrade:

  • Stufe 0 – Nur Empfehlung: KI liefert Vorschlag und Evidenz, Mensch entscheidet immer. Anwendbar bei hoher Fehlerkosten, geringer Verzögerungskosten.

  • Stufe 1 – Vorschlag mit Soft-Gate: KI setzt Entscheidung um, wenn Evidenzkriterien erfüllt sind (z. B. Konfidenzband, Konsistenzchecks, Regel-Compliance); sonst eskaliert an den Menschen.

  • Stufe 2 – Teilautonomie: KI entscheidet in definierten, reversiblen Subschritten; Mensch kontrolliert Meilensteine.

  • Stufe 3 – Autonomie mit rückwirkender Auditierung: KI arbeitet selbstständig, aber jede Aktion ist nachvollziehbar, revertierbar und wird stichprobenartig geprüft.

Wichtig ist: Diese Stufen sind nicht statisch. Sie werden pro Use Case und sogar pro Datenregion dynamisch entschieden – anhand von Betriebsdaten (z. B. Eskalationsraten) und Prozessrisiken. Ein konservativer Start in Stufe 0/1 und schrittweises Hochfahren ist in industriellen Umgebungen der Standard, wenn Souveränität und SLA-Sicherheit gefordert sind.

2) Architektur-Patterns für Human-in-the-Loop

Human-in-the-Loop ist kein UI-Dialog, sondern ein Systemkonzept. Die folgenden Muster begegnen uns wiederkehrend in Fertigung, Bahn, Defense, Bauvermessung und Instandhaltung:

  • Synchronous Confirm Pattern
  • Echtzeitvorschlag mit kurzer Bestätigungszeit (z. B. 2–5 Sekunden).
  • Erfordert latenzoptimierte On-Prem-Inferenz, Edge-Nähe und UI-Reduktion auf Entscheidungsfaktoren.
  • Fallback: Zeitüberschreitung führt zu sicherem Default (z. B. Prozess stoppen oder konservative Parameter).
  • Asynchronous Triage Queue
  • KI sortiert Fälle nach Risikoprofil in Arbeitskörbe für Operatoren.
  • Geeignet für visuelle Inspektion, Dokumentenprüfung, Anomaliebewertung im Condition Monitoring.
  • Wichtig: Strikte Trennung zwischen KI-Bias und Bearbeitungsreihenfolge; regelmäßiges Resampling und Qualitätskontrollen.
  • Two-Operator Rule with AI Assist
  • Bei hohen Fehlerkosten: zwei voneinander unabhängige menschliche Freigaben; KI liefert evidenzbasierte Entscheidungsvorlage.
  • Bei Diskrepanzen: KI generiert Gegenbeispiele oder zusätzliche Evidenz, nicht Druck zur Mehrheit.
  • Safety Wrapper / Policy Guard
  • Jede KI-Aktion passiert durch einen deterministischen Policy Layer (z. B. OPA/Rego-artige Regeln), der harte Constraints erzwingt: Grenzwerte, Whitelists, Freigabemasks.
  • Logging und Signierung im Guard, nicht in der KI-Komponente.
  • Reversible Operations
  • Architektur so auslegen, dass jede KI-Entscheidung zurückgenommen oder kompensiert werden kann (z. B. Soft-Storno in ERP, Quarantäne-Status in MES, Undo-Pipeline im Wissensspeicher).
  • Ohne Reversibilität ist HITL de facto wertlos, weil der Mensch zwar verantwortlich, aber technisch ohnmächtig wäre.
  • Evidence Bus
  • Neben Predictions gibt es einen erstklassigen Datenstrom mit Erklärartefakten: Features, Quellen, Heuristiken, Constraints, Unsicherheiten, alternative Hypothesen.
  • Dieser Bus ist versioniert, signiert und UI-agnostisch, sodass Operatoren, Auditoren und Entwickler dieselbe Evidenzbasis sehen.

3) Explainability, die Bediener wirklich nutzen

Explainability ist kein Plot, sondern ein Arbeitsvertrag zwischen System und Operator. In der Praxis funktionieren drei Bausteine:

  • Evidenzvertrag (Evidence Contract)
  • Jede Empfehlung kommt mit:
  • Eingangsartefakten (Bild, Messkurve, Textpassage) und deren Herkunft.
  • Abgeleiteten Merkmalen (z. B. Segmentflächen, Frequenzbänder, extrahierte Entitäten).
  • Regel- und Constraint-Checks (welche bestanden/nicht bestanden).
  • Unsicherheiten und Alternativen (Top-N Hypothesen) mit Gründen.
  • Vergleichsbeispielen aus der Historie (ähnliche Fälle, Outcome).
  • Der Vertrag ist maschinenlesbar (z. B. JSON) und wird zusammen mit der Entscheidung versioniert gespeichert.
  • Kalibrierung statt kosmetischer Scores
  • Ein Prozentwert ohne Bezug ist sinnlos. Nützlich sind kalibrierte Aussagen, z. B. in welchem Arbeitsbereich das Modell zuverlässig ist und wann es in den Out-of-Distribution-Modus schaltet.
  • UI-Muster: Ampel plus Begründungsbausteine („Warum Gelb?“), nicht nur ein Score.
  • Gegenfaktische und Exemplar-Erklärungen
  • „Welche minimale Änderung hätte das Ergebnis gekippt?“ ist für Prozessingenieure oft hilfreicher als globale Feature-Attributionen.
  • Beispiele aus der eigenen Historie sind wertvoller als generische SHAP-Wolken: „5 ähnliche Fälle – 3 mal Ausschuss, 2 mal Nacharbeit – Entscheidung damals: Nacharbeit.“

Pitfalls, die wir regelmäßig ausräumen:

  • Instabile Attributionsmethoden als Entscheidungsbasis. Lösung: Attributionsmethoden als Diagnosewerkzeug für Entwickler, nicht als Freigabekriterium für Operatoren.

  • Evidenz-Overload. Lösung: progressive Offenlegung. Erste Ebene: Kerngründe; zweite Ebene: Detailprovenienz; dritte Ebene: Rohdaten.

  • Verwechslung von Nachvollziehbarkeit und Rechtssicherheit. Lösung: Digitale Signaturen und vollständige Audit-Trails sind Teil der Governance, nicht der ML-Pipeline.

4) LLM-Agenten unter Kontrolle: Observability und Governance als Pflicht, nicht Kür