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) <noreply@anthropic.com>
This commit is contained in:
Benjamin Admin
171
zeroclaw/PLAN-control-relevance-filter.md
Normal file
171
zeroclaw/PLAN-control-relevance-filter.md
Normal file
@@ -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)
|
||||||
Reference in New Issue
Block a user