Onderzoek toont dat LLM's persoonsgegevens kunnen lekken

U moet nu vaststellen welke systemen gevoelige persoonsgegevens rechtstreeks aan een taalmodel voeren, en die stroom vóór het volgende kwartaal achter een aparte retrieval- en saneringslaag brengen.

De aanleiding is een analyse van 19 oktober 2026 van hoe taalmodellen persoonsgegevens kunnen lekken ondanks privacy-instructies, die aantoont dat modellen irrelevante informatie over derden kunnen reproduceren zelfs wanneer zij privacyregels correct lijken te herkennen. Een peer-reviewed studie in Frontiers in Digital Health onderzocht dit fenomeen in klinische documentatie met taalmodellen en stelde vast dat het opsplitsen van generatie en privacybewerking in afzonderlijke lagen de lekkage kon verminderen, hoewel geen enkele onderzochte maatregel volledige bescherming bood. In onze inschatting betekent dit voor u dat een privacyinstructie in de prompt het risico vermindert maar niet elimineert, en dat de bescherming daarom vóór het model moet liggen (wat gaat erin) en ná het model (wat komt eruit), niet alleen in het model zelf.

Waarom een privacyinstructie in de prompt niet volstaat

Het mechanisme is belangrijker dan de getallen. Een taalmodel dat de instructie "vermeld geen informatie over derden" correct kan parafraseert, handelt er niet betrouwbaar naar. Herkenning van een regel en naleving ervan zijn in een generatief model niet hetzelfde proces. Zodra gevoelige informatie in de context van het model zit, kan het model haar reproduceren. Een instructie verandert de kans, niet de mogelijkheid.

Dit verklaart waarom een afzonderlijke, deterministische stap — een filter dat niet redeneert maar vaste regels toepast — meer verschil maakt dan nog een zin in de prompt. De bescherming moet daarom buiten het model liggen.

Welke foutmechanismen u moet adresseren

• Lekkage van irrelevante persoonsgegevens — het model neemt informatie over derden op die niet in de output thuishoort, ondanks privacy-instructies.
• Reproducering van trainingsdata — gevoelige informatie die in de context staat, kan door het model worden herhaald.
• Onvoldoende effect van instructies — privacyregels in de prompt verminderen lekkage maar voorkomen deze niet.
• Afgeleide datastromen — vectorstores, evaluatiedatasets en modeluitvoer vormen nieuwe kopieën van gevoelige informatie.
• Resterende lekkage onder aanvallen — privacy-preserving architecturen reduceren risico onder standaardaanvallen, maar erkennen blootstelling onder adaptieve en herhaalde query-aanvallen.

Welke lagen u moet implementeren

1. Scheiding van retrieval en generatie — houd de ruwe gevoelige bron uitsluitend voor indexering; het generatiemodel ontvangt alleen een minimale, gesaneerde payload.
2. Deterministische nabewerking — pas vaste filterregels toe op de modeluitvoer voordat deze in een dossier belandt, niet alleen semantische instructies.
3. Gestructureerde uitvoer — dwing het model tot gestructureerde formaten die filtering en validatie vereenvoudigen.
4. Toegangscontrole buiten het model — plaats verificatie en logging op het niveau van retrieval en output, niet alleen in de prompt.
5. Menselijke eindcontrole — leg vast wie een door AI opgestelde notitie of samenvatting goedkeurt voordat deze in een dossier belandt, en zorg dat die beslissing herleidbaar is.

Wat u in contracten en documentatie moet vastleggen

Omdat geen enkele onderzochte maatregel volledige bescherming bood, is "we gebruiken een privacy-preserving architectuur" geen eindpunt. In het contract met een AI-leverancier hoort een clausule over logging-minimalisatie, bewaartermijnen van prompt-logs en het recht op onafhankelijke lektests, niet alleen een verwijzing naar hun privacybeleid.

Omdat vectorstores, evaluatiedatasets en modeluitvoer nieuwe kopieën van gevoelige informatie vormen, moet de verwerkingsverantwoordelijke deze artefacten opnemen in het verwerkingsregister en de DPIA. Toets nu of uw huidige privacy-by-design-documentatie onder AVG-artikel 25 deze afgeleide datastromen überhaupt benoemt.

Wat tooling kan doen en wat uw oordeel blijft

Automatische filtering en deterministische nabewerking kunnen lekkage aanzienlijk verminderen en maken controle herleidbaar. Maar geen enkele technische maatregel biedt volledige bescherming tegen alle dreigingsmodellen. Wie zo'n architectuur invoert, koopt risicoreductie binnen een gespecificeerd dreigingsmodel, geen veiligheidsbewijs. Uw professionele oordeel blijft nodig om vast te stellen welke gevoelige gegevens überhaupt in een extern model thuishoren, welke dreigingen u werkelijk moet adresseren, en wie eindverantwoordelijk is voor de output.