Was wir in produktiven Setups loggen und steuern

  • Vollständige Ausführungsgraphen: Jede Session als DAG mit Knoten (Gedanken/Plan, Tool-Call, Retrieval), Kanten (Datenfluss), Zeitstempeln.

  • Prompt-/Policy-Versionierung: Prompt-Templates, Tool-Schemata, Policies (Rollen, Budgets, Allow-/Deny-Listen) versioniert und signiert. Änderungen gehen durch Review-Workflow (4-Augen).

  • Telemetrie: Latenz pro Schritt, Token-Kosten, Fehlerraten pro Tool, Abbruch-/Loop-Erkennung (Agent hängt in Replan-Schleife).

  • Risikosignale: PII-/Geheimnis-Leak-Anzeichen via Pattern-Matching/Redaktion, Antwort-„Faktenrisiko“ basierend auf fehlenden/konfligierenden Quellen, Out-of-Scope-Erkennung.

  • Ressourcenkontrollen: Pro Session Budgets (Token, Zeit, Tool-Quotas), egress-Allowlist (DNS/IP), Sandbox (z. B. seccomp, read-only FS), Ephemeral Credentials über einen Secret-Broker.

  • Policy-as-Code: Rollenbasierte Toolfreigaben, Datenzugriffsbereiche, Hard Stops („nie Bestellungen auslösen“), Soft Gates („Bestellung > 5k€ nur mit Mensch“).

On-prem-Architekturkomponenten

  • K8s im Werk-/Behörden-DMZ, Air-gapped oder kontrollierte Egress-Pfade.

  • Inferenz-Runtimes (z. B. Text-LLMs) mit lokalen Gewichten; Vektorsuche on-prem (z. B. pgvector), Index-Builds als CI/CD-Artefakte.

  • Observability via OpenTelemetry; Logs in zentrale, verschlüsselte Stores; RBAC über Unternehmens-IdP.

  • Seitcar-Pattern für Audit: Jeder Agent-Pod hat einen Logging-Sidecar, der Prompt/Response-Metadaten, Tool-Traces, Policies mitschreibt. Inhalte werden nach DLP-Regeln geschwärzt.

Wie wir das bündeln: Alpi-M

  • Alpi-M ist unsere Plattform für Observability und Governance von LLM-Agenten. Sie aggregiert Ausführungsgraphen, misst Metriken (Kosten, Latenz, Tool-Erfolg), setzt Policies durch (Rollen, Budgets, egress), und stellt Audit-Trails bereit.

  • Fokus auf Industrietauglichkeit: On-premise, DSGVO-konform, ohne US-Cloud-Abhängigkeit. Unterstützt Air-Gap-Betrieb, integriert mit bestehenden SIEM-/IdP-Systemen, und erlaubt Policy-as-Code-Workflows inkl. Freigabeprozessen.

  • Praxisnutzen: Teams sehen, warum ein Agent eine Entscheidung traf, welche Evidenz er genutzt hat, welcher Step fehlschlug, und wann der Mensch eingriff. Das senkt die Hemmschwelle für Freigaben – weil Risiken sichtbar und kontrollierbar sind.

4) Governance: Wer ist verantwortlich, wenn die KI falsch liegt?

Governance beginnt nicht mit einem Gremium, sondern mit eindeutigen Verantwortlichkeiten im Code und in den Pipelines.

Rollen und Verantwortlichkeiten (RACI-artig)

  • Product Owner (Use Case): Verantwortlich für Business-Ziele, Fehlertoleranzen, SLOs und Freigabemodi.

  • Model Owner: Verantwortlich für Modellauswahl, Trainings-/Evaluationsdaten, Kalibrierung, Drift-Monitoring.

  • Policy Owner (Agenten): Verantwortlich für Toolfreigaben, Budgets, Datenzugriffsregeln, Change-Approval.

  • Operations/Platform: Verantwortlich für Laufzeitumgebung (K8s, Secrets, Observability), Backups, Restore, Patching.

  • Data Steward: Verantwortlich für Datenqualität, Katalogisierung, Lösch-/Sperrkonzepte.

Change-Management und Auditierbarkeit

  • Alles ist Code: Modelle (Versionen/Hashes), Prompts, Policies, Datenpipelines. Git, semantische Versionierung, Release Notes mit Breaking Changes.

  • 4-Augen-Prinzip für Risikoänderungen: Neue Tool-Freigaben, gelockerte Schwellwerte, neue Datenquellen.

  • Canary/Shadow-Rollouts: Änderungen werden zunächst ohne Seiteneffekte (read-only) oder auf einem Teilsegment gefahren; Metriken müssen SLOs halten, bevor global ausgerollt wird.

  • AI Decision Records (AIDR): Pro kritischer Entscheidung wird der Kontext protokolliert: Input, Modell/Policy-Versionen, Evidenz, Unsicherheitswerte, menschliche Freigabe/Override inkl. Begründung. So wird Verantwortlichkeit konkret und rekonstruierbar.

Incident-Response für KI-Systeme

  • Detection: Alerting auf SLO-Verletzungen (z. B. Anstieg Override-Rate, Häufung Out-of-Distribution-Inputs, Tool-Fehlerrate).

  • Containment: Kill-Switch pro Agent/Modell, Rollback auf letzte stabile Version, harte Policiesschließung (z. B. alle Schreib-Tools disabled).

  • Root Cause Analysis: Klassifizieren nach Prompt-/Policy-Change, Datenänderung (neue Charge, neues Ersatzteil), Infrastrukturfehler, Upstream-Service.

  • Postmortem mit Präventionsmaßnahmen: Neue Tests, striktere Kalibrierung, zusätzliche Evidenz im UI, härtere Policies. Kein „human error“ als Enddiagnose, wenn die UI den Fehler provoziert hat.

Metriken und SLOs, die zählen

  • TPR/FPR bei betriebsrelevantem Threshold, nicht nur „Accuracy“.

  • Auto-Accept-Rate vs. Review-Rate und Median Review Time.

  • Override-Rate des Menschen (und in welche Richtung).

  • Drift-Indikatoren: Population Stability Index, Score-Distribution-Shift.

  • Agenten-spezifisch: Tool-Failure-Rate, Loop-Rate, Kosten pro erledigtem Task, Policy-Violations.

5) Souveränität: On-Premise schlägt „bequeme“ Cloud – aus technischen Gründen

Warum insistieren wir auf On-Premise in sensiblen Industrien?

  • Datenkontrolle: Produktions-, Flotten-, Verteidigungsdaten verlassen die Domäne nicht. Egress ist deterministisch kontrollierbar.

  • Fehlerdomänen trennen: Wenn ein externer Cloud-Service eine Modelländerung ausrollt, haben Sie einen „unbounded change“. On-Prem: gleiche Gewichte, gleiche Runtimes, reproduzierbare Builds.

  • Latenz und Verfügbarkeit: Fabrik/Flotte funktioniert auch bei gestörten WAN-Verbindungen. Modelle liegen lokal, Vektorsuche ist lokal, Policies werden lokal erzwungen.

  • Lieferkette/Haftung: Klare Verantwortlichkeiten und Auditierbarkeit, keine Intransparenz durch externe Blackboxes.

  • Kosten-Kontrolle: Token-/API-Kosten sind nicht die dominierende Variable. GPU-Auslastung, Scheduling und Modellwahl sind unter Ihrer Kontrolle.

Typische Deployment-Topologie

  • Steuerungszone: K8s-Cluster mit Inferenzdiensten (REST/gRPC), Agenten-Orchestrierung, Policy-Engine (z. B. OPA/Rego), Secrets Vault.

  • Datenzone: Feature Store/Timeseries-DB, Vektorsuche (pgvector), DMS-Connectoren. Datenflüsse per Message-Bus (z. B. NATS/Kafka) mit Schema-Validation.

  • Observability: OpenTelemetry-Collector, Log-Archiv mit WORM-Eigenschaften, Metrik-Dashboards, Alerting.

  • CI/CD: Signierte Artefakte (Modelle, Prompts, Policies), Freigabe-Workflows, Canary/Shadow-Support. Air-gap-fähige Registry/Artefakt-Storage.

6) Was Sie nächste Woche umsetzen können: Minimal-Patterns