LLM-Agenten in der Fertigung: Architektur für deterministische Tool-Ausführung, On-Prem Governance und Auditierbarkeit

In der Produktion funktionieren „smarte Assistenten“ nur, wenn sie deterministisch, auditierbar und strikt getrennt von sicherheitskritischen Steuerungen arbeiten. LLM-Agenten, die unkontrolliert auf MES, Historian oder gar SPS schreiben, sind in der OT ein Sicherheits- und Compliance-Risiko. In diesem Artikel zeige ich eine praxiserprobte Architektur, wie man LLM-Agenten auf dem Werkgelände (ohne US-Cloud), mit klaren Guardrails, Policy Enforcement und vollständiger Observability betreibt – und wo die harten Grenzen liegen.

Das Problem, präzise benannt

  • LLMs sind probabilistisch. OT erwartet deterministische, nachvollziehbare Entscheidungen.

  • Produktionsumgebungen sind segmentiert (IT/OT), offline/partiell offline und unterliegen Change- und Audit-Pflichten (z. B. für Luftfahrt oder Bahn).

  • Ohne Governance schleicht sich „Function Creep“ ein: Ein anfänglich reiner FAQ-Bot bekommt „mal schnell“ Schreibrechte ins MES – bis der erste falsche Auftrag im Shopfloor landet.

  • Halluzinationen sind in der Fertigung nicht „nur peinlich“, sie sind teuer und potenziell gefährlich.

Zielarchitektur: Agentik als kontrollierte Orchestrierung, nicht als Autopilot
Der Agent ist nicht der Operator. Er ist ein Orchestrierer, der Vorschläge generiert, Daten zusammenführt, Dokumentation skaliert – und nur über strikte, typisierte Tool-Adapter mit Produktionssystemen interagiert. Schreiboperationen passieren nur über einen gesicherten „Executor“-Pfad mit Policy-Prüfung, optionaler Simulation und Freigabe.

Kernelemente der Architektur (On-Prem, souverän, auditierbar)
1) Segmentierung und Netzarchitektur

  • IT/OT-Trennung: Agentik-Cluster (z. B. Kubernetes/k3s/Openshift on-prem) in IT-Zone; Brücke zur OT über gesicherte DMZ. Nur explizit freigegebene Protokolle/Topics.

  • Broker-Pattern: MQTT (Sparkplug B) oder ein industrietauglicher Message-Bus in der DMZ. Subset aus OT (Read-Only) geht Richtung Agentik. Schreibintents gehen in die Gegenrichtung ausschließlich als „Proposal“-Events, niemals als direkte Aktor-Kommandos.

  • Keine direkte SPS-Steuerung: Der Agent schreibt nie auf Safety- oder Prozess-I/Os. Wenn überhaupt, nur auf MES/CMMS-Ebene (z. B. Arbeitsauftrag anlegen), nie an sicherheitskritische Steuerungen.

2) Tool-Adapter statt „beliebige“ Funktionsaufrufe

  • Jedes Tool (z. B. „MES_AnlegenArbeitsauftrag“, „SAP_PM_Bestellung“, „Historian_QueryTrend“, „OPC_UA_ReadVarSet“) ist ein separater, deterministischer Microservice mit strengem JSON-Schema (Input/Output), gRPC/HTTP-Schnittstelle und Idempotency-Key.

  • Strenge Typisierung: Validierung via z. B. Pydantic/JSON Schema. Agenten-Aufrufe werden vor Ausführung gegen Schema, Wertebereiche und Whitelists geprüft.

  • Timeouts, Rate-Limits, Circuit-Breaker: Kein Tool kann die Anlage fluten oder „hängen“.

  • Versionierung: Tool-Schnittstellen sind versioniert; Breaking Changes erfordern Pipeline-Update inkl. Tests.

3) Policy Enforcement und Freigaben

  • Zentrale Policy Engine (z. B. OPA-Pattern als PDP): Wer/was darf welches Tool mit welchen Parametern ausführen? Kontextbasiert (Schicht, Linie, Asset-Tags).

  • Write-Path immer zweistufig:

a) Proposal: Der Agent erzeugt einen signierten Vorschlag (Intent, Parameter, Begründung, Quelle).
b) Executor: Separater Service prüft Policy, führt optional Simulation/„Dry Run“ aus (auf digitalem Zwilling oder mit aufgezeichneten Daten) und verlangt Freigabe (Vier-Augen-Prinzip) für schreibende Aktionen.

  • Reproduzierbarkeit: Prompt, Kontextfenster, Modell-Hash, Policies und Tool-Responses werden als unveränderlicher Run in einem Event-Store gesichert.

4) Observability und Governance (Agentenlaufwerk statt „Black Box“)

  • Vollständiges Tracing pro Agentenlauf: Prompt, RAG-Kontextquellen, Tool-Calls, Latenzen, Rückgaben, Abweichungen zu Golden-Runs, Token-Metriken.

  • OpenTelemetry-Pattern: Spans für Inferenz, Retrieval, jedes Tool. Metriken für Fehlerraten, Tool-Verteilung, „Surprisingness“ (z. B. plötzliche, unübliche Parametrisierung).

  • Modell-/Prompt-Registry: Harte Versionierung, Pinning, Canary-Rollouts. Jede Änderung mit Ticket, Review, automatischer Offline-Eval (Golden Dataset).

  • Audit-Trails: Schreibintents, Freigaben, abgelehnte Aktionen mit Gründen und Signaturen – revisionssicher.

5) RAG unter Zugriffskontrolle

  • On-Prem Indexe: Dokumente (SOPs, Wartungsanleitungen, NCR-Reports) werden mit Security-Labels eingebettet. Keine Cloud-Abhängigkeiten.

  • ABAC für Retrieval: Der Query-Kontext führt Benutzer-/Asset-Tags mit. Der Retriever filtert Kandidaten vor dem Ranking. Keine „post-hoc“-Zensur, sondern „pre-filtering“ am Index/Query-Layer.

  • Layout-bewusste Chunking-Strategien (Tabellen, Explosionszeichnungen), damit der Agent Schritt-für-Schritt-Anweisungen korrekt extrahiert.

6) LLM-Ausführung so deterministisch wie möglich

  • Temperature 0, begrenzte Top-p. Keine „kreative“ Entropie für produktive Pfade.

  • Strikte Function-Calling/Structured Output: Constrained Decoding (JSON), damit das Parsing nicht driftet.

  • Nicht-blockierende Planung: ReAct/Toolformer-Pattern, aber mit Schrittgrenzen und Deviation-Guards (z. B. maximal N Tool-Versuche).

  • Fallbacks/Degradations: Wenn Tools nicht verfügbar sind, liefert der Agent eine begründete, lesbare Fehlermeldung – keine Halluzination über vermeintliche Ergebnisse.

7) Datenpfade zu OT-Systemen: nur über bewährte Protokolle

  • Lesen: OPC UA (Subscriptions), Historian-APIs, MQTT Sparkplug B. Video/Visionsysteme via RTSP/GStreamer – aber CV-Inferenz bleibt getrennt vom LLM.

  • Schreiben: MES-/CMMS-REST/gRPC, Message-Bus-„Proposal“-Topics. OPC UA Write nur an dedizierte, freigegebene Parameternodes (keine Safety, kein Bypass von Freigaben).

8) Sicherheit und Lieferkette

  • Keine externe Abhängigkeit zur Laufzeit: Modelle, Tokenizer, Embeddings on-prem, offline aktualisierbar.

  • Artefakt-Integrität: Hashes, SBOM, signierte Container-Images.

  • Secrets im Vault, kurzlebige Credentials. Netzwerk-Segmentation, „Default Deny“ in Policies.

  • IEC 62443-orientierte Zonen/Konnektoren. ISA-95-Alignments (Schichtenmodell) für Verantwortlichkeiten.

Konkrete Einsatzszenarien