Waarom uw RAG-privacy-verdediging waarschijnlijk niet werkt

RAG is de dominante architectuur voor overheids-LLM-toepassingen. Document retrieval, burgervraagstelsels, kennisbanken — overal waar een organisatie een LLM laat antwoorden op basis van eigen documenten, draait RAG. En overal waar die documenten persoonsgegevens bevatten, vertrouwt de organisatie op een privacy-verdediging.

Een nieuw arXiv-paper toont dat dit vertrouwen vaak misplaatst is. Black-box privacy-scores voor RAG-systemen zijn moeilijk te interpreteren tenzij je de actieve pipeline-hook van de verdediging kent. En in de benchmark-reimplementaties van het paper zijn de DP-style verdedigingen TODO-flagged stubs: ze passen alleen de retrieval-scores aan, en hun generatie-hooks retourneren responses ongewijzigd.

Met andere woorden: de verdediging bestaat niet echt in de generatiestap. En dat is precies waar de lekkage plaatsvindt.

De actieve-path audit

Het paper introduceert een active-path audit als methodologie. In plaats van een black-box score te vertrouwen, inventariseer je de source-level hooks over drie fasen:

1. Retrieval — hoe worden documenten geselecteerd?
2. Retrieved content — wat gebeurt er met de opgehaalde content?
3. Generation — hoe wordt de response gegenereerd?

Voor elke hook map je de metric naar het lekkage-kanaal dat het observeert. En je valideert generated-text effecten met exact-match canaries — bekende geheime strings die je in de documenten plaatst en waarvan je controleert of ze in de response lekken.

Formele definitie van de audit

Laat een RAG-systeem $R$ bestaan uit een retrieval-functie $r$ en een generatie-functie $g$:

$$R(x) = g(r(x), x)$$

waarbij $x$ de query is. Een privacy-verdediging $D$ claimt dat $R$ geen gevoelige informatie lekt. De verdediging kan op twee punten ingrijpen:

• Retrieval-hook: $r'(x) = \text{filter}(r(x))$ — gevoelige documenten worden uit de retrieval gefilterd.
• Generation-hook: $g'(r(x), x) = \text{sanitize}(g(r(x), x))$ — de response wordt gesaneerd.

De actieve-path audit controleert of beide hooks daadwerkelijk actief zijn. Het paper toont dat in de benchmark-reimplementaties de retrieval-hook actief is (scores worden aangepast) maar de generation-hook een stub is:

$$g'(r(x), x) = g(r(x), x)$$

De sanitize-functie is de identiteit. De verdediging beïnvloedt membership-inference-gedrag (omdat de retrieval anders is) maar doet niets tegen generated-text lekkage.

De canary-methode

De validatie gebruikt exact-match canaries. Je plaatst een bekende geheime string $c$ in een document, stelt een query die het document ophaalt, en controleert of $c$ in de response verschijnt.

def active_path_audit(rag, canaries: list, queries: list) → dict:
    """Active-path RAG privacy audit met exact-match canaries.
    
    Plaatst canaries in documenten, draait queries, en checkt of de
    canary in de gegenereerde response lekt.
    """
    results = {}
    for canary, query in zip(canaries, queries):
        # Injecteer canary in een document
        doc = f"Vertrouwelijk: {canary}. Dit is een testdocument."
        rag.add_document(doc)
        
        # Draai de query
        response = rag.generate(query)
        
        # Exact-match check op de canary
        leaked = canary in response
        results[canary] = {
            "leaked": leaked,
            "response_snippet": response[:200],
        }
    return results

De complexiteit is O(n) voor n canaries, met O(1) per canary-check. De kracht zit in de exact-match: een canary die in de response verschijnt is onweerlegbaar bewijs van lekkage, ongeacht wat de black-box score beweert.

De empirische resultaten

Het paper rapporteert twee contrasterende resultaten:

• DP-style verdedigingen: ze beïnvloeden membership-inference-gedrag maar tracken No-Defense op generated-text named-entity lekkage, gemeten met NEL_strict. De generatie-hooks zijn stubs.
• LPRAG (end-to-end): de path is canary-gevalideerd op het email-kanaal. Onder No-Defense herstelt het 53/150 canaries; onder LPRAG 0/150.

Het verschil is instructief. LPRAG beschermt het email-kanaal daadwerkelijk omdat de verdediging in de generatiestap zit. De DP-style verdedigingen beschermen alleen de retrieval, en de lekkage zit in de generatie.

Praktijkvoorbeeld: gemeentelijke kennisbank

Neem een gemeente die een RAG-systeem draait op burgerzaken-documenten. De documenten bevatten namen, BSN-achtige nummers, adressen. De leverancier claimt "privacy-by-design met differential privacy".

Een actieve-path audit onthult:

• De retrieval-hook filtert inderdaad sommige gevoelige documenten.
• Maar de generatie-hook is een TODO-stub. De LLM kan nog steeds persoonsgegevens uit niet-gefilterde documenten in de response genereren.
• Een canary "BSN-123456789" geplaatst in een niet-gefilterd document lekt in de response.

De DPIA van de gemeente nam de leveranciersclaim over zonder source-level validatie. GDPR Artikel 25 (privacy by design) is geschonden omdat de verdediging niet bestaat in de generatiestap.

Beperkingen

De bevindingen zijn genuanceerd en het paper is daar eerlijk over:

• De resultaten betreffen de reimplementaties van het paper, niet de released defenses. Het paper zegt expliciet: "deze bevindingen betreffen onze reimplementaties op onze stack, niet released defenses of defense families."
• De bijdrage is een methodologie en case study, geen universele ranking. Het is geen bewijs dat alle DP-style verdedigingen falen.
• De canary-methode vereist dat je documenten kunt injecteren. In productie is dat niet altijd mogelijk.
• Exact-match is conservatief. Een canary die geherformuleerd wordt (parafrase) wordt niet gedetecteerd, terwijl de informatie wel lekt.

Wat dit betekent voor Nederlandse overheden

De les is methodologisch en praktisch tegelijk. Methodologisch: vertrouw geen black-box privacy-scores. Een score die "privacy" claimt zonder dat je de actieve pipeline-hook kent, is betekenisloos. Praktisch: de lekkage zit in de generatiestap, en de meeste verdedigingen beschermen alleen de retrieval.

Voor overheden die RAG draaien op documenten met persoonsgegevens is de actieve-path audit een concrete, reproduceerbare methode om te valideren of de verdediging echt werkt. De DPIA moet niet de leveranciersclaim overnemen, maar de source-level hooks controleren.

Bron: Mind the Hook: Source-Level Auditing of Privacy Defenses in Retrieval-Augmented Generation (arXiv:2608.09001, 10 aug 2026, ICMLA 2026).