Pseudonimiseren voor AI: een lokaal privacyfilter

De Autoriteit Persoonsgegevens raadt organisaties in het hulpmiddel generatieve AI en de AVG van juli 2026 aan om te onderzoeken of generatieve AI "zonder persoonsgegevens" kan. Voor veel taken kan dat: de cloud heeft de inhoud nodig, niet de namen.

Pseudonimiseren voor AI is het vervangen van namen, nummers en andere herleidbare gegevens door neutrale labels voordat een tekst naar een cloud-AI gaat, terwijl de sleutel om ze terug te zetten binnen je eigen netwerk blijft. Een lokaal model of een lokale herkenningsregel vindt de persoonsgegevens, maakt van "Jan de Vries" [PERSOON_1], stuurt de opgeschoonde tekst naar het cloudmodel en zet de namen in het antwoord weer terug. De cloud ziet de vraag, maar niet wie het betreft.

Is gepseudonimiseerde data nog een persoonsgegeven?

Voor jou als organisatie: ja. De AVG zegt in overweging 26 dat gepseudonimiseerde gegevens die met aanvullende gegevens aan een persoon kunnen worden gekoppeld, als gegevens over een identificeerbare persoon gelden. Jij hebt de sleuteltabel, dus voor jou blijft alles persoonsgegevens, met alle plichten die daarbij horen.

Voor de ontvanger ligt het sinds 4 september 2025 genuanceerder. In het arrest EDPS tegen SRB (C-413/23 P) oordeelde het Hof van Justitie dat gepseudonimiseerde gegevens niet "in all cases and for every person" persoonsgegevens zijn. Of ze dat voor een ontvanger zijn, hangt ervan af of die ontvanger de betrokkene met redelijkerwijs beschikbare middelen kan herleiden. De zaak ging over de regels voor EU-instellingen, maar het Hof zegt in punt 52 dat het begrip persoonsgegevens daar en in de AVG op dezelfde manier wordt uitgelegd.

Twee kanttekeningen. De EDPB-richtsnoeren over pseudonimisering (Guidelines 01/2025) zijn van vóór het arrest, strenger, en nog steeds een consultatieversie. En het Hof zegt ook dat je de informatieplicht beoordeelt vanuit jouw positie op het moment van verzamelen. Je moet betrokkenen dus nog steeds vertellen dat hun gegevens, gepseudonimiseerd, naar een AI-dienst gaan.

De lijn van het Hof krijgt navolging. De EDPB gaat in de conceptrichtsnoeren over anonimisering (Guidelines 02/2026, in consultatie tot 30 oktober 2026) uit van een beoordeling per partij: informatie kan voor de ene organisatie anoniem zijn en voor de andere niet. De Europese Commissie stelde in november 2025 in het Digital Omnibus-pakket voor om die relatieve benadering in de definitie van persoonsgegevens in de AVG zelf op te nemen. Dat voorstel ligt nog in onderhandeling en is niet van kracht. Bouw je filter dus op de regels van vandaag: voor jou blijft het persoonsgegevens, voor de cloudaanbieder hangt het af van hoe goed je filter is.

Wanneer helpt pseudonimiseren bij doorgifte naar de VS?

De EDPB heeft in Aanbevelingen 01/2020 twee scenario's beschreven die precies over dit ontwerp gaan. In use case 6 heeft een cloudaanbieder de data leesbaar nodig, en voor dat geval kan de EDPB zich geen effectieve technische maatregel voorstellen. In use case 2 pseudonimiseert de exporteur de data eerst en geeft hij alleen de gepseudonimiseerde versie door. Dat geldt als effectieve aanvullende maatregel als aan vier voorwaarden is voldaan:

1. De gegevens zijn zonder aanvullende informatie niet aan een persoon te koppelen, en de persoon is er ook niet mee uit een grotere groep te lichten.
2. De aanvullende informatie berust uitsluitend bij de exporteur en wordt apart bewaard, in de EER of bij een vertrouwde partij onder gelijkwaardige bescherming.
3. De exporteur houdt als enige zeggenschap over de sleutel die herleiding mogelijk maakt.
4. Een grondige analyse toont aan dat herleiden ook niet lukt met informatie waarover de autoriteiten in het ontvangende land redelijkerwijs beschikken.

Een lokaal privacyfilter is een poging om een use-case-6-situatie om te bouwen tot use case 2. De sleuteltabel blijft op je eigen server, dat regelt voorwaarde 2 en 3. Voorwaarde 1 en 4 hangen af van hoe goed het filter is, en daar zit het werk.

Welke Nederlandse gegevens moet een privacyfilter herkennen?

De meeste kant-en-klare tools zijn gebouwd voor Engelse tekst en Amerikaanse nummers. Een Nederlands filter moet minstens dit herkennen:

Het BSN verdient een eigen regel. Volgens artikel 46 van de UAVG mag een wettelijk identificatienummer alleen worden gebruikt ter uitvoering van de wet die het voorschrijft, en de AP schrijft op de pagina over voorwaarden voor gebruik van het BSN dat dat "ook niet met toestemming" verandert. Een cloudmodel heeft het BSN voor geen enkele taak nodig. Het filter haalt het weg zonder het in de sleuteltabel op te nemen.

Combinaties zijn het tweede punt. De AP schrijft op de pagina gegevens pseudonimiseren dat een geboortedatum met de vier cijfers van een postcode "vaak uniek genoeg" is om iemand via de Basisregistratie Personen te herleiden. Alleen namen weghalen is volgens de AP geen pseudonimisering als de rest van de tekst nog naar een persoon wijst.

Wat missen de bestaande tools?

Bestaande tools voor het herkennen van persoonsgegevens missen meer Nederlandse gegevens dan hun documentatie doet vermoeden, en dat is gemeten.

• Presidio, de bekendste open-source toolkit voor het opsporen van persoonsgegevens, bevat herkenners voor nummers uit achttien landen, maar niet voor Nederland. Er is geen BSN-herkenner. IBAN wordt wel herkend, met controlegetal.
• De Nederlandse spaCy-modellen halen op entiteitsherkenning een F-score van ongeveer 0,76 voor het grootste model, getraind op nieuwstekst, en kennen geen labels voor BSN of IBAN.
• Gespecialiseerde Nederlandse modellen doen het beter, met een blinde vlek. In het onderzoek van Trienes en anderen op 1.260 Nederlandse patiëntdossiers haalde het beste model een F1 van 0,893 en vond het 95,6% van de namen. Van de beroepen vond het 26,2%.

Dat laatste cijfer is het probleem in één getal. "De nieuwe controller van onze vestiging in Zwolle" bevat geen naam, maar in een bedrijf van 200 mensen wijst het één persoon aan. De EDPB noemt in de richtsnoeren over pseudonimisering voor werknemers precies dit soort quasi-identificatoren: functie, aantal uren, dienstjaren. De makers van DEDUCE, een Nederlandse tool voor het de-identificeren van medische tekst, schrijven in de handleiding dat de-identificatie "almost never perfect" is en vooral een manier om risico te verkleinen, niet om anonieme data te krijgen.

Wat we in een filter combineren

Een filter dat in de praktijk werkt, gebruikt drie lagen. Vaste patronen met controlegetallen voor BSN, IBAN, KVK en postcode, omdat die betrouwbaar zijn. Een lijst met bekende namen uit je eigen systemen, zoals klanten uit het CRM en medewerkers uit de HR-administratie, omdat een opzoeklijst geen namen mist die erin staan. En een lokaal taalmodel voor de rest: onbekende namen, en functies en vestigingen die het generaliseert tot [FUNCTIE] en [VESTIGING]. Een klein taalmodel volstaat daarvoor, en draait op dezelfde server als de sleuteltabel.

Gebruik consistente labels per document. Als [PERSOON_1] in de hele tekst dezelfde persoon is, kan het cloudmodel nog redeneren over wie wat aan wie mailde. Willekeurige labels per zin maken het antwoord onbruikbaar.

Wanneer werkt een privacyfilter niet?

Een privacyfilter werkt niet bij taken waar de inhoud zelf de persoon is. Een medisch verhaal, een klachtbrief over een uniek incident of een tuchtdossier blijft herleidbaar, ook zonder één naam. Bij kleine groepen, zoals een directie van vijf mensen. En bij taken die de identiteit nodig hebben, zoals een KVK-inschrijving controleren of een dossier van een bekende klant samenvatten.

Voor de onderste twee rijen is een filter geen oplossing maar een papieren schild. Daar draait het om AI binnen het beroepsgeheim of om een volledig lokaal model, en de afweging tussen beide staat in onze gids over lokale AI voor bedrijven. Leg de keuze voor het filter, de geteste herkenning en de restrisico's vast in je DPIA. Waarom een EU-regio van een Amerikaanse aanbieder het doorgifteprobleem niet zelf oplost, staat in EU-dataresidentie bij AI, en de bredere AVG-kant in private AI onder de AVG en de EU AI Act.