Was wir zur Laufzeit erzwingen (Kontrollen):

  • Policy-Engine im Pfad: Kein Schreibzugriff nach außen ohne Policy-Match. Beispiel: „Buchen“ in ERP nur im Freigabe-Frame mit signiertem Operator-Token.

  • Allowlists und Verträge: Tools sind streng getypte Funktionen mit Eingabeverträgen, Timeouts, Retry-Budgets und Idempotenzgarantie. Agenten sehen nur Whitelist-Funktionen.

  • Circuit Breaker: Kill-Switch pro Agent, Rate-Limits, Canary-Modus per Use-Case, Quarantäne bei Häufung von Policy-Verstößen.

  • Determinismus im Test: In Staging deterministische Seeds, eingefrorene Tool-Stubs, reproduzierbare Läufe. Keine Freigabe ohne wiederholbare Testfälle.

Wie wir Qualität bewerten (Evaluation):

  • Golden Datasets: Kuratierte, versionierte Aufgaben mit korrekten Antworten und zulässigen Varianzen, einschließlich Negativfällen (wo die richtige Aktion „abbrechen/eskalieren“ ist).

  • Adversarials: Gezielte Störfälle (Mehrdeutigkeit, veraltete Quellen, widersprüchliche Daten).

  • Metriken jenseits von „Genauigkeit“: Abstain-Rate, Unterstützung-durch-Zitat-Quote, Tool-Fehler-Rate, Kettenlänge, Policy-Enforcement-Rate, Override-mit-Grund-Quote.

  • Human Feedback strukturiert: Jedes Override erfordert Grundkategorien (fehlende Quelle, unklare Anweisung, falsches Tool, zu riskant), automatisch ausgewertet in den Retrain-Backlog.

Alpi-M: Observability und Governance für LLM-Agenten, on-prem

Observability ist kein SaaS-Spielzeug, wenn Sie in regulierten oder sicherheitskritischen Umgebungen arbeiten. Wir betreiben unsere Observability und Governance on-prem, DSGVO-konform, ohne US-Cloud-Abhängigkeit. Alpi-M erfasst und versieht Agentenläufe mit Kontext, verknüpft sie mit Policies, ermöglicht reproduzierbare Tests und stellt Auditierbarkeit sicher — dort, wo die Daten entstehen. Das ist keine „nice to have“-Funktion, das ist die Grundlage dafür, dass die Fachseite einer Agentenempfehlung vertrauen kann und dass die Technikseite sie verantworten darf.

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

Ohne klare Rollen und Artefakte bleibt am Ende „niemand“ verantwortlich. Das ist in der Industrie untragbar. Unsere Governance-Struktur ist schlank, aber scharfkantig.

Rollen:

  • Model Owner (Engineering): Verantwortlich für Modellverhalten, Metriken, Kalibrierung, Release-Notizen. Zeichnet jede Änderung ab.

  • Data Steward: Verantwortlich für Datenherkunft, Datenqualität, Indexierungsprozesse und Löschkonzepte.

  • Operations/Line Owner: Verantwortlich für Integration in den Prozess, Workflows, Schulung und Eskalationspfade.

  • Safety/Compliance: Verantwortlich für Policies, Audit, Freigaben in sicherheitskritischen Bereichen.

Artefakte:

  • Decision Inventory: Liste aller Entscheidungen im Prozess mit Fehlkosten, Taktzeit, Automatisierungsgrad, Governance-Level.

  • Risk Register: Taxonomie von Fehlermodi (Halluzination, Tool-Missbrauch, Staleness, OOD, Bias) und Gegenmaßnahmen.

  • Playbooks: Was passiert bei Incident X? Wer stoppt was, wie, wo? Wie wird zurückgerollt?

  • Audit Trails: Unveränderliche Laufdaten, versionierte Artefakte, signierte Freigaben, aufbewahrt on-prem mit RBAC.

Prozesse:

  • Change Management: Kein stilles Prompt-Update am Freitagabend. Jede Änderung ist ein Release mit Impact-Analyse, Canary-Plan, Go/No-Go-Kriterien, Rollback.

  • Incident Response: Detektion → Klassifikation → Containment (Circuit Breaker) → Ursachenanalyse → Korrektur → Lessons Learned ins Golden Set.

Architektur-Muster für souveräne KI

Daten und Modelle bleiben dort, wo sie entstehen. Daraus folgen konkrete Architekturentscheidungen:

  • On-prem Inferenz-Cluster: Containerisierte LLMs/CV-Modelle, GPU-Orchestrierung, Ressourcenquoten, ohne externe Abhängigkeiten. Artifacts werden offline signiert und ins Netz gebracht (nicht umgekehrt).

  • Retrievial im eigenen Perimeter: Indizes werden innerhalb der Datenhoheit gebaut. Einbettungsmodelle laufen lokal. Quelle-zu-Antwort-Beziehungen sind explizit, kein „Black-Box-Vektorservice“ in fremden Clouds.

  • Agenten-Sandbox: Netzwerk-Egress kontrolliert, Dateisysteme gesandetboxt, Secrets in einem internen Tresor, keine „free-form shell“-Tools.

  • Tool-Verträge: Jede Funktion mit JSON-Schema, Idempotenz-Anforderung, Timeout, Retry-Policy und Nebenwirkungsklassifizierung (read-only, write, external).

  • Sicherheitsgeländer: Zweistufen-Freigaben für Außenwirkungen, minimaler Rechteumfang, durchgängige Signierung von Modellen, Prompts, Policies.

  • Beobachtbarkeit als First-Class: Telemetry nicht nachrüsten, sondern als Kernbaustein bauen: Events, Spans, Logs, Metriken — verknüpft, versioniert, durchsuchbar.

Drei Fallvignetten (anonymisiert)

  • Visuelle Inspektion in der Fertigung: Das System sortierte Teile in „OK/NOK“. Die Akzeptanz stieg erst, als wir eine dritte Kategorie „Unklar — an Mensch“ einführten, mit exemplarischer Evidenz aus der eigenen Linie. Die Taktzeit blieb stabil, weil die Menge unklarer Fälle gezielt über Konfidenz und OOD-Detektion begrenzt wurde. Entscheidend war die Bereitstellung einer kleinen, kuratierten Bibliothek „ähnlicher Fälle“ statt generischer Heatmaps.
  • Flottenintelligenz im Bahnkontext: Eine ML-Pipeline schlug Wartungsfenster vor. Wir stoppten Auto-Buchungen und führten eine Freigabeansicht ein, die Residualkurven, Messwertdrifts und einen „Datenabdeckung“-Indikator zeigte. Einfache Regel: Unter einem Abdeckungs-Schwellenwert ist Freigabe nicht möglich. Die Diskussion zwischen Instandhaltung und Data-Team drehte sich ab dann um Evidenz, nicht um Bauchgefühl.
  • Entscheidungsassistenz in verteidigungsnaher Planung: LLM-Agenten generierten Lagezusammenfassungen aus lokalem OSINT. Internetzugang war strikt verboten, jede Antwort erforderte Quellen aus dem eigenen Corpus. Agenten durften nur auf genehmigte Tools zugreifen, und wesentliche Ausgaben erforderten ein Zwei-Personen-Prinzip. Ohne Observability und Policy-Enforcement hätte das System dort nie eine Freigabe erhalten.

Metriken, die zählen

Wer nur „Accuracy“ reportet, verfehlt den Kern. Für Mensch-KI-Interaktion messen wir:

  • Annahme- vs. Override-Rate, segmentiert nach Unsicherheitsbändern

  • Begründete Overrides (mit Grundkategorie) vs. unbegründete

  • Abstain-Rate und ihre Korrelation mit OOD-Signalen

  • Kalibrierungsfehler (z. B. erwartete vs. beobachtete Fehler pro Score-Bin)

  • „Answer supported by evidence“-Quote bei LLMs

  • Zeit bis zur Detektion eines Incidents, Zeit bis zur Korrektur (MTTD/MTTR) im Modell

  • Nutzung der Erklärungsbausteine (welche Evidenz wird angeklickt, welche nicht)

  • Taktzeit-Effekt: zusätzliche Sekunden durch HITL an den definierten Gateways

Ein 90-Tage-Plan, der in der Praxis trägt

Tag 0–10: Entscheidungsinventur

  • Liste kritischer Entscheidungen, Fehlkosten, Taktzeiten, heutige Datenlage.

  • Definition von Governance-Leveln und Policies pro Entscheidung.

  • Auswahl eines Pilotbereichs mit echter Produktionsnähe und verantwortlicher Linie.