In vielen Umgebungen ist das Interface Teil der Sicherheitskette. Dann gelten zusätzliche Prinzipien:

  • Zustandsmaschinen explizit machen
  • UI folgt einer klaren Zustandslogik: Normalbetrieb, Anomalie erkannt (Empfehlung), Eskalation, Freigabe zur Aktion, Aktion ausgeführt, Freigabe entzogen, Rückkehr zum Normalbetrieb. Sichtbare Markierungen, keine impliziten Übergänge.
  • Rückfallebenen zeigen: „KI nicht verfügbar“, „Sensorqualität unzureichend“, „Zeitquelle unsicher“. Bediener müssen sofort sehen, welche Schutzebene greift.
  • Autorität kontrolliert übertragen
  • Kein Direktzugriff der KI auf Aktoren. Stattdessen ein Plan-Vorschlag (parametrisiert), menschliche Freigabe, anschließend deterministisches Ausführen durch das Steuerungssystem.
  • Für destruktive/irreversible Aktionen gilt mindestens eine zusätzliche Schranke: zweite Person, Rolle mit höherer Autorität oder Zeitverzögerung mit Abbruchfenster.
  • Forensik-freundliches Logging
  • Jede Empfehlung, jede Ablehnung, jede Begründung, jedes Model- und Prompt-Update in einer unveränderlichen Timeline. Im UI filter- und exportierbar. Zeit ist hart synchronisiert zur Prozesszeit.

5) LLM-Agenten sinnvoll einbinden – mit Observability statt Bauchgefühl

LLM-gestützte Komponenten sind in der Industrie nützlich, wenn sie:

  • natürlichsprachliche Abfragen über Telemetrie, Logs und Wartungshistorien ermöglichen („Zeig mir alle Motoren der Linie 2 mit steigender Lagertemperatur in den letzten 8 Stunden und vergleiche mit ähnlichen Mustern letzte Woche“),

  • Checklisten und SOPs kontextualisiert zusammenfassen („Für Störung X: Prüfschritte A–E, basierend auf diesen Signalen und letzten Fällen“),

  • heterogene Ereignisfluten zu einer priorisierten Lageeinschätzung verdichten.

Grenzen und Guardrails:

  • Keine autonome Aktorsteuerung. LLM schlägt vor, Mensch bestätigt, deterministisches System führt aus.

  • Antworten sind immer mit Evidenz verknüpft: verwendete Signale, Dokumentstellen, Zeitbereiche. Keine „nackten“ Behauptungen.

  • Tool-Use ist sichtbar: Wenn das Modell externe Werkzeuge nutzt (Abfragen, Skripte), werden die Aufrufe und Ergebnisse in einer für Menschen lesbaren Kurzform angezeigt.

  • Versionen und Policies im UI: Modellversion, Prompt-/Policy-Revision sichtbar; Änderungen erscheinen in der Timeline.

Observability-UI für Agenten (Governance):

  • Eingaben/Ausgaben pro Anfrage, inkl. Quellenauflistung. Keine internen Gedankenprozesse, sondern eine nachvollziehbare Kette aus Frage, abgerufenen Belegen und Antwort.

  • Fehlerzustände klar: Timeout, Tool-Fehler, Rate-Limit, unzureichende Belege. Vorschläge werden dann als „unsicher – bitte präzisieren“ gekennzeichnet.

  • Vergleichsansichten über Versionen: Dieselbe Frage unter neuer Modell-/Policy-Version, Unterschiede auf einen Blick. So erkennen Teams Drift ohne Ratespiel.

Praktisch heißt das: Wir bauen die LLM-Schicht wie jedes andere kritische Subsystem – mit Instrumentierung, Protokollierung und sichtbaren Grenzen. Eine Agent-Observability- und Governance-Oberfläche ist kein Extra, sondern Pflichtteil eines industriellen LLM-Deployments.

6) Accessibility in industriellen Umgebungen

Die Umgebung bestimmt die Interaktion:

  • Handschuhe, Staub, Öl, Vibrationen: Große, klar getrennte Ziele; Buttons mit deutlich unterscheidbaren Formen; großzügige Abstände. Keine winzigen Toggles.

  • Sonnenlicht und wechselnde Beleuchtung: Hoher Kontrast, anpassbare Themen, blendfreie Farbwahlen. Wichtige Informationen zusätzlich durch Icons und Text.

  • Lärm: Akustische Alarme sind nur ergänzend. Visuelle und – auf mobilen Geräten – haptische Signale sind oft wirksamer.

  • Mehrsprachigkeit und Einheiten: Texte in einfacher, fachlich korrekter Sprache; Einheiten klar am Wert; Datum/Uhrzeitformate konsistent; Zeitzonen-Verwechslungen vermeiden.

  • Bedienmodi: Touch, Hardwaretasten, Stift – je nach Gerät. Kritische Aktionen nicht allein auf wackelige Gesten stützen.

Ein kleiner, aber oft vergessener Punkt: Der „Hush“- oder Stummschaltfluss für Alarme braucht eigene Sorgfalt. Temporäres Stummschalten ohne Ursache zu verschleiern schadet; ein gut gestalteter Hush zeigt, wie lange, warum, von wem und was im Hintergrund trotzdem weiter überwacht wird.

7) Validierung und Metriken: Messen, was am Bedienplatz zählt

Wir verbessern, was wir messen – und zwar unter Realbedingungen, nicht nur im Büro-WLAN.

Sinnvolle Metriken:

  • Bediener-sichtbare Latenz: Zeit von Ereignis bis zur verlässlichen Sichtbarkeit im UI. Enthält Erfassung, Verarbeitung, Transport und Rendering. Sichtbare Warnhinweise, wenn überschritten.

  • Alarm-Verweildauer: Von Auslösung bis Bestätigung und bis Abhilfe. Hilft, Triage und Eskalationspfade zu bewerten.

  • Vorschlagsannahme und Korrekturrate: Wie oft folgen Bediener KI-Empfehlungen, und wie oft müssen sie sie nachträglich korrigieren? Das zeigt Kalibrierung und Vertrauen – beides UI-Themen.

  • Fehlbedienungsindikatoren: Häufige Undo-Aktionen, überraschende Navigationen, verlassene Dialoge. Deutet auf unklare Beschriftungen oder riskante Interaktionsmuster hin.

  • Stale-Quote: Anteil der Zeit, in der einzelne Widgets veraltete Daten zeigen. Leitet technische und UI-Optimierungen ab.

Testaufbau:

  • Szenarioreplays mit echten Telemetriedaten. Die UI muss bei Alarmfluten, Netzwerkunterbrechungen und Clock-Drift klar bleiben.

  • Handschuh-/Blendtests am realen Gerät. Klickpfade messen, Fehlklicks zählen, Interaktionskosten senken.

  • Rollenbasierte Tests. Ein Feature, das für Ingenieure toll ist, kann Bediener stören. Trennen, nicht mischen.

8) Zwei Beispielmuster aus der Praxis

  • Visuelle Qualitätskontrolle in der Fertigung
  • Problem: Sekunden- bis Minutenrhythmen, hohe Stückzahlen, Entscheidungen im Fluss. Die KI (Bildverarbeitung) liefert Treffer mit Bounding Boxes, Score und Verdachtstypen.
  • UI-Muster: Die Produktionsübersicht zeigt pro Linie eine Queue mit „verifizieren/ablehnen“ in einem Handgriff. Die Evidenz (Zoom auf Fehlerstelle, Vergleich mit letzten akzeptierten Grenzfällen) steht direkt daneben. Ablehnungspflicht: kurzer Grund. Ein Heatmap-Board hat keinen operativen Wert; Handlungsbuttons schon.
  • Trade-off: Strenge Limitierung an erklärenden Details im Hauptfluss, tiefe Analysen nur im Ingenieurmodus. So bleibt die Taktzeit stabil.
  • Flottenintelligenz für Schienenfahrzeuge
  • Problem: Stunden- bis Tagesrhythmen, geografische Verteilung, heterogene Datenqualität. KI markiert Anomalien in Antrieben, Türen, Klimasystemen.
  • UI-Muster: Karten- und Depotansichten mit Priorisierung nach betrieblicher Auswirkung. Statt rein technischer Scores: „Gefahr der Zugausmusterung in den nächsten 24h – Empfehlung: Tauschteil X im nächsten Depot Y verfügbar“. Drill-down bietet Trendlinien betroffener Sensoren, mit Vergleichsflotte als Referenz.
  • Trade-off: Raum für Unsicherheit ist größer; daher gewinnt das Evidenz-Panel an Bedeutung. Alerts werden eher geplant als hektisch abgearbeitet.