Benjamin Admin
9d79cf1576
Know-how-Freeze der Website-Compliance-Runde (DSE/Cookie/Impressum/AGB). docs: platform_evidence_v1 (Evidenz-/Qualitaetsnachweis, echte Zahlen), nutzungsbedingungen_mapping (neues Modul = Mapping, empirisch belegt), platform_checker_matrix (Meta-Modell verification_method x decision_method), verification_method, platform_validation_v1. code: checkers/ (reusable Pruefer-Library base+reference+embedding+llm, im Container validiert), agb/ (decision_method-Routing + Checker-Prototypen, 71% FP -> ~0 validiert). Dev-only, kein Prod-Push; Benchmark-GTs/Korpora im internen Archiv (data-retention). Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
5.4 KiB
BreakPilot — Evidenz- & Qualitätsnachweis (Website-Compliance v1)
Status: konsolidierter Freeze-Stand 2026-06-21. Belegbasis aus 4 kalibrierten Modulen (DSE, Cookie, Impressum, AGB). Dient als (a) technischer Freeze-Record und (b) Backbone für Sales/Investoren. Hinweis: Zahlen = gemessene Validierungsergebnisse gegen Opus-Ground-Truth. Tool-/Prod-Integrationsstand je Modul siehe §7 (validiert ≠ überall schon live).
1. Kernaussage
Die meisten Compliance-Tools machen: Dokument → LLM → Finding — ein Richter für alles. Das erzeugt systematische False Positives und hat keine belastbare Evidenzbasis.
BreakPilot macht: Dokument → Control-Routing → spezialisierter Prüfer → Finding.
Wir haben für jeden Kontrolltyp den optimalen Prüfer empirisch ermittelt — mit echten Vorher/Nachher-Zahlen, nicht mit Marketing.
Das ist über 4 strukturell verschiedene Dokumenttypen reproduzierbar belegt — und damit voraussichtlich das Routing-Prinzip für alle ~14.000 Master Controls.
2. Die Architektur (zwei Routing-Achsen)
Vollständige Kette: Regulation → Obligation → Control → verification_method → decision_method → Prüfer → Evidence → Finding → Ticket.
verification_method(Kategorie / welcher Prüfer-Typ): CONTENT · FIELD · REFERENCE · BEHAVIOR · PRESENTATION · PROCESS · TECHNICAL · CONTRACTUAL.decision_method(konkreter Mechanismus): REGEX · EMBEDDING · LLM · LINK_RESOLVER · PLAYWRIGHT · AUDIT · SCANNER.
Kernregel: Was im Text nicht beweisbar ist, gehört nicht in den Text-Check. Scope-Gate (Applicability) läuft vor allen Prüfern; Severity steuert Finding vs. Empfehlung.
3. Evidenz je Modul
| Modul | dominanter Prüfer | gemessenes Ergebnis | Hebel | Reife |
|---|---|---|---|---|
| DSE | CONTENT (Embedding+LLM) | False Positives 11 % → 6 %; an 8 Firmen validiert, Generalisierung nachgewiesen (kein Overfit auf einen Assessor); Claude-Tier-Pfad → ~2 % bekannt | Kriterien-Kalibrierung + LLM-Kaskade | RC |
| Impressum | FIELD + PRESENTATION (+ Scope-Gate) | 171 falsche Findings → 0 (Scope-Gate); Feldmatrix (Firma/Anschrift/HRB/USt-IdNr/Kontakt) FP 0 %, Recall 1.0; 5 Präsentations-Controls an Playwright re-routet | Scope-Gate + deterministischer Feld-Matcher schlägt LLM | RC |
| Cookie | BEHAVIOR + CONTENT | Artifact-Type-Trennung Banner ≠ Richtlinie validiert (Controls liefen am falschen Artefakt → re-routet); Browser-Verhaltens-Matrix (Enforcement, Dark-Pattern, Reject=Accept) | Artifact-Type-Routing + Playwright-Verhaltenssensor | Wave-1 (GT-Stab. offen) |
| AGB | CONTENT + REFERENCE + LLM | 71 % FP → ~0 (7-Firmen-Opus-GT): 49 Findings / 35 falsch → bereinigt; Embedding-Rescue 21 Recall-FP gekillt, 0 Fehl-Rescue; LLM-Judge (ganze §-Abschnitte) 14/14; Reference-Check 7/7 | decision_method pro Item (17 EMBEDDING, 2 LLM, 1 REFERENCE) | Architektur validiert |
4. Warum die Zahlen belastbar sind (Methodik-Rigor)
- Ground Truth mit dem stärksten Modell (Opus-4-8), nicht mit billigen Modellen.
- Prove-don't-handwave: echte FP/FN-Zählungen, Vorher/Nachher, keine Behauptungen.
- Generalisierung statt Overfit: Mehr-Firmen-GT (DSE 8, AGB 7) + explizite Leitplanken gegen Ein-Assessor-Overfit.
- Mehrfach-Referenz-Validierung: bei AGB 3-Wege (Opus-GT × Claude-Eigenbewertung × Laufzeit-Kaskade) — deckte sogar einen Fehler in der GT selbst auf.
- Stichprobe vor Aufbau: vor jeder teuren Klassifikation/Batch zuerst stratifizierte Stichprobe geprüft (verhinderte mehrfach Aufbau auf falschem Fundament).
5. Die Schlüssel-Entdeckung (AGB)
Verschiedene Controls innerhalb desselben Moduls brauchen verschiedene Richter. Belege:
- Eine globale Embedding-Schwelle scheitert bei juristischer Prosa; per-Item-Schwellen trennen sauber.
- Whole-Section-Retrieval (ganze §-Abschnitte) schlägt Top-k-Chunks für den LLM-Judge deutlich.
- Ein billig-zuerst-Kaskaden-LLM taugt nicht als Richter (eskaliert selbstbewusst-falsche Antworten nicht) — für harte Items starken Tier pinnen.
- Ein Verweis („siehe Datenschutzerklärung") ist ein REFERENCE/Link-Check, kein LLM-Fall.
6. Wettbewerbspositionierung
| Typisches Tool | BreakPilot | |
|---|---|---|
| Prüfansatz | ein LLM für alles | Control-Routing → spezialisierter Prüfer |
| False Positives | systematisch (LLM auf Nicht-Text-Pflichten) | je Kontrolltyp minimiert (gemessen) |
| Evidenzbasis | keine | Mehr-Firmen-GT, reproduzierbare Zahlen |
| Skalierung neuer Regulierungen | jedes Mal neu | Mapping auf bestehende Prüfer-Matrix |
7. Reifegrad, Ehrlichkeit & Roadmap
- Validiert (Messung): alle 4 Module oben.
- Live im Tool: DSE-Kriterien (prod). Impressum-Scope/Feldmatrix, Cookie-Artifact-Type und AGB-C-lean sind validiert, aber noch nicht überall ins Produkt integriert → Demo-Integration ist der nächste Schritt (Vorher/Nachher live zeigbar machen).
- Website-/Marketing-Compliance: abgeschlossen (DSE/Impressum/Cookie/AGB + Architektur). Restliche Web-Doc-Typen (Nutzungsbedingungen, Shop-AGB, Legal Notice, Social-Media) = Mapping, keine neue Architektur.
- Nächste große Etappe (nach Sales): industrielle Compliance (CRA, Maschinenverordnung, NIS2, DORA, ISO 27001, TISAX, AI Act) — neue Prüfertypen TECHNICAL/PROCESS/EVIDENCE/SYSTEM; die Prüfer-Matrix wird dort wiederverwendet.