fix: Restrict sub-section detection to genuinely separate document types
Only Cookie and Widerruf sections are checked as separate documents. Social Media, DSFA, Betroffenenrechte, Dienste von Drittanbietern are part of the parent DSI and no longer generate false findings. Added PLAN-rag-document-check.md for Phase 2: - RAG-based checks with document-type-specific Controls - DSFA checklist (Art. 35 + Landes-Listen) - AVV checklist (Art. 28) - Reference detection (sub-doc → parent doc) Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
This commit is contained in:
@@ -249,17 +249,17 @@ def _run_checklist(text: str, doc_type: str, label: str, url: str, word_count: i
|
|||||||
|
|
||||||
|
|
||||||
# Section heading patterns → document type mapping
|
# Section heading patterns → document type mapping
|
||||||
|
# ONLY sections that are genuinely separate document types with their own checklists.
|
||||||
|
# Everything else (Social Media, Betroffenenrechte, Dienste von Drittanbietern)
|
||||||
|
# is part of the parent DSI and inherits its checks.
|
||||||
SECTION_TYPE_MAP = [
|
SECTION_TYPE_MAP = [
|
||||||
(r"cookie", "cookie"),
|
(r"^cookie", "cookie"), # Cookie-Richtlinie → §25 TDDDG
|
||||||
(r"dienste?\s+von\s+drittanbieter", "dse"),
|
(r"widerrufsrecht|widerrufsbelehrung", "widerruf"), # Widerruf → §355 BGB
|
||||||
(r"social\s+media", "dse"),
|
(r"^impressum$", "impressum"), # Impressum → §5 TMG
|
||||||
(r"datensicherheit", "dse"),
|
(r"^(?:agb|allgemeine geschäftsbedingungen|nutzungsbedingungen)$", "agb"),
|
||||||
(r"betroffenenrecht", "dse"),
|
# NOTE: Social Media, DSFA, Datensicherheit, Betroffenenrechte are NOT
|
||||||
(r"widerrufsrecht|widerruf", "widerruf"),
|
# separate documents — they are sections within the parent DSI.
|
||||||
(r"impressum", "impressum"),
|
# DSFA needs its own checklist (RAG-based) — Phase 2.
|
||||||
(r"nutzungsbedingung|agb|geschaeftsbedingung", "agb"),
|
|
||||||
(r"datenschutz(?:folge|risiko).*(?:analyse|abschaetzung)|dsfa", "dse"),
|
|
||||||
(r"datenschutzerkl(?:ae|ä)rung.*social", "dse"),
|
|
||||||
]
|
]
|
||||||
|
|
||||||
|
|
||||||
|
|||||||
@@ -0,0 +1,85 @@
|
|||||||
|
# Plan: RAG-basierte Dokumentenpruefung (Phase 2)
|
||||||
|
|
||||||
|
## Problem
|
||||||
|
|
||||||
|
Die Dokumenten-Pruefung verwendet aktuell statische Regex-Checklists
|
||||||
|
(Art. 13 DSGVO, §305ff BGB, §5 TMG, §25 TDDDG). Das reicht fuer
|
||||||
|
Standard-Dokumente, aber nicht fuer:
|
||||||
|
|
||||||
|
1. **DSFA** — Datenschutz-Folgenabschaetzung hat eigene Anforderungen
|
||||||
|
(Art. 35 DSGVO, Landes-DSFA-Listen, z.B. BaWue)
|
||||||
|
2. **Social Media Konzepte** — Gemeinsame Verantwortlichkeit (Art. 26 DSGVO)
|
||||||
|
3. **Auftragsverarbeitungsvertraege** — Art. 28 DSGVO Mindestinhalte
|
||||||
|
4. **Loeschkonzepte** — DIN 66398, BfDI-Loeschkonzept
|
||||||
|
|
||||||
|
## Loesung: RAG-basierter Check
|
||||||
|
|
||||||
|
### Schritt 1: Dokumenttyp → Regulations Mapping
|
||||||
|
|
||||||
|
```python
|
||||||
|
DOC_TYPE_REGULATIONS = {
|
||||||
|
"dse": ["DSGVO Art. 13", "DSGVO Art. 14"],
|
||||||
|
"dsfa": ["DSGVO Art. 35", "DSK DSFA-Liste", "BaWue DSFA-Muss-Liste"],
|
||||||
|
"avv": ["DSGVO Art. 28"],
|
||||||
|
"agb": ["BGB §305", "BGB §307", "BGB §309"],
|
||||||
|
"impressum": ["TMG §5", "MStV §18"],
|
||||||
|
"widerruf": ["BGB §355", "BGB §312g"],
|
||||||
|
"cookie": ["TDDDG §25", "ePrivacy Art. 5(3)"],
|
||||||
|
"social_media_konzept": ["DSGVO Art. 26", "DSK OH Telemedien"],
|
||||||
|
"loeschkonzept": ["DIN 66398", "DSGVO Art. 5(1)(e)", "BfDI Loeschkonzept"],
|
||||||
|
}
|
||||||
|
```
|
||||||
|
|
||||||
|
### Schritt 2: Controls aus RAG laden
|
||||||
|
|
||||||
|
Fuer jede Regulation:
|
||||||
|
```python
|
||||||
|
controls = rag_client.search(
|
||||||
|
query=f"Pflichtinhalte fuer {doc_type}",
|
||||||
|
collection="bp_compliance_controls",
|
||||||
|
regulations=[regulation],
|
||||||
|
top_k=10,
|
||||||
|
)
|
||||||
|
```
|
||||||
|
|
||||||
|
### Schritt 3: Control-basierter Check
|
||||||
|
|
||||||
|
Fuer jeden Control pruefen ob der Dokumenttext die Anforderung erfuellt:
|
||||||
|
```python
|
||||||
|
for control in controls:
|
||||||
|
# Semantic check: Ist die Control-Anforderung im Text adressiert?
|
||||||
|
# Option A: Regex-Keywords aus Control extrahieren
|
||||||
|
# Option B: LLM fragen "Erfuellt dieser Text die Anforderung X?"
|
||||||
|
# Option C: Embedding-Similarity zwischen Control und Textabschnitten
|
||||||
|
```
|
||||||
|
|
||||||
|
### Schritt 4: Referenzierung erkennen
|
||||||
|
|
||||||
|
Wenn ein Sub-Dokument auf das Haupt-Dokument verweist:
|
||||||
|
- "Verantwortlicher: siehe Haupt-DSI"
|
||||||
|
- "Die unter Ziffer 1 genannten Angaben gelten entsprechend"
|
||||||
|
- Gleiche Domain-URL mit Anker → Referenz auf Eltern-Dokument
|
||||||
|
|
||||||
|
→ Fehlende Pflichtangaben nicht als Finding werten wenn Referenz erkannt
|
||||||
|
|
||||||
|
## Dateien
|
||||||
|
|
||||||
|
| Datei | Aenderung |
|
||||||
|
|-------|-----------|
|
||||||
|
| `backend-compliance/compliance/services/rag_document_checker.py` | NEU: RAG-basierter Check |
|
||||||
|
| `backend-compliance/compliance/api/agent_doc_check_routes.py` | Integration RAG-Check |
|
||||||
|
| `backend-compliance/compliance/services/dsi_document_checker.py` | DSFA/AVV/Loeschkonzept Checklists |
|
||||||
|
|
||||||
|
## Voraussetzungen
|
||||||
|
|
||||||
|
- RAG-Service muss laufen (bp-core-rag-service:8097)
|
||||||
|
- Qdrant muss die Control-Collections haben
|
||||||
|
- Embedding-Pipeline muss durchgelaufen sein (Controls embedded)
|
||||||
|
|
||||||
|
## Reihenfolge
|
||||||
|
|
||||||
|
1. Dokumenttyp-Erkennung erweitern (DSFA, AVV, Loeschkonzept)
|
||||||
|
2. RAG-Query fuer Controls pro Dokumenttyp
|
||||||
|
3. Control → Textabschnitt Matching
|
||||||
|
4. Referenzierungs-Erkennung
|
||||||
|
5. Frontend: Dokumenttyp-spezifische Checklisten anzeigen
|
||||||
Reference in New Issue
Block a user