Een referentiearchitectuur voor platformen die soeverein by default zijn
Acht posts verder, van de afhankelijkheidskaart tot het regioslot, volgt hier de synthese: de minimale architectuur die het woord "soeverein" eerlijk verdient. Geen productpraatje, een blauwdruk om de eigen stack tegen af te zetten.
Onderdeel van de pijlerreeks Soevereiniteit die te operationaliseren is.
"Soeverein" is het meest overvraagde woord in bedrijfsinfrastructuur geworden. Jammer, want het benoemt iets precies en bouwbaars. Dit sluitstuk zet een leveranciersneutrale referentiearchitectuur uiteen voor platformen die soeverein by default zijn: de zeven pijlers die samen van soevereiniteit een afgedwongen en toetsbare systeemeigenschap maken in plaats van een etiket. Elke pijler komt met een gezaghebbend ankerpunt en een nuchtere beschrijving van "hoe goed eruitziet". Te gebruiken als checklist bij de beoordeling van welk platform dan ook, het onze inbegrepen.
De ordenende gedachte, ontleend aan recent onderzoek naar systemen die "soeverein by design" zijn, luidt dat soevereiniteit een afdwingbare, verifieerbare systeemeigenschap hoort te zijn, iets wat de architectuur garandeert en een test kan bevestigen, niet iets wat een beheerder belooft na te leven.
De zeven pijlers
| # | Pijler | Hoe goed eruitziet |
|---|---|---|
| 1 | Jurisdictie en eigendom | Een EU-bestuurde exploitatie-entiteit, aantoonbaar immuun voor extraterritoriale dwang, niet slechts een "EU-regio" |
| 2 | Residency by design | Data blijft in de regio door replicatie die standaard alles weigert; ze kán niet weg, in plaats van dat ze niet weg hoort |
| 3 | Sleutelbeheer | Sleutels bij de klant of binnen de EU, buiten de grens van de aanbieder; confidential computing als extra verdedigingslaag |
| 4 | Regionale AI-inferentie | Inferentie en embeddings draaien in de jurisdictie van de data, de prompt ís de data |
| 5 | Weerbaarheid / anti-monocultuur | Celisolatie; geen enkele aanbieder als spil, geen gedeeld lot; impactstraal begrensd op 1/N |
| 6 | Tamper-evident audittrail | Hash-geketend, per regio, fail-closed, append-only is niet genoeg |
| 7 | Handhaving en toetsing | Residency afgedwongen op controlepunten, met een permanente test die aantoont dat een verboden beweging wordt geblokkeerd |
Eén voor één.
1 en 2, Jurisdictie en residency by design
Soevereiniteit begint met een juridisch feit en een fysiek feit. Het juridische feit is eigendom: zoals eerder in deze reeks besproken blijft een "EU-regio" van een aanbieder met een Amerikaanse moeder bereikbaar onder buitenlands recht. Echte soevereiniteit vraagt dus om een EU-bestuurde exploitatie-entiteit, de lat die kwalificaties als SecNumCloud leggen, met expliciete bescherming tegen extraterritoriale vorderingen. Het fysieke feit is residency by design: data blijft binnen een regio dankzij een replicatiebeleid dat standaard weigert en andere regio's ronduit uitsluit, zodat ze niet weg kán in plaats van enkel niet weg hoort. De SEAL-schaal 0–4 van het EU Cloud Sovereignty Framework is de maatstaf, en veelzeggend: in de aanbesteding van 2026 haalde geen enkele aanbieder het hoogste niveau (EC). Eerlijkheid over dat plafond hoort bij het vak.
3, Sleutelbeheer, met een eerlijke kanttekening
Versleuteling beslecht de dwangvraag alleen als de sleutels buiten het bereik van de aanbieder liggen. Sleutels in eigen beheer (HYOK) betekenen dat een rechterlijk bevel niets dan cijfertekst oplevert, er valt niets af te geven. Confidential computing, waarbij data wordt verwerkt in hardwarematig geïsoleerde enclaves, is een waardevolle extra laag. Maar het is gelaagde verdediging, geen garantie: in 2025 toonde het TEE.Fail-onderzoek aan dat een fysieke interposer van circa 1.000 dollar sleutels kon onttrekken aan gangbare trusted execution environments en zelfs de attestaties kon vervalsen die moesten bewijzen dat de isolatie standhield (tee.fail). In het dreigingsmodel van soevereiniteit, waarin de tegenstander fysieke toegang tot de hardware kan hebben, telt dat. Sleutels in eigen beheer blijven de dragende beheersmaatregel.
4, Regionale inferentie: de prompt ís de data
De nieuwste pijler, en degene die de meeste "soevereine" ontwerpen vergeten: AI. Een prompt is een doorgifte van data en een embedding is een herleidbare vingerafdruk van de brontekst. Een database aan een regio binden en tegelijk prompts naar een buitenlandse GPU sturen, haalt het hele ontwerp onderuit. Inferentie én embeddings moeten in de jurisdictie van de data draaien. Dat kost meer, inferentiecapaciteit wordt per regio gedupliceerd, en dat is de eerlijke prijs van de prompt thuishouden.
5, Weerbaarheid zonder monocultuur
Soevereiniteit en weerbaarheid delen dezelfde oorzaak: concentratie. Het architectonische antwoord is celgebaseerde isolatie, onafhankelijke replica's van de stack, elk voor een deel van de tenants, zodat, in de formulering van AWS zelf, "a single-cell failure affects at most 1/N of traffic", een storing in één cel raakt hooguit 1/N van het verkeer (AWS). Geen enkele aanbieder als spil, geen gedeeld lot, geen continentbrede impactstraal door één slechte wijziging.
6 en 7, De audittrail en de test die het bewijst
De laatste twee pijlers scheiden een claim van een garantie. De audittrail moet tamper-evident zijn, hash-geketend en met een integriteitssleutel, per regio, en fail-closed, zodat een handeling die niet aantoonbaar gelogd kan worden simpelweg niet plaatsvindt. (Append-only-opslag is niet hetzelfde als tamper-evident; wie de opslag beheert, kan haar alsnog herschrijven.) En handhaving moet worden gedekt door een permanente test: dwing residency af op de data-, dispatch- en auditlaag en laat vervolgens een geautomatiseerde controle een verboden toegang over regiogrenzen proberen en vaststellen dat die wordt geblokkeerd. Die test is het bewijsstuk. Zonder die test is elke refactor een kans om stilzwijgend de eigenschap te verliezen die geclaimd werd. Wat niet wordt afgedwongen en getest, is niet soeverein.
De Soveryne Cloud Foundation als uitgewerkt voorbeeld
Deze pijlers zijn niet in het luchtledige afgeleid, ze vormen de specificatie waartegen de Soveryne Cloud Foundation is gebouwd, en elke eerdere post in deze reeks is eigenlijk één pijler van dichtbij bekeken: jurisdictie en sleutels, regiogebonden residency, regionale inferentie, weerbaarheid tegen monocultuur en portabiliteit. De Foundation is EU-bestuurd en EU-geëxploiteerd, met data die door het ontwerp binnen de grens blijft, sleutels in de eigen jurisdictie, AI-inferentie die thuisblijft, gedistribueerde en celgeïsoleerde rekenkracht, een tamper-evident audittrail en handhaving die getest kan worden. Command en Counsel draaien erop, omdat soevereiniteit die bij de applicatielaag ophoudt geen soevereiniteit is.
Wie de eigen stack beoordeelt, of de onze, legt hem naast deze zeven pijlers. Waar het antwoord niet "ja, en hier is de test" kan zijn, doet het woord "soeverein" meer werk dan de architectuur. Om de architectuur samen met ons onder druk te zetten: vraag een technische intake aan.
Veelgestelde vragen
Wat maakt een cloudarchitectuur werkelijk "soeverein by default"? Soevereiniteit die door de architectuur wordt afgedwongen en met een test aantoonbaar is, over jurisdictie, residency, sleutelbeheer, regionale AI-inferentie, celgebaseerde weerbaarheid, een tamper-evident audittrail en permanente handhavingscontroles heen, in plaats van beloofd door een beheerder of gesuggereerd door het etiket "EU-regio".
Is confidential computing voldoende voor soevereine data? Nee. Het is een nuttige extra verdedigingslaag, maar onderzoek uit 2025 (TEE.Fail) liet zien dat gangbare trusted execution environments met fysieke toegang te verslaan zijn en hun attestaties te vervalsen. Sleutels in eigen beheer blijven de primaire beheersmaatregel.
Hoe wordt bewezen dat een systeem soeverein is in plaats van dat alleen te claimen? Door residency op meerdere controlepunten af te dwingen en een permanente geautomatiseerde test te draaien die een verboden toegang over regiogrenzen probeert en vaststelt dat die mislukt. Die test is het bewijs; zonder haar kan de eigenschap stilzwijgend wegzakken.
Wat is het SEAL-raamwerk? De assuranceniveaus (0–4) van het EU Cloud Sovereignty Framework, waarmee wordt gescoord hoe soeverein een dienst werkelijk is, een praktisch volwassenheidsmodel om elke architectuur tegen af te zetten, de eigen architectuur inbegrepen.
Dat is de blauwdruk: zeven pijlers, afgedwongen en getest. Leg de eigen stack ernaast, en wie de onze er ook naast wil leggen, kan een technische intake aanvragen of de Soveryne Cloud Foundation verkennen.
Bronnen
- European Commission, Cloud Sovereignty Framework explained (2026), https://commission.europa.eu/news-and-media/news/sovereign-cloud-framework-explained-2026-06-01_en
- TEE.Fail research (2025), https://tee.fail/
- AWS, Reducing the scope of impact with cell-based architecture, https://docs.aws.amazon.com/wellarchitected/latest/reducing-scope-of-impact-with-cell-based-architecture/
- Confidential Computing Consortium, https://confidentialcomputing.io/about/
- ANSSI, SecNumCloud (trusted cloud qualification), https://cyber.gouv.fr/secnumcloud-pour-les-fournisseurs-de-services-cloud
- "Sovereign-by-Design" (onderzoek naar soevereiniteit als afdwingbare systeemeigenschap), https://arxiv.org/abs/2602.05486
