From 2a6f526c88aef93799f5f014bbb9be5f25cc586d Mon Sep 17 00:00:00 2001 From: Benjamin Admin Date: Tue, 28 Apr 2026 14:32:25 +0200 Subject: [PATCH] docs: plan for Control Relevance Filter (3-stage: rules, LLM, follow-up) Addresses false-positive controls like C_TRANSPARENCY being recommended when no AI usage is evident. Plan for separate implementation session. Co-Authored-By: Claude Opus 4.6 (1M context) --- zeroclaw/PLAN-control-relevance-filter.md | 171 ++++++++++++++++++++++ 1 file changed, 171 insertions(+) create mode 100644 zeroclaw/PLAN-control-relevance-filter.md diff --git a/zeroclaw/PLAN-control-relevance-filter.md b/zeroclaw/PLAN-control-relevance-filter.md new file mode 100644 index 0000000..9b5d832 --- /dev/null +++ b/zeroclaw/PLAN-control-relevance-filter.md @@ -0,0 +1,171 @@ +# Plan: Control Relevance Filter — Generische Controls kontextsensitiv filtern + +## Problem + +Die UCCA-Engine empfiehlt Controls pauschal basierend auf Intake-Flags (Boolean-Felder wie +`personal_data: true`, `marketing: true`). Sie prueft NICHT, ob der analysierte Text die +Bedingungen fuer einen spezifischen Control tatsaechlich erfuellt. + +### Konkretes Beispiel (Opodo-Test, 2026-04-28) + +- **Control:** `[C_TRANSPARENCY] Nutzer informieren dass sie mit KI interagieren` +- **Quelle:** AI Act Art. 52 — nur relevant wenn KI eingesetzt wird +- **Opodo sagt:** "automated processing" (kann regelbasierte Software sein, muss keine KI sein) +- **Ergebnis:** False Positive — Control wird empfohlen obwohl kein KI-Einsatz belegt ist + +### Skalierung + +Von ~166.740 Controls in der RAG-Datenbank wird ein unbekannter Prozentsatz +bei jeder Bewertung generisch empfohlen. Jedes False Positive untergräbt das +Vertrauen des Nutzers und macht das Tool fuer Abmahnungen unbrauchbar. + +## Loesung: 3-Stufen Relevance Filter + +### Stufe 1: Regelbasierter Vorfilter (deterministisch, schnell) + +Jeder Control bekommt ein `relevance_conditions` Feld (JSON): + +```json +{ + "control_id": "C_TRANSPARENCY", + "relevance_conditions": { + "text_must_contain_any": ["KI", "kuenstliche Intelligenz", "artificial intelligence", + "machine learning", "maschinelles Lernen", "neural", "deep learning", + "AI system", "AI-System", "algorith"], + "text_must_not_contain": [], + "requires_intake_flag": "automation", + "min_confidence": 0.5 + } +} +``` + +**Implementierung:** +- Neues Feld `relevance_conditions` in `compliance.canonical_controls` (JSONB) +- Funktion `check_relevance(control, source_text) -> (relevant: bool, confidence: float)` +- Laeuft NACH dem UCCA-Assessment, BEVOR das Ergebnis zurueckgegeben wird +- Filtert Controls raus deren Keywords im Quelltext nicht vorkommen + +**Aufwand:** ~200 LOC Python, kein LLM-Call noetig +**Datei:** `ai-compliance-sdk/internal/ucca/relevance_filter.go` oder `backend-compliance/compliance/services/relevance_filter.py` + +### Stufe 2: LLM-Validierung (fuer High-Value Controls) + +Fuer Controls mit `severity >= HIGH` oder wenn der regelbasierte Filter unsicher ist +(confidence < 0.7), wird Qwen gefragt: + +``` +Gegeben dieser Dokumenttext: +"[...Auszug...]" + +Ist der folgende Control relevant fuer dieses Dokument? +Control: "[C_TRANSPARENCY] Nutzer informieren dass sie mit KI interagieren" +Rechtsgrundlage: Art. 52 AI Act + +Antworte NUR mit: JA (mit Begruendung) oder NEIN (mit Begruendung) +``` + +**Implementierung:** +- Neuer Endpoint: `POST /sdk/v1/ucca/validate-controls` +- Nimmt: `assessment_id`, `source_text`, `controls[]` +- Gibt zurueck: `controls[]` mit `relevant: bool`, `reason: string` +- Cached: Gleicher Text + Control = gleiche Antwort (24h TTL) + +**Aufwand:** ~150 LOC, 1 LLM-Call pro Control (parallelisierbar) + +### Stufe 3: Follow-Up-Fragen an den Nutzer (Hybrid) + +Wenn weder Regel noch LLM sicher entscheiden koennen: + +``` +Follow-Up: "Setzt der Anbieter KI oder maschinelles Lernen ein?" +→ Ja: Control bleibt +→ Nein: Control wird entfernt +→ Unsicher: Control bleibt mit Hinweis "Nicht verifizierbar" +``` + +**Bereits implementiert:** Das `follow_up_questions` System im Agent-Endpoint. + +## Datenmodell-Aenderung + +```sql +-- Neues Feld in canonical_controls +ALTER TABLE compliance.canonical_controls +ADD COLUMN IF NOT EXISTS relevance_conditions JSONB DEFAULT '{}'; + +-- Index fuer schnelle Abfrage +CREATE INDEX IF NOT EXISTS idx_controls_relevance +ON compliance.canonical_controls USING gin (relevance_conditions); +``` + +## Architektur + +``` +UCCA Assessment + │ + ▼ +┌────────────────────┐ +│ Stufe 1: Regelfilter│ ← text_must_contain_any, intake_flags +│ (deterministisch) │ +└────────┬───────────┘ + │ unsicher oder high-severity + ▼ +┌────────────────────┐ +│ Stufe 2: LLM-Check │ ← Qwen validiert Relevanz +│ (1 Call/Control) │ +└────────┬───────────┘ + │ immer noch unsicher + ▼ +┌────────────────────┐ +│ Stufe 3: Follow-Up │ ← Nutzer beantwortet Frage +│ (Frontend) │ +└────────────────────┘ +``` + +## Implementierungsreihenfolge + +### Phase 1: Regelfilter (1 Tag) + +1. Migration: `relevance_conditions` Feld zu `canonical_controls` +2. Seed-Script: Top-20 generische Controls mit Bedingungen versehen + (C_TRANSPARENCY, C_EXPLICIT_CONSENT, C_DSFA_REQUIRED, etc.) +3. Filter-Funktion in `agent_analyze_routes.py` +4. Test: Opodo erneut analysieren — C_TRANSPARENCY sollte rausfallen + +### Phase 2: LLM-Validierung (1 Tag) + +1. Neuer SDK-Endpoint `/sdk/v1/ucca/validate-controls` +2. Integration in den Agent-Workflow +3. Caching-Layer (Redis/Valkey) + +### Phase 3: Batch-Seeding (2-3 Tage) + +1. Pipeline-Job: Fuer alle 166k Controls `relevance_conditions` generieren + (LLM-gestuetzt: "Welche Keywords im Quelltext wuerden diesen Control relevant machen?") +2. Qualitaetspruefung: Stichprobe von 100 Controls manuell validieren + +## Betroffene Dateien + +| Datei | Aenderung | +|-------|-----------| +| `backend-compliance/compliance/api/agent_analyze_routes.py` | Filter-Integration | +| `backend-compliance/compliance/services/relevance_filter.py` | NEU: Regelfilter | +| `ai-compliance-sdk/internal/ucca/relevance_filter.go` | NEU: SDK-seitig (alternativ) | +| `ai-compliance-sdk/internal/api/handlers/ucca_handlers.go` | Neuer Endpoint | +| Migration | `relevance_conditions` Spalte | +| `control-pipeline/` | Batch-Seeding Job (Phase 3) | + +## Risiken + +| Risiko | Mitigation | +|--------|------------| +| Zu aggressive Filterung (False Negatives) | Stufe 1 nur fuer klare Faelle, Stufe 2 als Fallback | +| LLM-Kosten bei vielen Controls | Caching + nur high-severity Controls | +| Datenbank-Migration auf Production | `ADD COLUMN IF NOT EXISTS` ist non-blocking | +| 166k Controls ohne relevance_conditions | Default `{}` = kein Filter = bisheriges Verhalten | + +## Testfaelle + +1. **Opodo-Test:** C_TRANSPARENCY sollte NICHT mehr empfohlen werden (kein KI-Nachweis) +2. **Chatbot-Anbieter:** C_TRANSPARENCY SOLL empfohlen werden (KI explizit erwaehnt) +3. **Arztpraxis-Website:** C_DSFA_REQUIRED SOLL empfohlen werden (Gesundheitsdaten) +4. **Blog ohne Tracking:** Nur minimale Controls (Impressum, Datenschutzerklaerung)