• Structured Tracing:
  • Jede Agenten-Aktion ist ein Span mit Typ (Prompt, Retrieval, Tool-Call, Parser, Decision), Timing, Eingaben/Ausgaben, Tokens, Kosten, Fehlerzustand, Herkunft (User, System, anderes Tool).
  • Spans sind gerichtete Kanten in einem Session-Graph.
  • Content Provenance:
  • Dokument-IDs, Indexpipeline-Hash, Chunk-Referenzen, Embedding-Version. Kein unreferenziertes “hat recherchiert”.
  • Policy Engine:
  • Harte Schranken: erlaubte Tools, Parametergrenzen (Timeouts, Token-Budgets), erlaubte Ressourcentypen, PII-Redaktion.
  • Sanfte Schranken: Heuristiken für “Fragen statt Halluzinieren” (z. B. bei Retrieval-Nulltreffern Rückfragen erzwingen).
  • Human Gates:
  • Konfigurierbare Checkpoints: z. B. vor ERP-Schreibzugriff, vor Bestellungen, vor Ticket-Schließung.
  • UI zum Abnicken, Korrigieren oder Ablehnen, inkl. Pflichtfeld “Warum?” für Feedback-Loops.
  • Evaluation Harness:
  • Golden Sets pro Use-Case (50–500 repräsentative, verifizierte Sessions).
  • Offline-Replays gegen neue Prompts/Policies/Modelle, Metrikberichte (Korrektheit, Policy-Verstöße, Kosten, Latenz).
  • Fallbacks:
  • Bekannte, deterministische Routen bei Unsicherheit: “Keine verlässliche Quelle → Kandidatenliste + Rückfrage statt finaler Antwort.”
  • Stabile Baseline ohne LLM für Kernpfade (z. B. strikt regelbasierte Router für triviale Tickets).

Kontrollmuster, die sich in der Praxis bewährt haben:

  • Double-Validation: Schema-Validator vor und nach dem LLM. Beispiel: Tool-Aufruf wird erst syntaktisch, dann semantisch validiert (z. B. dürfen keine Negativpreise entstehen).
  • Retrieval Contracts: Antworten nur auf Basis gekennzeichneter Quellen, explizit mit Zitaten in die UI. Kein “Freitext ohne Quelle”.
  • Budget-Enforcement: Laufzeit, API-Kosten, Tool-Aufrufe. Budget-Überschreitung zwingt in Degradierung oder Human Gate.
  • Safe Parsing: JSON-Schemas mit strikten Parsern; nie Regex frei im Nirwana. Bei Parse-Fehler: definierter Recovery-Dialog oder Abbruch.
  • Greylist statt Blacklist: Erlaubt ist, was explizit auf der Whitelist ist. Je kritischer der Pfad, desto enger die Liste.

4) Fallbeispiel: Wartungsassistent in der Fertigung

Problem: Ein Werk hat wiederkehrende Störungen an Antrieben. Tickets sind unstrukturiert, Wissen steckt in Wartungsprotokollen, Teilelisten und Herstellerhandbüchern. Ziel: Ein Assistenzsystem, das Tickets triagiert, Lösungsvorschläge aus Quellen herauszieht, ggf. Ersatzteile vorschlägt und Workorders vorbereitet – ohne Wildwuchs im ERP.

Betriebsarchitektur:

  • Input: Tickettext, Anlagen-ID, Sensor-Schnappschüsse (letzte 24h Kernsignale), Schicht, SLA.
  • RAG-Schicht: Index über geprüftes Material (Herstellerhandbuch, eigene SOPs, historische Lösungen). Versionskontrolle und Herkunfts-Hashes.
  • Reasoner: LLM-Agent mit Tools:
  • Retrieve(id, query, k)
  • Diagnose(match_signals)
  • ERP.read(assets, parts, history)
  • ERP.draft_workorder
  • ERP.propose_purchase
  • Policies:
  • Kein ERP.write ohne Human Gate.
  • Nur Teile aus freigegebenen Katalogen.
  • Keine Diagnose ohne mindestens zwei unabhängige Evidenzen (z. B. Dokument + Sensorpattern).
  • UI:
  • Claim-Evidence-View: “Vermutete Ursache: Lager 3 trocken” mit Zitaten, Sensor-Plot, Alternativen.
  • Aktionen: “Workorder-Entwurf prüfen”, “Teilevorschlag prüfen”, “Rückfrage stellen”.

Beobachtung und Iteration:

  • Erste Woche im Shadow-Mode (nur Vorschläge, keine ERP-Schreibrechte).
  • Telemetrie zeigt: In 12% der Sessions schlägt der Agent Teile vor, obwohl Retrieval keine eindeutige Quelle fand. Grund: Aggressiver Prompt; LLM extrapoliert statt zurückzufragen.
  • Fix:
  • Retrieval Contract verschärft: “Wenn keine Quelle mit Score > T, stelle Rückfrage; keine Teilevorschläge.”
  • Budget für Tool-Aufrufe gesenkt, um unnötiges “Halluzinations-Stöbern” zu vermeiden.
  • Human Gate erweitert: Teilevorschläge immer gated, selbst bei hoher Konfidenz, bis Golden Set stabil.
  • Ergebnis im Betrieb: Stabileres Verhalten, klarere Beweisführung. Die Crew akzeptiert mehr Vorschläge, weil jede Entscheidung auf Evidenz basiert und Abweichungen dokumentiert sind.

5) Governance ist ein Organigramm, kein PDF: Wer trägt welches Risiko?

Ein KI-System ohne klare Entscheidungsrechte ist ein Haftungsrisiko. Wir nutzen einfache, robuste Strukturen:

  • Rollen und Verantwortungen:
  • Product Owner Use-Case: Zieldefinition, Business-Abnahme, Änderungskontrolle.
  • Model Owner: Trainingsdaten, Versionierung, Metriken, Shift-Erkennung.
  • Data Steward: Datenqualität, Katalog, Zugriff.
  • Operations (SRE/DevOps): Verfügbarkeit, Telemetrie, Incident-Response.
  • Fachverantwortliche: Review und Freigaben an Human Gates.
  • Legal/Compliance: Policies, Aufbewahrungsfristen, DPIA/Datenschutzkonzepte.
  • Entscheidungsrechte:
  • Wer darf überschreiben? In welchen Fällen ist “Override” Pflicht?
  • Wer akzeptiert Restrisiko? Dokumentierter “Risk Acceptance” pro Release.
  • Change Management:
  • Jede Änderung an Modell/Prompt/Policy durchläuft:

1) Offline-Tests gegen Golden Set,
2) Shadow-Mode,
3) Canary-Rollout mit Metrik-Gates,
4) Vollausrollung mit Revert-Plan.

  • Audit-Trail:
  • Pro Entscheidung: Input, Artefakte, Modell-/Indexversionen, Policies, Human-Interaktionen, Ergebnis.
  • Aufbewahrung on-prem, durchsuchbar, exportierbar. Ohne vollständigen Trail sind Post-Mortems wertlos.
  • Incident-Playbooks:
  • “Verdächtige Autonomie erkannt” → Sofortmaßnahmen: Budget auf 0, Gates auf “immer”, UI-Banner “Degradierter Modus”, Root-Cause-Analyse anhand Traces.
  • “Daten-Drift” → Automatisch erhöhtes Routing in Review, Alarm an Model Owner.

6) Souveränität ist Betriebsbedingung: Warum On-Prem mehr als Datenschutz ist

Souveräne KI heißt: Sie kontrollieren Daten, Modelle, Ausführung und Telemetrie. On-Prem (inkl. private Cloud/Edge) ist dafür das robusteste Betriebsmodell in Industrien, in denen Datenabfluss oder US-Cloud-Abhängigkeit nicht akzeptabel sind. Praktische Gründe:

  • Reproduzierbarkeit: Gleiche Artefakte (Modelle, Indizes, Policies) in Dev/Stage/Prod. Kein “versteckter” Managed-Service-State.
  • Luftspalt-Fähigkeit: Systeme lassen sich ohne Internet betreiben und aktualisieren.
  • Telemetrie vor Ort: Sensible Traces verlassen das Werk nicht. Aggregierte Metriken können exportiert werden, Rohdaten bleiben lokal.
  • Supply-Chain-Kontrolle: Von Trainingsdaten bis Container-Images – Signaturen und SBOMs sind prüfbar.

LLM-Agenten-Observability und Governance in der Praxis bündeln wir in einer Plattform-Disziplin: ein Observability- und Policy-Layer, der genau die oben beschriebenen Traces, Gates, Budgets, Evaluationsläufe und Audit-Trails bereitstellt – on-prem, DSGVO-konform, ohne externe Cloud-Abhängigkeiten. Entscheidend ist nicht das Tooling-Etikett, sondern dass Ihre Pipeline diese Kontrollpunkte tatsächlich erzwingt und nachvollziehbar macht.

7) UI für Vertrauen: Drei konkrete Interaktionsmuster