Ein praktikables Telemetrie-Schema nutzt Event-Sourcing:

  • Append-only Log pro Session und pro Agent-Version

  • Stark typisierte Events (PromptIssued, ToolCalled, ContextRetrieved, PolicyViolated, HumanApproved, OutputDelivered)

  • Versionierte Schemata, signierte Artefakte (Modell, Prompt, Policy), um bei Audits eindeutig zuordnen zu können

Governance-Policies als Code
Policies sollten nicht „in die Prompts“ geschrieben werden, sondern als explizite Regeln vor und hinter das Modell. Beispiel einer einfachen, maschinenlesbaren Policy:

{
“name”: “safety_and_data_policy_v3”,
“rules”: [
{ “if”: { “ticket.severity”: “safety_critical” },
“then”: [“require_human_approval”, “log_evidence_pack”] },
{ “if”: { “tool.name”: “web_search” },
“then”: [“deny”, “reason:external_egress_disallowed”] },
{ “if”: { “answer.has_sources”: false },
“then”: [“defer”, “route:research_queue”] }
]
}

Solche Policies laufen deterministisch, sind testbar und trennbar von Prompt-Änderungen. Sie bilden die Grundlage für Haftbarkeit: Man kann belegen, dass die KI nie außerhalb klar definierter Leitplanken agierte.

Evaluieren im Trockendock
Bevor ein Agent live geht:

  • Behavior-Testsuite mit realistischen Aufgaben, Edge-Cases, Red-Team-Szenarien (Prompt-Injection, Tool-Abuse, Datenlücken)

  • Golden-Questions mit deterministischer Erwartung, inklusive erlaubter Variabilität im Wortlaut, aber fester Tool- und Quellenanforderung

  • Canary-Prompts im Betrieb, um Drifts früh zu erkennen

  • Offline-Replays realer Sessions gegen neue Versionen (Modelle, Prompts, Policies) mit Diff der Outcomes

Operative Dashboards sollten nicht nur LLM-Metriken zeigen, sondern Entscheidungsmetriken:

  • Anteil Entscheidungen mit menschlicher Freigabe

  • Zeit bis Freigabe

  • Eskalationsrate je Schicht/Zeitfenster

  • Ursachenbäume für Deferrals (Policy-bedingt, Quellenabdeckung, Tool-Fehler)

Alpi-M als Plattform für Observability und Governance
Wir entwickeln mit Alpi-M eine Plattform, die genau diese Anforderungen adressiert: LLM-Agenten und komplexe KI-Workflows werden als beobachtbare, kontrollierbare Systeme betrieben – on-premise, DSGVO-konform, ohne US-Cloud-Abhängigkeit. Kernprinzipien sind Ereignisprotokollierung, Policy-as-Code und revisionssichere Nachvollziehbarkeit. Für Industrien, in denen Souveränität nicht verhandelbar ist, ist das die Basis, nicht die Kür.

4) Governance und Verantwortung: Wer haftet, wenn die KI falsch liegt?

Governance muss den juristischen und operativen Pfad abbilden – von der Idee bis zur Incident-Aufarbeitung.

Rollen und Verantwortlichkeiten

  • Product/Process Owner: definiert Entscheidungsrechte der KI, Abbruchkriterien, Fallback-Prozesse.

  • Data/ML Owner: verantwortet Datenqualität, Trainings-/Eval-Kriterien, Modellversionierung.

  • Ops Owner: verantwortet Laufzeitumgebung, Monitoring, Incident Response.

  • Approval Roles: definierte Personen/Gruppen, die Freigaben bei Safety-/Compliance-relevanten Aktionen erteilen.

Safety Case und Dokumentation

  • Hazard-Analyse je Entscheidungsklasse, inkl. Fehlermodi und Mitigations (Policy, HITL, technische Schranken).

  • Change-Logs zu Modellen, Prompts, Policies, Datenpipelines – signiert, auditierbar.

  • Traceability: Von Entscheidung zurück auf Daten, Modell, Policy und Mensch, der freigegeben hat.

Rollout-Strategie

  • Shadow-Mode: KI beobachtet, entscheidet „für sich“, Ergebnisse werden nur mitgeloggt.

  • Recommendation-Only: KI schlägt vor, Mensch entscheidet; Metriken stabilisieren.

  • Phasenweise Autonomie: Nur für risikoarme Entscheidungen; Safety-Entscheidungen bleiben freigabepflichtig.

Incident-Management

  • Eindeutige Meldeschwellen (z. B. sprunghafte Eskalationsraten, Policy-Verletzungen).

  • Playbooks: Sofortmaßnahmen (z. B. Agent deaktivieren, nur Deferral zulassen), Root-Cause-Analyse anhand Event-Logs, Korrekturmaßnahmen.

  • Lessons Learned in Eval-Sets und Policies zurückführen.

5) Architektur: On-Premise als Grundlage für Souveränität

In unseren Projekten trennt sich die Architektur in Control Plane und Data/Execution Plane – beide on-premise oder in einer souveränen Private Cloud.

Control Plane

  • AuthN/AuthZ via OIDC, fein granulare Rollen für Agenten, Tools, Benutzer

  • Policy-Engine als eigenständiger Service, sprachagnostisch

  • Registries für Modelle, Prompts, Policies, Tools (signierte Artefakte, SBOM)

  • Observability-Stack mit Event-Store (append-only), Query-Layer, Dashboards, Alarmierung

Data/Execution Plane

  • Modell-Serving (z. B. C++/Rust/Go-Microservices für CV/TS, dedizierte LLM-Server), GPU-Orchestrierung

  • Retrieval-Infrastruktur on-prem (Vektordatenbank, Dokumenten-Pipeline, Zugriffskontrollen auf Dokument-Ebene)

  • Tool-Sandboxing: strikte Whitelists, Parameter-Validatoren, Least Privilege für Credentials, Network Egress Control

  • Air-Gapped-Optionen für Defense/critical Infrastructure mit Update-Kanälen via signiertem Transfer

Querfunktionen

  • Datenschutz: PII-Redaktion in Telemetrie; Datenminimierung; konfigurierbare Retention-Policies

  • Testbarkeit: Repro-Umgebungen, deterministische Seeds wo möglich, Replay-Fähigkeit

  • Security: Prompt-Injection-Filter auf Input und in abgeleiteten Kontexten; Output-Validation gegen Schemas; kontextuelle Rate Limits

6) Konkretes Szenario: Flottenintelligenz im Bahnverkehr (Beispiel)

Problemstellung
Ein Bahnunternehmen möchte Anomalien in Antriebs- und Klimasystemen früh erkennen, um Ausfälle zu vermeiden. Datenbasis sind Onboard-Sensordaten, Diagnosetickets aus Wartungssystemen und technische Dokumentation. Ein LLM-Agent erstellt Diagnosenvorschläge auf Basis strukturierter Features und Dokumentation und erzeugt Wartungstickets.

HITL-Design

  • Entscheidungen mit niedriger Kritikalität (z. B. Komforteinschränkung ohne Sicherheitsbezug): Agent erstellt Ticket inkl. Maßnahmenvorschlag; automatische Freigabe, Mensch informiert.

  • Sicherheitsnahe Entscheidungen (z. B. Antriebsanomalie): Agent muss Deferral machen. Er packt Evidenz zusammen: betroffene Sensoren, Residuenverlauf, Gegenprüfung mit Regel-Overlays, relevante Auszüge aus dem Instandhaltungsmanual.

  • Approval-UI zeigt:

  • Zeitreihe mit markierten Anomalie-Regionen, Referenz vs. Ist

  • Liste der herangezogenen Dokumentpassagen mit Links/IDs

  • Tooltrace (z. B. „retrieve_manual_section”, „compute_residuals”, „compose_ticket”)

  • Policy-Hinweis („SafetyCritical -> Approval required”)

  • Klarer Vorschlag („Zug in nächster planmäßiger Wartung prüfen; sofortige Betriebseinschränkung nicht notwendig“) mit Button „Freigeben”/„Ablehnen”/„Weitere Prüfung anfordern”

Explainability

  • Kein „magisches Score“, sondern ein Residuenprofil mit überlagerter Regelverletzung (monotone Regel), ergänzt um LLM-Zitate der genutzten Kapitel.

  • „Nicht gefunden“-Transparenz: Anzeige, welche typischen Fehlerbilder explizit NICHT zutrafen.