1) Instandhaltungs-Copilot in der Textilfertigung

  • Trigger: Anomalie im Spindellager (SPC-Abweichung + Vibrationspeak).

  • Agentenverhalten:

a) Liest Trenddaten aus dem Historian (last 72h), verknüpft mit Schichtprotokoll.
b) Ruft RAG auf Wartungsleitfäden (on-prem), extrahiert relevante Prüfschritte für exakt diesen Maschinentyp.
c) Erzeugt einen Arbeitsauftrags-Entwurf im CMMS (Fachtext, Ersatzteilliste aus E-Katalog, Priorität nach OEE-Impact).
d) Sendet Proposal an Executor. Ein Instandhaltungsleiter prüft im HMI: Parameter, Risiko, Downtime-Slot. Nach Freigabe legt der Executor den Auftrag tatsächlich im CMMS an und plant einen Stillstand.

  • Guardrails: Kein direkter Eingriff in SPS. Keine Bestellung ohne Kostenstelle/Limit-Check (Policy). Vollständiger Audit-Trail.

2) Visuelle Montageunterstützung in der Elektronikfertigung

  • Trigger: Der Arbeiter fordert „Schritt 5 für Board-Variante X“ an.

  • Agentenverhalten:

a) RAG holt den WI-Abschnitt, bebildert, versioniert. Der Agent generiert klare, nummerierte Anweisungen mit Verweisen („Quelle: WI v3.4, Abschnitt 5.2“).
b) Vision-Service (separat) prüft parallel Steckverbinderlage, Lötpunkte. Das LLM interpretiert NICHT die Bilder; es orchestriert nur den Dialog.
c) Bei Abweichungen erzeugt der Agent einen NCR-Entwurf (8D-Template), inklusive vorgeschlagenen Sofortmaßnahmen, als Proposal zur Qualitätsfreigabe.

  • Guardrails: Keine Taktstopps oder Linienstellungen durch das LLM. ANDON/KVP bleiben führend. Das LLM liefert Kontext und Dokumente, keine Steuerbefehle.

3) Non-Conformance Reporting in der Luftfahrt

  • Trigger: Qualitätsprüfer dokumentiert einen Lackfehler.

  • Agentenverhalten:

a) Klassifiziert Defektart (kontrollierter Label-Space), füllt 8D-Vorlage vor, verlinkt ähnliche Fälle aus der eigenen NCR-Datenbank.
b) Erzeugt Änderungsantrag (ECO-Entwurf) als Proposal für MRB-Board.

  • Guardrails: Strikte Taxonomie, keine „neuen“ Fehlerklassen. Freigabepflicht durch MRB. Vollständige Versionierung der Texte und Quellen.

Trade-offs, die man bewusst trifft

  • On-Prem statt Cloud:

+ Pro: Datenhoheit, Latenzkontrolle, kein Schrecken vor Audit/Tomorrow’s Policy Changes der Hyperscaler.
+ Contra: Man betreibt Hardware (GPU/Storage), pflegt Modelle, baut Monitoring selbst. Das ist kein „Fünf-Minuten-Setup“.

  • Modelldimension vs. Betriebsrealität:

+ Ein kleines deutschsprachiges 7B/8B-Modell mit gutem Prompting + starkem RAG schlägt in der OT oft ein „SOTA-Cloudmodell“, weil es deterministischer, schneller und kontrollierbarer läuft.
+ Für komplexe Reasoning-Aufgaben kann ein größeres Modell on-prem nötig sein – dann mit Batch-/Throughput-Planung, Pinning und Canary.

  • Genauigkeit vs. Latenz:

+ Temperatur 0, strikte Schema-Ausgaben senken Entropie und Fehler – können aber Antworten „starrer“ machen. Für produktive Toolpfade ist das ein Feature, kein Bug.

  • Autonomie vs. Freigaben:

+ Vollautonome Agenten in der OT sind illusorisch. Wer das verspricht, ignoriert Safety, Haftung und Audit. Die richtige Balance: hochautomatisierte Vorschläge, aber bewusste, nachvollziehbare Freigaben.

Test- und Qualitätssicherung, wie in der Software – nicht „Prompt-Magie“

  • Offline-Evaluation: Golden Datasets für typische Aufgaben (Arbeitsauftrag, Trendanalyse, WI-Zusammenfassung). Metriken: Tool-Call-Korrektheit, Policy-Verletzungsrate, Antwortvollständigkeit, Quellenabdeckung.

  • Prompt-/Policy-Tests in CI: Jeder Prompt- oder Policy-Change triggert E2E-Simulationen mit fixierten Seeds. Unterschiede werden als Diffs angezeigt und blockieren bei Regressionen.

  • Property-based Testing für Tools: Generiere zulässige/ungültige Parameterkombinationen, prüfe Validierung und Fehlerpfade.

  • Chaos-Tests: Tool weg, Broker latent, Index teilweise leer: Der Agent muss würdevoll degradieren – nie halluzinieren.

  • Red-Team-Prompts: Jailbreak-Versuche, Prompt Injection über RAG-Dokumente. Der Policy-Layer muss greifen (z. B. „Nie schreibe in MES ohne Freigabe – unabhängig vom Prompt“).

Wie das im Betrieb aussieht (Dataflow auf einer Seite)

  • Eingehend: Events aus MES („Order Completed“), Historian-Alarme, manuelle Requests am HMI.

  • Retrieval: Indexabfrage mit ABAC-Filter, Quellenliste inkl. Zugriffsetiketten.

  • Reasoning: LLM plant in ReAct-Schritten, ruft Tools auf, sammelt Belege, erzeugt Proposal.

  • Gate: Policy-Check -> optional Simulation -> Freigabe/Human-in-the-loop -> Ausführung durch Executor.

  • Logging: OpenTelemetry-Spans + Event-Store (Prompt, Tool-Calls, Outputs, Freigaben).

  • Monitoring: Dashboards für Toollatenz, Policy-Drops, Halluzinationsindikatoren (z. B. nicht referenzierte Quellen), Drift.

Minimal-invasiver Rollout-Plan

  • Phase 1: Read-Only-Assistent (RAG + Historian-Read). Keine Schreibrechte. Ziel: Vertrauen, Metriken, Workflows verstehen.

  • Phase 2: Schreib-„Proposals“ für Low-Risk-Aktionen (z. B. CMMS-Entwürfe). Vier-Augen-Freigabe, strikte Policies.

  • Phase 3: Teilautorisierte Ausführung nach Simulation (z. B. Auto-Erstellung von Ersatzteilanforderungen unter Kostenlimit).

  • Phase 4: Erweiterung des Toolkatalogs mit gleichbleibend harten Guardrails. Keine Abkürzungen.

Warum wir es so machen
Weil „KI im Shopfloor“ ohne harte Architekturdisziplin scheitert: entweder an Security/Compliance oder an mangelnder Akzeptanz. Ein Agent, der alles darf, wird in der OT zu Recht nie produktiv gehen. Ein Agent mit klaren Tools, Policies, Observability und sauberen Schnittstellen schafft dagegen echten Nutzen: weniger Kontextwechsel, schnellere Dokumentation, konsistentere Entscheidungen – ohne die Safety- und Audit-Grenzen zu reißen.

Werkzeugkasten und Bauprinzipien, die sich bewährt haben

  • Message-Bus in der DMZ als einziger Brückenkopf IT↔OT.

  • Tool-Adapter als eigenständige, getestete Services – niemals direkt aus dem LLM in ERP/MES.

  • Policy als Code (PDP/PEP-Pattern), ABAC mit Asset/Schicht/Standort-Tags.

  • Structured Output erzwungen, deterministische Decoding-Parameter.

  • Event-Store + Tracing als Erstbürger, nicht als Nachgedanke.

  • RAG mit Zugriffskontrolle am Index, nicht erst im Stream der Antwort.

Was wir nicht tun

  • Keine direkten SPS-Schreiboperationen über einen LLM-Agenten.

  • Keine Cloud-Abhängigkeit in der Inferenzkette für produktive Pfade.

  • Keine ungetesteten Prompt-Änderungen im Live-System.

  • Keine „One-Size-Fits-All“-Assistenten – Domänenkontext und Ontologien sind Pflicht.

Bezug zur Praxis
Die oben skizzierte Architektur entstammt realen Deployments in regulierten Umgebungen (Aviation, Bahn, Defense-nah, produzierende Industrie). Der Schlüsselfaktor für Akzeptanz war stets der Audit- und Governance-Aspekt: Maintenance- und Qualitätsleiter akzeptieren Agenten, wenn sie jederzeit sehen, warum ein Vorschlag entstand, welche Daten herangezogen wurden, und wenn klar ist, dass ohne ihre Freigabe nichts Kritisches passiert.