Welke LLM kun je gebruiken met bedrijfsdata? Privacy, AVG en lokale AI uitgelegd

AI wordt steeds vaker gekoppeld aan bedrijfsprocessen. Denk aan:

facturen uitlezen;
e-mails classificeren;
offertes samenvatten;
documenten doorzoeken;
klantvragen beantwoorden;
gegevens omzetten naar gestructureerde JSON.

Technisch is dat tegenwoordig relatief eenvoudig. Maar zodra zo'n workflow persoonsgegevens verwerkt, komt ook de AVG in beeld. Naast de vraag welk AI-model technisch geschikt is, spelen dan ook vragen als: waar gaat de data heen, hoe lang wordt die bewaard en wie kan erbij?

Dit artikel zet op een rij wat de toezichthouders en de providers zelf publiceren. Het is een technisch overzicht, geen juridisch advies.

Wat zegt de Autoriteit Persoonsgegevens hierover?

De Nederlandse Autoriteit Persoonsgegevens publiceerde op 23 mei 2025 specifieke AVG-randvoorwaarden voor generatieve AI. Die richtlijnen zijn expliciet bedoeld voor organisaties die generatieve AI ontwikkelen of binnen hun bedrijfsvoering willen gebruiken. De AP maakt daarbij duidelijk dat de AVG gewoon van toepassing blijft wanneer persoonsgegevens in generatieve-AI-modellen of -toepassingen worden verwerkt.

Belangrijke onderwerpen zijn onder andere:

een geldige grondslag voor de verwerking;
doelbinding;
dataminimalisatie;
transparantie;
juistheid;
beveiliging;
bewaartermijnen;
rechten van betrokkenen;
verantwoordelijkheid van organisaties.

De AP benadrukt bovendien dat haar voorwaarden niet uitputtend zijn: afhankelijk van de toepassing kunnen aanvullende AVG-verplichtingen gelden. De Europese privacytoezichthouders komen tot een vergelijkbare conclusie. De European Data Protection Board publiceerde in december 2024 een officieel advies (Opinion 28/2024) over persoonsgegevens en AI-modellen, waaronder rechtsgrond, anonimisering en het gebruik van persoonsgegevens bij AI.

Er bestaat geen "AVG-goedgekeurde LLM"

Dit onderscheid is belangrijk. De Autoriteit Persoonsgegevens zegt niet:

OpenAI is toegestaan en Anthropic niet.
Of: Mistral is AVG-proof.
Of: een Europese server betekent automatisch dat alles voldoet.

Volgens de AP blijft de verantwoordelijkheid bij de organisatie die de AI-toepassing inzet. Dat maakt de hele gegevensstroom relevant, van de bron via de verwerkende systemen tot de LLM-provider en de uiteindelijke opslag.

Als op een factuur namen, adressen, e-mailadressen, bankgegevens of andere persoonsgegevens staan, worden die mogelijk door meerdere systemen verwerkt. De AP rekent die hele keten tot de verwerking.

Optie 1: het model volledig lokaal draaien

Bij lokaal draaien staat het model op eigen infrastructuur, waarbij de verwerking binnen het eigen netwerk plaatsvindt.

Je kunt daarvoor open-weight modellen gebruiken, bijvoorbeeld modellen uit families zoals Qwen, Mistral, Llama en Gemma. Software zoals Ollama, llama.cpp of vLLM kan worden gebruikt om dergelijke modellen op eigen infrastructuur te draaien.

Waarom lokaal interessant is

Het grote voordeel is dat de prompt niet noodzakelijk naar een externe LLM-provider hoeft te worden verzonden. Je kunt daardoor bijvoorbeeld bepalen:

op welke server de data staat;
wie toegang heeft;
welke logs worden bijgehouden;
wanneer gegevens worden verwijderd;
of er überhaupt externe AI-verwerking plaatsvindt.

Bij lokale verwerking blijven deze punten dus binnen de eigen omgeving.

Maar lokaal betekent niet automatisch AVG-vrij

Ook wanneer alles lokaal draait, blijft de AVG volgens de AP gewoon gelden. De AP wijst organisaties op de verantwoordingsplicht: bij het verwerken van persoonsgegevens hoort onder meer kunnen aantonen waarom die gegevens worden verwerkt en het nemen van passende technische en organisatorische beveiligingsmaatregelen. Bij verwerkingen met een hoog privacyrisico kan volgens de AP bovendien een DPIA verplicht zijn.

Lokaal draaien lost dus vooral een belangrijk technisch probleem op: je hoeft persoonsgegevens niet met een externe LLM-provider te delen. Het vervangt de AVG niet.

Optie 2: Mistral via een EU-endpoint

Mistral heeft tegenwoordig een expliciet Europees inference-endpoint: api.eu.mistral.ai. Volgens de officiële documentatie over regional inference verwerkt dit endpoint inferenceverzoeken in datacenters binnen de EU en EFTA. Dat verschilt nadrukkelijk van api.mistral.ai. Het normale globale endpoint heeft volgens Mistral geen garantie voor een specifieke inference-locatie.

Volgens Mistral geldt de EU-verwerking dus alleen wanneer daadwerkelijk het regionale EU-endpoint wordt aangeroepen.

Zero Data Retention bij Mistral

Mistral biedt daarnaast Zero Data Retention, oftewel ZDR. Wanneer dit is ingeschakeld voor ondersteunde stateless API-calls, worden input en output volgens Mistral niet langer opgeslagen of gelogd dan nodig is om de response te genereren. De beschikbaarheid, configuratie en uitzonderingen hiervan kunnen per account en endpoint verschillen, dus er zijn twee belangrijke nuances.

Ten eerste is ZDR volgens Mistral niet automatisch actief: het moet worden aangevraagd en Mistral beoordeelt de aanvraag. Ten tweede zijn regional inference en Zero Data Retention volgens Mistral twee afzonderlijke instellingen. Er kan dus EU-processing zijn zonder ZDR, of ZDR terwijl niet correct naar het regionale endpoint wordt gerouteerd. Mistral waarschuwt hier zelf expliciet voor.

Daarnaast heeft Mistral een officiële Data Processing Addendum waarin onder andere de AVG als toepasselijke privacywetgeving wordt genoemd.

Praktische configuratie

In de praktijk komt het erop neer dat onnodige persoonsgegevens al bij de bron worden geanonimiseerd of verwijderd, en dat het regionale EU-endpoint met ingeschakelde ZDR wordt aangeroepen. Deze opzet houdt de verwerking bij een externe LLM zoveel mogelijk binnen Europa, zoals in de Mistral-documentatie beschreven.

Optie 3: OpenAI API met Europese data residency

OpenAI biedt eveneens Europese data residency voor de API. Voor hiervoor ingerichte Europese API-projecten zegt OpenAI dat requests in-region worden verwerkt. OpenAI vermeldt daarbij expliciet dat deze projecten met Zero Data Retention werken: modelrequests en responses worden niet at-rest op de servers opgeslagen.

Dat is een belangrijk verschil met een standaard API-project: volgens OpenAI geldt de in-region verwerking alleen bij de daarvoor ingerichte Europese configuratie.

OpenAI heeft daarnaast afzonderlijke API-data-controls per endpoint waarin wordt uitgelegd dat ZDR alleen voor geschikte organisaties en endpoints beschikbaar is en voorafgaande goedkeuring kan vereisen. Niet iedere functie of endpoint gedraagt zich hetzelfde onder ZDR.

De uitspraak "OpenAI bewaart niets" is daarmee te kort door de bocht. Wat OpenAI zelf beschrijft, is dat er configuraties zijn waarmee bepaalde API-workloads met Europese verwerking en Zero Data Retention kunnen worden ingericht, en dat per endpoint en feature verschilt wat daarvoor in aanmerking komt.

Deze route combineert de modelkwaliteit van OpenAI met de Europese configuratie-opties die OpenAI in zijn documentatie beschrijft.

Optie 4: Azure OpenAI / Microsoft Foundry

Azure is vooral interessant voor organisaties die al Microsoft gebruiken of strengere enterprise-controls nodig hebben. Microsoft zegt in zijn officiële documentatie over data, privacy en beveiliging dat prompts en gegenereerde output binnen de Azure-geografie van de betreffende deployment kunnen worden verwerkt en opgeslagen. Voor deployments in de Europese Economische Ruimte bevinden menselijke reviewers die eventueel gemarkeerde abuse-data bekijken zich volgens Microsoft eveneens binnen de EER.

Maar hier zit een belangrijke nuance. Azure gebruikt standaard systemen voor abuse monitoring. Wanneer bepaalde content door die systemen wordt gemarkeerd, kan deze voor menselijke beoordeling beschikbaar worden gemaakt. Microsoft biedt voor goedgekeurde klanten ook modified abuse monitoring. Wanneer dat actief is, vindt het beschreven opslag- en human-reviewproces niet op dezelfde manier plaats.

Uit de Microsoft-documentatie blijkt dus dat het gedrag afhangt van de exacte configuratie: de Azure-regio, het deploymenttype, de logging, de abuse-monitoringinstellingen en de gebruikte features. Azure biedt daarmee veel controle, mits die controle ook wordt ingericht.

Optie 5: Google Vertex AI

Google Vertex AI heeft eveneens sterke enterprise-privacyopties. Volgens de Google Cloud Service Specific Terms wordt klantdata niet zonder toestemming gebruikt om AI/ML-modellen te trainen of fine-tunen. Google documenteert daarnaast hoe Zero Data Retention op Vertex AI kan worden bereikt.

Ook hier zijn uitzonderingen. Zo kunnen bepaalde functies gegevens tijdelijk opslaan. Google noemt bijvoorbeeld session resumption voor Gemini Live, waarbij data maximaal 24 uur gecachet kan worden als deze functie wordt ingeschakeld. Ook bepaalde grounding-functionaliteit kan andere retentievoorwaarden hebben.

Google heeft bovendien officiële data-residencyvoorwaarden waarin generatieve AI-diensten onder voorwaarden voor specifieke locaties kunnen worden geconfigureerd. Daarbij bestaan uitzonderingen voor bepaalde functionaliteiten zoals sommige grounding- en RAG-features.

Vertex AI sluit qua opzet aan bij omgevingen waarin een organisatie:

al Google Cloud gebruikt;
IAM en cloudbeveiliging centraal beheert;
specifieke data residency nodig heeft;
verschillende modellen binnen één cloudomgeving wil gebruiken.

En Anthropic?

Bij Anthropic ligt de standaardretentie hoger dan bij een directe ZDR-route. Anthropic geeft officieel aan dat input en output van gewone API-calls standaard binnen 30 dagen wordt verwijderd. Er bestaan Zero Data Retention-overeenkomsten voor bepaalde enterprise API-klanten, maar daarvoor is goedkeuring door Anthropic nodig.

Daarnaast gelden uitzonderingen. Onder andere Files API, bepaalde cachingfuncties en sommige batch-functionaliteit kunnen andere opslagregels hebben.

Feitelijk komt het erop neer dat een minimale-opslagroute bij Anthropic een afzonderlijke ZDR-overeenkomst vereist, terwijl sommige andere providers ZDR en EU-verwerking als in te schakelen opties in hun documentatie beschrijven.

De opties naast elkaar

Op basis van de documentatie hierboven zijn dit de technische kenmerken van de verschillende routes:

Route	Wat de documentatie beschrijft
Lokaal model	Draait op eigen infrastructuur; prompt hoeft niet naar een externe provider
Mistral EU-endpoint + ZDR	EU/EFTA-inference; ZDR apart aan te vragen en te configureren
OpenAI EU-project + ZDR	In-region verwerking en ZDR voor daarvoor ingerichte projecten
Azure OpenAI / Foundry	Verwerking binnen Azure-geografie; abuse monitoring configureerbaar
Google Vertex AI	ZDR en data residency mogelijk, met gedocumenteerde uitzonderingen
Anthropic API	Standaard 30 dagen retentie; ZDR via aparte overeenkomst

Dataminimalisatie: stuur minder data naar het model

Een van de AVG-principes die de AP noemt, is dataminimalisatie: niet meer persoonsgegevens verwerken dan nodig. Technisch vertaalt dat zich er vaak in dat het model bepaalde informatie helemaal niet ontvangt. Stel dat een AI alleen hoeft vast te stellen: is dit een factuur, herinnering of offerte? Dan is het volledige klantprofiel voor die taak niet nodig, bijvoorbeeld:

volledig woonadres;
IBAN;
telefoonnummer;
e-mailadres;
geboortedatum;
klantnummer.

In de praktijk kun je dan al bij de extractie de niet-benodigde persoonsgegevens verwijderen, zodat het model alleen de gegevens ontvangt die het voor de taak nodig heeft. Dit is een technische invulling van het AVG-principe dataminimalisatie zoals de AP dat beschrijft. Het moment waarop dit gebeurt telt mee: hoe eerder in de keten onnodige persoonsgegevens worden verwijderd of geanonimiseerd, hoe minder systemen ze daarna nog verwerken. Tussenliggende diensten houden doorgaans zelf logs bij, dus gegevens die pas later worden geminimaliseerd, zijn die logging al gepasseerd.

Verwerkersovereenkomst volgens de AVG

Wanneer een externe partij persoonsgegevens namens een organisatie verwerkt, kan die partij onder de AVG als verwerker optreden. De AVG stelt eisen aan die verhouding. De AP noemt onder andere onderwerpen zoals:

welke persoonsgegevens worden verwerkt;
beveiliging;
vertrouwelijkheid;
subverwerkers;
ondersteuning bij rechten van betrokkenen;
verwijdering na afloop;
internationale doorgifte.

De AP heeft hiervoor afzonderlijke richtlijnen en onderzoek gepubliceerd. In dat kader publiceren LLM-providers doorgaans een Data Processing Addendum of verwerkersvoorwaarden.

Doorgifte buiten de EER

Volgens de Autoriteit Persoonsgegevens is een server in Europa niet de enige relevante factor: persoonsgegevens mogen vanuit Nederland alleen buiten de Europese Economische Ruimte worden doorgegeven als daarvoor voldoende bescherming en een geldige AVG-basis bestaat. Daarbij gaat het niet alleen om het modelendpoint, maar om de hele keten: naast het model ook logging, back-ups, monitoring, subverwerkers, support en andere gekoppelde diensten. Een workflow is uiteindelijk maar zo privacyvriendelijk als de hele keten.

Let ook op je eigen datastroom

Naast de keuze van een LLM-provider zijn er ook andere onderdelen van de datastroom die een rol spelen, onder andere:

gebruik van HTTPS/TLS voor API-verkeer;
beveiliging van API-endpoints;
voorkomen dat persoonsgegevens onnodig in logs terechtkomen;
beperken van bewaartermijnen voor tijdelijke bestanden en workflowdata;
bescherming van opgeslagen gevoelige gegevens;
controle van error logs, monitoringtools en execution history.

Let op: gezondheidsgegevens vallen onder strengere AVG-regels

Niet alle persoonsgegevens worden onder de AVG hetzelfde behandeld. Een naam, e-mailadres, adres of klantnummer is een persoonsgegeven. Gegevens over iemands gezondheid vallen daarentegen onder de bijzondere categorieën van persoonsgegevens.

Daaronder vallen bijvoorbeeld:

diagnoses;
medicatie;
behandelgegevens;
medische dossiers;
testresultaten;
informatie over lichamelijke of geestelijke gezondheid;
gezondheidsinformatie van werknemers;
gegevens uit digitale zorgtoepassingen.

De AP behandelt bijzondere persoonsgegevens onder een strenger regime dan gewone persoonsgegevens. Een AI-workflow die een zakelijke factuur verwerkt, staat daardoor niet gelijk aan een workflow die een patiëntdossier verwerkt.

Bij gezondheidsgegevens zijn volgens de AP onder meer de grondslag, de dataminimalisatie, de beveiliging, het toegangsbeheer, de betrokken verwerkers, de opslaglocatie, de internationale doorgifte, de bewaartermijnen en de noodzaak van een DPIA punten waar extra op wordt gelet.

Gezondheidsgegevens in de cloud

De Autoriteit Persoonsgegevens publiceerde in maart 2026 specifiek de praktijkgids Gezondheidsgegevens in de cloud. Daarin benadrukt de AP dat een organisatie verantwoordelijk blijft wanneer zij gezondheidsgegevens door een cloudleverancier laat verwerken.

De organisatie moet onder andere weten:

waar de gegevens worden opgeslagen en verwerkt;
welke leveranciers en subverwerkers betrokken zijn;
of persoonsgegevens buiten de EER worden doorgegeven;
welke beveiligingsrisico's bestaan;
hoe afhankelijkheid van de leverancier wordt beheerst;
welke maatregelen nodig zijn om de gegevens voldoende te beschermen.

Een lokale of on-premise architectuur houdt gezondheidsgegevens technisch binnen de eigen omgeving. Het grote technische voordeel is dat de gezondheidsgegevens niet noodzakelijk naar een externe LLM-provider worden verzonden.

Categorieën volgens de AVG

Type data	Voorbeeld	Status onder de AVG
Gewone persoonsgegevens	naam, e-mail, adres	persoonsgegevens
Financiële/zakelijke persoonsgegevens	IBAN, factuurgegevens	persoonsgegevens
Gezondheidsgegevens	diagnose, medicatie, patiëntdossier	bijzondere persoonsgegevens (art. 9 AVG)
Andere bijzondere persoonsgegevens	religie, biometrie, genetische gegevens	bijzondere persoonsgegevens (art. 9 AVG)

Een EU-endpoint of Zero Data Retention is een technische eigenschap en staat los van de vraag onder welke AVG-categorie de gegevens vallen.

Wanneer is een DPIA nodig?

Bij gegevensverwerkingen met een hoog privacyrisico kan een Data Protection Impact Assessment (DPIA) verplicht zijn. Een DPIA brengt vooraf de privacyrisico's in kaart en beschrijft hoe die risico's worden beperkt. De AP noemt dit expliciet als onderdeel van de verantwoordingsplicht onder de AVG.

Volgens de AP is niet iedere AI-automation automatisch DPIA-plichtig. De AP noemt factoren als grootschalige verwerking, gevoelige gegevens en toepassingen die aanzienlijke gevolgen voor mensen kunnen hebben als situaties waarin een DPIA aan de orde kan zijn.

Checklist: vragen die uit de bronnen naar voren komen

De onderwerpen die de AP, de EDPB en de providers noemen, laten zich samenvatten als een lijst controlevragen:

Bevatten de prompts persoonsgegevens?
Zijn al die persoonsgegevens noodzakelijk?
Wat is de grondslag voor de verwerking?
Welke organisatie is verwerkingsverantwoordelijke?
Welke partijen zijn verwerker of subverwerker?
Is er een passende verwerkersovereenkomst?
Waar vindt inference plaats?
Waar worden logs en back-ups opgeslagen?
Worden prompts of outputs gebruikt voor training?
Wat is de bewaartermijn?
Is Zero Data Retention beschikbaar en daadwerkelijk ingeschakeld?
Welke features vallen niet onder ZDR?
Vindt doorgifte buiten de EER plaats?
Is een DPIA nodig?
Kan dezelfde taak met minder persoonsgegevens worden uitgevoerd?

Deze vragen komen rechtstreeks voort uit de onderwerpen die de toezichthouders en de providers zelf benoemen.

Dit artikel is een technisch overzicht op basis van openbare documentatie van de genoemde toezichthouders en providers. Het is geen juridisch advies; raadpleeg voor een concrete situatie de officiële bronnen of een gekwalificeerde adviseur.

Officiële bronnen

Nederland / Europa

Mistral

OpenAI

Microsoft

Google

Anthropic