Erklärbarkeit, die Bedienern wirklich hilft

Was in der Oberfläche sichtbar wird, entscheidet über Vertrauen. Keine Textwände, keine philosophischen Erklärungen – operator-taugliche Evidenz.

  • Evidenzbasiert statt eloquent
  • Zeigen Sie, welche Dokumentpassagen oder Sensordaten die Empfehlung tragen (mit Hash/ID, Zeitstempel).
  • Visualisieren Sie Quellenverteilung und Lücken (“keine frische Quelle < 30 Tage”).
  • Aufgaben-spezifische Erklärungen
  • Bild-/Vision: Region-Highlights (z. B. Segment-/Bounding-Masks) mit Scores.
  • Tabular: Beitrag relevanter Features, Gegenfakten (“Wäre Temperatur < 60°C, Empfehlung wäre Nein”).
  • Text/LLM: Knappe, post-hoc generierte Begründung mit Quellverweisen, ohne interne “Chain-of-Thought” offenzulegen.
  • Unsicherheit sichtbar machen
  • Konfidenz als kalibrierte Bandbreite, nicht als Prozent-Attrappe.
  • Klarer Hinweis, wenn außerhalb des Trainings-/Validierungsraums.
  • Entscheidungskompetenz beim Menschen
  • Drei Buttons genügen: Übernehmen, Anpassen, Ablehnen – jeweils mit Pflichtgrund. Gründe werden kategorisiert (z. B. “Falsche Quelle”, “Messwert unplausibel”).
  • Bei niedriger Sicherheit oder hoher Auswirkung: Doppelte Bestätigung oder Vier-Augen-Freigabe.

Governance, die im Alltag funktioniert

Richtlinienordner allein schaffen keine Sicherheit. Bauen Sie Governance in die Pipeline.

  • Rollen und Verantwortungen
  • Produktverantwortung: Was darf der Agent tun? In welchem Risikokorridor?
  • Technische Verantwortung: Modell-/Prompt-/Policy-Änderungen, Freigaben.
  • Betrieb: SLOs, Incident-Response, Rollbacks.
  • Audit/Compliance: Unveränderliche Logs, Zugriffskontrolle, Freigabenachweise.
  • Change-Management
  • Jede Änderung an Modell, Prompt, Policy, Tool-Schema ist versioniert, getestet und freigegeben (Vier-Augen-Prinzip).
  • Canary-/Shadow-Rollouts mit Metriken gegen Golden Datasets.
  • Risikoklassen
  • Einordnung nach Auswirkungsgrad (z. B. rein informativ, assistierend, teil-automatisiert, voll-automatisiert). Je Klasse steigen Nachweispflichten, Tests und Freigaben.
  • Daten- und Wissenshoheit
  • Daten bleiben On-Prem oder in souveränen Umgebungen.
  • Externe Abhängigkeiten sind in Allowlists gefasst, Outbound-Verkehr strikt kontrolliert.
  • Auditierbarkeit
  • WORM-Speicher oder manipulationssichere Hashketten für Events.
  • Wiederfindbarkeit: Jeder Output verlinkt auf seine Evidenz und Versionen.

Souveräne Deployments: Architekturbausteine

In industriellen Umgebungen gilt: Keine US-Cloud-Abhängigkeit, DSGVO-konform, oft mit Netzsegmentierung bis hin zur Luftschnittstelle. Daraus folgt ein bestimmtes Muster.

  • Orchestrator On-Prem
  • Agenten-Runner und Policy-Engine im eigenen Rechenzentrum oder Edge.
  • OpenTelemetry für Tracing, zentrale Ereignisablage, SIEM-Anbindung.
  • Model Serving
  • Selbst gehostete Modelle oder souveräne Cloud-Angebote mit klarer Datenlokalität.
  • Ressourcenplanung: GPU-/CPU-Profile, Quantisierung, Failover.
  • Tool-Konnektoren
  • Least-Privilege-Credentials, Sandboxing, deterministische APIs.
  • Input-Validierung, Rate-Limits, Circuit Breaker.
  • Netzwerk und Geheimnisse
  • Egress-Proxy mit Allowlist, DNS-Überwachung, Paketfilter.
  • Secrets-Management On-Prem, rollierende Schlüssel, kein Prompt-Leaking von Geheimnissen.
  • Daten- und Logspeicher
  • Verschlüsselung at rest, differenzierte Retention nach Datentyp.
  • Pseudonymisierung/Anonymisierung an Quelle, wo möglich.

Evaluation und Betrieb: Von der Demo zur verlässlichen Maschine

  • Evaluationssuiten
  • Aufgabenbezogene Szenarien als Golden Set, mit Ground Truth oder akzeptierten Referenzausgängen.
  • Metamorphe Tests für Robustheit (z. B. Wortlaut-Varianten, Störsignale).
  • Shadow und Canary
  • Neue Prompts/Policies laufen zunächst schattiert gegen Live-Daten, dann kleinflächig ausgerollt mit klaren Abbruchkriterien.
  • Drift und Regression
  • Monitoren Sie Erfolgsrate, Interventionsrate und Fehlermuster; Regressionen früh erkennen.
  • Prompt-/Policy-Drift ist real: Änderungen dokumentieren und korrelieren.
  • SLOs für Agenten
  • Beispiel: “Assistenzmodus-Erfolgsquote ≥ 95% auf Golden Set; menschliche Interventionsrate < 20% in Klasse B; 0 ungeblockte Ausleitungsversuche pro Woche.”
  • Fehlerbudgets für Autonomie: Bei Budgetüberschreitung fällt das System automatisch in Assistenzmodus zurück.

Ein Minimal-Stack für die ersten 90 Tage

Wenn Sie heute starten müssten, mit knappen Ressourcen:

1) Tracing zuerst

  • Strukturierte Traces für jeden Lauf: Prompts, Parameter, Tools, Evidenz-IDs, Policy-Events, Entscheidungen.
  • OpenTelemetry-Integration und ein Such-Frontend, das Operatoren bedienen können.

2) Policies als Code

  • Einfache, versionierte Regeln mit Signierung und getrenntem Deployweg.
  • Guardrails: PII/Secret-Detektion, Ausleitungs-Blockaden, Whitelists.

3) Autonomie-Gates

  • Einheitliches Risiko-Scoring; Assistenzmodus als Default, Autonomie nur, wo Scores und Policies es hergeben.

4) Golden Set und Canary

  • Kleines, kuratiertes Testset; jede Änderung läuft dagegen.
  • Canary auf 5–10% der Aufgaben, klare Abbruchschwellen.

5) UI für Vertrauen

  • Evidenzanzeigen, kalibrierte Unsicherheiten, Pflichtbegründungen, schnelles Feedback.

6) Vorfall- und Rollback-Pfade

  • Kill-Switch, Rollback auf letzte bekannte gute Version, Runbook für Incidents.

Konkretes Beispiel: Wartungsempfehlung mit Vision + LLM-Agent

  • Vision-Modell detektiert einen Anomaliebereich an einer Textilmaschine. Es liefert Bounding-Box, Score und drei Referenzbilder aus der Historie.
  • Der Agent zieht aus dem technischen Handbuch die passenden Abschnitte (Retrieval mit Dokument-Hashes und Zeitstempeln) und schlägt eine Justageprozedur vor.
  • Unsicherheiten: Retrieval-Score mittel, Vision-Score hoch. Policy: Justage in Schichtbetrieb nur mit Freigabe.
  • UI zeigt: markierte Bildregion, Handbuchstellen mit Hash/Version, Schrittfolge, erwartete Dauer. Konfidenzbandbreite sichtbar; Hinweis: “Handbuchversion 18 Monate alt”.
  • Operator prüft, ergänzt einen Schritt, bestätigt. System protokolliert Änderungen, Ausführung erfolgt in Sandbox-Schritten mit Telemetrie.
  • Nachher: Ergebnis und Dauer fließen in Golden Set; die Heuristik für ähnliche Fälle wird angepasst, aber erst nach Canary-Phase produktiv.

Warum On-Prem und Souveränität hier keine Option, sondern Voraussetzung sind

  • Operative Daten (Bilder, Telemetrie, Störungsmuster) sind IP-kritisch; Rechts- und Kundenanforderungen schließen US-Clouds oft aus.
  • Observability-Daten enthalten oft mehr Sensitives als der Ursprung (Korrelationen, Fehlerpfade, Rollen). Die vollständige Kontrolle über Speicherung, Zugriff und Löschung ist unabdingbar.
  • Latenz- und Verfügbarkeitsanforderungen in der Produktion sind mit externen Abhängigkeiten schwer vereinbar.