

Dataresidentie is geen soevereiniteit: de kaart met vier lagen
Mario Beck
2026-06-16
"Onze data staat in een datacenter in Amsterdam." Een of andere variant daarvan hoor ik in bijna elk gesprek over soevereiniteit, met veel zelfvertrouwen gezegd, alsof de kwestie daarmee beklonken is.
Dat is het niet. Het hele debat blijft hangen op één woord. Iedereen heeft het over waar data staat. Bijna niemand vraagt waar die data verwerkt wordt. En dat is precies de vraag die bepaalt of je echt soeverein bent of dat het alleen zo voelt.
Wat je EU-datacenter je niet vertelt: als je team een AI-query draait, reist die data vaak naar een Amerikaans inference-endpoint en weer terug. Je hebt tegelijk opslagsoevereiniteit en verwerkingsafhankelijkheid bereikt. Het bestand staat in Amsterdam. Het denkwerk gebeurt ergens anders, onder de regels van iemand anders.
Opslagsoevereiniteit is geen compute-soevereiniteit
Dataresidentie beantwoordt een smalle vraag: in welk land staat het bestand als het in rust is. Dat is echt, en voor sommige regelgeving telt het. Maar het is de makkelijke laag, en de laag die elke leverancier maar al te graag voor je oplost, want zo kan iedereen stoppen met de lastigere vragen stellen.
Compute-soevereiniteit beantwoordt de vraag die er wél toe doet: waar gebeurt inference, wie heeft controle over het model, en welke wetten gelden op het moment dat je data daadwerkelijk gelezen wordt. Dat moment, waarop het model je contract of je patiëntdossier inleest om een antwoord te geven, is het moment waarop je data het meest kwetsbaar is. Gebeurt dat op infrastructuur die jij niet beheert, dan zit er een gat in het midden van je soevereiniteitsclaim.
Als je data "soeverein" is in rust, maar elke AI-beslissing via de infrastructuur van iemand anders loopt, heb je je afhankelijkheid niet verminderd. Je hebt er een rondreis aan toegevoegd.
De kaart met vier lagen
De reden dat "is dit soeverein?" zo'n glibberige vraag is, is dat soevereiniteit niet één ding is. Het zit op vier verschillende lagen, en je kunt een paar daarvan beheersen terwijl je andere volledig mist. Dit is de kaart die ik gebruik.
Laag 1 - Opslag. Waar het bestand in rust staat. Dit is dataresidentie. Het is de laag die bijna iedereen oplost, en de laag die bijna iedereen aanziet voor het hele plaatje.
Laag 2 - Transport. De route die de data tussen systemen aflegt. Versleuteling tijdens transport telt hier, maar net zo goed de simpele vraag welke netwerken en grenzen de data passeert om van A naar B te komen.
Laag 3 - Compute. Waar het model je data leest en erover redeneert. Dit is de laag die de meeste "soevereine AI"-claims stilletjes overslaan. Draait inference op een buitenlands endpoint, dan is het gevoeligste moment in de hele pijplijn het minst soeverein.
Laag 4 - Governance. Wie gedwongen kan worden om je data af te staan, en onder welke wetten. Dit is de laag die elke technische maatregel die je neemt overleeft, want het gaat om juridisch bereik, niet om netwerkdiagrammen.
De meeste leveranciers lossen laag 1 op en laten je de rest aannemen. De interessante vragen, de vragen die je echt beschermen, zitten in laag 3 en 4. Neem deze kaart mee naar je volgende inkoopgesprek en een vage "is dit soeverein?" verandert in vier concrete vragen waar een antwoord op te geven valt.
De laag die iedereen vergeet: jurisdictie
Laag 4 verdient een eigen kopje, want hier verschuilen de duurste verrassingen zich.
Onder de Amerikaanse CLOUD Act moet een Amerikaanse aanbieder data die hij in bezit, beheer of onder controle heeft afgeven na een geldig Amerikaans juridisch verzoek, ongeacht waar die data fysiek staat. De European Data Protection Board en de European Data Protection Supervisor zeiden het onomwonden: de wet staat Amerikaanse autoriteiten toe om openbaarmaking te eisen van aanbieders onder Amerikaanse jurisdictie "irrespective of where the data is stored." De Amerikaanse Congressional Research Service bevestigt hetzelfde: aanbieders moeten data afgeven "regardless of whether the data is located in the United States."
In gewone taal: jurisdictie volgt de aanbieder, niet de server. Zolang je AI-leverancier een Amerikaans bedrijf is of in handen is van een Amerikaans moederbedrijf, haalt het lokaliseren van de data in Frankfurt of Amsterdam die niet buiten bereik. Geen enkele Amerikaanse hyperscaler kan absolute bescherming bieden door simpelweg een EU-regio te beloven.
Dit is niet anti-Amerikaans. Het is gewoon de wet zoals die er staat. En het is precies waarom "waar staat onze data?" de verkeerde vraag is, en "onder wiens jurisdictie wordt die verwerkt en beheerd?" de juiste.
De soevereine AI-stack: wat bezitten, wat huren
"Soevereine AI" klinkt als een alles-of-niets-moonshot. Dat is het niet. Het is een stack, en je kunt de lagen die ertoe doen bezitten zonder alles te bezitten.
- Je data en rechten. Niet onderhandelbaar. Dit zijn de kroonjuwelen. Bezit het.
- De index en retrieval. Dit hoort binnen je eigen grenzen te blijven, want hier wordt gevoelige inhoud daadwerkelijk gelezen en samengevoegd tot antwoorden.
- Het model. Dat kan open-weight zijn en lokaal draaien, of een gecontroleerd endpoint dat je zelf kiest. Het punt is niet om je eigen foundation-model te bouwen. Het punt is dat jij het model kiest en het kunt vervangen zonder alles opnieuw op te bouwen.
- De interface. Waar mensen echt werken. De minst gevoelige laag. Huur die op jouw voorwaarden.
De veelgemaakte fout is denken dat soevereiniteit betekent dat je je eigen GPT traint. Dat is niet zo. Het betekent dat je bepaalt waar je data verwerkt wordt, en dat je nooit vastzit aan de leidingen van één leverancier. Bezit de data en de inference-grens. Huur de rest, bewust.
On-prem is de snelste route, niet de noodoplossing
Er is een ongemakkelijke infrastructuurrealiteit in Europa. We hebben niet genoeg GPU's of grote datacenters, en Nederland zit extra krap. Je hebt dus twee eerlijke opties. Wachten op Europese hyperscale-infrastructuur die misschien tien jaar kost om te bouwen. Of vandaag lokaal draaien, on-prem.
On-prem heeft echte nadelen. Onderhoud. Capaciteitsgrenzen. Z'n eigen compliancewerk. Ik doe niet alsof dat niet zo is. Maar het is nu haalbaar voor de taken die het belangrijkst zijn, en het omzeilt het hele "waar gebeurt inference?"-probleem, want het antwoord wordt "in jouw eigen pand."
Voor veel gereguleerde en IP-zware bedrijven is de snelste route naar soevereiniteit niet een nationale cloud die nog niet bestaat. Het is een server die ze al beheren, met een capabel model dat draait op de data die ze zich niet kunnen veroorloven ergens heen te sturen. Perfecte soevereiniteit over tien jaar, of praktische soevereiniteit dit kwartaal. Ik kies dit kwartaal.
Soevereiniteit is een slotgracht, geen kostenpost
De meeste bedrijven streven soevereiniteit na om één reden: compliance. Vinkje zetten, boete vermijden, door. Die instelling laat het beste deel liggen.
Behandel soevereiniteit als een vinkje en je betaalt er alleen maar voor. Behandel het als controle over je eigen kennis en het begint zich terug te betalen. De bedrijven die voorop lopen stellen andere vragen. Wat kunnen we met onze data bouwen waar concurrenten letterlijk niet bij kunnen? Welke inzichten komen boven als we niet beperkt zijn tot wat we naar een externe aanbieder mogen sturen? Welke producten worden mogelijk als de data nooit weg hoeft?
Dat is geen compliancehouding. Dat is een slotgracht. Je gevoelige data is óf een risico waar je geld aan kwijt bent om het te beschermen, óf een voordeel waar je moeite in steekt om het te laten groeien. Dezelfde data, andere strategie.
Stel betere vragen
Je hoeft de wet niet uit je hoofd te leren of morgen je hele stack opnieuw te bouwen. Je moet stoppen met soevereiniteit afmeten aan waar data staat, en beginnen met afmeten waar die gebruikt wordt en wie dat moment beheerst. Met de kaart met vier lagen doe je dat in een leveranciersgesprek zonder te verdwalen in marketingtaal.
Ik heb de volledige kaart met vier lagen samengebracht met de precieze inkoopvragen die je per laag aan een leverancier stelt, als een gratis buyer's kit. Je krijgt 'm via onze nieuwsbrief hier.
Twijfel je tussen lokaal en cloud voor een specifieke workflow? Stuur me een DM. Ik denk graag met je mee over waar de grens voor jouw situatie zou moeten liggen.