b) Wissensassistenz für Instandhaltung mit LLM-Agent

  • Problem: Techniker benötigen pro Störung konsistente, sichere Handlungsanweisungen und Teilelisten.
  • Architektur:
  • On-Prem RAG über Handbücher, Service-Tickets, Zeichnungen. Strikte Dokumentenklassen und Löschbarkeit.
  • Agent mit Tool-Router: darf Diagnose-APIs lesen, Teilekatalog durchsuchen; Bestellungen nur mit Genehmigung.
  • Observability: Schrittweises Trace-Log mit Prompt-Provenienz und Dokumentreferenzen; Replay-fähig.
  • UI: Entscheidungsvorlage mit Zitaten aus Dokumenten, Gegenbeispielen (ähnliche Störung, anderer Lösungsweg), Policy-Checks.
  • Governance: Autonomie-Stufe 1 – der Agent bereitet Bestellung vor, Techniker oder Disponent gibt frei.
  • Ergebnis: Weniger Suchzeit, mehr Qualität in der Ausführung – ohne Daten das Werk zu verlassen und ohne unkontrollierte Agentenaktionen.

8) Praktischer Start: Checkliste für CTOs und Heads of Digital

  • Definieren Sie eine Autonomie-Gating-Matrix je Use Case: Fehlerkosten, Verzögerungskosten, Beobachtbarkeit, Umkehrbarkeit.
  • Etablieren Sie einen Evidence Bus: maschinenlesbare Erklärartefakte neben jedem Modelloutput; versioniert, signiert.
  • Setzen Sie einen deterministischen Policy Layer vor jede KI-Aktion; Policies sind Code, nicht Dokumente.
  • Bauen Sie Observability „by design“: strukturierte Agenten-Traces, Replay-Fähigkeit, Live-Kill-Switch.
  • Trennen Sie strikt Kurzzeitkontext und Langzeitspeicher; implementieren Sie echte Löschpfade.
  • Planen Sie On-Prem-Kapazitäten wie kritische Infrastruktur: GPU-Scheduling, Prioritäten, Wartungsfenster.
  • Führen Sie Shadow- und Canary-Rollouts verbindlich ein; definieren Sie messbare Akzeptanzkriterien.
  • Schulen Sie Operatoren nicht in „KI“, sondern in Evidenzinterpretation, Fallbacks und Freigabe-Entscheidungen.
  • Verankern Sie RACI und Signaturen im Workflow; kein „stiller“ Auto-Pilot.

Meinungen, die wir aus Projekten ableiten

  • Konservative Defaults schlagen smarte Heuristiken, wenn die Kosten des Fehlers hoch sind.
  • Explainability lohnt sich nur, wenn sie arbeitsfähig ist: weniger „Warum ist das Modell so?“ – mehr „Was habe ich gesehen, um zu entscheiden?“
  • Ohne Observability sind Agenten Betriebsrisiko, keine Hilfe. Traces, Replays und Policies sind nicht optional.
  • On-Prem ist in regulierten und sicherheitskritischen Industrien keine Ideologie, sondern eine Voraussetzung für Souveränität.

FAQ

Frage: Brauchen wir für Human-in-the-Loop zwingend eine grafische Oberfläche mit vielen Erklärungen?
Antwort: Sie brauchen eine Oberfläche, die den Evidenzvertrag abbildet – minimal, schnell, konsistent. Oft sind 3–5 gut gewählte Evidenzbausteine produktiver als eine Vielzahl an Plots. Wichtig ist, dass Ablehnen gleichwertig zu Freigeben ist und jede Entscheidung nachvollziehbar bleibt.

Frage: Wie verhindern wir, dass LLM-Agenten unkontrolliert handeln?
Antwort: Legen Sie einen deterministischen Policy Layer vor jeden Tool-Aufruf, protokollieren Sie jeden Agentenschritt strukturiert, trennen Sie Rollen und Berechtigungen, und betreiben Sie Live-Kontrollen wie Kill-Switches und Quoten. Autonomiegrade sind konfigurierbar und beginnen konservativ.

Frage: Erklärbarkeit klingt teuer. Wo ist der Hebel?
Antwort: Bauen Sie Explainability als Datenprodukt (Evidence Bus), nicht als Frontend-Spielerei. Dieselben Artefakte dienen Operatoren, Auditoren und Entwicklern. Einmal sauber modelliert, reduziert das langfristig Reibung und verkürzt Fehlersuche und Freigaben erheblich.

Frage: Wie gehen wir mit Datenlöschanforderungen in einem RAG/Agenten-Setup um?
Antwort: Speichern Sie Wissensobjekte referenzierbar und entkoppeln Sie sie vom generierten Langzeitgedächtnis. Löschen bedeutet: Dokumente entfernen, Indizes neu bauen, Referenzen invalidieren. Agenten müssen bei Zugriffen auf veraltete Referenzen definierte Fallbacks zeigen.

Frage: Wer trägt am Ende die Verantwortung für Fehlentscheidungen?
Antwort: Die Verantwortung ist in der Governance verankert: Der Genehmiger ist verantwortlich für die einzelne Freigabe, der Prozesseigentümer für Policies, SLOs und Änderungen. Diese Rollen müssen durch Signaturen, Audit-Trails und klare Runbooks technisch unterstützt werden.

Schluss

Mensch-KI-Interaktion ist ein Ingenieurthema. Wer sie als UX-Feinschliff oder als bloße Modellfrage behandelt, landet im Pilotierlabyrinth. Souveränität entsteht durch Architekturentscheidungen: Autonomie-Gates, Evidenzverträge, deterministische Policies, Observability und echte Reversibilität – on-premise und auditierbar. Erst dann beginnt die KI, in der industriellen Realität Wert zu liefern, ohne dass Vertrauen zur Glückssache wird. AlpiType baut genau in dieser Nahtstelle: von der Anforderung bis zur Qualitätssicherung – und mit Plattformbausteinen für Observability und Governance, die in souveräne Infrastrukturen passen.