# DSE-Engine — Validierung & Versionierung `DSE_v1` > **Status:** Release-Candidate (qualitativ validiert, nicht „fertig") > **Datum:** 2026-06-19 > **Modul:** Datenschutzerklärung (`doc_type = dse`) > **Zweck dieses Dokuments:** nachvollziehbar festhalten, *wie* die DSE-Engine gemessen > wurde, *welche* Controls *warum* korrigiert wurden und *welcher* reproduzierbare Prozess > daraus entstanden ist — als Referenz für Cookie-Richtlinie, Impressum, AGB, CRA, NIS2, KI-VO usw. ## 1. Kurzfazit Die zentrale Aussage ist nicht „FP 11 % → 6 %", sondern: **die False Positives wurden halbiert, ohne den Schutz vor echten Lücken zu verlieren** (deterministisch nachgewiesen, 0 verschluckte Lücken). | KPI (vs Opus-GT, 5 Firmen, 432 anwendbare Controls) | vorher | `DSE_v1` | |---|---|---| | Falsche Findings (Engine FEHLT / GT ERFÜLLT) | 51 (11 %) | **26 (6 %)** | | Verpasste Lücken (Engine ERFÜLLT / GT FEHLT) | 32 (7 %) | **~31 (~7 %, stabil)** | | Recall | 0,76 | **0,88** | | Precision | 0,83 | **0,84** | Ursache der falschen Findings war **nicht** ein zu schwaches LLM, sondern ~11 Controls, die mehr verlangten als das Gesetz. Die Korrektur der Regel verbessert OVH, Claude, Embeddings und menschliche Auditoren gleichzeitig — höchster ROI. ## 2. Testkorpus (Anti-Overfit) Fünf repräsentative, real abgerufene Datenschutzerklärungen unterschiedlicher Größe/Branche: | Firma | Charakter | DSE-Größe | |---|---|---| | BMW | Großkonzern, sehr umfangreich | ~64 k Zeichen | | Mercedes-Benz | Großkonzern | ~19 k | | ELLI (VW) | Tochter/Energie | ~26 k | | ETO | B2B-Mittelstand | ~26 k | | SafetyKon | kleiner B2B, dünne DSE | ~5 k | Die dünne SafetyKon-DSE ist bewusst der Härtetest gegen **zu lasche** Kriterien. ## 3. Ground-Truth-Methode - **Orakel:** `claude-opus-4-8` (stärkstes verfügbares Modell — NICHT Haiku, das auf 5-Firmen-DSE zu lasch/„N/A-blind" war). Pro `(Firma × Control)` ein Urteil `ERFUELLT | FEHLT | NA`. - Strenge juristische Leitplanken im Prompt (Speicherdauer: zirkuläre Formeln erfüllen nicht; berechtigtes Interesse eines Dritten ≠ eigenes; EU-Kommission-Erwähnung ≠ Angemessenheitsbeschluss). - 456 Urteile, davon 24 `NA` (nicht anwendbar) → 432 anwendbare als Messbasis. - Wichtige Einschränkung: das Opus-GT trägt auf einigen der korrigierten Controls **dieselbe Überstrenge** — siehe §6 (FN-Nachweis). Auf diesen Controls ist die Engine inzwischen *näher am Gesetz* als das GT. ## 4. Gemessene Engine-Architektur Dreistufig, Verdikt je `(Firma × Control)`: 1. **Keyword** (deterministisch) → trifft zu ⇒ ERFÜLLT. 2. **BGE-M3-Embedding-Recall**, Score < 0,50 ⇒ FEHLT (deterministisch, gecacht). 3. **LLM-Judge** (OVH `gpt-oss-120b`) auf den Embedding-Passes (Score ≥ 0,50) — fängt die „semantisch nah, aber nicht erfüllt"-Über-Passes des Embeddings. **Robustheit (Pflicht):** OVH liefert unter Concurrency teils leere Antworten. Eine leere LLM-Antwort darf **niemals** als FEHLT gewertet werden. `DSE_v1` misst mit Retry-on-empty, Concurrency 3, `max_tokens` 600; bei dauerhaft leer → `UNSICHER` (= 4-Status `INSUFFICIENT_EVIDENCE` / Eskalation), nicht FEHLT. ## 5. Messverlauf (ehrlich, inkl. Sackgassen) | Stufe | verpasste Lücken | falsche Findings | Anmerkung | |---|---|---|---| | nur Keyword + Embedding @0,58 | 32 % | 3 % | Embedding allein **ungenügend** (Über-Passes) | | + OVH-LLM (55k-Truncation) | 5 % | 19 % | LLM löst „nichts fehlt"; FP scheinbar hoch | | + Volltext (kein 55k-Cut) | 6 % | 14 % | Truncation hatte BMW-FP aufgebläht | | + Robust (Retry, kein Leer→FEHLT) | 7 % | 11 % | Artefaktfreie Basis | | **+ Kriterien-Fix = `DSE_v1`** | **~7 %** | **6 %** | siehe §7 | **Schlüssel-Befund (Produkt-relevant):** ein großer Teil der ursprünglichen falschen Findings waren **leere OVH-Antworten**, die als FEHLT verbucht wurden — ein echter Pipeline-Bug, nicht ein Inhaltsproblem. Lehre für die Kaskaden-Verdrahtung: leere/Timeout-Antwort → Retry → `INSUFFICIENT_EVIDENCE` / Claude-Eskalation. ## 6. Die korrigierten Controls (juristischer Review) 12 systematische FP-Controls (firmenübergreifend wiederkehrend) wurden juristisch reviewt (Gesetz-Forderung vs. Control-Forderung) und in drei Klassen geteilt. **11 korrigiert, 1 (`DATA-1611-A04`, Klasse A) unangetastet.** Volle Alt→Neu-Diffs: `dse_criteria_changelog.json` (Repo-Wurzel). Backup für Restore: `dse_criteria_backup.json`. ### Klasse B — Control verlangte mehr als das Gesetz (7) | Control | Rechtsnorm | Kern-Korrektur | |---|---|---| | `DATA-2260-A01` | Art. 13(1)(c) | „*primärer*/einzelner Zweck" → Zweck(e) im Plural genügen | | `AUTH-3737-A06` | Art. 13(1)(c)+(e) | keine Zweck/Rechtsgrundlage-Matrix *je* Übermittlung | | `DATA-2992-A03` | Art. 13(1)(e) | Empfänger/Kategorien + Zweck; keine AV-Distinktion/Vertraulichkeit | | `DATA-1624-A03` | Art. 13(1)(f) | Garantie + Zugang via **Link ODER** Kontakt; keine Schutzwirkungs-Beschreibung | | `DATA-1619-A03` | Art. 13(1)(c) | Rechtsgrundlage je Zweck; Artikel-Zitat *nicht* zwingend | | `DATA-424-A09` | Art. 20 | Recht erwähnen genügt; Format (CSV/JSON) *nicht* in der DSE | | `GOV-3300-A06` | Art. 20 | wie A09 (Dedupe-Kandidat zu `DATA-424-A09`) | ### Klasse C — Control mehrdeutig / Pflichten vermischt (4) | Control | Rechtsnorm | Kern-Korrektur | |---|---|---| | `AI-1560-A01` | Art. 13(1)(c) vs (2)(a) | Speicherdauer-Forderung entfernt (eigene Pflicht) | | `SEC-3444-A04` | Art. 13(1)(c) | Titel/Frage „*beschränken*" (Verhalten) → „offenlegen" | | `DATA-1624-A06` | Art. 13(1)(f) | Schutzwirkungs-Beschreibung raus; ⚠️ Near-Duplikat zu `DATA-1624-A03` | | `DATA-2812-A05` | Art. 17 / §25 TTDSG | Titel „*implementieren*" → „offenlegen"; Verweis auf Cookie-Einstellungen genügt | ### Klasse A — Control korrekt, LLM/Artefakt (1, nicht geändert) `DATA-1611-A04` (Art. 13(1)(c)): Kriterien rechtlich sauber; die FP waren OVH-Leerantworten. ## 7. FN-Sicherheitsnachweis (kein Aufweichen) Lockerere Kriterien dürfen keine echten Lücken durchwinken. Nach dem Fix stieg FN scheinbar 32 → 36. Kausaltest (11 korrigierte Controls × 5 Firmen) + **deterministische Textprüfung**: - **0 echte verschluckte Lücken.** Alle 5 „neuen FN" sind Fälle, in denen die Engine jetzt *korrekt* ist und das **Opus-GT zu streng war** — im DSE-Text belegt (bmw nennt „Art. 20 DSGVO", elli „EU-Standardvertragsklauseln … USA", mercedes Empfänger+Weitergabe, eto konkrete Zwecke). - **11 echte Lücken weiterhin gefangen** (TN), v.a. SafetyKons dünne DSE → die Kriterien sind nicht zahnlos geworden. ⇒ Die wahre Engine-FN bleibt bei ~7 % (stabil); die scheinbaren +4 sind GT-Überstrenge. ## 8. Reproduzierbarer Kalibrierungsprozess (das eigentliche Ergebnis) Auf jedes weitere Modul anwendbar (Cookie, Impressum, AGB, CRA, NIS2, KI-VO, DORA, MaschVO): 1. **Opus-GT** je `(Firma × Control)` über 5 repräsentative Firmen bauen. 2. **Engine messen** (Keyword → Embedding → robuster LLM-Judge) vs GT. 3. **FP clustern** — wiederkehrende Controls statt Einzel-Findings (systematisch ≠ zufällig). 4. **Gesetz-vs-Control-Review** der Top-Cluster → Klassen A (LLM-Fehler) / B (zu streng) / C (mehrdeutig). 5. **Kriterien korrigieren** (B+C), versioniert, mit Rechtsnotiz im Changelog. 6. **Re-Messung** — Pflicht: FP gesunken **und** FN stabil (FN-Kausaltest gegen Über-Lockerung). ## 9. Bekannte Grenzen / offene Punkte - **OVH stochastisch** (kein Seed): ±~4 Findings Lauf-zu-Lauf. Für harte Zahlen Mehrfachlauf/Mehrheit. - **GT-Überstrenge** auf einigen korrigierten Controls → „8 % FN" überzeichnet leicht (wahr ~7 %). - **Dedupe offen** (separater Catalog-Schritt, nicht gelöscht): `DATA-1624-A06`↔`A03`, `DATA-424-A09`↔`GOV-3300`. - **Nur macmini-dev.** Kriterien-Änderungen sind reversibel (Backup) und noch **nicht** auf Prod. - **Restliche FP-Tail** (~17 außerhalb der Top-12) bei 6 % belassen — weitere Optimierung schlechter ROI; operativer Hebel ist der Claude-Freigabe-Tier (Kaskade), nicht Regel-Tuning. ## 10. Artefakte & Reproduktion - GT-Verdikte: `/tmp/gt_opus_dse.json` (Container) · Kandidaten/Scores: `/tmp/multi_company_gt.json` - Changelog (Alt→Neu + Rechtsnotiz): `dse_criteria_changelog.json` · Restore: `dse_criteria_backup.json` - Skripte (MacBook `/tmp`, Ausführung via `docker exec -i bp-compliance-backend python3 -`): `cc_gt_opus_dse.py` (GT) · `cc_engine_llm_dse3.py` (robuste Messung) · `cc_apply_criteria.py` (Korrektur + Versionierung) · `cc_check_fn.py` (FN-Kausaltest) · `cc_verify_fn.py` (deterministische Textprüfung)