# Persoonsgegevens buiten AI-prompts houden

*Een Sluis-gids voor privacy-, security- en platformteams. Laatst gecontroleerd op 23 september 2026.*

Elke prompt die bij een AI-provider terechtkomt, is een verstrekking van gegevens. Deze gids behandelt welke persoonsgegevens meestal in prompts belanden, hoe goed elke detectiemethode ze verwijdert, wat het vervangen door placeholders onder EU-recht oplevert sinds het arrest van het Hof van Justitie van september 2025, en wat je nog steeds moet doen als redactie goed werkt.

## Kort samengevat

- **Patroonherkenning** vangt gestructureerde identificatiegegevens: e-mailadressen, telefoonnummers, IBAN's, kaartnummers, nationale identificatienummers, API-sleutels. In onze test verwijderde het **57%** van de geannoteerde persoonlijke gegevens. Namen en beschrijvingen mist het.
- Een **getraind entiteitsherkenningsmodel** dicht het grootste deel van die kloof. In dezelfde test steeg het verwijderpercentage naar **98,7%**, tegen ongeveer een halve seconde per tekstsegment.
- Identificatiegegevens vervangen door **placeholders** kan betekenen dat de tekst voor de AI-provider geen persoonsgegevens meer is. Het Hof van Justitie bevestigde dit in *EDPS tegen SRB*, maar alleen als de provider de persoon realistisch gezien niet opnieuw kan identificeren, ook niet door gegevens te combineren.
- Voor jou blijven het persoonsgegevens en moet je mensen nog steeds **laten weten dat ze naar de AI-provider gaan**. Het Hof beoordeelde die plicht vanuit de verwerkingsverantwoordelijke, op het moment dat de gegevens worden verzameld.
- Controleer de **standaardbewaartermijn van je provider in het contract**, niet op de marketingpagina. Meerdere grote providers hebben hun standaardinstellingen het afgelopen jaar gewijzigd.

## Wat er in prompts terechtkomt

Wat medewerkers in AI-tools plakken, volgt het werk dat ze doen. In bijna elke organisatie komen dezelfde categorieën terug:

| Gegevens | Voorbeeld | Wat het detecteert |
|---|---|---|
| Gestructureerde identificatiegegevens | `jan.devries@example.nl`, `NL91 ABNA 0417 1643 00`, +31 6 1234 5678 | Patronen en controlegetallen, zeer betrouwbaar |
| Inloggegevens | API-sleutels, toegangstokens, verbindingsstrings in geplakte logs | Patronen en entropiecontroles |
| Namen van personen | "Antwoord Marieke even over haar terugbetaling" | Woordenlijsten voor veelvoorkomende namen; een getraind model voor de rest |
| Organisaties en plaatsen | Bedrijfsnamen, straatadressen, steden | Woordenlijsten plus een getraind model |
| Bijzondere categorieën van persoonsgegevens | "Ze is sinds mei ziek thuis met een burn-out" | Context. Geen enkele detector is hier betrouwbaar: hiervoor is een gebruiksregel nodig |
| Identificerende combinaties | "Onze enige vrouwelijke partner op het kantoor in Eindhoven" | Niets betrouwbaars. De combinatie identificeert, niet een los woord |

De laatste twee rijen zijn het belangrijkst. Een detector vindt waarden; hij begrijpt niet dat een functietitel, een locatie en een datum samen naar één persoon wijzen. Die gevallen los je het best op met beleid: sommige taken horen helemaal niet bij een extern model terecht te komen.

## Hoe goed detectie werkt: onze meting

We hebben drie detectieopstellingen in onze eigen gateway gemeten op 105 achtergehouden synthetische testgevallen (geen 105 onafhankelijke documenten), met 372 geannoteerde gegevens per opstelling. Of elk gegeven in context was verwijderd, werd beoordeeld door de modelbeoordelaar van de benchmark, een apart taalmodel, niet door menselijke beoordeling.

| Opstelling | Wat draait er | Verwijderde gegevens | Percentage |
|---|---|---|---|
| Alleen patronen | Reguliere expressies, controlegetallen, contextregels, namenregister en woordenlijsten | 211 van 372 | **56,7%** |
| Patronen en een licht model | Het bovenstaande plus een klein meertalig entiteitsmodel | 299 van 372 | **80,4%** |
| Patronen en een PII-model | Het bovenstaande met een model dat speciaal voor persoonsgegevens is getraind | 367 van 372 | **98,7%** |
| PII-model en LLM-controle | Het bovenstaande plus een optionele controle door een gehost taalmodel | 371 van 372 | **99,7%** |

Gemeten op 15 september 2026. Houd bij het gebruik van deze cijfers twee dingen in gedachten:

- Ze meten hoeveel **geannoteerde gegevens** in context zijn verwijderd. Ze meten niet of een heel document anoniem is geworden. Eén gemist gegeven kan genoeg zijn om iemand te identificeren.
- Het zijn metingen van **onze eigen pipeline** op **onze eigen synthetische testset**. We hebben de producten van andere leveranciers niet op dezelfde testgevallen gedraaid. Draai een vergelijkbare test op 50 van je eigen documenten voordat je op het cijfer van een leverancier vertrouwt, ook op het onze.

### Wat het kost

| Niveau | Mediane tijd per aanroep | Langzaamste van 30 aanroepen |
|---|---|---|
| Licht model | 3,5 ms | 4,0 ms |
| PII-model | 521,5 ms | 549,6 ms |

Gemeten op 14 september 2026 op een meertalige tekst van 919 tekens, in-process, exclusief netwerktijd. Voor een chatassistent is een halve seconde voordat het model begint te antwoorden meestal acceptabel. Voor een API met hoog volume en strakke latentiedoelen is het een ontwerpbeslissing.

Recall gaat ook ten koste van precisie. Agressieve regels verwijderen dingen die geen persoonsgegevens zijn. Een regel die elk onbekend woord met hoofdletter als mogelijke naam behandelt, verwijdert ook productnamen, projectcodes en modelnamen, waardoor antwoorden slechter kunnen worden. Daarom leveren we die regel uitgeschakeld. Meet foutpositieven op je eigen documenten naast recall.

### Fail closed

Bepaal wat er gebeurt als detectie faalt: een model loopt tegen een time-out aan, een document is niet te parsen, een bestandstype is onbekend. Een pipeline die **fail open** werkt, verstuurt de ongeredigeerde tekst. Een pipeline die **fail closed** werkt, blokkeert het verzoek. Kies bij persoonsgegevens voor fail closed. Deze ene instelling doet meer ertoe dan de keuze van het model.

## Placeholders in plaats van verwijderen

Persoonsgegevens verwijderen maakt veel prompts onbruikbaar: "Schrijf een antwoord aan [verwijderd] over de terugbetaling van EUR 40 aan [verwijderd]" geeft het model niets om mee te werken. Vervangen behoudt de structuur:

> Schrijf een antwoord aan «PERSON_NAME_1» over de terugbetaling van EUR 40 aan «IBAN_1».

De gateway bewaart de koppeling tussen «PERSON_NAME_1» en de echte naam, stuurt alleen de placeholder naar de provider en zet de echte waarden terug in het antwoord voordat het de gebruiker bereikt. Twee details maken dit in de praktijk werkbaar:

- **Consistentie.** Dezelfde persoon krijgt in een gesprek steeds dezelfde placeholder, zodat het model kan volgen wie wie is.
- **Typeinformatie.** «PERSON_NAME_1» en «IBAN_1» vertellen het model wat voor soort waarde er stond, waardoor antwoorden grammaticaal correct en bruikbaar blijven.

## Wat de wet zegt

### Het Hof van Justitie: *EDPS tegen SRB*, 4 september 2025

De zaak (C-413/23 P) betrof de Gemeenschappelijke Afwikkelingsraad (SRB), die de namen van mensen die opmerkingen hadden ingediend verving door willekeurig gegenereerde codes van 33 cijfers, de tabel bewaarde die codes aan namen koppelt, en 1.104 opmerkingen doorgaf aan Deloitte. Het Hof oordeelde:

1. **Meningen zijn persoonsgegevens over hun auteur** (punten 58 tot en met 60). Tekst die je medewerkers in een prompt schrijven, is in de regel een persoonsgegeven over hen.
2. **Gepseudonimiseerde gegevens zijn niet automatisch voor iedereen persoonsgegevens.** Het bestaan van een koppeltabel betekent dat gepseudonimiseerde gegevens niet in alle gevallen als anoniem kunnen worden behandeld (punt 73). Maar pseudonimisering "kan, afhankelijk van de omstandigheden van het geval, andere personen dan de verwerkingsverantwoordelijke effectief beletten de betrokkene te identificeren, zodanig dat de betrokkene voor hen niet of niet meer identificeerbaar is" (punt 86).
3. **Voor de ontvanger hangt dat af van twee voorwaarden** (punt 77): de ontvanger kan de pseudonimisering niet ongedaan maken, en kan de persoon niet identificeren "door middel van andere identificatiemiddelen, zoals het kruiselings vergelijken met andere factoren".
4. **Jouw informatieplicht verandert niet.** Of je mensen moest laten weten dat hun gegevens naar een ontvanger gaan, wordt beoordeeld vanuit de positie van de verwerkingsverantwoordelijke, op het moment van verzameling (punten 111 en 112). Wat de ontvanger achteraf wel of niet kan identificeren, is voor die plicht niet relevant.

Toegepast op prompts:

| Prompt verstuurd naar de provider | Identificeerbaar voor de provider? | Waarom |
|---|---|---|
| "Terugbetaling voor «PERSON_NAME_1», IBAN «IBAN_1», bestelling 48213" | Waarschijnlijk niet | Het bestelnummer zegt de provider niets en de koppeling blijft bij jou |
| "«PERSON_NAME_1», onze enige vrouwelijke partner in Eindhoven, is ziek thuis" | Ja | De beschrijving identificeert haar zonder naam en onthult gezondheidsgegevens |
| Een stacktrace met het e-mailadres van een klant | Ja | Het identificatiegegeven is niet gedetecteerd en dus in leesbare vorm verstuurd |

### De richtsnoeren van de EDPB zijn nog een ontwerp

De *Richtsnoeren 01/2025 inzake pseudonimisering* van de EDPB zijn in januari 2025 ter consultatie gepubliceerd; de consultatie sloot op 14 maart 2025. We hebben geen definitieve versie kunnen vinden. Het ontwerp stelt dat gepseudonimiseerde gegevens persoonsgegevens blijven wanneer ze met aanvullende informatie aan een persoon kunnen worden toegeschreven. Het is van vóór het arrest en het is nog niet duidelijk hoe de definitieve tekst het zal verwerken.

In de praktijk: behandel prompts als persoonsgegevens in je eigen registers en DPIA; gebruik de twee voorwaarden uit het arrest om de positie van de provider te beoordelen; en leg je redenering vast.

### Wat je nog steeds moet doen

- **Noem de AI-provider als ontvanger** in je privacyverklaring, of de categorie van ontvangers, zoals punt 111 van het arrest duidelijk maakt.
- **Voer een gegevensbeschermingseffectbeoordeling (DPIA) uit** wanneer het gebruik waarschijnlijk een hoog risico inhoudt, bijvoorbeeld bij HR-, gezondheids- of grootschalige klantgegevens.
- **Houd een register van verwerkingsactiviteiten bij** waarin de AI-provider als verwerker of ontvanger is opgenomen.
- **Controleer de doorgiftepositie** als de provider of zijn moedermaatschappij buiten de EU is gevestigd. Onze gids over CLOUD Act-blootstelling behandelt dit.

## Wat de providers bewaren

De standaardbewaartermijnen zijn het afgelopen jaar herhaaldelijk gewijzigd. De onderstaande posities zijn zoals de providers ze in aankondigingen en helppagina's melden; bevestig ze aan de hand van de voorwaarden die je daadwerkelijk tekent.

| Provider | Standaard voor API-klanten, zoals gemeld | Waar je om moet vragen |
|---|---|---|
| OpenAI | Inhoud wordt standaard niet gebruikt voor training bij zakelijke klanten. Zero data retention beschikbaar voor in aanmerking komende API-klanten, bevestigd in augustus 2026 | Zero data retention in je overeenkomst, en of jouw endpoints daarvoor in aanmerking komen |
| Anthropic | API-logs worden sinds september 2025 7 dagen bewaard. Zero data retention-overeenkomsten voor kwalificerende enterprise-klanten. Een bewaarregeling van 30 dagen voor de meest capabele modellen, met de optie om de gegevens in je eigen cloud te houden, aangekondigd voor het najaar van 2026 | Welke bewaarregeling geldt voor de modellen die je gebruikt, en de zero-retention-overeenkomst |

Het bevel in de zaak van de New York Times, dat OpenAI verplichtte de uitvoerlogs van ChatGPT onbeperkt te bewaren, is in oktober 2025 opgeheven, met uitzonderingen voor reeds bewaarde logs en voor accounts die in de zaak zijn gemarkeerd. Het wordt nog steeds als actueel risico aangehaald; het is geen open einde meer.

## Checklist

- [ ] Use cases gekoppeld aan de gegevens die ze in prompts brengen
- [ ] Taken die nooit naar een extern model mogen, vastgelegd in het AI-gebruiksbeleid
- [ ] Detectielagen per use case gekozen, met een getraind model waar namen voorkomen
- [ ] Pipeline werkt fail closed bij detectiefouten of time-outs
- [ ] Recall en foutpositieven gemeten op minstens 50 van je eigen documenten
- [ ] Placeholders gebruikt in plaats van verwijdering, consistent binnen een gesprek
- [ ] Privacyverklaring noemt de AI-provider of de categorie van ontvangers
- [ ] DPIA afgerond voor gebruik met een hoog risico
- [ ] Bewaar- en trainingsinstellingen van de provider bevestigd in de getekende voorwaarden

## Bronnen

- [Hof van Justitie van de Europese Unie, *EDPS tegen SRB*, zaak C-413/23 P, arrest van 4 september 2025, punten 23 tot en met 28, 58 tot en met 60, 72 tot en met 77, 85, 86, 111 en 112](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=celex%3A62023CJ0413)
- [Europees Comité voor gegevensbescherming, *Richtsnoeren 01/2025 inzake pseudonimisering*, consultatieversie, feedbackperiode 17 januari tot en met 14 maart 2025](https://www.edpb.europa.eu/public-consultations/guidelines-012025-on-pseudonymisation_en)
- [OpenAI, *Offering Zero Data Retention for frontier models*, 19 augustus 2026](https://openai.com/index/offering-zero-data-retention-for-frontier-models/)
- [Anthropic, documentatie over API en dataretentie](https://platform.claude.com/docs/en/manage-claude/api-and-data-retention)
- Het opheffen van het bewaarbevel in de zaak van de New York Times (bevel van 9 oktober 2025) en de bewaarregeling van Anthropic voor het najaar van 2026 zijn ontleend aan persberichtgeving, onder meer van Engadget en CNBC.
- Detectie- en latentiecijfers: Sluis-metingen van 15 en 14 september 2026. De methode is beschreven in de [Sluis-documentatie over gegevensbescherming](/docs/data-protection).