• Verantwortlichkeit transparent
  • Wer hat freigegeben/abgelehnt? Warum? Mit digitaler Signatur und Zeitstempel.
  • Rückverfolgbarkeit bis auf Modell‑, Prompt‑ und Daten‑Version.

Das alles ist UX‑Design für Vertrauen: nicht „Erklärungstexte“, sondern prüfbare Spuren.

On‑premise Observability: Souveränität ist eine Architekturentscheidung

Agenten‑Telemetrie enthält die wertvollsten und sensibelsten Informationen: vollständige Prompts, Dokumentauszüge, operative Parameter, Business‑Regeln. Diese gehören nicht in eine externe APM‑SaaS. Daraus folgen Architekturprinzipien:

  • Ereignisbus und Telemetriestore on‑premise
  • Ein internes Event‑Log für Agentenereignisse (Action Graph Knoten/Kanten) mit beständigen IDs, Zeitstempeln (NTP‑synchronisiert) und Retention‑Policies.
  • Telemetriedaten verschlüsselt at‑rest/in‑transit, feingranulare RBAC, Mandantentrennung.
  • Evidenz‑Speicher mit Datenklassifizierung
  • Technische Trennung zwischen strukturierten Metadaten (z. B. Prompt‑Hashes) und inhaltlichen Evidenzen (Dokumentauszüge).
  • Zugriff nach Need‑to‑Know; nicht jeder, der Latenzen sehen darf, darf Dokumentinhalte sehen.
  • Modell‑ und Tool‑Gateway
  • Einheitlicher Zugriffspunkt, der alle Modell- und Toolaufrufe protokolliert, Policies durchsetzt und PII‑Scrubbing beherrscht.
  • Keine Direktverbindungen von Agentenlogik zu externen Services.
  • Air‑gapped‑Optionen
  • Für Defense/OT‑Netze: vollständiger Betrieb ohne Internetzugriff; Aktualisierungen über signierte Artefakte/Offline‑Sync.
  • Vendor‑Lock‑in vermeiden
  • Telemetrie‑Schema offen/portabel halten (z. B. JSON‑basiert mit stabilen Schemas).
  • Trennung von Erfassung (SDK/Sidecar) und Visualisierung/Analyse, damit Konsolen austauschbar sind.

Evaluieren, bevor man skaliert: Szenarienbank und Offline/Online‑Gates

Statt „Wir schauen mal live, wie’s läuft“ braucht es belastbare Evaluation:

  • Szenarienbank
  • Kuratierte, versionierte Aufgabenfamilien: Normalfälle, Edge‑Cases, adversariale Inputs, Domänenspezifika.
  • Jede mit Ground‑Truth oder akzeptierten Auflösungspfaden (z. B. zulässige Quellen, maximale Abweichungen).
  • Offline‑Evals als Gate
  • Neue Prompt/Policy/Modell‑Versionen müssen definierte Schwellenwerte in der Szenarienbank erfüllen.
  • Metriken nicht nur „Richtig/Falsch“, sondern Pfadqualität: Anzahl Tool‑Schritte, Regelverletzungen, benötigte HITL‑Eingriffe.
  • Online‑Evals im Shadow/Canary
  • Korrigierte Fehler-/Interventionsrate, Latenz, Kosten, Auswirkung auf nachgelagerte KPIs (z. B. First‑Time‑Right in Workflows).
  • Automatisches Stoppen bei Drift über Toleranz.

KPIs für kontrollierte Intelligenz

Wenn Teams nur auf „Accuracy“ schauen, entgeht ihnen der Betrieb. Sinnvolle Betriebs‑KPIs:

  • Intervention Rate: Anteil der Tasks, die HITL benötigen – pro Risikoklasse.
  • Approval Lead Time: Zeit von Agentenvorschlag bis Freigabe – trennt Agent‑/Operator‑Engpässe.
  • Guardrail Violation Rate: Anteil verhinderter Aktionen durch Policies/Validierungen.
  • Replay Determinism: Anteil reproduzierbarer Replays mit identischem Outcome – zeigt, ob Versionierung/Seeds korrekt sind.
  • Evidence Coverage: Anteil der Aussagen mit belegten Quellen/Validierungen.
  • Tool Success Rate und Retry Depth: Robustheit integrierter Tools.
  • Trace Completeness: Anteil an Knoten mit vollständigen Metadaten – Observability‑Qualität als eigenes SLO.

XAI in der Praxis: Erklärbarkeit durch Konstruktion, nicht durch Spekulation

In regulierten Domänen ist „Das Modell hat es so begründet“ kein Argument. Praktikabel sind:

  • Externe Rationalität
  • Begründungen aus nachvollziehbaren Artefakten: Welche Quellen? Welche Regeln? Welche Rechenwege?
  • Kein Offenlegen interner „Gedankenketten“. Stattdessen: Strukturierte Gründe im Action Graph.
  • Verifizierbare Zwischenschritte
  • Explizite Tool‑Aufrufe statt impliziter „Gedankensprünge“.
  • Deterministische Checks neben probabilistischer Generierung.
  • Erklärbarkeit als Nebenprodukt des Designs
  • Wenn jeder Schritt eine Evidenzpflicht hat und jede Entscheidung am Policy‑Knoten vorbeimuss, entsteht Erklärbarkeit automatisch.

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

Verantwortung verschwindet nicht, nur weil ein Agent handelt. Wir setzen Governance operativ auf:

  • Rollen und Verantwortungen
  • Product Owner: Business‑Ziele, Freigabekriterien, Risikoklassen.
  • Model/Prompt/Policy Owner: Qualität, Versionierung, Regressionsschutz.
  • Data Steward: Datenquellen, Klassifizierung, Zugriff.
  • Operator/Supervisor: Freigaben, Audits, Incident‑Handling.
  • Change‑Management
  • Promotionspfad: Dev → Test (Szenarienbank) → Shadow → Canary → Prod.
  • Jede Promotion ist ein Ticket mit Evidenzen (Eval‑Ergebnisse, Risk‑Assessment, Changelog).
  • Audit‑Fähigkeit
  • Unveränderliche Aktions‑Ledger: Jede Entscheidung/Aktion mit Hash‑Kette, Signaturen.
  • Rekonstruktionsfähigkeit: From‑Scratch‑Rebuild eines Tasks anhand gespeicherter Artefakte.
  • Incident‑Response
  • Playbooks: Was passiert bei Guardrail‑Verletzung, Datenleck, falscher Ausführung?
  • Post‑Mortems mit Action‑Graph‑Analyse, nicht nur „wir trainieren besser“.

Anwendungsbeispiele entlang realer Industrieprobleme

  • Visuale Qualitätskontrolle: Ein Agent schlägt vor, eine Fertigungszelle zu kalibrieren, weil die Ausschussrate steigt.
  • Observability: Bildserien, Feature‑Statistiken, Änderungshistorie der Kalibrierparameter.
  • Guardrails: Maximale Kalibrieränderung, Zeitfenster, HITL ab einem Schwellwert.
  • HITL‑UX: Belegbilder mit markierten Defekten, Simulationsauswirkung auf Ausschussquote.
  • Flottenintelligenz Bahn: Agent priorisiert Fahrzeuge für Werkstattplanung basierend auf Telemetrie und Störungsmeldungen.
  • Observability: Signalwege vom Sensordatensatz zur Priorisierungsentscheidung, Quellengewichtung.
  • Guardrails: Sicherheitsrelevante Komponenten stets HITL, Budget-/Kapazitätsrestriktionen als Policy.
  • Governance: Nachvollziehbarkeit gegenüber Aufsichtsbehörde via Aktions‑Ledger.
  • Instandhaltung Textilmaschinen: Agent erzeugt Bestellvorschläge für Verschleißteile durch RAG über Wartungsprotokolle.
  • Observability: Dokumentpassagen, die zum Vorschlag führten; alternative Teilelisten.
  • Guardrails: Limit pro Bestellung, Lieferantenvorgaben, Eskalation bei Obsoleszenzhinweisen.
  • UX: „What‑if“ zwischen Original‑ und Alternativteilen, Kosten-/Lieferzeit‑Trade‑off sichtbar.

So setzen wir das technisch um: Bausteine einer on‑prem Agent‑Observability‑Plattform

Im Kern sind es wiederkehrende Komponenten. Unsere Plattform Alpi‑M implementiert diese Muster on‑premise und DSGVO‑konform:

  • Agent Runtime Integration
  • SDK/Sidecar, der alle Agent‑Schritte instrumentiert (Action Graph Events), unabhängig von der konkreten Orchestrierungsbibliothek.
  • Standardisierte Ereignisschemata, damit die Observability‑Schicht nicht an einen Vendor bindet.