Titel: Mensch bleibt Entscheider: Wie wir industrielle KI so bauen, dass Operateur, Auditor und Governance ihr wirklich trauen

Es gibt zwei Arten von KI-Fehlern, die in der Industrie weh tun: der stille Fehler, den niemand merkt, und der laute Fehler, dem niemand traut. Beides ist Ergebnis derselben Ursache: Wir integrieren KI in Abläufe, ohne die menschliche Entscheidung als First-Class-Bürger mitzudenken. In sicherheitskritischen oder hochregulierten Umgebungen ist das nicht „nur“ ein UX-Problem – es ist ein Systemarchitektur-Problem.

Dieser Artikel ist eine Bauanleitung aus der Praxis: Wann muss der Mensch entscheiden? Welche Erklärungen braucht er wirklich? Wie behalten wir LLM-Agenten unter Kontrolle, ohne US-Cloud-Abhängigkeit? Und wer ist verantwortlich, wenn das System daneben liegt? Alles mit einem klaren Fokus: Daten- und Betriebssouveränität als Voraussetzung für Vertrauen.

1) Human-in-the-Loop: Wann der Mensch entscheiden muss

Die wichtigste Designentscheidung kommt vor jedem Modell: Wo im Prozess entscheidet die Maschine, wo der Mensch, und wie sieht die Eskalation aus?

Es gibt in der Praxis drei Muster, die funktionieren:

  • Mensch als Freigabeinstanz (Approval-in-the-Loop):

Die KI schlägt vor, der Mensch gibt frei. Typisch bei sicherheitsrelevanten Eingriffen (z. B. „Zug aus dem Betrieb nehmen“, „Bauteil als Ausschuss markieren“).

  • Mensch als Ausnahme-Manager (Exception-in-the-Loop):

Die KI arbeitet autonom, aber eskaliert Unsicherheit, Neuartigkeit oder Regelkonflikte. Typisch bei Qualitätssicherung oder Flottenüberwachung.

  • Mensch als Trainingsrichter (Feedback-in-the-Loop):

Der Mensch korrigiert Bewertungen systematisch; Korrekturen fließen in Datenqualität und Modellverbesserung ein. Typisch in frühen Einführungsphasen und bei driftanfälligen Prozessen.

Damit das nicht zu einem Bauchgefühl-System verkommt, braucht es eine formalisierte Entscheidungslogik. Die ist immer eine Funktion aus drei Größen:

  • Unsicherheit: Wie sicher ist das Modell in genau diesem Fall?
  • Neuartigkeit: Liegt die Eingabe innerhalb des bekannten Datenraums?
  • Auswirkungsrisiko: Was passiert, wenn die Empfehlung falsch ist?

Eine robuste Richtlinie sieht so aus:

  • Low Impact + hohe Sicherheit + bekannte Verteilung → autonom entscheiden.
  • Medium Impact ODER mittlere Sicherheit ODER potenziell neuartig → Ausnahme-Queue, Entscheidung durch Operateur mit Erklärungspaket.
  • High Impact ODER niedrige Sicherheit ODER out-of-distribution → verpflichtende menschliche Freigabe (Zwei-Augen-Prinzip, ggf. Vier-Augen).

Wichtig: „Unsicherheit“ ist kein Buzzword, sondern ein auslieferungsreifes Artefakt. Wenn Ihr System Unsicherheit nicht ausgibt und kalibriert, ist es kaputt – es kennt seine Grenzen nicht. In der Praxis setzen wir auf:

  • Kalibrierung der Scores (z. B. temperaturbasierte Nachkalibrierung, klassifikatorspezifische Platt-ähnliche Verfahren).
  • Mehrfachschätzungen (Ensembles) zur Streuung.
  • Out-of-Distribution-Checks anhand von Merkmalsembeddings und Dichteabschätzungen.
  • Regelbasierte Vorfilter für bekannte Sonderfälle.

Diese Werte gehen nicht „irgendwo in die UI“, sondern steuern die Workflow-Engine. Ein einfacher Pseudocode für eine Edge-Station:

  • if impact == high then require human approval
  • else if uncertainty > θ1 then route to exception queue
  • else if ood_score > θ2 then route to exception queue
  • else auto-accept

θ1/θ2 werden pro Linie und Schicht dynamisch angepasst – auf Grundlage realer Fehlersichtungen und Rückmeldungen. Das ist Engineering, kein Bauchgefühl.

2) Erklärbarkeit, die ein Operateur wirklich nutzt

„Erklärbarkeit“ ist kein Regulatorik-Häkchen, sondern ein Werkzeugkasten, der drei Fragen des Bedieners beantwortet:

  • Wieso behauptet die KI X?
  • Was passiert, wenn ich Y tue?
  • Was ist die Unsicherheit und woher kommt sie?

Industrial-spezifische Muster:

Computer Vision (Qualitätsprüfung, Montagekontrolle)

  • Evidenz statt Esoterik: Zeigen Sie segmentierte Defekt-Overlays mit Konturen, Ausmaßen und Lagebezug zum Bauteil. Keine abstrakten „Heatmaps“, die nur Datenwissenschaftler deuten können.

  • Kontrastpaare: Nächste-Nachbarn aus der Trainingsdatenbank anzeigen – „So sah ein akzeptierter/abgelehnter Defekt in der Vergangenheit aus“. Ähnlichkeitsscore inklusive.

  • Kontextmerkmale: Belichtung, Kamera-ID, Brennweite, Temperaturbereich. Operateure kennen ihre Linie – geben Sie ihnen die Umweltparameter.

Zeitreihen und tabellarische Sensorik (Predictive Maintenance, Anomalieerkennung)

  • Beitragswerte pro Merkmal und Zeitfenster: Welche Sensorkanäle trugen wie stark zur Entscheidung bei? Nur in Aggregation anzeigen, nicht jedes Sample – sonst Overload.

  • Kontrafaktische Vorschläge: „Wenn Schwingung im Band 2 um 15% niedriger, wäre Empfehlung nicht ausgelöst.“ Das ist operativ wertvoller als jede abstrakte Attribution.

LLMs in Bedienerassistenz und Dokumentenflüssen

  • Quellenbelege verpflichtend: Jeder Satz muss auf verlinkte Dokument-Passagen oder Werkstandards referenzieren. „Keine Quelle = keine Aussage.“

  • Tool-Trace: Welche Tools und Daten wurden angefragt, mit welchen Parametern, in welcher Reihenfolge?

Das „Erklärungspaket“ als UI-Artefakt enthält immer:

  • Eingabe-Summary (reduziert, anonymisiert wo nötig).

  • Modellversion, Datenversion, Pipeline-Hash.

  • Kalibrierter Konfidenzwert, OOD-Score.

  • Evidenz (Overlays, Quellenzitate, Nearest Neighbors).

  • Begründung in Domänensprache, nicht in Modelljargon.

  • Handlungsoptionen mit erwarteter Auswirkung und Risiko.

Diese Pakete sind serialisierbar (z. B. JSON mit Schemas) und werden revisionssicher gespeichert. Ohne standardisiertes Format bekommen Sie keine prüffähige Nachvollziehbarkeit.

3) Observability und Kontrolle für LLM-Agenten – ohne Cloud-Abhängigkeit

LLM-Agenten sind keine „schlauen Chatbots“, sondern ausführende Systeme mit Werkzugriff (RAG, ERP-Connectoren, Ticketanlagen). Jeder Aufruf ist potenziell eine Änderung am Systemzustand. Was Sie brauchen, ist dasselbe, was gute Backend-Teams seit Jahren bauen: Telemetrie, Policy, Reproduzierbarkeit.

Technische Mindestanforderungen an LLM-Agent-Observability:

  • Vollständige Traces:
  • Prompt-Kette inkl. System-/Entwickler-/Benutzerkontext.
  • Retrieval-Artefakte: Welche Dokumente/Abschnitte wurden herangezogen?
  • Tool-Invocations: Name, Parameter, Response, Latenz, Fehler.
  • Versionierung: Modell-ID, Tokenizer, Prompt-Template-Version, Tool-Schema-Version.
  • Deterministische Replays:
  • Fixierte Seeds/Tempi/Top-p pro Ausführungsklasse.
  • Snapshots der Wissensbasis (Dokumentindex, Vektoren).
  • Offline-Replays in isolierten Staging-Umgebungen.
  • Policy-Enforcement:
  • Zulässige Tools per Rolle/Use-Case whitelisten.
  • Strikte JSON-Schemata für Tool-Parameter.
  • Budget- und Frequenzlimits pro Session und Benutzerrolle.