breakpilot-compliance/docs-src/development/dse_v1_validation.md

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)