Een bedrijf besluit een LLM te implementeren op interne documenten. IT configureert een API-sleutel, een ontwikkelaar schrijft een wrapper, medewerkers beginnen offertes, contracten en vergaderverslagen in het model te voeren. De eerste week ziet er geweldig uit. Dan stapt de DPO binnen en stelt één vraag: "Waar belanden die data?" En niemand heeft een antwoord.
Dit scenario is geen uitzondering — het is de regel bij veel EU-bedrijven. GDPR bij LLM-implementaties is geen academisch vraagstuk. Het is een concrete checklist die u ofwel heeft, ofwel niet. Dit artikel legt die checklist praktisch uit: waar data precies weglekt, wat u ondertekend moet hebben, wanneer een DPIA verplicht is, en hoe een beslisser zich kan beroepen op een gestructureerd kader in plaats van op gevoel.
Waar data heen gaat — een overzicht van de stromen
Voordat u juridische stappen onderneemt, moet u begrijpen wat er technisch gebeurt. Een LLM in productie is geen enkel systeem — het is een keten van componenten waarbij elk onderdeel een potentieel lekpunt vormt.
Een typische stroom bij een cloud-LLM ziet er zo uit:
- Invoerdocument (contract, e-mail, rapport) → chunking → embedding → vectordatabase
- Gebruikersquery → retrieval uit de vector-DB → context + query worden verstuurd naar de LLM API
- LLM API (bijv. OpenAI, Anthropic, Google) → verwerkt de prompt → geeft antwoord terug
- Logs en traces → observability (Langfuse, LangSmith, eigen logging) → mogelijk aanvullende opslag
Elke stap kan persoonsgegevens (Personal Identifiable Information — PII) bevatten: de naam van een klant in een contract, het e-mailadres van een contactpersoon, medische informatie in een rapport, een IBAN in een betaalbewijs. Als deze gegevens uw perimeter verlaten — en bij een cloud-API doen ze dat — bent u een verwerkingsverantwoordelijke met concrete verplichtingen.
Een andere stroom die vaak over het hoofd wordt gezien: training en fine-tuning. Sommige cloudproviders stellen expliciet dat gegevens via de API niet worden gebruikt voor training (OpenAI bij de enterprise tier, Anthropic via de API). Maar standaardinstellingen verschillen — en wat vandaag geldt, kan morgen veranderen bij een update van de voorwaarden. Controleer altijd de actuele Terms of Service en leg dit contractueel vast.
Cloud API versus on-prem — een beslissing met GDPR-impact
Dit is de belangrijkste architectuurkeuze vanuit complianceperspectief.
Cloud API (OpenAI, Anthropic, Gemini, Azure OpenAI...)
De voordelen zijn duidelijk: de sterkste modellen, nul infrastructuur, snelle start. De GDPR-knelpunten:
- Data verlaat uw perimeter — u bent verplicht een Data Processing Agreement (DPA) te sluiten met de provider als verwerker
- Bij doorgifte buiten de EER (bijv. data op Amerikaanse servers) heeft u een overdrachtsmechanisme nodig — standaard contractbepalingen (SCC) of een gelijkwaardig rechtskader
- U moet weten waar de servers fysiek staan; het antwoord "in de cloud" volstaat niet voor uw DPO of toezichthouder
De meeste grote providers bieden een DPA aan — maar u moet die actief afsluiten, niet slechts een checkbox aanvinken. Azure OpenAI beschikt over Europese regio's, waardoor gegevensdoorgifte buiten de EER eenvoudiger te vermijden is. Raadpleeg de actuele voorwaarden rechtstreeks bij elke provider.
On-prem / self-hosted LLM
Data verlaat uw perimeter niet. Als het model op uw eigen servers draait (of op servers in de EER met een duidelijk contract), is de GDPR-blootstelling aanzienlijk kleiner. Deze keuze is vooral zinvol voor gereguleerde sectoren — gezondheidszorg, juridische dienstverlening, financiën — waar gevoelige persoonsgegevens worden verwerkt. Een uitgebreidere bespreking van dit onderwerp vindt u in on-prem LLM voor gereguleerde sectoren.
De afweging zit in kwaliteit en kosten: self-hosted open-weight modellen (Llama, Qwen, Mistral, DeepSeek in hun open-weight varianten) bereiken vandaag productiekwaliteit voor de meeste bedrijfsuse-cases, maar vereisen GPU-infrastructuur en technische capaciteit voor beheer. Voor inferentie van een 7B–14B model met redelijke latentie volstaat doorgaans één server met een GPU met voldoende VRAM; grotere modellen vragen meer.
DPA — wat erin moet staan en waarom een klik niet volstaat
Data Processing Agreement is een wettelijke vereiste op grond van artikel 28 GDPR wanneer u persoonsgegevens overdraagt aan een externe partij voor verwerking. Een LLM-provider naar wie u documenten met persoonsgegevens stuurt, is een verwerker. U bent de verwerkingsverantwoordelijke. Zonder DPA handelt u in strijd met de wet.
Wat een DPA moet bevatten (conform art. 28 lid 3 GDPR):
- Onderwerp en duur van de verwerking — concreet, niet vaag
- Aard en doel van de verwerking — "inferentie voor interne chatbot" is concreter dan "AI-diensten"
- Type persoonsgegevens en categorieën van betrokkenen — klanten? medewerkers? patiënten?
- Verplichtingen en rechten van de verwerkingsverantwoordelijke — inclusief auditrecht
- Technische en organisatorische maatregelen (TOM) — encryptie, toegangscontrole, incident response
- Verbod op verdere sub-verwerkers zonder toestemming of algemene toestemming met een rechtskader
Let op een detail dat bedrijven vaak onderschatten: de DPA moet ook de sub-verwerkers van de provider dekken — cloudinfrastructuur, loggingdienst, monitoringtools. Grote providers publiceren lijsten van sub-verwerkers; controleer die.
Rechtgrondslag — op welke basis u verwerkt
GDPR vereist dat elke verwerking van persoonsgegevens een rechtgrondslag heeft (art. 6). Bij bedrijfsmatige LLM-implementaties komen we het meest de volgende grondslagen tegen:
- Gerechtvaardigd belang (art. 6 lid 1 sub f) — de meest gebruikte grondslag voor interne bedrijfstools; vereist een LIA (Legitimate Interest Assessment) waarbij u documenteert dat het belang van het bedrijf zwaarder weegt dan de rechten van betrokkenen
- Uitvoering van een overeenkomst (art. 6 lid 1 sub b) — relevant als de LLM rechtstreeks dient ter uitvoering van een contract met de klant
- Toestemming (art. 6 lid 1 sub a) — voor de meeste interne tools onpraktisch; toestemming moet vrij, geïnformeerd en intrekbaar zijn
Verwerkt u bijzondere categorieën persoonsgegevens (gezondheids-, genetische, biometrische, politieke, religieuze, vakbonds- of seksuele gegevens) — art. 9 GDPR — dan gelden strengere voorwaarden en is toestemming vrijwel onvermijdelijk, of moet u een andere grondslag uit de uitputtende lijst van art. 9 lid 2 aantonen.
In de praktijk: bij LLM op HR-documentatie, medische dossiers of gerechtelijke stukken komt u zonder jurist niet ver. Anders riskeert u niet alleen een boete, maar ook dat u het hele project moet stilleggen en ontmantelen.
PII scrubbing — wanneer en hoe
PII scrubbing (het verwijderen van persoonsgegevens vóór verzending naar de LLM) is een technische maatregel die de blootstelling vermindert. Het vervangt een correcte rechtgrondslag of DPA niet, maar verkleint het risicooppervlak aanzienlijk.
Waar het zinvol is:
- Documenten waarbij de LLM de concrete naam niet hoeft te kennen — hij moet de context, structuur en inhoud begrijpen
- Logrecords — PII mag nooit in logs staan; dat is zowel een wettelijke vereiste als technische hygiëne
- Trainingsdatasets — als u een model fine-tunet op interne data, kan PII in de trainingsdata door het model worden "onthouden" (memorization problem) en later worden vrijgegeven
Hoe het technisch werkt:
- Regex-gebaseerde detectoren — e-mails, telefoonnummers, IBAN, BSN/rijksregisternummer, IP-adressen; snel, deterministisch, laag aantal missers bij gestructureerde formaten
- NER-gebaseerde detectoren (Named Entity Recognition) — persoonsnamen, bedrijven, adressen; pakken ongestructureerde teksten aan; vereisen een model en hebben een hogere foutmarge
- Combinatie — regex voor gestructureerde formaten + NER voor vrije tekst; productiestandaard
Belangrijke kanttekening: pseudonimisering is geen anonimisering volgens GDPR. Vervangt u een gegeven door een token maar bestaat er een sleutel om het te reconstrueren, dan gaat het nog steeds om persoonsgegevens. Het EDPB (Europees Comité voor gegevensbescherming) heeft herhaaldelijk bevestigd dat LLM's zelden de standaard van echte anonimisering halen. Scrubbing vermindert het risico — het elimineert het niet.
Voor inspiratie bij de implementatie van een scrubbing-pipeline kunt u kijken hoe deze laag is uitgewerkt in guardrails voor AI-agenten, waar inputvalidatie en PII-detectie de eerste verdedigingslinie vormen vóór de LLM.
Data minimization — niets meer dan noodzakelijk
Data minimization is een van de kernbeginselen van GDPR (art. 5 lid 1 sub c): verwerk alleen de persoonsgegevens die strikt noodzakelijk zijn voor het beoogde doel.
Voor LLM betekent dit in de praktijk:
- Alleen relevante chunks gaan de prompt in, niet hele documenten — een RAG-pipeline die correct is ingesteld op nauwkeurig ophalen, is direct ook een compliance-instrument
- Retentiebeleid voor logs en traces — hoe lang bewaart u gesprekshistorie? 30 dagen? 90 dagen? Zonder vastgesteld beleid duurt het "voor altijd"
- Embedding-vectoren — ook een vectorrepresentatie van een document kan een persoonsgegeven zijn als daaruit het origineel kan worden gereconstrueerd of een persoon kan worden geïdentificeerd; behandel ze net als de brondata
- Systeemlogboeken van inferentie — als u de volledige prompt inclusief gebruikersquery logt, logt u potentieel persoonsgegevens; voer selectief loggen of log scrubbing in
DPIA — wanneer verplicht en wat erin staat
Data Protection Impact Assessment (DPIA) is verplicht bij verwerkingen die "waarschijnlijk een hoog risico inhouden voor de rechten en vrijheden van natuurlijke personen" (art. 35 GDPR). Voor LLM-implementaties betekent dit doorgaans:
- Systematische en grootschalige verwerking van bijzondere categorieën persoonsgegevens (gezondheids-, financiële, HR-data)
- Geautomatiseerde besluitvorming met rechtsgevolgen of vergelijkbare significante gevolgen voor personen
- Grootschalige monitoring van publiek toegankelijke ruimten
In de praktijk: als uw LLM meehelpt besluiten te nemen over medewerkers, klanten of patiënten, is een DPIA aangewezen. Gaat het om een interne chatbot op technische documentatie zonder bijzondere categorieën persoonsgegevens, dan is een DPIA waarschijnlijk niet verplicht — maar we raden aan minimaal een interne risicobeoordeling uit te voeren.
Wat een DPIA moet bevatten:
- Beschrijving van de verwerkingsoperatie — wat, waarom, wie, waar
- Beoordeling van noodzakelijkheid en evenredigheid — kan het doel met minder privacyinbreuk worden bereikt?
- Risicobeoordeling voor de rechten en vrijheden van betrokkenen
- Maatregelen om risico's te beheersen — technisch én organisatorisch
- Als het restrisico nog steeds hoog is → raadpleging van de toezichthouder (bijv. Autoriteit Persoonsgegevens)
EU AI Act en GDPR — twee compliancelagen
Sinds augustus 2025 gelden verplichtingen voor GPAI-modellen (General Purpose AI) onder de EU AI Act. Voor deployende bedrijven gelden verplichtingen op grond van artikel 26 — met name bij high-risk AI-systemen.
Belangrijk punt: de EU AI Act en GDPR dupliceren elkaar niet, maar vullen elkaar aan. GDPR regelt de bescherming van persoonsgegevens. De EU AI Act regelt de risico's van AI-systemen — inclusief situaties waarbij AI beslissingen over mensen neemt of beïnvloedt. Als uw LLM-systeem meehelpt bij beslissingen over HR, kredietverlening, toegang tot diensten of beveiligingsclassificatie, kan het worden aangemerkt als high-risk AI — en dan gelden verplichtingen uit beide verordeningen tegelijk.
Een diepere bespreking van de concrete verplichtingen voor bedrijven vindt u in het artikel over EU AI Act en bedrijfsverplichtingen.
Praktische compliance-checklist
Een overzicht als controlelijst vóór de inzet van een LLM op bedrijfsdata:
- DPA met elke LLM-provider — ondertekend, niet slechts aangeklikt; dekt ook sub-verwerkers
- Rechtgrondslag gedocumenteerd — LIA voor gerechtvaardigd belang, toestemming indien vereist; vastgelegd, niet alleen in het hoofd
- Doorgifte van data buiten de EER geregeld — SCC of equivalent, als de provider op Amerikaanse servers draait
- PII scrubbing — minimaal ingezet voor logs; voor documenten waar technisch haalbaar
- Data minimization-beleid — retentietermijnen voor logs, gesprekken en embeddings vastgesteld en gehandhaafd
- DPIA — uitgevoerd voor high-risk use-cases; resultaten gedocumenteerd
- Technische en organisatorische maatregelen — encryptie in transit en at rest, toegangscontrole, incident response-plan
- Verwerkingsregister (art. 30 GDPR) — het LLM-systeem moet zijn opgenomen in het Register van Verwerkingsactiviteiten
- EU AI Act-beoordeling — is uw systeem high-risk? Zo ja, verplichtingen conform art. 26
Veelgestelde vragen
Is hiervoor een advocaat nodig, of lukt het intern?
Dat hangt af van de omvang. Voor een eenvoudige interne chatbot op openbare technische documentatie zonder persoonsgegevens volstaat een interne beoordeling met de DPO. Verwerkt u bijzondere categorieën persoonsgegevens, is er sprake van doorgifte buiten de EER of beïnvloedt uw systeem beslissingen over mensen, dan loont een externe jurist gespecialiseerd in data privacy en AI — boetes voor GDPR-schending kunnen oplopen tot 4% van de wereldwijde jaaromzet of 20 miljoen euro.
Kan ik geanonimiseerde data gebruiken en GDPR omzeilen?
Als u echte anonimisering heeft bereikt — d.w.z. de data kan op geen enkele manier worden herleid tot een natuurlijke persoon — valt GDPR niet van toepassing. In de praktijk is dat moeilijk. LLM's halen zelden de standaard van echte anonimisering; pseudonimisering (vervanging door een token dat kan worden gereconstrueerd) volstaat niet. Raadpleeg uw DPO om te verifiëren of uw methode daadwerkelijk aan de anonimiseringsstandaard voldoet.
Moeten we voor elk LLM-project een DPIA doen?
Niet voor elk project. Een DPIA is verplicht bij een hoog risico voor de rechten van betrokkenen — doorgaans bij bijzondere categorieën persoonsgegevens, geautomatiseerde besluitvorming met gevolgen voor mensen, of grootschalige monitoring. Voor een interne helpdesk op technische handleidingen zonder persoonsgegevens is een DPIA niet verplicht. We raden aan minimaal een korte interne risicobeoordeling uit te voeren en de beslissing te documenteren.
Wat als de LLM-provider zijn voorwaarden wijzigt en onze data gaat gebruiken voor training?
Dat is een reëel risico. Daarom moet de DPA een verbod bevatten op het gebruik van uw data voor training en een auditrecht. Houd wijzigingen in de Terms of Service bij en stel een reviewproces in, minimaal één keer per jaar. Als een provider zijn voorwaarden wijzigt in strijd met de DPA, heeft u het recht de overeenkomst te beëindigen en verwijdering van de data te eisen.
Is een on-prem LLM automatisch GDPR-compliant?
Niet automatisch. On-prem elimineert het risico van doorgifte aan een derde verwerker, maar u moet nog steeds een rechtgrondslag hebben, een data minimization-beleid, retentietermijnen en technische maatregelen. Het verschil is dat u de problemen intern oplost — niet via een DPA met een externe provider.
*GDPR en LLM op bedrijfsdata is geen project voor één weekend, maar het mag ook geen reden zijn om de implementatie te blokkeren. De meeste bedrijven waarmee wij werken, hebben vooral behoefte aan een gestructureerd overzicht van wat zij al hebben geregeld en wat nog niet — niet aan tientallen uren juridisch overleg. Als u deze checklist wilt doorlopen voor een concrete implementatie in uw organisatie, staan we klaar voor een vrijblijvend kennismakingsgesprek.*