AI en de AVG
Waar gaat je klantdata heen als je Claude of GPT belt?
Je typt een klantvraag in ChatGPT. Een naam, een adres, een klacht over een verkeerd bezorgd paar schoenen. Enter. Een paar seconden later krijg je een keurig antwoord terug. En dan pas dringt het door: die gegevens zijn net het land uit gereisd. Door een kabel onder de oceaan. Naar een datacenter waar iemand anders de regels maakt. Wat dat betekent, juridisch en praktisch, is de stof van deze les.
Waar je data heen gaat als je op Enter drukt
Bij de meeste populaire AI-diensten verlaten je prompts je eigen infrastructuur. Bij OpenAI, Google en Anthropic staan de inference-servers grotendeels in de Verenigde Staten. Sommige regio's worden in Europa gehost, maar de default is vaak nog steeds overzee. Voor de AVG is dit geen detail. Zodra persoonsgegevens de EU verlaten, heb je een doorgifte buiten de Unie. En daar hangen verplichtingen aan.
Het Schrems II-arrest heeft het Privacy Shield gesloopt. Sindsdien leunt de praktijk op het EU-US Data Privacy Framework en standaardcontractbepalingen. Dat werkt — mits je leverancier daar expliciet onder valt. De meeste grote AI-labs regelen dit in hun Enterprise- en API-voorwaarden, maar in de consumenten-app van ChatGPT staat het er een stuk zwakker bij. Die scheiding is belangrijk: wat je op chat.openai.com doet, valt onder andere voorwaarden dan wat je via de API verwerkt.
US-providers versus EU-hosted
De grote drie — Anthropic, OpenAI, Google — bieden inmiddels EU-regionale endpoints voor hun enterprise-klanten. Bij Anthropic via AWS Bedrock in Frankfurt of Ierland. Bij OpenAI via Azure OpenAI in West Europe. Bij Google via Vertex AI in europe-west4. De modellen zijn identiek, de prijzen vergelijkbaar, maar je data blijft binnen de EU-grenzen. Voor een solo-SaaS die klantgegevens door een model haalt, is dat vaak het makkelijkste pad naar rust.
De goedkopere, directe API's (api.anthropic.com, api.openai.com) sturen nog steeds richting de VS. Dat mag — met de juiste DPA en grondslag — maar je moet het documenteren. Leg in je verwerkingsregister vast welke data waar naartoe gaat, op welke grondslag, met welke waarborgen.
Bij Anthropic en OpenAI kun je via een Zero Data Retention-afspraak regelen dat prompts niet worden opgeslagen en niet worden gebruikt voor training. Dat moet je actief aanvragen — op het standaardcontract bewaart OpenAI prompts 30 dagen voor abuse-monitoring. Die 30 dagen zijn voor veel use cases prima, maar voor gezondheidsdata of juridische stukken niet acceptabel.
De verwerkersovereenkomst die niemand leest
Je bent zelf verwerkingsverantwoordelijke voor je klantgegevens. Het AI-lab is je verwerker. Dus: Data Processing Agreement tekenen. Anthropic, OpenAI en Google hebben allemaal een standaard-DPA die je digitaal kunt ondertekenen of automatisch meegeleverd krijgt bij een zakelijk account. Zonder getekende DPA is het doorsturen van klantgegevens juridisch een probleem, hoe goed het technisch ook werkt.
Wat er in een goede DPA staat: welke sub-processors (AWS, GCP, hun eigen datacenters), hoe lang data bewaard wordt, wie eigenaar is van input en output, hoe datalek-meldingen lopen, en wat er gebeurt bij een overheidsbevel. Lees het door. Eén keer. Dan weet je het.
Grondslag — want je mag niet zomaar
De AVG eist voor élke verwerking een grondslag. Voor AI verandert dat niet. Je kunt kiezen uit toestemming, uitvoering overeenkomst, wettelijke verplichting, gerechtvaardigd belang, vitaal belang, of publieke taak. Voor een SaaS met betalende klanten is "uitvoering overeenkomst" meestal de rustigste keuze, mits de AI-verwerking noodzakelijk is voor de dienst die jij levert.
Verwerk je gegevens van derden — de klant-van-je-klant, bijvoorbeeld mensen die een order plaatsen bij de sportzaak die jouw tool gebruikt — dan wordt dit getrapt. Jij bent sub-verwerker. Je klant is verwerker. De eindklant is betrokkene. Leg dat vast in je servicevoorwaarden of in een aparte DPA met je eigen klanten.
Minimaliseer, altijd
De sterkste AVG-maatregel is niet technisch maar redactioneel: stuur geen data naar het model die het niet nodig heeft. Wil je een offerte laten concipiëren? Dan heeft het model de klantvraag, het type product en misschien een voorkeurstoon nodig. Niet het BSN. Niet het rekeningnummer. Niet de geboortedatum. Zet tussen je applicatie en de API een laag die persoonsgegevens eruit filtert of pseudonimiseert voordat ze vertrekken.
In PHP kun je dat laagje zelf bouwen. Haal e-mailadressen, telefoonnummers, IBAN's en BSN-patronen uit de prompt met een reeks reguliere expressies of een kleine named-entity-stap. Vervang ze door placeholders (KLANT_1, IBAN_1). In de output koppel je ze terug. Dat is niet perfect, maar het maakt een groot verschil, en het is precies het soort "passende technische en organisatorische maatregel" waar de AVG om vraagt.
Anonieme data valt buiten de AVG. Pseudonieme data (waar je nog terug kunt herleiden wie het was) valt er nog steeds onder — alleen met een lager risicoprofiel. Dat is belangrijk: zelfs als je namen vervangt door codes, blijft het persoonsgegevens zolang jij de sleutel bewaart.
Wanneer moet je een DPIA doen
Een Data Protection Impact Assessment is verplicht bij verwerkingen met een hoog risico voor betrokkenen. De Autoriteit Persoonsgegevens heeft een lijst met gevallen waar het altijd moet: grootschalige verwerking van bijzondere persoonsgegevens, systematische profilering, monitoring van publieke ruimtes, en sinds de EU AI Act-uitrol ook high-risk AI-toepassingen zoals CV-screening, credit scoring en toegangscontrole.
Voor de meeste SaaS-use cases — een chatbot, een offerte-generator, een samenvattingstool — is een DPIA niet verplicht maar wel aan te raden als je met klantdata werkt. Een goede DPIA is geen zestig pagina's; vier of vijf is genoeg. Wat verwerk je, waarom, welk risico loopt de betrokkene, welke maatregelen neem je, en wat is je restrisico.
De EU AI Act, bondig
Naast de AVG is er inmiddels de EU AI Act. Die is vanaf 2024 gefaseerd in werking getreden en in 2026 grotendeels van toepassing. Voor jou als bouwer van een SaaS betekent dat vooral: transparantie-eisen. Als je klanten met AI-output interacteert (chatbot, gegenereerde tekst), moet je dat duidelijk maken. Voor gewone tools is dat het grootste blokje. High-risk-toepassingen (werving, krediet, onderwijs, kritieke infrastructuur) hebben zwaardere eisen: documentatie, menselijke controle, logging van beslissingen.
Voor de bulk van SaaS-tools blijf je in de lage risicocategorie. Dat is goed nieuws — maar schrijf het wel even op. Een paragraafje in je privacyverklaring over welk AI-model je gebruikt, waarvoor, en hoe gebruikers kunnen bezwaar maken is tegenwoordig het minimum.
Drie dingen om mee te nemen
- Weet waar je data landt. EU-regionaal endpoint of Zero Data Retention-contract is voor klantgegevens de rustigste keuze. Documenteer die keuze.
- Minimaliseer bij de bron. Haal persoonsgegevens uit je prompts voordat ze vertrekken. Pseudonimiseer en koppel bij de output terug.
- DPA én grondslag. Geen klantdata naar een AI-API zonder getekende verwerkersovereenkomst en een duidelijke AVG-grondslag. Leg het één keer goed vast en je hebt er jaren rust van.
In de volgende les duiken we in een hardnekkiger probleem dan de jurist ooit zal signaleren: AI die vol overtuiging dingen verzint die nooit zijn gebeurd. Hallucinations — waar ze vandaan komen, en wat je eraan kunt doen.
Tot dan. Blijf scherp.