diff --git a/PLATFORM_ROADMAP.md b/PLATFORM_ROADMAP.md
index eee2a97..79959bc 100644
--- a/PLATFORM_ROADMAP.md
+++ b/PLATFORM_ROADMAP.md
@@ -1,7 +1,7 @@
 # LeoCRM → LeoPlatform: Entwicklungs-Roadmap
 
 > **Erstellt:** 2026-08-11
-> **Überarbeitet:** 2026-08-13 — Endstand-Audit gegen aktuellen Code + vollständiges Produktziel eingearbeitet
+> **Überarbeitet:** 2026-08-13 — Endstand-Audit + Privacy/DSGVO/EU-AI-Act-by-Design integriert
 > **Status:** Finale Endstand-Roadmap
 > **Leitlinie:** «LeoCRM soll einfacher, konsistenter und erweiterbarer werden – nicht abstrakter, generischer oder frameworklastiger.»
 
@@ -73,6 +73,21 @@ Betroffen: Password Hashes, SMTP/IMAP Credentials, API Keys, OAuth Tokens, Sessi
 
 Lösung: Zentrale Exclude-/Sensitive-Field-Konvention. Verbindlich, getestet, keine riesige Security-Engine.
 
+### Privacy / DSGVO / EU AI Act by Design (verbindlich)
+
+Compliance wird **nicht** als nachträgliche Parallelarchitektur gebaut. Datenschutz-, Transparenz-, Human-Oversight- und Nachweisfunktionen werden direkt an den bereits vorhandenen technischen Grenzen umgesetzt: Entity/Field-Metadaten, `AIProvider`, LLM-Client, Outbox, SearchProvider, AgentRun, WorkflowRun, ApprovalRequest, Audit und Communication.
+
+**Grundregeln:**
+- Leo stellt technische Compliance-Funktionen bereit; die rechtliche Zulässigkeit eines konkreten Einsatzes hängt weiterhin von Zweck, Daten, Betreiberrolle, Rechtsgrundlage und Branchenkontext ab.
+- Jeder relevante AI-Use-Case erhält mindestens: `intended_purpose`, Owner, verwendete Agenten/Modelle/Provider, Datenkategorien, zulässige Aktionen, Human-Oversight-Policy und eine konfigurierbare Risikoklasse.
+- **Keine Universal-Compliance-Engine:** kleine deklarative Policies an bestehenden Grenzen statt eines zweiten Policy-/Rechtesystems.
+- `SENSITIVE_FIELDS` bleibt die harte Secret-Grenze. Zusätzlich gibt es eine kleine **AI/Data Exposure Policy** für personenbezogene bzw. besonders schützenswerte Fachfelder: ob sie in LLM Context, Search, Embeddings, RAG, Agent Memory und Export gelangen dürfen.
+- Löschung/Korrektur einer authoritative Quelle muss abgeleitete Daten konsistent nachziehen können: Search/FTS, Vector/Embeddings, RAG-Chunks, Graph-Referenzen und Agent Memory. Kein blindes pauschales Hard-Delete, wenn gesetzliche Aufbewahrung oder fachliche Sperrgründe gelten; dafür muss der Betreiber die passende Retention-/Erasure-Policy konfigurieren.
+- AI-Akteure werden im Workstream eindeutig als AI gekennzeichnet. Extern ausgegebene AI-generierte Inhalte können je Use-Case zusätzliche Transparenz-/Kennzeichnungsmetadaten erhalten.
+- Personenbezogene oder sonst hochwirksame Entscheidungen können per Use-Case-Policy zwingend Human Review/Approval verlangen; Empfehlung, Evidenz, menschliche Entscheidung und Zeitpunkt bleiben nachvollziehbar.
+- AI-Provider erhalten Compliance-Metadaten (Region, DPA/Vertragsstatus, Retention, Training-on-Customer-Data, Transfer-/Hosting-Hinweise, erlaubte Datenklassen). Der zentrale LLM-Client erzwingt die konfigurierte Provider-/Datenpolicy.
+- High-Risk-/regulierte Branchenplugins nutzen dieselben Plattformmechanismen, bringen aber ihre **fachspezifische** Dokumentation, Risikobewertung und zusätzliche Kontrollen selbst mit. Der Core wird nicht auf Verdacht zu einer High-Risk-Suite aufgeblasen.
+
 ### Migration-Staffelung
 
 Nicht: neu → migrieren → alt sofort löschen.
@@ -222,6 +237,7 @@ Phase G — Workflow MVP                               [Woche 30-35]
 Phase H — Knowledge                                  [Woche 36-41]
 Phase I — Integration, Workstream & Polish           [Woche 42-47]
 Phase J — Controlled Self-Improvement                [Woche 48-52]
+Phase K — EU Compliance Finalization                 [Woche 52]
 Später — Advanced Autonomy/Automation nur bei echtem Bedarf
 ```
 
@@ -243,7 +259,7 @@ Später — Advanced Autonomy/Automation nur bei echtem Bedarf
 
 ## Phase B — Kleine System-Konsolidierung
 
-**Dauer:** 4 Wochen
+**Dauer:** 5 Wochen
 **Ziel:** Nur wirklich gemeinsame technische Infrastruktur konsolidieren. Keine Universalmodelle.
 
 ### B.1 Zentraler LLM Client
@@ -343,7 +359,8 @@ Gemeinsame Helpers statt großer BaseWebSocketManager. Spezialisierte Manager bl
 17. **Schema Authority** — Core → Alembic, Plugin → Plugin-Migrationsweg, Runtime Auto-Sync → nicht authoritative
 18. **Migration-Staffelung** — wie Plugin Migrationen sicher durchführt (neu → migrieren → umstellen → testen → release → alt entfernen)
 19. **Frontend** — wie Plugin Frontend-Komponenten erstellt (Standard-Komponenten nutzen, Manifest deklarieren, Theme respektieren, i18n nutzen, ErrorBoundary), inklusive Delivery-Vertrag: volle React-Komponenten deployment-time/bundled; runtime MiniApps schema-/registry-basiert
-20. **Test-Strategie** — wie Plugin Tests schreibt (Backend: pytest, Frontend: Vitest, E2E: Playwright), was getestet werden muss
+20. **Privacy/AI Compliance** — wie Plugin Datenklassen/AI-Exposure deklariert, AI-Use-Cases beschreibt, Human-Oversight/Transparency nutzt und abgeleitete Daten bei Correction/Erasure nachzieht; High-Risk-Spezialpflichten bleiben beim konkreten Vertical/Use-Case
+21. **Test-Strategie** — wie Plugin Tests schreibt (Backend: pytest, Frontend: Vitest, E2E: Playwright), was getestet werden muss
 
 ### B.8 Rate-Limiting Konsistenz
 
@@ -356,6 +373,9 @@ Gemeinsame Helpers statt großer BaseWebSocketManager. Spezialisierte Manager bl
 | Task | Beschreibung | Aufwand |
 |------|-------------|---------|
 | B-SENS | Zentrale Exclude-/Sensitive-Field-Konvention: `SENSITIVE_FIELDS` Set pro Entity. EntityHistory, Search, Embeddings, Export filtern automatisch. Tests die verifizieren dass keine Secrets in Snapshots/Index landen | 2 Tage |
+| B-DATA-POL | **AI/Data Exposure Policy** — kleine deklarative Entity-/Field-Policy ergänzen: zulässig für LLM Context, Search, Embeddings/RAG, Agent Memory und Export. `SENSITIVE_FIELDS` bleibt harte Secret-Sperre; keine zweite Permission-Engine | 2 Tage |
+| B-AIPROV-COMP | **AIProvider Compliance Metadata** — Region/Hosting, DPA-/Vertragsstatus, Retention, Training-on-Customer-Data, Transfer-Hinweise und erlaubte Datenklassen am bestehenden `AIProvider`; zentraler LLM-Client prüft die konfigurierte Policy vor Übermittlung | 1.5 Tage |
+| B-PRIV-TEST | Tests: Secrets immer blockiert, Exposure-Policy greift, nicht freigegebener Provider erhält keine entsprechenden Daten | 1 Tag |
 
 ### B.10 Lifecycle Hooks & relevante Outbox Events
 
@@ -418,7 +438,7 @@ Das bisher separate Notification-System und das Communication-/Message-System we
 | B-NOTIF-DEPREC | **Notification-System vollständig zurückbauen** — nach Migration und Verifikation: `Notification` Model, `NotificationType` Model, `/api/v1/notifications` Routes, `NotificationDropdown.tsx`, `NotificationItem.tsx` vollständig entfernen. Kein doppeltes System. `NotificationPreference` bleibt (für E-Mail/Stumm-Einstellungen). `create_notification()` wird zu `post_system_message()` im Comm-System | 1 Tag |
 | B-NOTIF-TEST | Tests: System-Events → Chat-Nachrichten, Preferences respektiert, Unread-Badge korrekt, Migration korrekt | 1 Tag |
 
-**Deliverables Phase B:** Zentraler LLM Client, zentraler Redis Pool, gemeinsamer File Storage, WebSocket Helpers, Event-System dokumentiert, Schema Authority definiert, schlanker Plugin-Guide, MiniApp-Contribution-Wiring, klarer Plugin-Frontend-Vertrag, gezieltes Rate-Limiting, Sensitive Data Boundary, konsistente Lifecycle-Hooks + relevante Domain-Outbox-Events, gemeinsamer Trigger-Kern sowie vollständige Notification→Message-Konsolidierung.
+**Deliverables Phase B:** Zentraler LLM Client, zentraler Redis Pool, gemeinsamer File Storage, WebSocket Helpers, Event-System dokumentiert, Schema Authority definiert, schlanker Plugin-Guide, MiniApp-Contribution-Wiring, klarer Plugin-Frontend-Vertrag, gezieltes Rate-Limiting, Sensitive Data Boundary + AI/Data Exposure Policy, AIProvider-Compliance-Metadaten, konsistente Lifecycle-Hooks + relevante Domain-Outbox-Events, gemeinsamer Trigger-Kern sowie vollständige Notification→Message-Konsolidierung.
 
 ---
 
@@ -575,6 +595,7 @@ Die spezifischen Suchen bleiben für gute Fach-UX erhalten, laufen technisch abe
 | E-PERM | Permission-aware Search (Tenant, RBAC, Visibility-Filter) | 1 Tag |
 | E-IX-EVT | Auto-Indexierung: Mutation → Outbox → Worker → Index aktualisieren. Ein Weg, nicht Hook + EventBus parallel | 2 Tage |
 | E-IX-RE | Re-Indexierung: Batch-Reindex Kommando, Delete-Handling, Retry | 1 Tag |
+| E-DATA-LIFE | **Derived-Data Lifecycle für Search/Vector** — Correction/Delete/Erasure-Signal aktualisiert oder entfernt FTS-/Search-Dokumente und Embeddings reproduzierbar; Rebuild aus authoritative Quelle möglich. Retention-/Legal-Hold-Entscheidung bleibt fachlich konfiguriert | 1.5 Tage |
 | E-K-MAIL | Mail-spezifische Suche behalten, interne ILIKE-Logik aber auf `MailSearchProvider`/Unified Search Core umstellen | 1 Tag |
 | E-K-DMS | DMS-spezifische Suche behalten, interne Suchlogik aber auf `FileSearchProvider`/Unified Search Core umstellen | 1 Tag |
 | E-K-TASKS | Task-spezifische Suche behalten, interne Suchlogik aber auf `TaskSearchProvider`/Unified Search Core umstellen | 0.5 Tage |
@@ -590,7 +611,7 @@ Die spezifischen Suchen bleiben für gute Fach-UX erhalten, laufen technisch abe
 | E-TEST | Tests: FTS, Vector, RAG, Graph, Permission-Filter, Auto-Index, Sensitive Fields ausgeschlossen | 3 Tage |
 | E-DOC | `docs/api-documentation.md`, `docs/plugin-development-guide.md` (Search-Kapitel) | 1 Tag |
 
-**Deliverables Phase E:** Unified Search mit FTS+Vector+RAG+Graph, Provider deklarieren Modi, Auto-Indexierung (Outbox→Worker), KI-nutzbar (Tool, MCP, API), Command Palette sowie globale und modulspezifische Suchen auf demselben Search-Kern.
+**Deliverables Phase E:** Unified Search mit FTS+Vector+RAG+Graph, Provider deklarieren Modi, Auto-Indexierung (Outbox→Worker), konsistenter Correction/Delete-Lifecycle für Search/Vector, KI-nutzbar (Tool, MCP, API), Command Palette sowie globale und modulspezifische Suchen auf demselben Search-Kern.
 
 ---
 
@@ -628,6 +649,8 @@ Kein vollständiger interner Chain-of-Thought; der Extended Trace ist ein expliz
 | F-ERR | Error-Handling: Tool-Fehler → LLM bekommt Error-Message | 1 Tag |
 | F-STR | SSE-Streaming mit **Standard- und Extended-Trace-Modus**: Status, Tool-Calls/-Results, Fortschritt, Kosten, Fehler, finale Antwort; optional zusätzlich strukturierte kurze Entscheidungsbegründungen/Zwischenzusammenfassungen | 1 Tag |
 | F-DEF | Bestehende AgentDefinition CRUD/API/Versionierung verifizieren und nur fehlende Felder/Contracts für Runtime, Skills, Trigger und Limits ergänzen | 1 Tag |
+| F-AIUSE | **AI Use-Case Metadata** — für relevante Agent-/AI-Funktionen `intended_purpose`, Owner, Datenklassen, zugelassene Provider/Modelle, zulässige Aktionen, Oversight-Policy und konfigurierbare Risikoklasse erfassen. Kein juristischer Auto-Klassifizierer | 1 Tag |
+| F-TRANS | **AI Transparency** — Agent-/AI-Teilnehmer im Workstream und relevanten UIs eindeutig als AI kennzeichnen; generierte Inhalte können typisierte Herkunfts-/Kennzeichnungsmetadaten tragen | 0.5 Tage |
 | F-SKILL | **Kleiner Skill-Baustein** — `SkillDefinition`/Registry + `skill_definitions`-Plugin-Contribution (oder gleichwertig) mit Name/Beschreibung/Instructions, erlaubten Tool-IDs und optionaler Context-Policy. Skills sind Orchestrierungsmetadaten, **keine Rechtequelle**, kein `SkillRole`, kein zweites RBAC | 1.5 Tage |
 | F-TOOL | Tool-/Skill-Binding — Agent definiert, welche Tools und Skills er nutzen darf. Skills dürfen nur freigegebene Tools/Services orchestrieren und keine Permissions umgehen | 1 Tag |
 | F-PERM | Permission-Context: Agent agiert im Kontext eines Users/Run-as. RBAC/ABAC pro Tool-/Service-Aufruf, Visibility-Filter und EntityPermission. Effektiv: User/Run-as ∩ Agent ∩ Skill ∩ Tool. Aktuelle Rechte bei jedem Call neu prüfen | 2 Tage |
@@ -638,6 +661,8 @@ Kein vollständiger interner Chain-of-Thought; der Extended Trace ist ein expliz
 | F-APPR | **Agent Action Approval + zentraler ApprovalRequest-Kern** — Tool-/Skill-Aktionen können per Policy/Metadaten approval-pflichtig sein (nicht nur destruktiv; auch extern, irreversibel oder sensibel). Da Agents vor Phase G kommen, wird hier der minimale **zentrale** `ApprovalRequest`-Kern angelegt/vereinheitlicht; Phase G baut nur den Workflow-Step/Queue darauf. Keine separate Agent-Approval-Engine | 2 Tage |
 | F-DRY | Dry-Run-Mode | 0.5 Tage |
 | F-AUDIT | Audit-Log für jeden Tool-Call | 1 Tag |
+| F-OVERSIGHT | **Human-Oversight / Decision Record** — Use-Cases können bestimmte personen-/risikorelevante Aktionen zwingend vor Außenwirkung an `ApprovalRequest` binden; Recommendation/Evidence, Reviewer, Entscheidung, Zeitpunkt und Abweichung nachvollziehbar speichern | 1 Tag |
+| F-DATA-POL | **Runtime Provider/Data Policy Enforcement** — Agent/Context Builder/LLM Client respektieren B-DATA-POL und B-AIPROV-COMP; nicht erlaubte Felder/Provider werden vor dem LLM-Call geblockt bzw. minimiert | 1 Tag |
 | F-UI-CTRL | **Bestehendes AI UI Control als Agent-Tool integrieren/erweitern** — Navigation, Filter, Tabs, Modals, Ansichten, Form-Prefill und UI-Kontext steuern. **Persistente fachliche Mutationen ausschließlich über reguläre Tools/Services mit bestehenden Permission-Prüfungen**; `ai_ui_control:write` darf keine Fachrechte umgehen. Feedback-Loop: Agent → REST/WebSocket → Frontend → Feedback → Agent | 1.5 Tage |
 | F-UI-TRIG | **Bestehende UI-Context-Events zum allgemeinen UI-Trigger ausbauen** — Frontend-Events (`ui.contact_selected`, `ui.page_navigated`, `ui.mail_opened`, `ui.task_status_changed` etc.) triggern Agenten/Proactive Suggestions **ephemer über EventBus/Redis + gemeinsamen Trigger-Dispatcher, nicht über Outbox**. Trigger im Agent-Editor konfigurierbar; Bedingungen nutzen vorhandene Condition-Logik. Sobald ein Agent startet, wird `AgentRun` persistent gespeichert | 2 Tage |
 | F-WORK | **Agent → zentraler Workstream** — Agenten posten Text, Status, `action_card`, Entity-/Contact-Cards, Knowledge-Quellen, Approval- und `miniapp`-Blocks über das bestehende Communication-System. Kein zweites Agent-Message-/Chat-Modell | 1.5 Tage |
@@ -653,7 +678,7 @@ Kein vollständiger interner Chain-of-Thought; der Extended Trace ist ein expliz
 | F-TEST | Tests: ReAct-Loop, Tool-Calling, Permissions, Approval, Budget-Limits | 3 Tage |
 | F-DOC | `docs/api-documentation.md`, `docs/plugin-development-guide.md` (Agent-Kapitel) | 1 Tag |
 
-**Deliverables Phase F:** ReAct-Agenten auf vorhandener Agentenbasis, kleiner Skill-Baustein, Tool-/Skill-Calling, Permission-Modell (User/Run-as ∩ Agent ∩ Skill ∩ Tool), Standard+Extended Trace, trigger-basierte Proaktivität, UI Control ohne Permission-Bypass, zentraler ApprovalRequest-Kern, Workstream-Ausgabe, Agent UI und 4 Pre-Built Agenten.
+**Deliverables Phase F:** ReAct-Agenten auf vorhandener Agentenbasis, kleiner Skill-Baustein, Tool-/Skill-Calling, Permission-Modell (User/Run-as ∩ Agent ∩ Skill ∩ Tool), AI-Use-Case-/Transparency-Metadaten, Provider/Data-Policy-Enforcement, Standard+Extended Trace, trigger-basierte Proaktivität, UI Control ohne Permission-Bypass, zentraler ApprovalRequest-Kern + Human-Oversight-Record, Workstream-Ausgabe, Agent UI und 4 Pre-Built Agenten.
 
 ---
 
@@ -685,6 +710,7 @@ Kein vollständiger interner Chain-of-Thought; der Extended Trace ist ein expliz
 | G-LOG | Execution-Log pro Step (Input, Output, Duration, Status) | 1 Tag |
 | G-WORK | **Workflow/System → zentraler Workstream** — typisierte Status-, Handoff-, Approval-, Action- und MiniApp-Blocks über Communication posten. Bestehende Workflow-`notification`-Produzenten auf zentrales Message-System umstellen; kein separates Workflow-Notification-System | 1 Tag |
 | G-APPROVAL | **Generischer Approval-Step auf zentralem `ApprovalRequest`** — den in Phase F angelegten gemeinsamen Kern für Workflows verwenden/erweitern; für beliebige Workflows, Entities und Aktionen nutzbar; Approver/Gruppe, `pending/approved/rejected/expired`, Referenz auf Workflow/Run/Aktion, Kommentar, Zeitstempel, System-Message, Approval-Queue, Audit und optional Timeout. **Keine pauschalen `pending_approval/active/rejected`-Statusfelder auf allen Entities**; fachliche Status nur im jeweiligen Modul, wenn benötigt. Derselbe Mechanismus wird von Agent-Approvals verwendet | 2.5 Tage |
+| G-HUMAN-DEC | **Automated-Decision Guard** — für entsprechend konfigurierte AI-Use-Cases dürfen Workflow-/Agent-Ergebnisse keine definierte personen-/risikorelevante Außenwirkung automatisch auslösen, bevor die geforderte Human-Review-/Approval-Policy erfüllt ist. Kein pauschaler Zwang für normale CRM-Automation | 1 Tag |
 | G-CTX | **Persistenter Execution-Context** — Daten-Flow zwischen Steps (Variablen, Expressions) wird zusammen mit WorkflowRun dauerhaft gespeichert und kann nach Wait, Restart, Worker-Crash oder Event-Resume fortgesetzt werden | 2 Tage |
 | G-RUN | **Durable WorkflowRun / Resume-Semantik** — Run-State, Step-State und Resume-Grund (`resume_at`, Event/Approval/Webhook) persistent halten. Resume lädt denselben Run und setzt exakt am vorgesehenen Step fort; keine zweite Workflow-Runtime | 1.5 Tage |
 | G-IDEMP | **Idempotency-/Deduplizierungsschutz für Side Effects** — Side-Effect-Steps (z. B. Mail, HTTP, CRM-Mutation) erhalten pro Execution einen stabilen Idempotency-/Execution-Key bzw. deduplizierbare Ausführungslogik, damit Retry/Worker-Restart keine unbeabsichtigten Doppelaktionen erzeugt | 1 Tag |
@@ -695,7 +721,7 @@ Kein vollständiger interner Chain-of-Thought; der Extended Trace ist ein expliz
 | G-TEST | Tests: Step-Execution, Trigger, Retry, Expressions | 2 Tage |
 | G-DOC | `docs/api-documentation.md` aktualisieren | 1 Tag |
 
-**Deliverables Phase G:** Bestehende Workflow/Automation-Basis konsolidiert, Workflow Engine mit Form+JSON Editor, 10+ Step-Types, 4 Trigger-Typen, persistenter/resumable WorkflowRun, idempotency-sicheren Side-Effect-Steps, Retry, Execution-Log, zentralem ApprovalRequest, Workstream-Ausgabe und Template-Gallery.
+**Deliverables Phase G:** Bestehende Workflow/Automation-Basis konsolidiert, Workflow Engine mit Form+JSON Editor, 10+ Step-Types, 4 Trigger-Typen, persistenter/resumable WorkflowRun, idempotency-sicheren Side-Effect-Steps, Retry, Execution-Log, zentralem ApprovalRequest + konfigurierbarem Automated-Decision Guard, Workstream-Ausgabe und Template-Gallery.
 
 ---
 
@@ -720,6 +746,8 @@ Kein vollständiger interner Chain-of-Thought; der Extended Trace ist ein expliz
 | H-AUTO | Auto-Relationship-Creation in GraphRAG | 1 Tag |
 | H-CONF | Confidence-Score, Low-Confidence → Review-Queue | 1 Tag |
 | H-EVT | Event-Driven-Extraction (neue Mail/Dokument/Message bzw. relevante fachliche Wissensänderung → ARQ-Job → Extraktion); nur konfigurierte Knowledge-Quellen | 1 Tag |
+| H-DATA-LIFE | **Derived-Data Lifecycle für Knowledge** — Correction/Delete/Erasure der authoritative Quelle propagiert über denselben Event-/Worker-Weg zu RAG-Chunks, Embeddings, Graph-Referenzen und angebundenem Agent Memory; source references ermöglichen gezieltes Rebuild/Remove | 2 Tage |
+| H-RET | **Knowledge/Memory Retention** — kleine Retention-/Source-Policy je Wissensquelle/Datenklasse; keine zweite Archivierungsengine, ARQ räumt nur nach konfigurierter Policy auf | 1 Tag |
 | H-GRAPH | Wissensgraph-Visualisierung (Cytoscape) | 2 Tage |
 | H-EDITOR | Wiki-Artikel-Editor (TipTap) | 1 Tag |
 | H-BROWSE | Knowledge-Browser — Baumansicht, Artikel-Liste | 1 Tag |
@@ -728,7 +756,7 @@ Kein vollständiger interner Chain-of-Thought; der Extended Trace ist ein expliz
 | H-TEST | Tests: Wiki CRUD, RAG-Query, Extraction, Graph | 2 Tage |
 | H-DOC | `docs/api-documentation.md`, `docs/plugin-development-guide.md` | 1 Tag |
 
-**Deliverables Phase H:** Firmenwissensschicht aus Wiki + DMS + Mail + Communication + freigegebenen Businessinhalten, Document-RAG, Quellen/Evidence-Cards, automatische Wissensgraph-Extraktion, Knowledge-UI mit Graph-Visualisierung und Ask-Knowledge im zentralen Workstream.
+**Deliverables Phase H:** Firmenwissensschicht aus Wiki + DMS + Mail + Communication + freigegebenen Businessinhalten, Document-RAG, Quellen/Evidence-Cards, automatische Wissensgraph-Extraktion, konsistenter Correction/Delete/Retention-Lifecycle für RAG/Embeddings/Graph/Memory, Knowledge-UI mit Graph-Visualisierung und Ask-Knowledge im zentralen Workstream.
 
 ---
 
@@ -787,13 +815,15 @@ Alle in Phase E-H gebauten Systeme müssen miteinander verbunden werden.
 | I-QUEUE | **ARQ-Queue-Tuning (conditional)** — Prioritäten, Concurrency-Limits, DLQ nur anhand realer Last/Bottlenecks konfigurieren | 1 Tag |
 | I-IDX | **DB-/FTS-/pgvector-/HNSW-Tuning (conditional)** — Indizes/Parameter anhand Messwerten optimieren; Write-Performance und Ressourcenverbrauch gegenprüfen | 1 Tag |
 
-### I.5 DSGVO-Auskunfts-Export
+### I.5 DSGVO-Betroffenenrechte & Compliance Export
 
-Der vollständige plattformweite Datenauskunfts-Export wird erst hier gebaut, wenn Core, Communication, Agents, Workflows und Knowledge vorhanden sind. Keine eigene universelle Export-Provider-Architektur nur für diesen Zweck.
+Wenn Core, Communication, Agents, Workflows und Knowledge vollständig integriert sind, wird der plattformweite Betroffenenrechts-/Nachweisweg fertiggestellt. Keine universelle Privacy-Engine und kein blindes automatisches Löschen über fachliche/gesetzliche Aufbewahrungspflichten hinweg.
 
 | Task | Beschreibung | Aufwand |
 |------|-------------|---------|
-| I-DSGVO | **Vollständiger Plattform-Datenauskunfts-Export** — personenbezogene Daten eines Users über Core und aktive Plugins hinweg (u. a. CRM, Mail, Calendar, DMS, Communication/Workstreams, Agents, Workflows, Knowledge, Audit) als strukturierter JSON/ZIP-Export. Sensitive-Data-Regeln zwingend beachten | 2 Tage |
+| I-DSGVO | **Vollständiger Plattform-Datenauskunfts-Export** — personenbezogene Daten eines Users/Betroffenen über Core und aktive Plugins hinweg (u. a. CRM, Mail, Calendar, DMS, Communication/Workstreams, Agents, Workflows, Knowledge, Audit) als strukturierter JSON/ZIP-Export. Sensitive-/Exposure-Regeln zwingend beachten | 2 Tage |
+| I-DSAR | **Betroffenenrechts-Workflow** — Access/Correction/Erasure/Restriction als nachvollziehbarer administrativer Vorgang: betroffene Quellen finden, fachliche Handler aufrufen, abgeleitete Daten über E/H-Lifecycle nachziehen, Ausnahmen/Retention dokumentieren. Kein generischer Blind-Hard-Delete | 2 Tage |
+| I-COMP-EXPORT | **AI/Compliance Evidence Export** — AI-Use-Case-Metadaten, Provider-/Modellbezug, Agent-/Workflow-Versionen, relevante Audit-/Oversight-/Approval-Evidenz und technische Policies als exportierbares Nachweispaket | 1 Tag |
 
 ### I.6 Onboarding & Dokumentation
 
@@ -811,7 +841,7 @@ Der vollständige plattformweite Datenauskunfts-Export wird erst hier gebaut, we
 | I-TEST | **Vollständige Test-Pipeline** — alle 8 Checks über das gesamte System, E2E für alle kritischen Flows inklusive Workstream/MiniApps/Mobile | 2 Tage |
 | I-DEPLOY | **Production-Deploy** — Deploy, Health-Check, Smoke-Test, Monitoring verifizieren | 1 Tag |
 
-**Deliverables Phase I:** Alle Systeme verbunden (Agent↔Workflow↔Search↔Knowledge↔Communication), produktiver Human-AI Workstream auf dem zentralen Message-System, echte plugin-erweiterbare MiniApps, Proactive Collaboration, Shared Group Workstreams, mobile/PWA-Workstreams, MCP, Dashboard/Analytics, DSGVO-Export, Onboarding und Production-Deploy.
+**Deliverables Phase I:** Alle Systeme verbunden (Agent↔Workflow↔Search↔Knowledge↔Communication), produktiver Human-AI Workstream auf dem zentralen Message-System, echte plugin-erweiterbare MiniApps, Proactive Collaboration, Shared Group Workstreams, mobile/PWA-Workstreams, MCP, Dashboard/Analytics, DSGVO-Betroffenenrechtsweg + Compliance Evidence Export, Onboarding und Production-Deploy.
 
 ---
 
@@ -833,7 +863,7 @@ Beobachten → Muster/Effekt erkennen → ImprovementProposal
 
 | Task | Beschreibung | Aufwand |
 |------|-------------|---------|
-| J-SIGNAL | **Improvement Signals** — vorhandene `ContextLog`, accepted/dismissed Proactive Suggestions, AgentRuns, WorkflowRuns, AuditLog, EntityHistory, User-Korrekturen/Handoffs und Outcome-Metriken als referenzierte Signale nutzbar machen. Keine unnötigen sensiblen Datenkopien | 2 Tage |
+| J-SIGNAL | **Improvement Signals** — vorhandene `ContextLog`, accepted/dismissed Proactive Suggestions, AgentRuns, WorkflowRuns, AuditLog, EntityHistory, User-Korrekturen/Handoffs und Outcome-Metriken als referenzierte Signale nutzbar machen. Datenminimierung/Exposure-Policy/Retention gelten auch hier; möglichst Referenzen/Aggregate statt unnötiger personenbezogener Vollkopien | 2 Tage |
 | J-PATTERN | **Pattern/Bottleneck Detection** — wiederkehrende manuelle Sequenzen, häufige Korrekturen, abgelehnte Vorschläge, Retries/Fehler und repetitive Handoffs erkennen; Confidence/Evidence speichern | 2 Tage |
 | J-PROP | **`ImprovementProposal`** — Vorschlag mit Zieltyp (`agent`, `skill`, `trigger`, `workflow`, `miniapp_template`, optional `plugin_patch`), Evidence-Refs, Begründung, erwarteter Nutzen, Risiko und Status | 1.5 Tage |
 | J-DRAFT | **Versionierter Draft** — vorhandene Agent-/Automation-/Workflow-Versionierung wiederverwenden und bei Bedarf kleine Skill/MiniApp-Template-Versionierung ergänzen. Keine universelle Versionierungsengine | 2 Tage |
@@ -850,6 +880,24 @@ Beobachten → Muster/Effekt erkennen → ImprovementProposal
 
 ---
 
+## Phase K — EU Compliance Finalization
+
+**Dauer:** 1 Woche
+**Ziel:** Die während B–J bereits technisch eingebauten Privacy-/AI-Compliance-Funktionen zu einem prüfbaren Betreiber-/Produktnachweis zusammenführen. Kein neuer Runtime-Kern, keine juristische Auto-Entscheidungsengine.
+
+| Task | Beschreibung | Aufwand |
+|------|-------------|---------|
+| K-REG | **AI System / Use-Case Register UI** — vorhandene F-AIUSE-Metadaten übersichtlich verwalten: Intended Purpose, Owner, Agent/Workflow/Plugin, Provider/Model, Datenklassen, Oversight, Risk-Class, Status/Version | 1 Tag |
+| K-DPIA | **DPIA / AI Impact / FRIA Support** — aus vorhandenen Metadaten und Evidence vorbefüllbare Templates/Exports für Datenschutz-Folgenabschätzung bzw. AI-/Grundrechts-Risikoprüfung, **wo der konkrete Einsatz dies verlangt**. Keine automatische Rechtsbewertung | 1 Tag |
+| K-INC | **AI/Privacy Incident Register** — Incident erfassen, betroffene Use-Cases/Versionen/Provider/Runs referenzieren, Maßnahmen und Evidence dokumentieren; Reporting-Fristen/-pflichten bleiben organisatorisch/use-case-spezifisch | 0.5 Tage |
+| K-RET | **Retention-/Erasure Admin UI** — vorhandene Daten-/Knowledge-/Memory-Retention-Policies administrierbar und nachvollziehbar machen; Legal Hold/Ausnahme nur als explizite Policy, keine neue Storage-Engine | 0.5 Tage |
+| K-COMP-TEST | **Compliance E2E/Contract Tests** — AI-Kennzeichnung, Data-Exposure/Provider-Blocking, Search/RAG/Graph/Memory-Cleanup, Betroffenenrechtsweg, Oversight/Approval-Record, Tenant-Isolation und Evidence Export durchtesten | 1.5 Tage |
+| K-DOC | **EU Compliance Betriebsdoku** — Rollen/Verantwortlichkeiten, Provider-Onboarding, Use-Case-Klassifikation, DPIA/AI-Impact-Checkliste, Incident-/DSAR-Ablauf, Plugin-Anforderungen und klare Grenze „Plattformfunktion ≠ automatische Rechtskonformität“ | 0.5 Tage |
+
+**Deliverables Phase K:** prüfbares AI-/Privacy-Use-Case-Register, vorbefüllbare Compliance-Templates, Incident-/Retention-Administration, E2E-Nachweis der technischen Datenschutz-/Oversight-Kontrollen und vollständige EU-Compliance-Betriebsdokumentation.
+
+---
+
 ## Zielarchitektur im Endstand
 
 ```text
@@ -880,10 +928,12 @@ Vertical / Branchen-Plugin
 │ Plugin Runtime / Manifest / Registries                   │
 ├──────────────────────────────────────────────────────────┤
 │ Controlled Self-Improvement                              │
+├──────────────────────────────────────────────────────────┤
+│ Privacy / DSGVO / AI Compliance by Design                │
 └──────────────────────────────────────────────────────────┘
 ```
 
-**Architekturgrenze:** Plugins erweitern die Plattform fachlich. Workstream/MiniApps sind die gemeinsame Interaktionsschicht; sie ersetzen keine Domain-Services. Agenten/Skills/Workflows/MCP greifen immer über normale Services/Tools und deren aktuellen Auth-/Run-as-/Permission-Kontext zu.
+**Architekturgrenze:** Plugins erweitern die Plattform fachlich. Workstream/MiniApps sind die gemeinsame Interaktionsschicht; sie ersetzen keine Domain-Services. Agenten/Skills/Workflows/MCP greifen immer über normale Services/Tools und deren aktuellen Auth-/Run-as-/Permission-Kontext zu. Privacy-/AI-Compliance nutzt dieselben vorhandenen Daten-, Provider-, Audit-, Approval- und Lifecycle-Grenzen; sie bildet **keine zweite Policy-/Runtime-Architektur**.
 
 ---
 
@@ -938,7 +988,7 @@ Effektive Child-Agent-Fähigkeiten
 
 Ein Parent-/Supervisor-Agent darf einem Child-Agent keine Rechte verleihen, die im aktuellen Run-as-Kontext nicht vorhanden sind. Delegations-Tiefe, Budgets, Max-Runs und Loop-Limits verhindern unkontrollierte Agent-zu-Agent-Schleifen.
 
-**Wichtig:** Diese Fähigkeiten werden jetzt noch nicht vorgebaut. Die aktuelle Agent-MVP-Architektur muss sie nur offenlassen. Später wird die bestehende Runtime um `AgentJob`, Task-Decomposition, Delegation/Subagents, Supervisor-Logik und Evaluation/Replanning erweitert — keine zweite Agent-Plattform.
+**Wichtig:** Diese Fähigkeiten werden jetzt noch nicht vorgebaut. Die aktuelle Agent-MVP-Architektur muss sie nur offenlassen. Später wird die bestehende Runtime um `AgentJob`, Task-Decomposition, Delegation/Subagents, Supervisor-Logik und Evaluation/Replanning erweitert — keine zweite Agent-Plattform. Auch Advanced AgentJobs/Subagents erben dieselbe AI-Use-Case-, Provider/Data-Policy-, Transparency-, Oversight- und Audit-Semantik; keine Sonder-Compliance-Engine für Advanced Agents.
 
 ### Advanced Automation Runtime
 
@@ -1016,8 +1066,9 @@ Trigger / Event / Cron / Webhook / Agent
 | H — Firmenwissen | 6 Wochen | Wiki + DMS + Mail + Communication + Businesswissen, RAG, Evidence, Graph-Extraktion, Ask Knowledge im Workstream |
 | I — Integration & Human-AI Workstream | 6 Wochen | Agent↔Workflow↔Knowledge↔Communication, echte MiniApps, Shared/Proactive/Mobile Workstreams, Dashboard, MCP, Polish |
 | J — Controlled Self-Improvement | 5 Wochen | Improvement Signals/Proposals, Evaluation/Dry-Run, Approval, Versionierung/Rollback, Wirkungsmessung |
-| **Total** | **52 Wochen** | **LeoPlatform Endstand-Kern** |
+| K — EU Compliance Finalization | 1 Woche | AI-Use-Case-Register, DPIA/AI-Impact-Support, Incident/Retention, Compliance-E2E, Betriebsdoku |
+| **Total** | **52 Wochen** | **LeoPlatform Endstand-Kern inkl. Privacy/DSGVO/EU-AI-Act-by-Design** |
 
 ---
 
-*Diese Roadmap basiert auf dem Endstand-Audit des aktuellen Code-Archivs und der gemeinsamen Detail-Review. Ziel bleibt: keine unnötigen Universalmodelle, keine Massenrefactorings und keine parallelen Mechanismen. Gemeinsame technische Kerne werden dort genutzt, wo Semantik wirklich gleich ist; fachliche Speziallogik bleibt erlaubt. Bestehender funktionierender Code wird respektiert.*
+*Diese Roadmap basiert auf dem Endstand-Audit des aktuellen Code-Archivs und der gemeinsamen Detail-Review. Ziel bleibt: keine unnötigen Universalmodelle, keine Massenrefactorings und keine parallelen Mechanismen. Gemeinsame technische Kerne werden dort genutzt, wo Semantik wirklich gleich ist; fachliche Speziallogik bleibt erlaubt. Bestehender funktionierender Code wird respektiert. Die eingebauten Privacy-/AI-Compliance-Funktionen schaffen technische Voraussetzungen und Nachweise; die rechtliche Konformität eines konkreten Deployments/Branchenplugins hängt zusätzlich von dessen tatsächlichem Zweck, Datenverarbeitung, Betreiberrolle und organisatorischen Maßnahmen ab.*