Datasoevereiniteit: wie heeft echt zeggenschap over je data?

1. Data residency versus datasoevereiniteit

Data residency beschrijft de fysieke locatie: je database staat bijvoorbeeld in Frankfurt of Amsterdam. Datasoevereiniteit beschrijft de juridische en operationele controle: welke wetten zijn van toepassing op de partij die de infrastructuur beheert, en kan een buitenlandse overheid toegang afdwingen?

• Residency: waar staan de schijven?
• Soevereiniteit: wie mag erbij, en op grond van welke wet?

2. De CLOUD Act en de AVG

De Amerikaanse CLOUD Act (2018) kan Amerikaanse bedrijven verplichten gegevens te verstrekken aan Amerikaanse autoriteiten, ook als die gegevens in een datacenter buiten de Verenigde Staten staan. Dat geldt ook voor Europese dochterondernemingen van Amerikaanse cloudproviders.

De AVG beperkt juist de doorgifte van persoonsgegevens naar landen buiten de EER. Na de Schrems II-uitspraak van het Europees Hof (2020) moeten organisaties beoordelen of gegevens daar voldoende beschermd zijn. Het EU-US Data Privacy Framework van 2023 biedt nu een basis, maar staat juridisch onder druk. Wie op lange termijn zekerheid wil, beperkt de afhankelijkheid van niet-Europese partijen.

3. Drie lagen van soevereiniteit

In een software-architectuur bekijken we soevereiniteit op drie lagen. Elke laag kan apart worden ingericht.

• Opslag: waar staan de gegevens, en wie beheert de encryptiesleutels? Met eigen sleutels (customer managed keys) kan de provider zelf niet meelezen.
• Operatie: wie heeft beheertoegang tot de systemen, ook bij support en onderhoud, en vanuit welk land?
• AI: waar draaien de modellen die je gegevens verwerken? Prompts en documenten die naar een AI-dienst gaan, verlaten vaak ongemerkt de Europese jurisdictie.

4. Europese alternatieven

Er zijn volwassen Europese aanbieders voor hosting, databases, opslag en AI. Denk aan Scaleway, OVHcloud, Hetzner en IONOS voor infrastructuur, en aan Europese modellen zoals Mistral voor AI. Ook de grote Amerikaanse providers bieden Europese varianten, zoals de EU Data Boundary van Microsoft Azure. Die verkleinen het risico, maar lossen de CLOUD Act-vraag niet volledig op.

5. Drie architectuurniveaus

Soevereiniteit is geen alles-of-niets keuze. We onderscheiden drie niveaus, afhankelijk van de gevoeligheid van de gegevens.

• Standaard cloud in een EU-regio: geschikt voor de meeste interne tools en zakelijke applicaties, met een verwerkersovereenkomst en goede beveiliging.
• Hybride: een snelle, moderne interface, bijvoorbeeld gebouwd met Lovable, gekoppeld aan een database en servercomponenten bij een Europese provider. Persoonsgegevens blijven dan onder Europese controle.
• Volledig soeverein: de hele stack bij Europese aanbieders, met eigen sleutelbeheer en Europese of zelf gehoste AI-modellen. Voor zorg, overheid en andere sectoren met de strengste eisen.

6. Hoe past Lovable hierin?

Lovable is een Amerikaans-Zweeds platform. Op Business en Enterprise kies je voor nieuwe projecten een Europese dataregio, en Enterprise biedt AI-verwerking binnen de EU. De frontend wordt wereldwijd via een CDN verspreid. De vraag is dus niet óf je Lovable kunt gebruiken, maar welk deel van de applicatie je erin onderbrengt.

Is Lovable afdoende? Dat hangt af van drie vragen: hoe gevoelig zijn de gegevens, welke eisen stellen je klanten of toezichthouders in de verwerkersovereenkomst, en mogen prompts en documenten via een gedeelde AI-dienst lopen? Hieronder zie je hoe wij die afweging per niveau maken.

Bij de meeste zakelijke applicaties is Lovable Cloud in een EU-regio voldoende, mits de applicatie zelf goed beveiligd is. Wordt de data gevoeliger, dan houden we Lovable voor wat het het beste doet, snel een moderne interface bouwen, en verplaatsen we de gegevens, logica en AI stap voor stap naar een Europese omgeving. Je hoeft Lovable dus zelden af te wijzen om soevereiniteitsredenen, zolang de architectuur past bij het risico.