Souveräne Mensch-KI-Interaktion in der Industrie: Wann der Mensch entscheiden muss, wie wir Erklärungen nutzbar machen – und wie wir LLM-Agenten wirklich kontrollieren

Die beste KI ist wertlos, wenn der Bediener ihrer Empfehlung nicht vertraut. In Industrieumgebungen entscheidet Vertrauen aber nicht allein über Akzeptanz, sondern über Sicherheit, Haftung und letztlich über Betriebszeit und Qualität. Wer eine visuelle Prüfzelle, eine Flottenintelligenz oder einen LLM-Agenten in bestehende Betriebsprozesse integrieren will, muss eine einfache Wahrheit akzeptieren: Ohne klare Verantwortlichkeiten, beobachtbares Verhalten und erklärbare Entscheidungsgrundlagen wird jedes Modell zum Risiko.

Dieser Beitrag beschreibt aus Praxisperspektive, wie man

  • Human-in-the-Loop so auslegt, dass Menschen an den richtigen Stellen entscheiden,

  • Erklärungen baut, die in der Leitwarte oder an der Linie tatsächlich Entscheidungssicherheit geben,

  • LLM-Agenten beobachtet, steuert und in der Haftung beherrscht,

  • und warum On-Prem-Architekturen in sensiblen Industrien der einzige gangbare Weg sind, wenn Souveränität nicht verhandelbar ist.

1) Human-in-the-Loop: Nicht „immer” oder „nie“, sondern risikobasiert

Human-in-the-Loop (HITL) ist kein Feature, sondern ein Governance-Konzept. Es beantwortet drei Fragen:

  • Welche Entscheidungen darf die Maschine alleine treffen?

  • In welchen Fällen muss ein Mensch entscheiden oder freigeben?

  • Wie stellen wir sicher, dass beides innerhalb der operativen Randbedingungen (Latenz, Shift-Besetzung, Eskalationswege) funktioniert?

Die technische Auslegung beginnt mit einer Risikoklassifikation. Drei Achsen haben sich bewährt:

  • Kosten des Fehlers: Welche Konsequenzen hat ein False Positive/False Negative? Qualitätsausschuss, Anlagenstillstand, Sicherheitsrisiko, Vertragsstrafe?

  • Reversibilität: Kann ich den Effekt der Entscheidung schnell und vollständig rückgängig machen?

  • Erklärbarkeit/Beweisbarkeit: Kann ich im Nachgang nachweisen, warum entschieden wurde und ob die Entscheidung im Rahmen der festgelegten Regeln lag?

Aus dieser Einordnung ergeben sich Steuerungsmuster:

  • Vollautomatisiert: Für reversible, kostengünstige Fehlentscheidungen (z. B. Sortieren von leichter Nacharbeit) wird die Maschine autorisiert. Mensch überwacht nur KPIs.
  • Gatekeeper (Approval): Für irreversible oder sicherheitsnahe Maßnahmen (z. B. Abschaltung eines Aggregats) gilt: Die KI erstellt eine Empfehlung mit Evidenzpaket; ein berechtigter Operator gibt frei. Zwei-Personen-Regel, wenn Sicherheitskritikalität hoch ist.
  • Triage/Deferral: Für uneindeutige Fälle oder wenn die Konfidenz unter einen dynamischen Schwellwert fällt: Ticket in Mensch-Queue, inklusive komprimierter Evidenz und Standardvorschlag.
  • Abstention als Feature: Modelle müssen „weiß nicht” sagen dürfen. Ein erzwungenes Binärurteil erzeugt künstliche Sicherheit. Operativ heißt das: definierte Fallback-Prozesse ohne Schuldzuweisung an „Modell unsicher”.
  • Progressive Automatisierung: Start mit Shadow/Recommendation-Only, dann Assisted Execution, erst danach Autonomie – je KPI-Reife und Safety Case.

Wichtig: Konfidenz alleine taugt nicht als Gate-Kriterium. Nutzt pro Domäne robuste Surrogate:

  • Visuelle Inspektion: Abdeckungsmetriken (z. B. Anteil geprüfter Zonen), Konsistenz über Test-Time-Augmentation, Übereinstimmung zwischen unabhängigen Detektoren.

  • Anomalie/Zeitsignal: Stabilität der Residuen, Drift-Indikatoren, Übereinstimmung zwischen Sensoren.

  • LLM-Agenten: Tool-Erfolgsquote, Deckung von Antworten durch tatsächlich zitierte/geladene Dokumente, Anzahl Policy-Deferals.

Diese Surrogate sind manipulationsresistenter als reine Softmax-Wahrscheinlichkeiten und lassen sich auditierbar protokollieren.

2) Erklärbarkeit, die an der Linie nutzbar ist

Post-hoc-Erklärungen sind kein Selbstzweck. In der Praxis zählen Erklärungen, die:

  • konkret belegen, welche Evidenz herangezogen wurde,

  • plausibilisierbar sind (der Bediener kann sie gegen sein Domänenwissen abgleichen),

  • und operational vollständig sind (alle Daten für Freigabe oder Ablehnung in einem Screen).

Was funktioniert zuverlässig in der Industrie:

Für Computer Vision

  • Regionale Evidenz statt bunter Heatmaps: Bounding-Boxen/Masken mit Klassifikation und Konfidenz, Overlay von Referenz- und Ist-Kanten, Differenzbilder für Bauteil-Lage.

  • Gegenbeweise: Zeigen, welche relevanten Regionen explizit als „in Ordnung“ geprüft wurden (Abdeckung statt nur Fundstellen).

  • Konsistenzprüfungen: Ergebnisstabilität über mehrere Beleuchtungs-/Augmentationsvarianten; divergierende Outcomes markieren.

Für Zeitreihen/Tabular

  • Feature-Attributions als Verlauf: Beitrag einzelner Sensorkanäle über das Zeitfenster; Peaks korrelierbar mit Prozessereignissen.

  • Regel-Overlays: Zusätzlich zu ML-Scores laufen monotone, nachvollziehbare Regeln (z. B. Grenzwerte, Rate-of-Change), die begründete Warnungen liefern.

Für LLM/Agents

  • Quellen statt Meinungen: Jede Antwort enthält die tatsächlich verwendeten Dokument-IDs/Passagen; fehlende Deckung führt zu Deferral.

  • Tooltrace statt Chain-of-Thought: Zeigt Chronologie der Aktionen, Eingaben/Ausgaben der Tools, ohne interne Prompt-Gedanken freizugeben. Das ist nachvollziehbar und rechtlich sauberer.

  • Constraint-Hinweise: Welche Policy hat eingegriffen (z. B. „External Egress not allowed”, „SafetyCritical -> Approval Required”).

Minimal-Set an Erklärungen in der UI

  • Evidenzliste: Datenquellen, Zeitstempel, Versionen der Modelle/Policies.

  • Sicht auf die „nicht gefundenen“ Gründe: Was wurde geprüft und als unkritisch markiert?

  • Kontextsichere Abweichung: Differenz zu Golden-Reference/Last-Good-State.

  • Begründete Empfehlung: Klarer Vorschlag („Stoppen“, „Weiterlaufen mit Beobachtung X“, „Manuelle Messung durchführen“), mit der kleinsten Menge an Infos, um zu entscheiden.

3) LLM-Agenten: Observability und Kontrolle sind nicht optional

LLM-Agenten führen Aktionen aus, nicht nur Text. Wer sie im Betrieb nicht beobachten kann, verliert Kontrolle über Kosten, Qualität und Haftung. Beobachtbarkeit heißt hier: jede Agentensitzung als gerichteten Graphen aus Prompts, Toolaufrufen, Antworten, Policies, Benutzerinteraktionen und Ergebnissen zu erfassen – in Echtzeit und revisionssicher.

Was instrumentiert werden muss:

  • Prompt- und Tool-I/O: Template-Version, Variablenbindung, Normalisierung, Toolparameter und -Outputs.

  • Kontextzusammenstellung: Welche Dokumente/Chunks wurden geladen? Welche Scores hatten sie? Warum wurden andere ausgeschlossen?

  • Metriken: Latenzen je Schritt, Tokenverbrauch, Tool-Fehlerquoten, Halluzinations-Proxies (z. B. Quellenabdeckung), Ablehnungs-/Eskalationsraten.

  • Policy-Eingriffe: Welche Regel griff? Welche Alternative wurde dadurch erzwungen (z. B. Deferral statt Ausführung)?

  • Benutzerfeedback: Korrekturen, Freigaben, Notizen – mit Rollenbezug.