← terug

10 juni 2026

Het verschil tussen data residency en echte data-soevereiniteit

"Uw data staat in een datacenter in Frankfurt." Die zin hoor ik vaak in gesprekken over AI en gevoelige data, en hij wordt bijna altijd gebracht als eindstation van de discussie. Data in Europa, dus geregeld. Maar dat is het niet. Waar data fysiek staat is een van de vragen, en eerlijk gezegd vaak de minst interessante.

Data residency betekent: de servers staan op een bepaalde plek. Data-soevereiniteit betekent: jij bepaalt wat er met je data gebeurt, wie erbij kan en onder welk recht dat valt. Dat zijn twee verschillende dingen, en het verschil wordt belangrijk zodra je AI wilt gebruiken met klantdossiers, patiëntgegevens of interne documenten.

Wat data residency wel en niet regelt

Residency regelt de geografie. De schijven waarop je data staat bevinden zich in een Europees datacenter. Dat is niet niks: het scheelt latency, het helpt bij sommige contractuele eisen en het voelt voor veel organisaties als een logische basisvoorwaarde.

Maar een datacenter is een gebouw. De interessante vragen gaan over wat er in dat gebouw draait en wie daar de touwtjes in handen heeft. Wie schrijft en beheert de software die jouw data verwerkt? Wie kan er met beheerrechten bij de systemen? Naar welke moederorganisatie rapporteert het bedrijf dat de dienst levert? Een Amerikaanse clouddienst die een regio in Frankfurt aanbiedt, blijft een Amerikaanse clouddienst. De data staat in Europa, de zeggenschap niet per se.

Drie lagen die residency niet afdekt

Als ik met organisaties naar hun AI-opzet kijk, leg ik het verschil meestal uit in drie lagen.

Eén: wie beheert de software. Je data mag dan in Europa staan, de software eromheen wordt ergens anders gebouwd, geüpdatet en op afstand beheerd. De leverancier rolt updates uit, beheert de toegangslagen en kan in veel gevallen technisch bij de systemen waarop jouw data draait. Support-medewerkers, beheerders en geautomatiseerde processen zitten niet in dat Duitse datacenter, die zitten waar de leverancier zit. Operationele controle volgt de organisatie, niet het gebouw.

Twee: welk recht van toepassing is. Hier raakt het aan wetgeving zoals de Amerikaanse CLOUD Act. Die wet maakt het mogelijk dat Amerikaanse autoriteiten onder voorwaarden data opvragen bij Amerikaanse bedrijven, ook als die data buiten de Verenigde Staten staat. Dit is geen juridisch advies, en het betekent niet dat het gebruik van Amerikaanse clouddiensten verboden of onveilig is. Maar het laat wel zien dat de vestigingsplaats van je data niet automatisch bepaalt welk recht erop van toepassing is. De nationaliteit en structuur van de leverancier spelen mee. Voor de meeste organisaties is dat geen acuut probleem, wel iets dat in de afweging hoort, zeker bij gevoelige data.

Drie: wie de encryptiesleutels heeft. "Alles is versleuteld" klinkt geruststellend, maar de vraag is altijd: wie kan ontsleutelen? Als de leverancier de sleutels beheert, dan kan de leverancier bij de data. Dat is geen schande, zo werken de meeste clouddiensten, maar het betekent wel dat de encryptie jou beschermt tegen buitenstaanders, niet tegen de partij die je dienst levert. Echte controle begint waar jij de sleutels beheert, of waar de architectuur zo is ingericht dat de leverancier je data niet in leesbare vorm kan zien.

Waarom dit bij AI extra speelt

Bij een klassieke database is dit al een relevante discussie. Bij AI komt er een laag bovenop, omdat de dataflow groter is dan de meeste mensen denken. De gebruiker ziet alleen het antwoord. De organisatie moet de hele dataflow begrijpen.

Een vraag aan een AI-systeem dat met je eigen documenten werkt, raakt al snel meerdere plekken: de prompt zelf, de documenten die als context worden meegestuurd, de embeddings die van je kennis zijn afgeleid, de logs van het systeem en het antwoord dat wordt opgeslagen in een gespreksgeschiedenis. Elk van die onderdelen kan ergens anders staan, onder andere voorwaarden, bij een andere partij.

Neem een zorginstelling die AI wil gebruiken om rapportages samen te vatten. De rapportage gaat als context mee in de prompt. Die prompt gaat naar een modelprovider. Misschien logt die provider de aanvraag voor misbruikdetectie. Misschien staat de vector database met embeddings van eerdere rapportages bij weer een andere dienst. De instelling kan dan met recht zeggen dat haar database in Nederland staat, terwijl kopieën en afgeleiden van diezelfde gevoelige data door drie andere systemen stromen. Residency op papier, weinig soevereiniteit in de praktijk.

Waar het technisch misgaat

De meest voorkomende fout die ik zie is niet kwade wil, maar onvolledig kijken. Een organisatie beoordeelt de hoofddienst en vergeet de randen. Een paar voorbeelden.

Geen van deze punten betekent dat zo'n opzet fout is. Het betekent dat residency je een vinkje geeft op een vraag die je misschien niet eens stelde, terwijl de echte vragen open blijven.

De praktische route: zelf hosten wordt steeds normaler

Het goede nieuws is dat soevereiniteit geen theoretisch ideaal hoeft te blijven. Twee ontwikkelingen maken het praktisch haalbaar.

De eerste is de volwassenheid van open-source modellen. Er zijn inmiddels open modellen die voor veel zakelijke taken (samenvatten, classificeren, vraag-antwoord over eigen documenten) goed genoeg zijn. Goed genoeg is hier het sleutelwoord: je hebt voor het samenvatten van een vergaderverslag niet het allergrootste model ter wereld nodig. Een open model dat jij zelf draait, stuurt niets terug naar een maker. De gewichten staan op jouw infrastructuur en de prompts blijven binnen je eigen omgeving.

De tweede is dat Europese hosting van zulke modellen geen exotisch project meer is. Er zijn Europese datacenters met GPU-capaciteit, en de software om modellen te serveren is open source en goed gedocumenteerd. Je kunt een opzet bouwen waarin het model, de vector database, de logs en de applicatie allemaal binnen een omgeving draaien waarvan jij of een Europese partij de controle heeft. Een model draaien is niet hetzelfde als een AI-omgeving bouwen, dus reken op echt werk: je moet nadenken over GPU-kosten, updates, monitoring en toegangsrechten. Maar het is gewoon te doen, en het wordt elk jaar makkelijker.

Belangrijk: dit is geen alles-of-niets keuze. Veel organisaties komen uit op een gemengd model. Gevoelige verwerkingen via een zelf gehoste of Europese route, generieke taken via een grote commerciële API. Dat is een prima uitkomst, zolang de keuze bewust is en per dataflow is gemaakt.

Vijf vragen om aan elke leverancier te stellen

Wil je morgen iets concreets doen, stel dan deze vragen bij elke AI-dienst die je gebruikt of overweegt.

Een leverancier die deze vragen helder beantwoordt, is meestal serieus bezig. Een leverancier die terugvalt op "alles staat veilig in Europa" heeft je vraag niet begrepen, of hoopt dat jij hem niet begrijpt.

Tot slot

Data residency is een opslaglocatie. Data-soevereiniteit is zeggenschap: over de software, het toepasselijke recht, de sleutels en de hele dataflow eromheen. Voor een nieuwsbrieftool is dat verschil meestal niet spannend. Voor AI met patiëntdossiers, juridische stukken of bedrijfsgeheimen wel.

De vraag is dus niet "staat onze data in Europa?" maar "wie heeft controle over wat er met onze data gebeurt?". Wie die tweede vraag eerlijk beantwoordt, weet daarna pas echt waar hij staat. En vaker dan je denkt is het antwoord: dat kunnen we zelf in handen nemen. 

↘︎ ALLE ARTIKELEN