• Telemetrie und Metriken:
  • Tool Success Rate, Policy Violation Rate, Hold-to-Approve Ratio, Override Rate (vom Menschen abgelehnt), Mean Time to Approve, Cost per Decision, Knowledge-Citation Coverage (Anteil Entscheidungen mit belegter Quelle), Halluzinationsverdacht (Heuristik über Nicht-Zitations-Quoten in riskanten Aktionen).

Diese Bausteine bilden die Grundlage unseres Ansatzes und sind im Produkt Alpi-M als on-premise Observability- und Governance-Komponenten umgesetzt: Event-Schema, Policy Engine, Telemetrie, Replay, Approval-Workflows. Die Punkte sind aber unabhängig von einem spezifischen Tool als Architekturprinzip anwendbar.

4) On-premise und DSGVO: Souveränität ist eine Architekturentscheidung

Wenn Datenhoheit nicht verhandelbar ist, muss die Gesamtarchitektur das abbilden — nicht nur das Datenblatt eines Modells. Kernelemente:

  • Data Plane lokal
  • Vektor-Suche (RAG) in einem selbst betriebenen Vektor-Store (z. B. auf Kubernetes/VM), Indexe mit Versions-Tags.
  • Dokumenten-Pipeline mit PII-Redaktion vor Embedding/Indexierung; Hash-basierte Deduplikation; OCR/PDF-Parsing in Containern ohne Internetzugriff.
  • Control Plane lokal
  • Prompt-Registry: signierte Templates, Change-Management; nur genehmigte Templates im Produktivpfad.
  • Secrets, Key-Management, WORM-Audit-Storage (Write Once Read Many) für Unveränderlichkeit.
  • Policy Engine mit Yaml/DSL-Definitionen, die im Repo versioniert sind.
  • Model Serving
  • Entweder On-premise GPU-Kapazitäten (Closed- oder Open-Weights-Modelle) oder dedizierte EU-Clouds mit Netzwerksegmentierung; keine US-Cloud-Abhängigkeit.
  • Für CV/Anomalie: Inferenz möglichst Edge-nah; Aggregation/Steuerung on-prem.
  • Netzwerk/Isolation
  • Air-Gap-Optionen; zwingende Egress-Kontrolle; Allowlist für Updates; Telemetrie roll-up ohne personenbezogene Rohdaten.

Souveränität ist nicht nur „wo liegt der Server“, sondern „wer kontrolliert Verhalten, Updates, Prompts, Policies, Wissenszustände und Audit-Spuren“.

5) Qualitätssicherung, die den Operator schützt: Shadow, Golden Sets, Adversarial und Chaos

Damit die Freigabeknöpfe in Produktion vertrauenswürdig sind, braucht es QA, die das tatsächliche Nutzungsszenario abbildet:

  • Shadow Mode
  • Agent/Modell läuft passiv mit, erzeugt Empfehlungen, die nicht exekutiert werden. Vergleich mit menschlichen Entscheidungen und bereits existierenden SOPs.
  • Metriken: Disagreement Rate, Time-to-Useful, False Auto-Exec Risk (hochbewertete, aber vom Menschen verworfene Empfehlungen).
  • Golden Sets
  • Kuratierte Szenarien mit Ground Truth: Edge Cases, saisonale Muster, bekannte Störquellen.
  • Für LLM-Agenten: „Playbooks“ mit definierten Tool-Ketten und erwarteten Semantik-Diffs.
  • Adversarial/Red Team
  • Prompt-Angriffe, Tool-Missbrauch, Kontextverschmutzung (z. B. falsche Meta-Tags in Dokumenten).
  • Für CV: adversariale Perturbationen, Beleuchtungs-/Vibrationsprofile.
  • Zielmetrik: Robustheitsschwelle und Degradationsprofile.
  • Chaos für Tools
  • Simulierte Timeouts, Teilausfälle, inkonsistente API-Schemen. Beobachten, ob der Agent sicher degradiert (Stop statt Halluzination als Ersatzhandlung).
  • Kalibrierung
  • Konfidenzkalibrierung (Platt, Isotonic) für Klassifikatoren.
  • Für LLM-RAG: Abgleich zwischen Retrieval-Score und Antwortsicherheit; Grenzwerte für „I don’t know“-Handlungen.

6) UX, die Vertrauen verdient: Sichtbare Gründe, sichtbare Grenzen

Technik ist nur die halbe Miete. Bediener brauchen Oberflächen, die ihre Verantwortung ernst nehmen:

  • „Warum jetzt?“-Begründung auf einen Blick: Top-3 Faktoren, Quelle, erwarteter Nutzen (z. B. eingesparte Downtime), verbleibendes Risiko.
  • Unsicherheit explizit anzeigen: Konfidenz mit Bandbreite, nicht nur Prozentzahl; Link „Was bedeutet das?“.
  • Semantische Diffs statt kryptischer Tool-Logs.
  • Schnelle Eskalation: „Stop“, „Eskalieren an [Rolle]“, „Nachbesserung anfordern“.
  • Gated Controls nach Risiko: Bei High-Impact-Aktionen zwingender Zweitprüfer mit Timeout/Eskalationslogik.
  • Lernschleife: Jede Ablehnung erfragt mit minimalem Aufwand den Grund (z. B. „falsche Quelle“, „Kontext fehlte“); dieses Feedback fließt in Datenpflege, Prompt-Templates und Policies zurück.
  • Kosten-/Zeit-Transparenz bei LLM-Agenten: Geschätzte Token-Kosten, Latenz; alternativ „Schnellmodus“ vs. „Sorgfaltsmodus“.

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

Ohne klare Verantwortungen wird die beste Observability wertlos. In der Praxis bewährte Artefakte:

  • RACI pro Entscheidungstyp
  • Responsible: Rollen mit Freigaberecht.
  • Accountable: Produkt-/Systemverantwortung für Fehlentscheidungen.
  • Consulted: Recht/Compliance/OT.
  • Informed: Operations/Schichtleiter.
  • Decision Log und Incident Playbook
  • Jede High-Impact-Entscheidung mit: Who/When/Why/What Changed/Source/Policy-Context.
  • Incidents: Meldekanal, Priorisierung, Erstmaßnahmen, Reproduktionsschritte, Hotfix-Policy (z. B. Deaktivieren eines Tools per Feature-Flag), Kommunikationsplan.
  • Change Management
  • Versionierung und Freigabe von Modellen, Prompt-Templates, Policies, Wissensindizes.
  • Rollback-fähige Deployments; Canary/Blue-Green für Agenten-Policies.
  • Auditierbarkeit
  • WORM-Storage, signierte Events, Replay-Fähigkeit, Trennung von Betriebs- und Audit-Identitäten.

8) Konkrete Branchenmuster

  • Fertigung: Visuelle Qualitätskontrolle
  • Problem: Falsch-Positiv-Raten führen zu unnötigen Ausschleusungen; Bediener überstimmen das System häufig.
  • Architektur:
  • Edge-CV-Inferenz mit Heatmaps.
  • Zentraler Policy-Layer: Auto-Ausschleusung nur, wenn Konfidenz > Schwelle und Anlage in Auto-Modus; sonst Human-Gate mit Heatmap, Vergleich zu Near-Miss-Beispielen, Materialkosten-Abschätzung.
  • Telemetrie: Override Rate, FP/TP pro Schicht, Beleuchtungsdrift.
  • QA: Golden Set mit Grenzmustern, regelmäßige Rekalibrierung.
  • Ergebnis: Reduktion von Overrides, weil Gründe sichtbar und korrigierbar werden (z. B. Drift-Erkennung schlägt Auto-Exec ab, bevor falsche harte Entscheidungen getroffen werden).
  • Bahn: Flotten-Dispositionsagent
  • Problem: LLM-Agent schlägt Umlaufänderungen vor, doch Operations scheut Automatik aus Angst vor Kaskadenfehlern.
  • Architektur:
  • RAG auf Fahrplandokumenten, Werkstattkapazitäten, aktuellen Störungen; Vektor-Index on-prem.
  • Agent-Observability: Tool-Chain sichtbar (Störungsabfrage → Kapazitätscheck → Vorschlag), Semantic Diff der Umlaufänderung inkl. Anschlussauswirkungen.
  • Policy: Nur Verschiebungen <15 Min auto-ausführbar; darüber hinaus Human-Approval; Nachtfahrten gesonderte Rolle.
  • Metriken: Hold-to-Approve Ratio, Anschlussverlust-Vermeidung, Entscheidungszeit.
  • Ergebnis: Automatisierungsgrad steigt dort, wo Risiko klar begrenzt und transparent ist.