Harte Grenzen für smarte Agenten: LLM-gestützte Instandhaltung on-premise betreiben, ohne Produktionsrisiken zu erhöhen

Einstieg
Viele Werke experimentieren mit „Wartungs-Assistenten“, die Betriebsanleitungen zusammenfassen, Ersatzteile vorschlagen oder Tickets im EAM anlegen. Auf dem Papier klingt das wie ein schneller Effizienzgewinn. In der Praxis scheitern diese Projekte oft an zwei Dingen: fehlende Souveränität (Daten verlassen das Werk, Blackbox-Modelle, keine Auditierbarkeit) und fehlende Deterministik (der Agent macht „smarte“ Dinge, aber nicht immer die gleichen). Dieser Artikel beschreibt eine Architektur, mit der LLM-Agenten in der Instandhaltung on-premise, DSGVO-konform und deterministisch betrieben werden können – inklusive Governance, Observability und klaren Abbruchkriterien, bevor ein Agent Schaden anrichtet statt zu helfen.

Kernthese: In industriellen Umgebungen ist ein „Chatbot“ kein Produkt. Ein LLM-Agent ist ein Softwarebaustein mit harten Grenzen. Wer Governance, Observability und deterministische Flows nicht zuerst baut, verlagert Risiko von der Infrastruktur in die Produktion.

1) Die richtigen Use Cases: Beratend statt steuernd
Bevor wir Technik stapeln, ein Abgrenzungspunkt aus der Praxis:

  • Beratend (empfohlen für den Start):
  • Kontextualisierte Anleitungen: Schritt-für-Schritt-Anweisungen aus OEM-Handbüchern für die konkrete Seriennummer und Firmware-Version.
  • Fehlertriage: Aggregation aus Alarmspeichern/Meldungslisten plus Vorschläge für Prüfsequenzen.
  • Teile-/Stammdatenabgleich: EAM-Check (z. B. Lagerbestand, kompatible Varianten), mit Quellenangabe.
  • Dokumentationsautomatisierung: Vorbefüllen von Störmeldungen inkl. Anlagenkontext und verlinkten Evidenzen.
  • Steuernd (kritisch, nur mit externer Freigabe):
  • Automatisiertes Ändern von Sollwerten, Anstoßen von Rezeptwechseln, Durchführen von Kalibrierroutinen.
  • Jegliche Schreibzugriffe in OT-Netzen ohne zweistufige Freigabe sind No-Go für den MVP.

Unser Pattern: Der Agent erzeugt maximal „Handlungsvorschläge mit Belegen“ und kann Tickets vorbereiten. Alles, was physisch wirkt, bleibt hart durch Rollen, Policies und menschliche Quittierung getrennt.

2) Architekturübersicht: On-Prem-Stack mit deterministischem Agent-Graph
Zwei Ebenen trennen wir strikt:

  • Datenebene (Data Plane):
  • Dokumentenbasis: technische Handbücher, SAP-PM-/Maximo-Daten, Wartungspläne, Störungshistorie, Sensordatenaggregationen, HSE-Vorschriften.
  • Indexierung: strukturwahrendes Chunking, Metadaten (Anlagentyp, Seriennummer, Gültigkeitszeitraum, Sprache, Werk).
  • Vektorindex: on-prem, per-Werk segmentiert; keine zentrale, werksübergreifende Ähnlichkeitssuche ohne explizite Freigabe.
  • Tooling-Gateways: strikte, typisierte Schnittstellen zu EAM, Historian, MES mit Circuit Breakern, Idempotenz und Rate Limits.
  • Kontrollebene (Control Plane):
  • Modelllaufzeit: lokales LLM mit vordefinierten Dekodierparametern (z. B. Temperature 0–0,2, Top-p < 0,3), Grammatik-/JSON-Zwang für Tool-Aufrufe.
  • Agent-Orchestrierung: deterministischer Workflow-Graph (DAG) statt freier Planung. Beispiel-Knoten: Retrieve -> Ground -> Validate -> ToolCall -> Summarize -> Cite.
  • Policy-Engine: Who/What/Where – welche Aktionen dürfen in welchem Werk, für welche Role, an welchen Systemen.
  • Observability & Governance: Prompt-/Policy-Versionierung, Telemetrie, Replay, Offline-Evaluation, Canary-Rollouts, Kill-Switch.

Diese Trennung erlaubt harte Zusagen: Gleiche Eingabe + gleiche Revision von Prompt/Policies + gleicher Indexstand -> gleiche Ausgabe. Alles ist versioniert und reproduzierbar.

3) Datenaufbereitung richtig gemacht: Retrieval dominiert die Qualität
LLM-Generierung ist selten das Problem. Die Qualität kippt beim Retrieval. Drei Regeln:

  • Strukturwahrendes Chunking:
  • Wir schneiden nicht stumpf nach Token-Länge. Abschnitte folgen Dokumentstruktur (Kapitel -> Abschnitt -> Tabelle/Abbildung).
  • Jedes Chunk erhält Anlagentyp, Seriennummer-Klassen, Gültigkeitsfenster, Sprachkennung, Quelle (Datei-Hash, Seitenbereich).
  • Tabellen werden zusätzlich als „extrahierte Records“ hinterlegt (z. B. Drehmomenttabellen als key-value) für präzisere Antworten.
  • Filter vor semantischer Suche:
  • Erst filtern wir streng nach Metadaten (Werk, Asset-Klasse, Firmware-Major), dann semantisch ranken.
  • So verhindern wir „Werk A liest Werk B“-Lecks und reduzieren False Positives.
  • Re-Ranking und Zitieren:
  • Top-k semantisch, dann Re-Ranking mit einem präzisen Scoring (kann ein kompakter Cross-Encoder oder regelbasiert sein).
  • Der Agent muss jede Aussage auf 1–3 Belege zurückführen. Fehlen Belege, muss er „unklar“ sagen.

4) Tool-Aufrufe: Typisiert, begrenzt, mit Circuit Breakern
LLM-Agenten kochen über, wenn Tooling unkontrolliert ist. Unser Muster:

  • Typisierte Tools:
  • Jeder Tool-Call ist ein strikt validiertes JSON-Schema mit Grenzwerten (z. B. Zeitraum ≤ 24 h, max. 100 Records).
  • Eingaben werden serverseitig hereinsaniert; der Agent bekommt Fehlermeldungen mit Gründen (nicht nur 500).
  • Allow-/Deny-Listen:
  • Whitelisted Endpunkte pro Rolle/Werk. Kein Discovery aus Agent-Sicht.
  • Idempotenz & Audits:
  • Schreibende Operationen (z. B. Ticket anlegen) bekommen idempotency_key und Dry-Run-Modus.
  • Jeder Call ist auditierbar: Zeit, Nutzer, Prompt-Hash, Policy-Revision, Tool-Version, Ergebnis-Hash.
  • Circuit Breaker:
  • Timeouts pro Tool, Bulkhead-Isolierung pro Domäne (EAM getrennt von Historian).
  • Fallback auf read-only, falls Schreibpfad instabil.

5) Agent-Design: Workflow statt „kreativer“ Langzeitplanung
Freiform-Agenten (Chain-of-Thought, Multi-Tool-Exploration) sind im Enterprise attraktiv, aber in OT-Randnähe falsch. Unser Ansatz:

  • Deterministischer DAG:
  • Schritt 1: Kontext zusammenstellen (Asset, Fehlermeldung, letzte Maßnahmen).
  • Schritt 2: Retrieval (Filter -> semantisch -> Re-Ranking).
  • Schritt 3: Grounding: Antworten ausschließlich aus Zitaten generieren; keine extrapolierten Behauptungen.
  • Schritt 4: Optionale Tools (EAM-Lookup, Historian-Query) mit klaren Limits.
  • Schritt 5: Zusammenfassung mit Quellen, Konfidenz-Heuristik (z. B. Coverage der Zitate, Widerspruchserkennung).
  • Schritt 6: Ausgabe in strengem Schema (z. B. Steps[], RequiredTools[], SafetyNotes[], Citations[]).
  • Kontrollierte „Intelligenz“:
  • Maximal 1–2 Reflexionsschleifen mit hartem Token-Limit.
  • Keine autonom initialisierten Tool-Sequenzen; Tool-Calls sind im Graph vordefiniert.
  • Dekodierdisziplin:
  • Niedrige Temperatur, deterministische Sampling-Pfade.
  • Grammar-constrained Decoding für JSON-Ausgaben.

6) On-Prem-Betrieb: Souveränität ist eine Architekturentscheidung
Warum wir konsequent on-prem gehen: