feat(K): Phase K EU Compliance — AI Registry, DPIA, Incident Register, Retention Admin, Tests, Doku

- K-REG: GET /api/v1/compliance/ai-registry — lists all agents with ai_use_case_metadata
- K-DPIA: GET /api/v1/compliance/dpia-template — pre-filled DPIA template export
- K-INC: ComplianceIncident model, Migration 0133 (RLS), CRUD routes (admin-only)
- K-RET: GET/PATCH /api/v1/compliance/retention-policies — 5 policies editable
- K-COMP-TEST: 12/12 integration tests pass
- K-DOC: docs/compliance.md — Betriebsdoku
- Frontend: ComplianceTab.tsx in SettingsAI.tsx (new tab)
- 13 files created/modified

docs/compliance.md

@@ -0,0 +1,164 @@
+# EU Compliance Betriebsdokumentation
+
+> **Wichtiger Hinweis:** Diese Dokumentation beschreibt die Plattformfunktionen zur Unterstützung der EU-Compliance. Die Plattformfunktionen ersetzen **keine** rechtliche Beratung oder automatische Rechtskonformität. Ein qualifizierter Datenschutzbeauftragter (DPO) oder Rechtsberater muss die Compliance stets im Einzelfall prüfen.
+
+## 1. Rollen und Verantwortlichkeiten
+
+| Rolle | Verantwortung | Plattform-Funktion |
+|-------|-------------|-------------------|
+| **Datenschutzbeauftragter (DPO)** | Aufsicht über Datenverarbeitung, DPIA-Prüfung, Incident-Management | Zugriff auf Compliance-Tab (admin), AI-Register, DPIA-Export |
+| **System-Administrator** | Technische Konfiguration, Retention-Policies, Plugin-Verwaltung | Vollzugriff auf alle Compliance-Endpunkte |
+| **AI-Agent-Verantwortlicher (Owner)** | Use-Case-Klassifikation, Risiko-Bewertung | AI-Use-Case-Metadata pro Agent |
+| **Mitarbeiter** | Nutzung der AI-Systeme im Rahmen der Use-Case-Metadaten | Kein direkter Compliance-Zugriff |
+
+## 2. Provider-Onboarding
+
+Bevor ein neuer AI-Provider in der Plattform verwendet wird:
+
+1. **Technische Einrichtung**: Provider in den KI-Einstellungen konfigurieren (API-Key, Base-URL)
+2. **Use-Case-Metadaten**: Für jeden Agenten, der den Provider nutzt, `ai_use_case_metadata` ausfüllen:
+   - `allowed_providers`: Provider-ID eintragen
+   - `allowed_models`: Erlaubte Modelle einschränken
+   - `intended_purpose`: Zweckbeschreibung
+   - `owner`: Verantwortliche Person
+3. **Risiko-Klassifizierung**: `risk_class` festlegen (low/medium/high)
+4. **Oversight-Policy**: `oversight_policy` konfigurieren (always_required/on_high_risk/never)
+5. **DPIA-Export**: DPIA-Template über den Compliance-Tab exportieren und vom DPO prüfen lassen
+
+## 3. Use-Case-Klassifikation
+
+Jeder AI-Agent in der Plattform hat strukturierte Metadaten (`AIUseCaseMetadata`):
+
+| Feld | Beschreibung | Werte |
+|-----|-------------|-------|
+| `intended_purpose` | Beschreibung des Verwendungszwecks | Freitext (max. 1000 Zeichen) |
+| `owner` | Verantwortliche Person (User-ID oder E-Mail) | Freitext |
+| `data_categories` | Datenkategorien, die verarbeitet werden | `contact_data`, `email_content`, `calendar`, `tasks`, `dms`, `communication`, `financial`, `public` |
+| `allowed_providers` | Erlaubte Provider (leer = alle) | Provider-IDs |
+| `allowed_models` | Erlaubte Modelle (leer = alle) | Modellnamen |
+| `allowed_actions` | Erlaubte Aktionen (leer = alle) | `read`, `summarize`, `draft`, `send`, `create`, `update`, `delete` |
+| `oversight_policy` | Wann menschliche Prüfung erforderlich ist | `always_required`, `on_high_risk`, `never` |
+| `risk_class` | Risikoklassifizierung | `low`, `medium`, `high` |
+| `human_review_required` | Muss ein Mensch die Ausgabe prüfen? | Boolean |
+
+### Validierung
+
+Die Plattform validiert die Metadaten automatisch (`validate_ai_use_case`):
+- `intended_purpose` und `owner` müssen gesetzt sein
+- `data_categories` müssen bekannte Werte sein
+- `oversight_policy` und `risk_class` müssen gültig sein
+- `allowed_models` müssen das konfigurierte Modell enthalten (falls nicht leer)
+- `allowed_providers` müssen den konfigurierten Provider enthalten (falls nicht leer)
+- `human_review_required` muss mit `oversight_policy` konsistent sein
+
+Warnungen werden im AI-Register angezeigt.
+
+## 4. DPIA / AI-Impact-Checkliste
+
+Die Plattform bietet einen DPIA-Template-Export (`GET /api/v1/compliance/dpia-template?agent_id=...`):
+
+- Vorbefüllt aus den `ai_use_case_metadata` des Agenten
+- Enthält: Zweck, Owner, Risiko-Klasse, Oversight-Policy, Datenkategorien, Provider, Modelle, Aktionen
+- Enthält Validierungswarnungen
+- Enthält Disclaimer: **keine Rechtsberatung**
+
+### DPIA-Checkliste (manuell vom DPO zu vervollständigen):
+
+- [ ] Zweck der Datenverarbeitung dokumentiert
+- [ ] Rechtsgrundlage identifiziert (Art. 6 DSGVO, ggf. Art. 9)
+- [ ] Datenkategorien katalogisiert
+- [ ] Empfänger/Dritte identifiziert
+- [ ] Übermittlung in Drittländer ausgeschlossen oder abgesichert
+- [ ] Speicherdauer definiert (siehe Retention-Policies)
+- [ ] Betroffenenrechte gewährleistet (Auskunft, Löschung, Berichtigung)
+- [ ] Technische und organisatorische Maßnahmen (TOMs) dokumentiert
+- [ ] Risiko-Bewertung durchgeführt
+- [ ] Bei hohem Risiko: Datenschutz-Folgenabschätzung (Art. 35 DSGVO)
+- [ ] Menschliche Aufsicht sichergestellt (oversight_policy)
+- [ ] Protokollierung und Audit-Trail aktiviert
+
+## 5. Incident- und DSAR-Ablauf
+
+### AI/Privacy/Security Incidents
+
+Incidents werden über `POST /api/v1/compliance/incidents` erfasst:
+
+1. **Entdeckung**: Mitarbeiter oder System entdeckt einen Vorfall
+2. **Erfassung**: Admin erstellt Incident-Eintrag mit:
+   - `incident_type`: ai, privacy, security
+   - `title`, `description`: Beschreibung des Vorfalls
+   - `affected_use_cases`: Betroffene AI-Use-Cases (Agent-IDs)
+   - `affected_versions`: Betroffene Versionen
+   - `provider`: Betroffener AI-Provider
+   - `measures_taken`: Ergriffene Maßnahmen
+   - `evidence_refs`: Beweisverweise
+   - `status`: open → resolved → closed
+3. **Maßnahmen**: Durchführung und Dokumentation der Maßnahmen
+4. **Auflösung**: Status auf `resolved` oder `closed` setzen (setzt `resolved_at` und `resolved_by`)
+5. **Audit-Trail**: Alle Incident-Mutationen werden im Audit-Log protokolliert
+
+### Data Subject Access Request (DSAR / DSGVO-Auskunft)
+
+Die Plattform bietet einen DSGVO-Export über `GET /api/v1/system-settings/dsgvo-export/{user_id}`:
+
+- Exportiert alle personenbezogenen Daten eines Users
+- Enthält: Profil, Kontakte, Audit-Logs, Mail-Accounts, Tasks, Kalender, Kommunikation
+- Admin-only
+
+## 6. Retention-Policies (Aufbewahrungsrichtlinien)
+
+Die Plattform verwaltet Retention-Policies über `GET/PATCH /api/v1/compliance/retention-policies`:
+
+| Policy | Standard (Tage) | Beschreibung |
+|--------|----------------|---------------|
+| `audit_log` | 365 | Aufbewahrung von Audit-Log-Einträgen |
+| `backup` | 7 | Aufbewahrung von Backup-Dateien |
+| `trash` | 30 | Aufbewahrung von soft-deleted Datensätzen |
+| `knowledge` | 365 | Aufbewahrung von Knowledge-Base-Artikeln und -Extraktionen |
+| `agent_memory` | 90 | Aufbewahrung von AI-Agent-Memory-Embeddings |
+
+Retention-Werte werden in `system_settings.retention_config` (JSONB) pro Tenant gespeichert.
+
+## 7. Plugin-Anforderungen
+
+Plugins, die AI-Funktionalität bereitstellen, müssen:
+
+- **Use-Case-Metadaten**: `ai_use_case_metadata` für jeden Agenten ausfüllen
+- **Tenant-Isolation**: Alle Tabellen benötigen `tenant_id` und RLS
+- **Audit-Logging**: Alle Mutationen müssen Audit-Log-Einträge erstellen
+- **Data-Policy-Enforcement**: `app/ai/data_policy.py` für Datenkategorien-Prüfung nutzen
+- **Transparency-Logging**: `app/ai/transparency.py` für AI-Entscheidungsprotokollierung nutzen
+- **Oversight**: `app/ai/oversight.py` für menschliche Aufsicht nutzen
+
+## 8. Grenze: Plattformfunktion ≠ automatische Rechtskonformität
+
+**Die Plattform bietet Werkzeuge zur Unterstützung der EU-Compliance, ersetzt aber nicht:**
+
+- Eine rechtliche Beratung oder Datenschutz-Folgenabschätzung durch einen qualifizierten DPO
+- Die Verantwortung des Verantwortlichen (Art. 24 DSGVO)
+- Die Pflicht zur Datenschutz-Folgenabschätzung bei hohem Risiko (Art. 35 DSGVO)
+- Die Meldepflicht bei Datenpannen (Art. 33-34 DSGVO)
+- Die Dokumentationspflicht der Verarbeitungstätigkeiten (Art. 30 DSGVO)
+- Die Berücksichtigung der AI-Verordnung (EU AI Act) bei Hochrisiko-Systemen
+
+Die Plattformfunktionen sind **Werkzeuge**, die die Compliance-Arbeit erleichtern. Die rechtliche Verantwortung verbleibt beim Betreiber.
+
+## 9. API-Endpunkte
+
+| Endpunkt | Methode | Beschreibung | Berechtigung |
+|----------|---------|-------------|-------------|
+| `/api/v1/compliance/ai-registry` | GET | AI-Use-Case-Register | system:admin |
+| `/api/v1/compliance/dpia-template` | GET | DPIA-Template-Export | system:admin |
+| `/api/v1/compliance/incidents` | GET | Incident-Liste | system:admin |
+| `/api/v1/compliance/incidents` | POST | Incident erstellen | system:admin |
+| `/api/v1/compliance/incidents/{id}` | PATCH | Incident aktualisieren | system:admin |
+| `/api/v1/compliance/retention-policies` | GET | Retention-Policies auflisten | system:admin |
+| `/api/v1/compliance/retention-policies/{key}` | PATCH | Retention-Policy aktualisieren | system:admin |
+
+## 10. Frontend
+
+Der Compliance-Tab ist in den KI-Einstellungen (`SettingsAI.tsx`) unter dem Tab "Compliance" erreichbar. Er enthält drei Sub-Tabs:
+
+- **AI-Register**: Tabelle aller AI-Agenten mit Use-Case-Metadaten und DPIA-Export-Button
+- **Vorfälle**: Incident-Liste mit Erstellungsformular und Auflösungsfunktion
+- **Aufbewahrung**: Retention-Policies-Tabelle mit editierbaren Tagen