Titel: UX für industrielle KI: Wenn Interfaces über Sicherheit entscheiden

Ein Bediener, der in einer Leitwarte 18 Bildschirme überblickt, hat kein Interesse an „delightful experiences“. Er braucht in 30 Sekunden eine richtige Entscheidung – unter Lärm, mit Handschuhen, bei wechselndem Licht und mit Datenströmen, die nie pausieren. In solchen Umgebungen ist UX nicht Kosmetik. UX ist ein sicherheitskritischer Bestandteil des Systems.

Dieser Text richtet sich an technische Entscheider und führt durch konkrete Architektur- und Designmuster, mit denen KI-gestützte Interfaces in der Industrie robust, souverän und auditierbar funktionieren. Leitfrage: Wie gestaltet man Interaktionen so, dass Menschen den Überblick behalten, KI vertrauenswürdig unterstützen kann und das Gesamtsystem auch ohne Cloud erreichbar bleibt?

1) Architektur-Realitäten zuerst: UX hängt am Datenpfad

Gutes Interaktionsdesign entsteht nicht im Figma-File, sondern entlang des Datenpfads. Die wichtigsten technischen Randbedingungen:

  • Edge-dominanter Datenfluss: Sensoren und Aktoren sprechen typischerweise OPC UA, Modbus oder MQTT. Ereignisraten liegen von ein paar Hz bis in den kHz-Bereich (Vibrationen, Bildverarbeitung). Für die UI sind drei Pfade relevant:
  • Hot Path: Streaming-Ereignisse für Alarme, Zustandswechsel, Taktzeiten. Transport via WebSockets/SSE, Latenz sub-sekundär.
  • Warm Path: Aggregierte KPIs und Trends (1–60 s Intervalle) aus einer Timeseries-DB.
  • Cold Path: Historik, Dokumente, Wartungsanleitungen, Logs für Ursachenanalyse oder KI-Retrieval.
  • On-Premise als UX-Anforderung: Air-Gaps, eingeschränkte WAN-Verbindungen und DSGVO-Vorgaben bedeuten: UI muss ohne US-Cloud funktionieren, mit lokaler Authentifizierung/Autorisierung, lokaler Inferenz und lokalen Speichern. „Souveränität ermöglicht Intelligenz“ heißt hier: erst Datenhoheit, dann smarte Funktion.
  • Ressourcenknappheit: Bedienterminals sind oft ältere Panel-PCs mit begrenzter GPU/CPU und resistiven Touchscreens. Rechne mit geringer Browserleistung und setze Rendering-Budgets (weniger Repaints, virtuallisierte Listen, begrenzte Animationsdauer).
  • Inkonsistente Zeit: Sensoren sind nicht perfekt synchron. UI-Interaktionen, die Korrelation zeigen (z. B. Temperatur gegen Vibration), müssen mit Zeitunschärfe umgehen und die Synchronitätsqualität anzeigen.

Konsequenz fürs UI: Architektonisch trennen, was „jetzt handeln“ erfordert (Hot Path) von „besser verstehen“ (Warm/Cold). Die Hot-Path-UI muss bei Netzaussetzern lokal funktionsfähig bleiben und sich deterministisch verhalten. Die Cold-Path-UI darf langsamer, aber reichhaltiger sein.

2) UX für KI-gestützte Entscheidungssysteme

KI darf die Bediener nicht entmündigen – sie muss ihre OODA-Schleife (Observe–Orient–Decide–Act) beschleunigen. Das gelingt nur, wenn folgende Prinzipien erfüllt sind:

  • Klarer Automationsgrad: Jedes KI-Feature läuft in einem expliziten Modus:
  • Empfehlen: KI schlägt eine Maßnahme vor, der Mensch entscheidet.
  • Genehmigen: KI führt vor, Mensch gibt frei (Two-Step).
  • Autonom mit Sicherungen: KI agiert in engen Grenzen, UI zeigt kontinuierlich Telemetrie, Sperr- und Not-Aus-Pfade.

Moduswechsel sind prominent sichtbar, protokolliert und rollenabhängig freigegeben.

  • Begründungen und Unsicherheit: Ein „Mach Ventil V23 zu“ ohne Belege ist unbenutzbar. Notwendig:
  • Welche Sensorwerte, Regeln oder Bilder führten zur Empfehlung?
  • Wie hoch ist die Unsicherheit? Eindeutig visualisiert (z. B. Balken statt Prozent mit zwei Stufen: sicher/unsicher) – keine vagen Formulierungen.
  • Welche Alternativen wurden verworfen („Why-not“)? Kurz und scanbar.
  • Kontextverankerung: KI-Ausgaben sind an die Zeitachse, die Anlage und die Quelle gebunden. Ein Klick auf die Empfehlung springt in die korrelierte Zeitspanne und blendenrelevante Trends ein. Ohne harte Kontextverlinkung entsteht „KI sagt“-Theater.
  • Menschenlesbare Playbooks: Jede KI-Aktion verweist auf ein hinterlegtes, kurzes Playbook: Schritt 1–3, Sicherheitscheck, Rückfall bei Fehlschlag. Playbooks sind versioniert, lokal verfügbar und offline lesbar.
  • Beobachtbarkeit der KI: Für LLM- oder Agenten-basierte Funktionen brauchen Operatoren und Eigentümer Einblick:
  • Welche Tools wurden mit welchen Parametern aufgerufen?
  • Welche Wissensquellen (Dokumente, Protokolle) flossen ein?
  • Latenzen, Fehlversuche, Abbrüche. Im Zweifel will die Schichtleitung den gesamten Entscheidungsweg „abspulen“ können.

Genau hier setzen wir mit Alpi-M an: Agenten-Observability und Governance on-prem, inklusive Prompt-/Tool-Call-Transparenz, Richtlinien, Freigabeflüssen und Audit-Trails – ohne Abfluss in US-Clouds.

Designmuster im UI:

  • Sidecar-Erklärungen: Rechts eine schmale Spalte mit erklärbarer KI: Input-Snippets, eingesetzte Regeln/Funktionen, Konfidenzstufe, Links zu Quellen. Ein-/ausblendbar, aber standardmäßig sichtbar im Lernenbetrieb, dezent im Routinebetrieb.

  • Entscheidungs-Panel: Kompakter Dialog mit drei Buttons: „Aktion ausführen“, „Aktion mit Modifikation“ (Parameterfeld), „Ablehnen mit Grund“. Pflichtfeld für Ablehnung erzeugt wertvolle Trainingsdaten – on-prem gespeichert, später zum Feintuning.

  • Schattenmodus: Neue KI läuft zuerst „schattig“ mit, erzeugt Empfehlungen, die nicht ausgeführt werden. UI zeigt Phantom-Labels („KI hätte X getan“), und verlinkt zur Begründung. Erst nach messbar niedriger Fehl-Interventionsrate folgt ein Freigabeschritt.

3) Dashboard-Design für industrielle IoT-Daten

Die meisten Dashboards scheitern nicht am Chart-Typ, sondern am fehlenden „So what?“. Für operative Leitstände gilt: