Souveräne Mensch-KI-Interaktion in der Industrie: Architektur, Metriken und Governance für Systeme, denen Bediener wirklich vertrauen

Das eigentliche Problem ist nicht „KI einführen“, sondern „KI so einführen, dass der Bediener ihr in kritischen Momenten vertraut — und sie trotzdem kontrolliert“. In jeder Branche, in der wir industrielle KI-Systeme gebaut haben, taucht derselbe Bruch auf: Die Modelle sind beeindruckend, aber der Mensch steht allein mit der Frage „Kann ich dieser Empfehlung folgen, ohne mich oder das System zu gefährden?“. Wenn diese Frage nicht vorab technisch beantwortet wird, endet KI-Nutzung im besten Fall als „PowerPoint-Erfolg“ und im Alltag deaktiviert.

Dieser Beitrag zeigt, wie wir Mensch-KI-Interaktion für industrielle Umgebungen konstruieren: mit Human-in-the-Loop-Gates, erklärbaren Entscheidungen, Observability für LLM-Agenten, robusten QA-Prozessen und Governance, die in on-premise, DSGVO-konforme Architekturen passt — ohne US-Cloud-Abhängigkeiten. Die Perspektive ist bewusst technisch: konkrete Muster, Artefakte, Schnittstellen und Metriken, die in Produktion tragfähig sind.

1) Wann der Mensch entscheiden muss: Risikobasierte HITL-Gates statt generische „Freigabe-Buttons“

Nicht jede KI-Interaktion braucht denselben Grad menschlicher Kontrolle. Das Muster, das zuverlässig skaliert, ist eine klare Risiko-Typisierung mit korrespondierenden Eingriffspunkten:

  • Advisory (niedriges Risiko, reversible Folgen): KI liefert Einstufungen, Cluster, Priorisierungen. Beispiele: Ranking von Wartungsjobs, Verdachtslisten. Der Mensch entscheidet, aber das System darf Workflows vorstrukturieren. Gating: Soft Gate (keine Explizit-Freigabe nötig), jedoch nachvollziehbare Begründung und einfache Korrekturmöglichkeit.
  • Constrained Action (mittleres Risiko, begrenzte Folgen): KI führt Handlungen aus, aber nur innerhalb enger Parameter. Beispiele: Erstellen eines Wartungstickets bis Betrag X, Vorschlag einer Disposition im erlaubten Fenster. Gating: Parameter-Policy + optionales Freigabefenster (Just-in-Time Approval). Rückrollbar.
  • Irreversible/High-Impact (hohes Risiko): Alles, was Sicherheit, Compliance, Fertigungslinien oder Kundenbeziehungen substantiell berührt. Beispiele: Deaktivierung einer Maschine, Versand eines rechtlich bindenden Schreibens, Änderung an Flottenfahrplänen. Gating: Harte menschliche Freigabe durch Rollen mit Verantwortung (Vier-Augen-Prinzip), inklusive geplanter Eskalationspfade.

Dieses Muster erzwingt eine Architekturentscheidung: Nicht das Modell (CV, LLM, Time Series) bestimmt die Kontrolle, sondern der Risiko-Context der Aktion. Deshalb trennen wir strikt „Inference“ (Vorhersage/Empfehlung) und „Execution“ (Handeln im Zielsystem). Dazwischen liegt eine Policy Engine, die sowohl die Inferenzmetadaten (Unsicherheit, Begründung, Datenherkunft) als auch die Prozessrisiken kennt.

2) Erklärbarkeit, die in der Praxis genügt: Drei Ebenen, ein Prinzip

Eine UI-Schaltfläche „Explain“ bringt wenig, wenn die Erklärung nicht zur Aufgabe passt. In industriellen Setups setzen wir drei Ebenen durch:

  • Global/Modell-Ebene (für Ingenieure): Architekturentscheidungen, Trainingsdatenräume, bekannte Grenzen. Artefakte: Modellkarte, Datenherkunft (Lineage), Trainingsprotokolle, Benchmarks. Diese Ebene dient primär QA, Audit und Weiterbildung der Betreiber — weniger der Laufzeitnutzung.
  • Fall-/Decision-Ebene (für Bediener): Warum diese konkrete Empfehlung? Beispiele:
  • Computer Vision: Heatmaps/Saliency auf Bildausschnitten, die zum Befund geführt haben; Schwellenwerte; Vergleich mit „Near-Miss“-Beispielen.
  • RAG/LLM-Agenten: Zitationsliste der verwendeten Quellen mit Passage-Snippets und semantischem Score; Werkzeugverlauf (welche Tools wurden in welcher Reihenfolge mit welchen Parametern aufgerufen); Confidenz und Abbruchgründe.
  • Zeitreihen/Anomalie: Welche Sensoren tragen wie stark zum Score bei; wie verhält sich der aktuelle Verlauf gegenüber historischen Normal-Profilen; Konfidenzintervall und Drift-Indikatoren.
  • Prozess-/Policy-Ebene (für Verantwortliche): Welche Regeln/Policies haben die Entscheidung begrenzt oder getriggert? Beispiele: „Auto-Execute deaktiviert wegen unsicherer Quelle“, „Betragslimit überschritten — menschliche Freigabe erforderlich“, „Letztes Kalibrierungsdatum abgelaufen“.

Ein verbindendes Prinzip: Erklärung muss handlungsleitend sein, nicht nur rechtfertigend. Gute Erklärung beantwortet: „Was soll ich als Nächstes tun, und welches Risiko bleibt?“. Das spiegelt sich im UI: Erklärungen mit konkreter Option „abweisen/akzeptieren/eskalieren“ und einem sichtbaren Risikoindikator.

3) Observability und Kontrolle für LLM-Agenten: Von der Thought-Action-Spur zur Auditierbarkeit

LLM-Agenten erhöhen Produktivität — aber nur, wenn ihre Schritte transparent sind und kontrolliert werden können. Observability ist hier nicht „Logs sammeln“, sondern eine strukturierte Temporalisierung von Agentenhandlungen. Ein tragfähiges Agent Observability-Modell umfasst:

  • Einheitliches Event-Schema je Agenten-Schritt:
  • agent_step_id, parent_trace_id
  • prompt_template_id (signiert), user_context_hash (PII-frei)
  • tool_name, tool_version, tool_schema_hash
  • input_args_redacted/raw_pointer (on-prem verschlüsselt)
  • model_name, temperature/top_p, system_prompt_hash
  • output_summary (Trunkierung), output_hash
  • latenz_ms, token_in/out, kosten_budget
  • risk_score (Policy Engine), policy_decision (allow/hold/deny)
  • approval_actor_id (falls human-in-the-loop)
  • side_effects: Liste geplanter/erfolgter Änderungen im Zielsystem (mit Semantic Diff)
  • Semantic Diff für Side-Effects:
  • Statt nur „Tool X aufgerufen“ braucht es eine domänenspezifische Darstellung der beabsichtigten Systemänderung. Beispiele: „Fahrplan-Verschiebung: Zug 4711 → +12 Min, Auswirkungen: 3 Anschlüsse; Pufferverbrauch 40% → 62%“ oder „Wartungsauftrag: Anlage Z34 → Inspektion Typ B, Materialliste: …, geplante Downtime: 45 Min“.
  • Diese Diffs speisen die Freigabeentscheidung und sind auditierbar.
  • Policy Engine als formale Schranke:
  • Konfigurierbar pro Risiko-Klasse: maximale Aktionsumfänge, erlaubte Tools, Zeitschranken, Kostenbudget, Sensitivitätsstufen.
  • Statische Validierung: Tool-Args gegen JSON-Schema; Black-/Whitelist von Feldern.
  • Dynamische Validierung: Cross-Checks gegen Datendienste (z. B. „Kunde ist gesperrt“ → Aktion blockieren).
  • Replay und deterministische Reproduktion:
  • Signierte Prompt-Templates, Versionierung aller Tools und Policies, Snapshot der Wissensbasis (RAG-Index mit Commit-ID).
  • Damit lässt sich eine strittige Agentenhandlung unter identischen Bedingungen reproduzieren — zentral für Audits und Ursachenanalyse.