• Agentenschritte explizit:

Tool-Aufrufe und Zwischenschlüsse des Agenten können in einem „Plan“-Panel sichtbar geschaltet werden. In sensiblen Umgebungen läuft der Agent prinzipiell im „Propose“-Modus; „Execute“ erfordert menschliche Freigabe oder vordefinierte, schmale Autonomie.

  • Versionierung und Reproduktion:

Prompts, Retrieval-Kontexte und Tool-IOs werden on-prem gespeichert. Die UI ermöglicht Replays: „Warum wurde diese Empfehlung damals gegeben?“ – reproduzierbar, ohne Internet.

  • Korrekturen als Lernsignal, nicht als stilles Override:

Operator-Overrides bekommen Kategorien (z. B. falscher Kontext, veraltete Daten, Domänenregel). Diese Kategorien dienen der Modellpflege – sichtbar in einer Analyseansicht, nicht versteckt in Telemetrie.

Unsicherheit und Qualitätssignale gestalten

Unsicherheit ist kein UI-Defekt, sondern ein Primärsignal in KI-Systemen. Sichtbarkeit ohne Reizüberflutung gelingt, wenn:

  • Zeit und Herkunft immer sichtbar sind: Zeitstempel und Datenquelle auf Elementebene (z. B. „Anomaliescore, Edge-Inferenz, 12:32:10.203“).
  • Qualität als Status, nicht nur als Zahl: „Live“, „Verzögert“, „Schätzwert“, „Stale“ sind klar unterscheidbare Badges, die auch farbunabhängig erkennbar sind.
  • Prognosen getrennt von Messwerten stehen: Ein prognostizierter Ausfall liegt nicht auf der gleichen Skala wie gemessene Temperatur. Beide Welten nicht mischen, sondern in Karten oder Panels trennen.

Zugänglichkeit in harschen Umgebungen

Accessibility in der Industrie bedeutet Robustheit:

  • Interaktionsziele und Gesten:

Große Klick-/Touch-Ziele, Mindestabstände, kein „Swipe-only“. Kritische Aktionen benötigen deliberate input (z. B. lange drücken). Alternativpfade via Tastatur/Encoder.

  • Kontrast und Sonnenlicht:

Hoher statischer Kontrast, sparsame Verläufe, großzügige Flächen. Keine feinen Linien für primäre Informationen. Nacht-/Tag-Profile, die nicht nur Dark/Light sind, sondern Blendung und Reflexe berücksichtigen.

  • Handschuhe und Feinmotorik:

Drag-and-drop ist sekundär, nicht primär. Drehregler/Stepper-Komponenten sind robust. Fokusringe und aktive Zustände müssen dick und farbunabhängig erkennbar sein.

  • Lärm und Vibration:

Audiofeedback ist optional, nie exklusiv. Haptik nur, wenn Hardware vorhanden und zuverlässiger Trigger möglich. Visuelle Bestätigungen sind verpflichtend.

  • Mehrsprachigkeit und Maßeinheiten:

Einheitenumschaltung und Terminologieprofile je Standort. UI-Sprachwechsler darf nie die Semantik von Zuständen verändern.

  • Farbenblindheit:

Primärsignale nicht ausschließlich über Farbe kodieren. Formen, Muster, Icons mit klaren Konturen beilegen.

Testen unter realen Betriebsbedingungen

In der Industrie reicht „läuft im Büro“ nicht. Ein belastbarer QA-Prozess für UI umfasst:

  • Umfeldsimulation:

Sonnenlichttests, Handschuhtests, Vibration, schmutzige Screens. Input-Devices variieren (Touch, Tastatur, Encoder, Stift).

  • Netz- und Rechenbudget:

Latenz-Injektion, Paketverlust, gedrosselte GPU/CPU, Speicherdruck. UI darf unter Druck in definierte Degradationsmodi wechseln.

  • Szenario-Tests statt Klickpfade:

Realistische Ereignisfolgen (z. B. Intermittierende Sensoren, zeitgleiche Alarme, Tool-Timeouts von Agenten, Konflikte zwischen Mensch und Autonomie).

  • Shadow Mode:

Neue Modelle/Agenten laufen zunächst schattenhaft mit, geben Empfehlungen ohne Eingriffsrechte. UI zeigt die hypothetischen Aktionen separat. Erst nach ausreichender Beobachtung: selektives Freischalten.

  • On-Prem Analytics:

Da keine Cloud-Analytics, braucht es lokale Event-Streams und Dashboards: Entscheidungslatenz, Vorschlag-Adoption, Overrides, Alarm-Quittierzeiten. Diese Metriken sind Grundlage für UI-Iterationen.

  • Replays:

Jedes kritische Ereignis ist reproduzierbar: UI-Zustand, Daten-Snapshots, Modellversionen, Agentenschritte. Das ermöglicht Audits und Schulung – On-Prem.

Deploymentmodelle ohne Cloud-Transparenzverlust

  • Paketierung:

UI-Assets, Modelle, Vektordaten, Konfigurationen als signierte Bundles. Keine externen CDNs. Asset-Fallbacks lokal.

  • Orchestrierung:

Kubernetes-On-Prem (z. B. schlanke Distribution), lokale Registry-Spiegel. Deployments mit vorab validierten Ressourcenbudgets, damit UI bei Überbelegung nicht „verhungert“.

  • Auth und RBAC:

SSO on-prem oder lokale Identity-Provider. Rollen sind UI-präsent: Was darf in welchem Modus wer? Kritische Aktionen an Rollen koppeln.

  • Monitoring:

Prometheus/Grafana-ähnliche Setups On-Prem. UI-spezifische Health-Checks (Eventloop-Delay, Renderzeiten, WebSocket-Drops).

  • Backup und Wiederherstellung:

UI-Zustände, Preferences und lokale Caches sind deterministisch wiederherstellbar. Kein stiller Verlust von Alarmeinstellungen oder Layouts nach Update.

Musterbeispiel 1: Visuelle Fehlererkennung in der Montage

Problem:
Teile werden visuell geprüft. KI erkennt potenzielle Fehler. Bediener muss entscheiden: akzeptieren, nacharbeiten, aussortieren. Taktzeiten sind eng. Handschuhe, Ölfilm, wechselndes Licht.

UI-Lösung:

  • Live-Feed mit stabilisiertem Overlay. „Live“-Badge wechselt zu „Verzögert“, wenn Inferenz älter als Budget.

  • Hypothese-Panel zeigt Top-N Fundstellen mit Crops, Konfidenz als Rangfolge, nicht als Prozentzahl.

  • Handlungsraum: Drei primäre Aktionen großflächig, Undo möglich. Kritische Aktion erfordert press-and-hold.

  • Quellen: Modellbuild-ID, Kamera-ID, Beleuchtungsprofil.

  • Overrides kategorisiert (Falschpositiv, Falschnegativ, Mangelnde Sicht). Kategorien fließen in die Analyse.

  • Shadow-Mode bei neuen Modellen: Empfehlungen sichtbar, aber ohne Autonomie. Adoption-Rate lokal ausgewertet.

  • Accessibility: Hoher Kontrast, große Targets, keine feinen Umrisse für Bounding Boxes. Alternativpfade via Tasten.

Musterbeispiel 2: Flottenereignisse im Bahnkontext

Problem:
Zehntausende Telemetriepunkte, sporadische Anomalien. Ziel: Ereignisse triagieren, Wartungstermine planen, Betrieb nicht stören.

UI-Lösung:

  • Situationsbild als Timeline mit Ereignisclustern. Farb- und Formkodierung plus Badges.

  • Modellhypothese: „Wahrscheinliche Ursache“ mit verlinkten Sensorkanälen und historischen Vergleichsfenstern.

  • Handlungsraum: Maßnahmenkarten (Überwachen, Inspektion planen, Geschwindigkeit begrenzen) mit Auswirkungen auf Betrieb.

  • Agentik: Vorschlagstexte sind mit Datenkacheln verknüpft. Jede Aussage lässt sich zur Quelle zurückverfolgen.

  • Alarm-Ökonomie: Nur neue, signifikante Events eskalieren. Wiederkehrer werden zusammengefasst.

  • Degradationsmodus: Bei Datenlücken werden Prognosen klar als Schätzwerte markiert; Handlungsoptionen passen sich an (konservativ).

Governance und Observability von LLM-Agenten: Alpi-M im Einsatz

In industriellen Projekten ist es sinnvoll, die Interaktion zwischen Mensch und Agent sichtbar und steuerbar zu machen. Eine Observability- und Governance-Schicht wie Alpi-M übernimmt u. a.:

  • Protokollierung von Agentenpfaden:

Prompts, Tools, Zwischenergebnisse, Modellversionen, Timing – On-Prem gespeichert, reproduzierbar.