UX für KI-gestützte Industrieoberflächen: Sicherheit, Souveränität und Entscheidungszeit statt Hype

In industriellen Umgebungen gewinnt oder verliert man Sicherheit und Taktzeit nicht im Backend, sondern an der Oberfläche. Bediener treffen Entscheidungen unter Zeitdruck, mit unvollständigen Daten und im Spannungsfeld aus Automatisierung und Verantwortung. KI verschärft diese Spannung: Modelle sind probabilistisch, viele Werkzeuge sind cloud-zentriert, und Erklärbarkeit ist oft nachgelagert. Wer hier „schöne Dashboards“ baut, verfehlt das Ziel. Es geht um Gestaltung, die deterministische Steuerung mit nicht-deterministischer Intelligenz verheiratet, ohne Souveränität, Auditierbarkeit und Reaktionszeiten zu kompromittieren.

Dieser Text beschreibt gestaltungs- und architekturgetriebene Prinzipien für UI/UX in industriellen KI-Systemen – aus der Perspektive von Teams, die on-premises, DSGVO-konforme Lösungen für sicherheitsrelevante Branchen ausliefern. Er ist problemorientiert: Welche Randbedingungen zwingen welche Designentscheidungen? Welche Trade-offs sind bewusst zu treffen?

Randbedingungen industrieller KI-Interfaces

  • Zeit und Zuständigkeit: Bediener sind verantwortlich, auch wenn ein Modell Vorschläge macht. Die Zeit bis zur Entscheidung ist begrenzt, und Fehler wirken real in Anlagen, Flotten oder Sicherheit.
  • On-Premise zuerst: Datenhoheit erfordert den Betrieb ohne US-Cloud-Abhängigkeiten, teils in isolierten Netzen. Latenzen, Ausfallszenarien und Updatefenster sind anders als im typischen SaaS.
  • Nicht-deterministische KI trifft deterministische Steuerung: Klassische Automatisierung verlangt deterministische Pfade. KI liefert Wahrscheinlichkeiten und Unsicherheiten. Das UI muss diesen Widerspruch auflösen.
  • Umgebungseinflüsse: Handschuhe, Vibration, Staub, Sonnenlicht, Lärm. Touch-Eingaben, Farbdarstellung und akustische Alarme sind eingeschränkt nutzbar.
  • Sensorik und Datenqualität: Jitter, Aussetzer, Drift, uneinheitliche Zeitsynchronisation, nicht vertrauenswürdige Timestamps. Das UI darf keine Scheingenauigkeit erzeugen.
  • Auditierbarkeit: Jede Entscheidung muss rückführbar sein: Zustand der Anlage, Eingaben, verwendete Datenquellen, Modellversion, Policies und Freigaben.

Gestaltungsprinzipien für KI-gestützte Entscheidungen

  • Mensch hat die Hoheit: KI empfiehlt, der Mensch entscheidet. Keine stillen Autohandlungen ohne vorgelagerte Freigabe. Not-Aus und sichere Zustände sind immer direkt erreichbar.
  • Unsicherheit sichtbar machen: Wahrscheinlichkeiten, Konfidenzintervalle und Datenlücken gehören in die Primäransicht – verdichtet, nicht im Kleingedruckten.
  • Progressive Offenlegung: Schnelle Erstentscheidung im Fokus, Hintergrunddetails auf Anforderung. Tiefe nur dort, wo sie die Entscheidung verbessert.
  • Degradierbarkeit: Definierte Fallbacks bei Modellfehlern, Datenverlust und Verbindungsproblemen. Das UI bleibt bedienbar, Handlungsfähigkeit ist wichtiger als Vollständigkeit.
  • Keine Informationsflut: Alarm-Fluten werden gruppiert, priorisiert, und mit sinnvollen Suppressionsfenstern kontrolliert. Ziele: Erkennen statt verdrängen.
  • Erklärungen sind artefaktisch: Erklärungen nicht als Textbaustein, sondern als Beipackzettel der Entscheidung – welche Daten, welche Regeln/Prompts, welches Modell, welche Richtlinien.

UI-Patterns, die in der Praxis tragen

1) Alarmtrichter statt Alarmhölle

  • Gruppierung nach Ursache/Wirkung und räumlicher Nähe.

  • Eskalationslogik: Warnung → Alarm → Intervention, mit klaren Übergangsbedingungen.

  • Temporäre Unterdrückung mit sichtbarem Timer, Begründungspflicht und Rückholbarkeit.

  • Visuelle Ruhe: wenige feste Farbcodes, Zeichenredundanz (Form/Ikone) für farbsehschwache Nutzer.

  • Fixe Positionen für kritische Elemente, keine kontextabhängige Wanderung von Buttons.

2) Konfidenz-Leiter für KI-Empfehlungen

  • Drei Schwellen: informativ (keine Aktion), vorschlagswürdig (Bedienerentscheidung), sperrend (erfordert zusätzliche Verifikation).

  • Konfidenz nicht nur als Zahl: kombinierte Qualitätssignale (Datenfrische, Messwertstreuung, Sensorstatus).

  • Klare Implikationen: „Unter 60% nur anzeigen“, „70–85% erfordert Mensch“, „>85% erlaubt halbautomatisches Makro mit Bestätigung“. Schwellen sind konfigurierbar und auditierbar.

3) Entscheidungs-Beipackzettel (Decision Bill of Materials)

  • Datenquellenliste: Sensoren, Zeitfenster, Vorverarbeitungsschritte, Abtastraten.

  • Modell-Metadaten: Modellname, Version, Trainings- bzw. Freigabestand.

  • Regel-/Prompt-Schnappschuss: deterministische Regeln, LLM-Prompt, Toolaufrufe.

  • Richtlinienprüfung: welche Policies gegriffen haben (z. B. Rollenzugriff, Standortgrenzen).

  • Trace-ID: Verknüpft UI-Event, Inferenz, Telemetrie und Log – Grundlage für Governance und Forensik.

4) Ereignis-Zeitlineal

  • Gemeinsame Zeitachse für Sensoren, KI-Ausgaben und Bedienereingriffe.

  • Markierungen für Datenlücken, Pufferüberläufe, Neusynchronisation – keine geglätteten Kurven ohne Hinweis.

  • Drilldown bis zum Rohsignal, aber mit sicherem „Zurück zur Lage“-Sprung.

5) Degradierte Betriebsarten

  • Offline/Isoliert: Anzeige Minimalmenge kritischer Signale, Schreiboperationen als wartende Jobs sichtbar.

  • Sensorausfall: Ersatzgrößen oder konservative Schätzwerte deutlich markiert.

  • Modell nicht verfügbar: Umschalten auf deterministische Regeln, UI markiert „KI aus“ persistent.

  • Latenz sichtbar: „Datenstand vor X s“, mit Schwellwertanzeige und optischer Entschleunigung, wenn Frische zu niedrig ist.

6) Bestätigungs- und Arming-Muster

  • Zweistufige Aktionen: Scharfschalten → Ausführen, räumlich getrennt, mit bewusst verlangsamter Interaktion für irreversible Schritte.

  • Kontextwiederholung beim Bestätigen: betroffene Assets, erwartete Auswirkungen, Abbruchpfad.

7) Feedback in den ML-Lebenszyklus

  • Ein-Klick-Annotation: „Falsch positiv“, „Falsch negativ“, mit minimaler Begründungsauswahl.

  • Aufgabenwarteschlange für Nachbewertungen durch Qualitätsteams.

  • Sichtbare Wirkung: nächste Versionen referenzieren, dass Feedback einfloss (Transparenz motiviert Nutzung).

8) Robuste Navigation unter Stress

  • Flache Hierarchien, kurze Wege zum Notwendigen.

  • Tastatur/Hardware-Parität: wesentliche Funktionen liegen auf Tasten, Pedalen, Drehgebern; Touch ist Add-on, nicht Single-Point-of-Failure.

  • Kein modales Labyrinth; kritische Anzeigen werden nicht von Dialogen verdeckt.

Dashboards für industrielle IoT-Daten: von Zweck zu Layout

Ein OEE-Board, ein Leitstand für Störungen und eine Zustandsüberwachung benötigen unterschiedliche Interaktionsmodelle. „Ein Dashboard für alles“ ist ein Anti-Pattern.