UX für industrielle KI: Wenn Interfaces sicher entscheiden helfen müssen

Problem, nicht Technologie: In industriellen Systemen trifft der Bediener Entscheidungen unter Zeitdruck, oft mit unvollständigen Daten und hoher Verantwortung. Wenn wir KI-gestützte Vorschläge oder Aktionen in diese Schleife einführen, reicht „hübsch und modern“ nicht. Es geht darum, wie das Interface den Entscheidungsprozess absichert: Wie wird Unsicherheit angezeigt? Welche Informationen sind relevant, welche lenken ab? Wie stellen wir sicher, dass das System auch bei Netzsegmentierung, Latenzspitzen oder Sensorfehlern bedienbar bleibt? Die UI ist hier nicht Marketingoberfläche, sondern Teil der Sicherheitsarchitektur.

Dieser Artikel legt einen praxisnahen, technischen Blick auf UX für:

  • KI-gestützte Entscheidungssysteme (Assistenz, Agenten, Autonomiegrade)

  • Dashboards für industrielle IoT-Daten in Echtzeit

  • Sicherheitskritische Interaktionen mit klaren Fallbacks

  • Accessibility unter rauen Umgebungsbedingungen (Handschuhe, Staub, Sonnenlicht, Lärm)

Wir behandeln Architektur, konkrete Muster und harte Trade-offs. Keine Hypethemen, sondern Dinge, die auf Anlagen, Zügen, Fahrzeugen und in Werken heute laufen – offline-fähig, auditierbar, DSGVO-konform, ohne US-Cloud-Abhängigkeit.

1) Von Operationszwang zu Designzielen

Bevor wir Render-Engines oder Farbschemata diskutieren, müssen die operativen Zwänge ins Lastenheft der UX:

  • Zeitdruck: Es gibt eine Decision Latency Budget (DLB). Beispiel: 5–30 Sekunden für einen Eingriff am Band, Millisekunden bis Sekunden für Alarm-Sichtung mit Eskalationskaskade. Das UI darf die knappen Sekunden nicht mit Navigation, Spinnern oder Bestätigungsorgien verbrennen.
  • Datenqualität und Unsicherheit: Sensor-Drift, fehlende Frames, Rechenlatenzen am Edge. KI liefert Wahrscheinlichkeiten und, in der Realität, auch Fehlklassifikationen. Die UI muss Unsicherheit explizit, kompakt und handlungsleitend zeigen – nicht als wissenschaftliches Poster.
  • Souveränität und Air-Gap: Keine externen Calls zur Laufzeit, Netzwerke segmentiert, Logging/Audit lokal. Das UI darf niemals einen „Cloud-Hänger“ verschleiern. Offline- und Degradationsmodi sind First-Class-Use-Cases.
  • Multi-Modalität der Arbeit: Handschuhe, vibrierende Maschinen, wechselndes Licht. Große Trefferflächen, redundante Codierung (Farbe + Form + Text), robuste Eingaben, klare Hierarchien.
  • Auditierbarkeit: Jede Empfehlung, Aktion und Bestätigung braucht Zeitstempel, Nutzer-ID, Datenprovenienz. Nicht im Kleingedruckten – im Flow zugänglich.

Diese Constraints übersetzen wir in Designziele: hohe Informationsdichte ohne kognitive Überlast, stabile Performance unter Last, explizite Systemzustände, reversible gefährliche Aktionen, Fallbacks ohne Support-Ticket, nachvollziehbare KI-Entscheide.

2) Architektur: Von Sensoren zum Screen, on-prem und echtzeitfähig

Ein UI für industrielle KI ist so gut wie seine Daten- und Reaktionspipeline. Ein typisches on-prem Setup:

  • Ingestion: Feldbus/MQTT/Kafka für Telemetrie, Video/Audio-Streams, Events. Wichtig: Backpressure-Strategie und Priorisierung von „lebenswichtigen“ Topics.
  • Stream Processing: Feature-Extraktion, Voraggregation, Event-Korrelation am Edge. Graceful Degradation: Wenn CPU/GPU knapp wird, fallen Nicht-Kernfeatures zuerst weg.
  • Inferenzdienste: Modelle als Services (z. B. CV, Anomalieerkennung, LLM-Tools). Warm-Kacheln, um Cold-Starts in kritischen Pfaden zu vermeiden. GPU-Scheduling: Inferenz hat Priorität vor visuellen Spielereien.
  • State Cache: Zustands- und Zeitreihen-Cache lokal (RAM + persistentes Log), um UI-Aufrufe deterministisch und schnell zu bedienen.
  • Eventbus zum UI: WebSocket oder gRPC-Streaming, mit Heartbeats und Sequenznummern. Transparente Lückenanzeige im UI bei verpassten Frames.
  • UI-Layer: Web (Canvas/WebGL) oder nativ (z. B. Qt/QML) je nach Härtungsanforderungen. Offline-first, Transaktionslog für Eingaben, die später synchronisieren.

Wesentlich: Das UI bezieht niemals „heimlich“ Daten von außen. Jeder Datenfluss ist in der Oberfläche nachvollziehbar: Quelle, Zeit, Qualität. Das ist nicht nur Governance – es ist UX: Der Bediener versteht, worauf er seine Entscheidung stützt.

3) KI im UI: Unsicherheit, Begründung, Kontrolle

„Confidence 0,87“ ist kein UX. Wir brauchen handlungsfähige Oberflächen:

  • Hypothesenliste statt Einzahl-Urteil: Zeige die Top-2/3 Hypothesen mit kompaktem Kontext (z. B. betroffene Sensoren, Abweichung vom Normalzustand, ähnliche vergangene Fälle). Für Hochdruck: Markiere die wahrscheinlichste Empfehlung deutlich, aber ohne die Alternativen zu verstecken.
  • Unsicherheit als Struktur, nicht nur Zahl: Visualisiere Bandbreiten, Datenlücken, Konflikte zwischen Modellen. Beispiel: „Modell A: 0,82 (Temperatursprung) vs. Modell B: 0,44 (Vibration normal) – Konflikt“. Eine UI, die Konflikte sichtbar macht, verhindert blinde Automatisierung.
  • Begründung über Datenprovenienz: Keine generischen „Erklärungen“. Stattdessen: „Datenbasis: Sensor T3 12:01:10–12:01:40; 5% Ausfall; Threshold-Überschreitung + Anomaliescore 2,1σ“. Links auf Rohsignale/Frames unmittelbar erreichbar.
  • AI-Agenten mit Leitplanken: Wenn Agenten Tools ausführen dürfen, gehört ein Ausführungsprotokoll ins UI: Welche Tools wurden angefragt, welche Policies griffen, was wurde blockiert, welche Daten wurden gelesen/geschrieben. Live und historisch. Das ist Governance und zugleich Debug-UX.
  • Handlungsschablonen: Für jede KI-Empfehlung existieren 2–3 Standardaktionen („Sofort stoppen“, „Temporär drosseln 20%“, „Ignorieren mit Grund“). Default ist die sicherste reversible Option. Aktion erfordert minimalen Interaktionspfad, aber mit klarer Konsequenzanzeige.
  • Vorhersagefenster: Ein kurzer Blick in die „nächsten 60 Sekunden“ mit Konfidenzband statt nur Ist-Zustand. Das hilft, Eingriffe zu timen.

Wichtig: Keine „magischen“ Automatismen. Wenn Autonomiegrade steigen, muss das UI den Übergang explizit zeigen: „System wechselt in Automatikmodus in 10 s. Geplante Handlung: Drosselung um 20%. Abbrechen/Ändern.“ Das baut Vertrauen, weil der Bediener die Kontrolle behält.

4) Dashboards für IoT-Daten: Muster, die unter Last funktionieren

Gute Dashboards sind Triage-Werkzeuge. Einige bewährte Muster: