Sobald LLMs oder Agenten Werkzeuge im System ansteuern, braucht es strikte Leitplanken. In Produktionsumgebungen setzen wir auf On-Prem-Observability und -Governance von Agentenläufen:

  • Rollen- und Policy-Engine: Wer darf was ausführen, mit welchen Ressourcen, Zeit- und Budgetgrenzen.

  • Tool-Access-Whitelist: Agenten können nur freigegebene Tools/Endpunkte nutzen, mit klaren Nebenwirkungsgrenzen.

  • Prompt- und Kontext-Versionierung: Jede Ausführung referenziert eine Prompt-/Kontextversion; Konfigurationen sind reproduzierbar.

  • Lauf-Logging mit PII-Reduktion und Audit-Trail: Vollständige Nachvollziehbarkeit ohne Datenschutzverletzungen.

  • Red-Teaming und sichere Defaults: Standardmäßig „advisory-only“, Eskalationen erfordern explizite Freigaben.

Als Produkt setzen wir hierfür Alpi-M ein – eine On-Prem-Plattform für Observability und Governance von LLM-Agenten. Der Punkt ist weniger das Tool, sondern die Tatsache, dass Agentenläufe in regulierten Branchen ohne zentrale, auditierbare Steuerung nicht in den Betrieb gehören.

Technical Ownership: Das fehlende Bindeglied

Product Ownership löst keine Systemrisiken. Technical Ownership bedeutet End-to-End-Verantwortung über:

  • Architektur und Schnittstellenverträge (inkl. Stabilitätsversprechen und Evolutionspfade),

  • Nichtfunktionale Anforderungen (Determinismus, Latenz, Testbarkeit, Operabilität, Datenhoheit),

  • Assurance-Backlog und Nachweisstrategie,

  • Betriebsmodell (On-Prem, Air-Gap, Updatefluss, Rollback, Telemetrie, Incident-Playbooks),

  • Lieferkette (Dependencies, SBOM, reproduzierbare Builds, signierte Artefakte).

Praktiken:

  • Architekturentscheidungen als ADRs mit Konsequenzen und Trade-offs. Keine stillen Weichenstellungen.

  • Change Impact Analysis bei jeder relevanten Änderung auf Risiko, Testumfang, Dokumentation, Operator-Training.

  • RACI für sicherheitsrelevante Entscheidungen. Wer akzeptiert welches Risiko?

  • Budget für das „Unsichtbare“ fix einplanen: Observability, Testsysteme, Datenkuratierung, Tooling-Härtung.

  • Keine Blackbox-Integrationen ohne Isolationskonzept und Akzeptanztests. Eingekaufte Komponenten laufen hinter klar begrenzten Adaptern, nie tief im Kern.

MVP in sicherheitskritischen Systemen: Nicht „Minimal Product“, sondern „Minimaler Nachweis“

Ein MVP, das im Labor hübsch aussieht, aber kein sicheres Rollout erlaubt, ist wertlos. Zielzustand:

  • MVSC – Minimum Viable Safety Case: Ein minimaler, aber vollständiger Faden vom Risikoannahmenkatalog bis zur Verifikation auf der Zielumgebung. Schlank, aber geschlossen.

  • Shadow Mode vor Active Mode: Einsatz im Feld ohne Aktorenfreigabe. Wir sammeln Telemetrie, Override-Raten (durch menschliche Operatoren) und messen den Nutzen ohne Risiko.

  • Interface Freeze früh: Die äußeren Verträge werden stabilisiert, der innere Algorithmus darf iterieren. So kann man parallel Nachweise und Betriebsmittel aufbauen.

  • Instrumentation First: Bevor die Funktion „wirkt“, misst sie. Ohne Telemetrie kein Rollout.

  • Degradationsplan: Was passiert bei Unsicherheit, Fehlern, Ressourcenmangel? Dieser Plan wird getestet, nicht nur beschrieben.

On-Prem- und Souveränitätsanforderungen pragmatisch umsetzen

In Defense, Bahn und Industrie ist On-Prem kein Glaubenssatz, sondern betriebliche Notwendigkeit. Daraus folgen konkrete technische Anforderungen:

  • Air-Gap-fähiger Supply-Chain-Flow: Eigener Container- und Artefakt-Registry, kuratierte Base-Images, immutablen Tags, signierte Manifeste, SBOM-Erzeugung und -Prüfung, Repro-Builds, wiederholbare Toolchains. Keine Pulls aus dem Internet im Produktionsnetz.

  • Trainings- und Auswertungsumgebungen on-prem: Daten bleiben lokal, Modellartefakte werden signiert und durch den gleichen Promotionsfluss wie Code bewegt.

  • Secrets- und Schlüsselverwaltung lokal: Keine Abhängigkeit von externen KMS.

  • Observability lokal: Metriken, Logs, Traces und Audit-Daten werden on-prem aggregiert und aufbewahrt. Export nur nach Freigabe.

  • Betriebsstandard ohne US-Cloud-Abhängigkeiten: Nicht aus Prinzip, sondern um Hoheit, Verfügbarkeit und rechtliche Klarheit zu sichern.

Praktischer 16-Wochen-Blueprint bis zum ersten sicheren Feldtest

Ziel: Advisory-Only-Deployment in einer realen Umgebung, mit messbarem Nutzen und belastbarem Assurance-Faden.

Wochen 1–4: Fundament

  • Risiko-/Annahmenkatalog skizzieren; welche Gefährdungen mitigiert der Sicherheitskern, welche nutzt der Advisor?

  • Architektur-Partitionierung festzurren; Schnittstellenverträge grob definieren; erste ADRs.

  • Pipeline-Grundgerüst: Repo-Layout, Evidence-as-Code-Konventionen, SBOM-Generierung, Signaturkette, Contract-Test-Harness.

  • Observability-Schema: Welche Metriken, welche Events, wie werden sie gespeichert und visualisiert?

  • Datenpfad festlegen: Dataset-Versionierung, Lab-Umgebung, Repro-Trainingskonfigurationen.

Wochen 5–8: Kern + Advisor lauffähig

  • Sicherheitskern als lauffähiges Skelett (Dummy-Strategie, Failsafe, Watchdog).

  • Advisor-Container mit erstem Modell/Heuristik; Schnittstelle implementiert; Konfidenzsignale und Telemetrie vollständig.

  • Simulation und ggf. HIL aufsetzen; Golden-Datasets und Grundszenarien.

  • Definition of Done++ operationalisieren; erster End-to-End-Durchstich mit vollständigen Evidence-Artefakten.

Wochen 9–12: Härten und Messen

  • Fehlerinjektion, Lasttests, Timingvariation, Fault-Isolation validieren.

  • Evaluationsberichte mit Kostenprofilen für Fehlentscheidungen; Gate-Kriterien für Shadow Mode definieren.

  • Operator-Interface für Overrides und Feedback; Audit-Trail prüfen.

  • Alpi-M oder äquivalente Governance für Agenten/LLMs einbinden, falls relevant.

Wochen 13–16: Shadow Mode im Feld

  • Rollout in Ring 0 (ein Standort, definierte Nutzergruppe), advisory-only.

  • Metrikziele: Override-Rate, Latenzen, Abdeckungsgrad der Szenarien, Stabilität des Kernels unter Störung.

  • Tägliche Promotionsentscheidung an harten Kriterien; Rollback jederzeit möglich.

  • MVSC-Stand prüfen; Lücken im Assurance-Backlog schließen. Entscheidungsvorlage für nächsten Gate (begrenzt aktive Funktion oder Ausweitung Shadow Mode).

Diese 16 Wochen liefern kein „fertiges“ zertifiziertes System – sie liefern eine validierte Architektur, einen belastbaren Assurance-Faden, ein messbares Nutzen-/Risikoprofil und ein Betriebsmodell, das in regulierten Umgebungen tragfähig ist.

Konkrete technische Leitplanken für den Alltag