Governance & Sicherheit

Warum KI-Governance¶

Ein KI-Agent mit Zugriff auf Produktionssysteme ist ein mächtiges Werkzeug — und wie jedes mächtige Werkzeug braucht er Kontrolle. Ohne Governance riskieren Sie:

• Datenleck — Agent gibt interne Informationen in Antworten preis
• Prompt Injection — Angreifer manipuliert Agent durch Eingabedaten
• Unautorisierte Aktionen — Agent schreibt Daten, wo er nicht sollte
• Compliance-Vorfall — fehlender Audit-Trail in regulierter Umgebung
• Reputationsschaden — Agent sagt etwas Unangemessenes zu Kunden

Governance-Framework¶

┌─────────────────────────────────────────────────────────┐
│                  KI-GOVERNANCE-FRAMEWORK                   │
│                                                          │
│  ┌─────────────┐  ┌─────────────┐  ┌─────────────────┐ │
│  │   ZUGRIFFS-  │  │  SICHERHEITS-│  │   COMPLIANCE    │ │
│  │   KONTROLLE  │  │  GUARDRAILS  │  │   & AUDIT       │ │
│  │              │  │             │  │                 │ │
│  │ RBAC         │  │ Input-      │  │ Audit-Trail     │ │
│  │ Berechtigungs-│  │ Guardrails  │  │ Model Cards     │ │
│  │ grenzen      │  │ Output-     │  │ Impact-         │ │
│  │ Daten-       │  │ Guardrails  │  │ Bewertung       │ │
│  │ klassifizierung│  │ Kill-Switch │  │ Reporting       │ │
│  │ Minimale     │  │ Eskalation  │  │ Bias-           │ │
│  │ Berechtigung │  │ Rate-Limit  │  │ Monitoring      │ │
│  └─────────────┘  └─────────────┘  └─────────────────┘ │
└─────────────────────────────────────────────────────────┘

Zugriffskontrolle¶

Role-Based Access Control (RBAC)¶

Wir definieren wer was mit welchem Agenten tun darf:

Rolle	Berechtigungen
Agent-Operator	Agenten starten/stoppen, Monitoring, Konfigurationsänderungen
Agent-Entwickler	Deploy, Prompt-Änderungen, Eval-Management
Business-Nutzer	Mit Agent innerhalb definiertem Umfang interagieren
Auditor	Nur-Lese-Zugriff auf Audit-Trail, Reports
Admin	Vollzugriff, Kill-Switch, Notfallprozeduren

Berechtigungsgrenzen für Agenten¶

Jeder Agent hat eine explizite Fähigkeitsmatrix:

• Leseberechtigungen — welche Systeme/Daten er lesen kann
• Schreibberechtigungen — wohin er schreiben kann (mit/ohne Genehmigung)
• Aktionsberechtigungen — welche Aktionen er ausführen kann
• Datenumfang — welche Daten er verarbeiten kann (PII, finanziell, intern)
• Kommunikationsumfang — mit wem er kommunizieren kann (intern/extern)

Prinzip der minimalen Berechtigung: Agent hat nur Zugriff auf das, was er für seinen Anwendungsfall unbedingt braucht. Nicht mehr.

Datenklassifizierung¶

Wir klassifizieren Daten, mit denen der Agent arbeitet:

Klassifizierung	Beispiele	Handhabung
Öffentlich	Öffentliche Infos, Marketing	Keine Einschränkungen
Intern	Interne Prozesse, Wiki	Agent kann lesen, nicht extern teilen
Vertraulich	Geschäftsdaten, Verträge	Verschlüsselt, Audit-Trail, Need-to-know
Eingeschränkt	PII, Finanzdaten, Gesundheitsdaten	PII-Schwärzung, Verschlüsselung, strenges Audit

Sicherheits-Guardrails¶

Input-Guardrails¶

Prompt-Injection-Erkennung: Mehrschichtige Verteidigung:

1. Mustererkennung — Erkennung bekannter Injection-Muster (“ignoriere vorherige Anweisungen”, “System-Prompt:”, kodierte Angriffe)
2. Semantische Analyse — LLM-Klassifikator erkennt Manipulationsversuche auch in natürlicher Sprache
3. Instruktionshierarchie — System-Prompt hat immer Vorrang vor Benutzereingaben
4. Canary-Token — versteckte Token im Kontext erkennen, wenn der Agent den System-Prompt preisgibt

Input-Bereinigung: - Erkennung und Neutralisierung von Sonderzeichen, Markdown-Injection, HTML-Injection - Längenbegrenzung für Eingaben - Rate-Limiting pro Benutzer

Output-Guardrails¶

Inhaltsfilterung: - Toxizitätserkennung (schädliche, beleidigende Inhalte) - PII-Schwärzung (Erkennung und Maskierung personenbezogener Daten in Antworten) - Vertraulichkeitsprüfung (Antwort enthält keine internen Informationen außerhalb des Umfangs) - Markenkonformität (Antwort entspricht dem Tone of Voice)

Treuvalidierung: - Prüfung, ob Behauptungen in der Antwort durch den Kontext gestützt werden (für RAG) - Konfidenz-Scoring — wenn das Modell unsicher ist, eskaliert es statt zu handeln

Kill-Switch¶

Dreistufiger Kill-Switch:

1. Aufgabenebene — stoppt eine bestimmte laufende Aufgabe
2. Agentenebene — stoppt alle Aufgaben eines Agenten
3. Systemebene — Notfallstopp für alle Agenten

Kill-Switch ist unabhängig vom KI-System — funktioniert auch bei komplettem Ausfall der Agent-Schicht.

Eskalation¶

Wir definieren Regeln für automatische Eskalation:

• Konfidenz < Schwellenwert → Eskalation an Menschen mit Kontext
• Hochrisikoaktionen → menschliche Genehmigung vor Ausführung
• Anomalien → protokollieren, alarmieren, im sicheren Modus fortfahren
• Wiederholte Fehler → Eskalation an Engineering-Team

Compliance & Audit¶

Audit-Trail¶

Jede Agent-Aktion wird in einem unveränderlichen Audit-Log protokolliert:

{
  "timestamp": "2025-01-15T14:23:45Z",
  "agent_id": "invoice-processor-v2",
  "task_id": "task-abc123",
  "action": "tool_call",
  "tool": "erp_write_invoice",
  "input": { "invoice_id": "INV-2025-0042", "amount": 125000 },
  "output": { "status": "success", "erp_id": "ERP-98765" },
  "reasoning": "Rechnung gegen PO-2024-1234 validiert. Betrag stimmt überein. Schreibe in ERP.",
  "model": "claude-3-5-sonnet",
  "tokens": { "input": 2340, "output": 156 },
  "duration_ms": 1230,
  "user_id": "system_trigger",
  "permission_check": "PASS"
}

Der Audit-Trail ist: - Unveränderlich — kann nicht nachträglich geändert werden - Archiviert — 12+ Monate (je nach Regulierung konfigurierbar) - Durchsuchbar — Volltextsuche + strukturierte Abfragen - Exportierbar — JSON, CSV für Compliance-Audit

Model Cards¶

Für jeden Agenten/jedes Modell erstellen wir Model Cards:

• Zweck — wofür der Agent konzipiert ist
• Daten — auf welchen Daten er trainiert/evaluiert wurde
• Einschränkungen — was der Agent nicht bewältigen kann, bekannte Schwächen
• Bias — identifizierte Verzerrungen und Gegenmaßnahmen
• Metriken — aktuelle Leistungsmetriken
• Verantwortung — wer ist Eigentümer, wer genehmigt Änderungen

KI-Folgenabschätzung¶

Für kritische Anwendungsfälle führen wir eine Folgenabschätzung durch:

• Auswirkung auf Individuen — wie Agent-Entscheidungen Menschen betreffen
• Bias-Analyse — Tests auf Fairness über Gruppen hinweg
• Fehlermodus-Analyse — was passiert, wenn der Agent versagt
• Gegenmaßnahmen — wie wir Risiken minimieren
• Monitoring-Plan — wie wir die Auswirkungen nach dem Deployment verfolgen

Regulatorische Compliance¶

Wir haben Erfahrung mit:

• EU AI Act — KI-Systemklassifizierung, Hochrisiko-Anforderungen
• DSGVO — Recht auf Erklärung, Datenminimierung, Zweckbindung
• BaFin/EBA-Richtlinien — Modellrisikomanagement im Finanzsektor
• ISO 27001 — Informationssicherheitsmanagement
• SOC 2 — Sicherheit, Verfügbarkeit, Verarbeitungsintegrität

Governance-Implementierung¶

Phase 1: Bewertung (1 Woche)¶

• Audit des bestehenden KI-Systems
• Risikoidentifikation und Lückenanalyse
• Daten- und Prozessklassifizierung
• Governance-Framework-Design

Phase 2: Implementierung (2-4 Wochen)¶

• RBAC und Berechtigungsgrenzen
• Input-/Output-Guardrails
• Audit-Trail-Implementierung
• Kill-Switch und Eskalationsregeln

Phase 3: Testing (1-2 Wochen)¶

• Red-Team-Testing (Prompt Injection, Datenexfiltration)
• Compliance-Audit
• KI-Layer-Penetrationstest
• Stresstests (hohe Last, Grenzfälle)

Phase 4: Betrieb (fortlaufend)¶

• Monitoring und Alarmierung
• Regelmäßige Sicherheitsüberprüfung (vierteljährlich)
• Model-Card-Updates
• Compliance-Reporting

Verwandt mit