Wenn Sie ein solches System aufsetzen möchten: Starten Sie klein, on-prem, mit realen Dokumenten und echten Prozessereignissen. Messen Sie jede Interaktion. Und bauen Sie Ihre Policies nicht als „Excel-Matrix“, sondern als ausführbare, getestete Regeln. Wir unterstützen bei Anforderungsaufnahme, Architektur, Implementierung und Qualitätssicherung – inklusive einer Observability- und Governance-Schicht für LLM-Agenten (→ alpitype.de/leistungen/).

Fazit
LLM-Agenten sind in der Fertigung sinnvoll – aber nur als streng reglementierte Orchestrierer mit klaren, getesteten Tools, On-Prem-Governance und voller Observability. Alles andere ist ein Sicherheitsrisiko oder ein Pilot, der nie produktiv geht. Meine Position ist klar: Kein produktiver Agent ohne Policy-Engine, Executor-Gate und revisionssichere Laufwerksdaten. Cloud-first, „move fast“-Agenten gehören nicht in die OT. Souveränität und Determinismus schlagen „SOTA“ – jeden Tag.

FAQ – häufige technische Fragen

1) Wie verhindere ich, dass ein Agent „aus Versehen“ auf eine SPS schreibt?

  • Erstens: Der Agent hat physisch/logisch keinen Pfad zu Safety/PLC-Aktoren. OT-Schreibzugriffe sind im Netzwerk geblockt.

  • Zweitens: Schreiboperationen laufen ausschließlich als Proposal an einen separaten Executor-Dienst.

  • Drittens: Der Executor kennt Whitelists (z. B. nur MES/CMMS-APIs, ggf. exakt definierte OPC UA-Parameter-Nodes ohne Safety-Relevanz) und erzwingt Policy-Prüfungen, Simulationen und Freigaben.

  • Viertens: Tool-Adapter sind strikt typisiert; ein „WriteVarSet“ akzeptiert nur erlaubte Variablen und Wertebereiche, sonst Fail-Closed.

2) Wie setze ich Zugriffskontrolle im RAG um, ohne die Treffergenauigkeit zu ruinieren?

  • Dokumente werden beim Ingest mit Sicherheitslabels versehen (z. B. Werk/Schicht/Programm). Diese Labels werden auf Chunk-/Vektor-Ebene mitgeführt.

  • Bereits beim Retrieval werden Kandidaten nach ABAC gefiltert (Attribut des Nutzers/Agents + Asset-Kontext), erst dann gerankt.

  • Der Agent bekommt die Quellenliste zwingend zurück und muss verlinken; Antworten ohne referenzierte, berechtigte Quellen werden verworfen.

3) Wie auditiere ich Agentenläufe revisionssicher?

  • Jeder Lauf hat eine Run-ID. Gespeichert werden: Prompt, Modell-/Prompt-Version, verwendete Policies, Kontextdokumente (Hashes), Tool-Calls inkl. Parameter/Responses, Zeitstempel, Signaturen, Freigaben.

  • Die Daten landen in einem Event-Store/WORM-Storage mit Retention-Policy. Dashboards visualisieren Pfade; Exporte für Audits sind reproduzierbar.

4) Wie dimensioniere ich Hardware für on-prem LLMs?

  • Daumenregeln: Kleine deutschsprachige 7–8B-Modelle lassen sich oft im Bereich 8–16 GB VRAM (mit 8-/4-Bit-Quantisierung) betreiben; 13B-Modelle benötigen entsprechend mehr. Für mehrere gleichzeitige Sessions kalkulieren Sie Puffer ein und planen Sie Batch/Throughput bewusst.

  • Für reine RAG/FAQ-Aufgaben reichen oft kleine Modelle mit guter Wissensbasis. Für komplexes Reasoning einzelne größere Knoten – aber immer mit Version-Pinning und Canary-Rollouts.

5) Welche Standards sollte ich berücksichtigen?

  • Sicherheitsarchitektur: IEC 62443 (Zonen/Konnektoren).

  • Produktions-Stack: ISA-95-Schichtenmodell (Zuordnung von Verantwortlichkeiten).

  • OT-Protokolle: OPC UA (inkl. Subscriptions), MQTT Sparkplug B, Historian-APIs. Für Vision: RTSP/GStreamer.

  • Governance: „Policy as Code“-Pattern (PDP/PEP), OpenTelemetry-Standards für Tracing/Metriken.

Wenn Sie die oben genannte Architektur konsequent umsetzen, erhalten Sie einen Agenten, der Mehrwert schafft, ohne die roten Linien der OT zu überschreiten. Genau das bauen wir: souveräne, on-prem betreibbare KI-Systeme mit klarer Governance, robusten Integrationen und testbaren Garantien (→ alpitype.de/leistungen/).