UX für KI-gestützte Industriesysteme: Wenn Interfaces über Sicherheit entscheiden

Problemstellung

In industriellen Umgebungen ist UX kein Nice-to-have. Sie entscheidet darüber, ob eine Bedienerin unter Lärm, Zeitdruck und unvollständigen Daten die richtige Entscheidung trifft. Wir sprechen über Anlagen, die bei Fehlbedienung stehen bleiben, Produkte beschädigen oder im Worst Case Menschen gefährden. Zeit ist knapp, Aufmerksamkeitsfenster sind klein, Eingaben passieren mit Handschuhen, Displays sind dem Sonnenlicht ausgesetzt, Netzwerke sind segmentiert oder zeitweise offline, und Systeme laufen on-premise – oft ohne Cloud-Fallback. Gleichzeitig ziehen KI-Komponenten in die Betreiberoberflächen ein: visuelle Inspektionssysteme, Anomalieerkennung, Planungsvorschläge, Text- und Sprach-Interfaces, zunehmend auch Agenten, die Workflows anstoßen.

Dieser Artikel richtet sich an CTOs, VP Engineering und Leiter Digitalisierung, die UX-Design nicht als Farbwahl sehen, sondern als Architekturelement. Wir gehen von konkreten technischen Constraints aus, die das UI-Design bestimmen, und leiten daraus Muster ab, die im Feld funktionieren.

Grundprinzip: Entscheidungssystem statt App

KI im Industrie-UI darf keine Blackbox sein. Ein Interface für ein KI-gestütztes Entscheidungssystem muss drei Dinge gleichzeitig leisten:

  • Was ist die Lage? Verdichtete, belastbare Situational Awareness innerhalb von Sekundenbruchteilen.
  • Was empfiehlt die KI, und warum? Entscheidungsvorschläge inklusive Begründbarkeit und Grenzen.
  • Was ist die sichere nächste Aktion? Klar markierte Handlungsoptionen mit Schutzgeländern (Interlocks, Quittierungen), die das Risiko angemessen kontrollieren.

Daraus ergeben sich zentrale Designentscheidungen, die nicht primär visuell sind, sondern in der Systemarchitektur liegen: Datenflüsse, Latenzbudgets, Offline-Fähigkeit, Rechtekonzepte, Protokollierung.

Echtzeit-Daten und UI: Update-Budgets statt „Live um jeden Preis“

IIoT-Systeme liefern mehr Daten, als jede Bedienoberfläche sinnvoll darstellen kann. Für tragfähige Dashboards gilt:

  • Ereignisgetriebene UI statt Polling: Frontends abonnieren Topics/Streams (z. B. über MQTT/AMQP/WebSockets), Server übernehmen Aggregation, Deduplikation und Backpressure.
  • Zeitbezug sichtbar machen: Jeder Wert zeigt Zeitstempel inkl. Quelle. Bei synchronisierten Systemen hilft die Anzeige von Takt-/Sync-Qualität (z. B. NTP/PTP-Drift), um scheinbare Inkonsistenzen zu erklären.
  • Decimation und Stabilisierung: Rohwerte werden serverseitig verdichtet. UI-seitig vermeiden wir Flackern durch Hysterese und definierte Update-Fenster. Ziel ist eine „in 2 Sekunden erfassbare“ Stabilität, nicht maximale Bildwiederholrate.
  • Ausfall- und Partitionstoleranz: Bei Netzsegmentierung zeigt das UI den letzten validen Zeitpunkt und fällt auf lokale Messpunkte um. Aktionen, die Synchronität erfordern, werden gesperrt oder klar als „offline ausstehend“ markiert.

Unsicherheit der KI gehört ins Interface – ohne den Menschen zu überfordern

Ein Industrie-UI, das KI nutzt, muss Unsicherheit als Erste-Klasse-Bürger behandeln:

  • Konfidenz nicht als Prozent-Fetisch: Statt „91 % sicher richtig“ verwenden wir abgestufte Vertrauenszonen mit operationaler Bedeutung (z. B. „hoch – automatische Freigabe möglich“, „mittel – Freigabe durch Bediener nötig“, „niedrig – Vorschlag nur zur Information“).
  • Gegenbeispiele und Alternativen: Zeige top-2/3 Hypothesen, wenn sie operativ unterschiedlich wären. Das hilft insbesondere bei Visionsystemen: „Fehler: Kratzer (hoch), Alternative: Verschmutzung (mittel)“.
  • Erklärflächen on-demand: Heatmaps, Bounding Boxes, Feature-Beiträge oder Schlüssel-Frames sind toggelbar, nicht dauerhaft sichtbar. Standardansicht bleibt ruhig, Erklärungen sind einen Klick entfernt.
  • Schwellen mit Hysterese: Für Zustände, die Aktionen triggern, arbeiten wir mit Ansprech- und Abfallwerten. Das verhindert Flickern und reduces Alarmfluten.
  • Fallback-Pfade: Wenn Unsicherheit über Grenzwert steigt, wechselt das UI automatisch in einen „verlangsamten“, sichereren Modus mit zusätzlichen Checks.

Aktionsgestaltung: Risiko-adaptierte Interaktionsmuster

Nicht jede Bestätigung ist sinnvoll. Bestätigungszwang bei Routineaktionen erzeugt Blindheit; fehlende Bestätigung bei risikoreichen Aktionen ist gefährlich. Wir etablieren risikoadaptive Muster:

  • Confidence-aware Action: Der gleiche Button verhält sich abhängig von Kontext und KI-Vertrauen unterschiedlich. Bei hohem Vertrauen und geringer Konsequenz: 1-Klick. Bei mittlerem Vertrauen oder höherer Konsequenz: Doppelklick oder Halteinteraktion. Bei niedrigem Vertrauen oder hoher Konsequenz: Zweifaktor-Quittierung (z. B. zweiter Operator oder Supervisor).
  • Interlocks explizit sichtbar: Wenn ein Interlock eine Aktion verhindert (z. B. Schutzhaube offen), ist der Grund mit Wiederherstellungsweg direkt am Bedienelement sichtbar, nicht in einem separaten Log.
  • Dead-man und Cancel-first: Langlaufende Aktionen sind jederzeit abbrechbar; bei unklarer Lage präferiert das UI „sicher abbrechen“ statt „weiterlaufen“.
  • Handlungswarteschlange: Geplante Agentenaktionen sind als Queue mit Begründung, Inputs, erwarteter Wirkung und Timeouts sichtbar und einzeln stoppbar.

Alarm- und Ereignisdesign: Von Flood zu Diagnose

Alarmsysteme entscheiden häufig darüber, ob Menschen noch verstehen, was passiert. Designziele:

  • Priorisierung mit Semantik: Kritikalität basiert auf Auswirkung, nicht nur Schwellenverletzung. Kaskadierende Alarme (Folgealarme) werden gruppiert, Root Cause herausgestellt.
  • Rate-Limiting und Batching: Wiederholte gleichartige Alarme werden gedrosselt und zusammengefasst, inklusive „n in m Minuten“-Angaben.
  • Kontextsprüngen folgen: Ein Alarm ist ein Einstiegspunkt. Ein Klick führt zur passenden Diagnoseansicht mit relevanten Trends, nicht zur generischen Übersichtsseite.
  • Quittierungsfluss mit Audit-Trail: Wer hat wann was gesehen/bestätigt/überstimmt, inklusive Begründung. Dieser Trail ist unveränderbar und lokal verfügbar (ohne Cloud).

On-Premise und Datenhoheit prägen die UX-Architektur

Wo Datenhoheit nicht verhandelbar ist, sind UI-Design und Deployment eng verknüpft:

  • Offline-first als Default: Jede kritische UI-Funktion muss ohne Internet funktionieren. Das erfordert lokale Caches, edge-seitige Inferenz und degradierbare Visualisierungen.
  • Kein Hidden Cloud Dependency: Fonts, Kartenkacheln, Model-Downloads, Telemetrie – alles muss on-premise verfügbar sein. Jede Abhängigkeit ist ein Risiko und gehört sichtbar dokumentiert.
  • Update-Strategien: UI und Modelle werden rollierend aktualisiert, mit Version-Pinning und schneller Rollback-Fähigkeit. Aus Sicht der UX heißt das: Versionen und Changelogs sind im UI sichtbar, ein Operator kann lokales Verhalten einer Version zuordnen.
  • Zugriffs- und Rollenmodell: Rollen sind lokal prüfbar (z. B. via on-prem IAM). Temporäre Rechteerhöhungen werden im UI mit Timer und Zweckbindung angezeigt.