UX für KI-gestützte Industrieanwendungen: Wenn die Oberfläche über Sicherheit entscheidet

Problemstellung

In industriellen Systemen entscheidet UX nicht über Conversion Rates, sondern über Sicherheit, Durchsatz und Stillstandszeiten. Bediener treffen Entscheidungen unter Zeitdruck, mit unvollständigen Daten und in Umgebungen, die Handschuhe, Staub, Sonnenlicht und Vibrationen mitbringen. Gleichzeitig verschiebt KI den Schwerpunkt: Ergebnisse sind probabilistisch, nicht deterministisch; Vorschläge sind erklärungsbedürftig; Governance und Auditierbarkeit sind nicht optional. Und: In vielen Branchen ist Datensouveränität nicht verhandelbar. Das hat konkrete Auswirkungen auf das, was eine UI darf und können muss – von Latenzbudgets bis zu On-Prem-Deployment ohne Internetabhängigkeiten.

Dieser Beitrag beschreibt konkrete Muster, Architekturen und Trade-offs für UI/UX in industriellen, KI-gestützten Systemen – aus der Perspektive eines Teams, das Software in sicherheitsrelevanten und datensouveränen Umgebungen baut. Ausgangspunkt ist das Problem, nicht die Technologie. Die Beispiele fokussieren auf reale Randbedingungen: On-Prem, DSGVO-konform, keine US-Cloud, gemischte Kritikalität, menschliche Entscheidungen unter Zeitdruck.

Rahmenbedingungen, die das UI-Design prägen

  • Determinismus vs. Probabilistik:

Klassische Steuerungssysteme sind deterministisch. KI-Komponenten liefern plausible, aber nicht garantiert richtige Hypothesen. Die UI muss diese beiden Welten sichtbar machen: Was ist sicher? Was ist Vorschlag? Was ist ungesichert?

  • Latenzbudgets:

Zwei Budgets sind relevant: Render-Latenz (UI fühlt sich sofort an) und Entscheidungs-Latenz (Zeit von Ereignis bis informierte Aktion). Ein UI kann großartig aussehen und trotzdem unbrauchbar sein, wenn der Befund 800 ms zu spät gerendert wird.

  • Degradationsmodi:

Verlust von Sensordaten, verzögerte Edge-Inferenz, Ausfall einer GPU, Netzwerk-Jitter, veraltetes Wissensmodell – die UI muss aktiv und sichtbar in degradierte Modi übergehen, nicht „still“ versagen.

  • Datenhoheit:

On-Prem bedeutet: Keine Telemetrie in die Cloud, keine CDN-Fonts, keine externen Feature-Flags, keine Online-A/B-Tests. UI-Analytik, Prompt-Logging für LLM-Agenten, Rollbacks und Replays – alles lokal.

  • Umweltbedingungen:

Bedienung mit Handschuhen, im Sonnenlicht, bei Vibrationen und Lärm. Buttons, Kontraste, Fokusmanagement und Interaktionen müssen robust sein – inklusive Tastatur-, Encoder- oder Not-Bedienpfade.

Architekturgrundlagen für eine belastbare Industrie-UI

Ein wiederkehrendes Architekturpattern für industrielle KI-Interfaces sieht so aus:

  • Datenpfad
  • Sensorik/PLC -> Edge-Inferenz (CV, Zeitreihen-Modelle, LLM-Tools) -> Message Bus (z. B. MQTT oder Kafka On-Prem) -> Timeseries-/Event-Store (On-Prem) -> Backend-Services -> UI-Clients via WebSocket/gRPC-Web mit serverseitigem Backpressure.
  • Zustandsmodell im Frontend
  • Explizite State Machines statt impliziter Flag-Suppe. Zustände wie Connecting, Live, Stale, Degraded, Maintenance, Shadow aktiv anzeigen. Zeitstempel und Herkunft für jede Metrik rendern.
  • Caching und Offline-Strategie
  • Edge-Caches für Basiskarten, Vektorkacheln, Fonts, Icons. Kein externer DNS benötigt. Ressourcen-Bundles signiert auslieferbar.
  • LLM/Agentik On-Prem
  • Model Serving lokal (z. B. vLLM/TGI-äquivalente Setups), Retrieval via lokale Vektorindizes und DMS, strikt auf geprüfte Quellen begrenzt. Tool-Aufrufe (Betriebsmittel, Ticketsysteme, Datenabfragen) sind getrackt, limitiert und require-approval, je nach Systemautorität.
  • Observability und Governance
  • Prompt-, Tool- und Entscheidungstelemetrie bleiben On-Prem. Ein Layer wie Alpi-M erfasst Agent-Pfade, Tool-Resultate, Confidences, Operator Overrides und sorgt für Reprozierbarkeit und Auditierbarkeit.

Dieses Setup ist widerstandsfähig gegen Netzwerkausfälle, lässt sich offline prüfen und erfüllt strenge Souveränitätsanforderungen.

Muster für KI-gestützte Entscheidungsoberflächen

Wir nutzen drei wiederkehrende Panels, die zusammen eine Entscheidungsoberfläche bilden:

1) Situationsbild

  • Live-Datenstrom, geordnet nach Relevanz, mit klaren Zeit- und Qualitätsmarkern.

  • Kontextuelle Layer: Maschinenzustände, Prozessschritte, räumliche Lage.

  • „Stale“-Hinweise, wenn Daten älter als das definierte Budget sind.

  • Unterscheidung: Rohsignal (z. B. Kamera-Feed) vs. berechnetes Feature (z. B. Anomaliescore).

2) Modellhypothese

  • KI-Vorschlag als Hypothese, nicht als Fakt. Visualisierung der Unsicherheit: z. B. Balken/Bänder, nicht nur Farben.

  • Quellenangaben/Provenienz: Welche Eingaben, welches Modellbuild, welches Wissenssnapshot?

  • Kontrafaktische Referenz: „So sähe es aus, wenn wir mit Option B fortfahren“ – als Simulation, nicht als geheime Aktion.

3) Handlungsraum

  • Operator-Optionen mit Sicherheitslogik: erlaubte Aktionen, erforderliche Bestätigungen, klare Nebenwirkungen.

  • Vorschlag-Adoption mit Begründungsauswahl (z. B. „Plausibel“, „Zeitkritisch“, „Regelwerk verlangt“).

  • „Ask the model again“ als explizite Aktion mit Kostenhinweis (Zeit, Rechenbudget).

Trade-offs, die man upfront entscheiden sollte

  • Konfidenz visualisieren oder nicht?

Zu viel Unsicherheitsvisualisierung verwirrt, zu wenig überhöht die KI. Ein praktikabler Ansatz ist, Konfidenz nur dort zu rendern, wo sie die Wahl zwischen Handlungsoptionen plausibel beeinflusst – und in den restlichen Fällen die Konfidenz für die Governance zu protokollieren.

  • Automationsgrad:

Modi müssen latenzarm und unmissverständlich sein: Manuell, Assistiert, Automatisch. In assistierten Modi sollten KI-Interventionen stets gesondert markiert und rücknehmbar sein.

  • Alarm-Ökonomie:

Ein „Alarm“ ist eine UI-Währung. Überschreitet das System das Alarminflationsniveau, sinkt die Aufmerksamkeit. Besser: gestufte Hinweise (Hinweis -> Warnung -> Alarm), jeweils mit klaren Eskalationskriterien und quittierbaren Zuständen.

  • Bediengeschwindigkeit vs. Fehlertoleranz:

Große Touchziele und reduzierte Interaktionen beschleunigen – können aber ungewollte Eingaben begünstigen. Guardrails wie „press-and-hold“ für kritische Aktionen, Undo-Fenster und Rollenbindung helfen.

LLM-Agenten bedienbar und kontrollierbar machen

LLM-gestützte Assistenten in der Industrie sind Tools, keine Orakel. Daraus ergeben sich UI-Prinzipien:

  • Quellengebundenheit:

Der Assistent darf nur über Dinge sprechen, die aus freigegebenen Dokumenten, Telemetrie oder Tools stammen. Die UI zeigt Quellenlisten, Dokument-Snippets und Tool-Resultate an – nie nur freien Text. Freitext ohne Quelle wird als „Vermutung“ gekennzeichnet oder unterdrückt.

  • Grenzen der Autorität sichtbar machen:

Jede Antwort trägt die Signatur: Modellversion, Wissensstand, Toolzugriffsrechte. Änderungen daran werden in der UI wie ein Moduswechsel behandelt.