Zoals beloofd stel ik ook hier dezelfde twee vragen: Wat heb je nodig voor de bouw en wat heb je nodig voor de operatie?

Wat doet het platform eigenlijk?

Het platform is niet één ding. Het is nuttig om het onderscheid te maken tussen control plane en data plane. De data plane is waar het werk gebeurt voor klanten. Hier leven hun virtuele machines, opslag, netwerk, enzovoorts. De control plane is het besturingssysteem van de cloud zelf. Het verwerkt aanvragen zoals “geef mij vier VM’s met deze specificaties in deze regio”, zoekt er capaciteit bij, richt de netwerken in, koppelt de opslag, houdt de gewenste toestand bij en grijpt in als de werkelijkheid daarvan afwijkt. De control plane omvat verder systemen voor toegangsbeheer, logging, monitoring, encryptie en nog veel meer om de cloud draaiende en veilig te houden.

Het onderscheid tussen control plane en data plane is geen technisch detail. De data plane is waar de data van klanten leeft en waar elke klant controle heeft over de eigen omgeving. De control plane daarentegen staat onder controle van de cloud provider en dient zo ingericht te zijn dat de cloud provider geen toegang heeft tot klantdata. Of in ieder geval dat wanneer dat onverhoopt toch nodig is, dat dit gecontroleerd gebeurt en er een auditlog van gemaakt wordt, zodat alle acties traceerbaar zijn. Dat is belangrijk om na te kunnen gaan wat er fout is gegaan of hoe een lek heeft kunnen ontstaan bij een (security) incident, maar ook omdat aangetoond kan worden dat voldaan wordt aan allerlei wet- en regelgeving, en globale-, lokale-, of industrie-certificeringen zoals ISO 27001 en 27018, SOC 1 tot 3, BIR 2012 (NL), PCI-DSS en SOX. Hyperscale clouds hebben vele van dit soort certiceringen en behoren daarmee tot de meest geaudite systemen op de planeet.

Dat clouds zoveel geaudit wordt is enorm belangrijk. Want wie het control plane beheerst, beheerst de cloud. Dat betekent dat cloud providers moeten kunnen aantonen dat ze er alles aan doen om de systemen van hun klanten in de lucht te houden tijdens allerlei soorten incidenten en te beschermen tegen cyberaanvallen, zonder dat ze klantdata zien tenzij strikt noodzakelijk. En dit is waar in het soevereiniteitsdebat de vraag gesteld wordt “wie kan mijn diensten uitzetten?” Dat gaat namelijk feitelijk over de platformlaag en grotendeels over SOV‑3 en SOV‑6 uit het framework, over operationele autonomie en beheer.

Virtualisatie: waar het platform op de infrastructuur leunt

Het platform virtualiseert de infrastructuur, maar het kan dat alleen veilig doen door te steunen op wat er in de hardware aan beveiliging zit. Dat is de directe voortzetting van deel 3.

De hardware root of trust die ik daar beschreef (Cerberus, Nitro, Titan, en in open vorm Caliptra) verifieert de firmware voordat de machine opstart. Het platform bouwt daarop verder met measured boot: elke schakel in de opstartketen meet de volgende en legt die meting vast, zodat de hypervisor pas draait als bewezen is dat er onderweg niets veranderd is. Zonder die hardwarelaag is een veilige hypervisor een aanname; met die laag is het een cryptografisch controleerbaar feit. Dat is de reden waarom je deze lagen niet los kunt kopen: een soeverein platform op niet-geattesteerde hardware is een slot op een deur zonder muur.

Datzelfde geldt voor de isolatie tussen klanten. De hypervisor scheidt VM’s van elkaar, maar leunt daarbij volledig op geheugenbeveiliging in de processor. En de moderne stap verder, Confidential Computing, gaat nog een niveau dieper. Met technologie als AMD SEV‑SNP en Intel TDX wordt het geheugen van een VM versleuteld met een sleutel die de hypervisor zelf niet heeft. De beheerder van het platform kan de machine starten, stoppen en verplaatsen, maar niet in het geheugen kijken.

In het soevereiniteitsdebat dit minder aandacht dan zou moeten. De angst achter SOV‑2 en SOV‑7 is namelijk dat iemand met beheerrechten (of iemand die die rechten juridisch afdwingt) bij je data kan. Confidential Computing haalt precies die mogelijkheid technisch weg. Het is dezelfde redenering als bij hardware-integriteit in deel 3: je hoeft de beheerder niet te vertrouwen als de wiskunde het overneemt. Het maakt herkomst niet irrelevant, maar het verschuift de vraag van “wie is de eigenaar” naar “wie kan er technisch bij”, en dat is de vraag die er in de praktijk toe doet.

Een derde stuk dat vaak vergeten wordt: bij hyperscalers draait een groeiend deel van het control plane helemaal niet meer op de CPU van de server, maar op aparte hardware. Netwerkvirtualisatie, opslagverkeer en beveiligingsregels worden daar afgehandeld, fysiek gescheiden van de omgeving waar de klant zijn code draait. Daarmee is er geen software van de klant die op dezelfde processor draait als de beheerlaag. Dat is architectuur als beveiliging, en het is een van de duidelijkste voorbeelden van wat schaal je oplevert: zo’n kaart ontwikkel je alleen als je er honderdduizenden van gebruikt.

Toegang: hoe je zorgt dat niemand te veel rechten heeft

Nu de vraag die in mijn ogen het hart van deze laag raakt. Want als het control plane de macht is, dan is de mens met toegang tot het control plane het risico.

De reflex in kleine organisaties is een groep vertrouwde beheerders met brede rechten, gescreend en van onbesproken gedrag. Dat werkt, tot iemand een fout maakt, tot iemands account overgenomen wordt, of tot iemand onder druk gezet wordt. Screening beschermt tegen slechte intenties, niet tegen gestolen credentials, en de meeste incidenten beginnen niet bij een kwaadwillende medewerker maar bij een gecompromitteerde legitieme sessie.

Hyperscalers lossen dat structureel anders op, en het principe is confronterend simpel: standaard heeft niemand rechten. Geen enkele engineer heeft permanente toegang tot productie. Wat er in plaats daarvan staat, is een stapel maatregelen die samenwerken:

• Just-in-time access- Toegang wordt aangevraagd voor een specifieke taak, een specifiek systeem en een beperkte tijdsduur, met een expliciete reden die aan een ticket of incident gekoppeld is. Na afloop vervalt de toegang automatisch. Een compromittering van een engineer-account levert daarmee op een willekeurig moment niets op, want er hangt niets aan.
• Goedkeuring door een ander – Voor gevoelige acties is een min-of-meer willekeurig gekozen tweede persoon nodig die de aanvraag goedkeurt. Dat is geen bureaucratie maar hetzelfde principe als twee sleutels voor een kluis: één persoon kan niet op eigen houtje toegang krijgen.
• Geen menselijke toegang tot klantdata – De beheerinterfaces zijn zo ontworpen dat een engineer diagnostiek kan doen zonder de inhoud te zien. Waar dat onvermijdelijk is, zit er een expliciete, goedgekeurde en gelogde procedure omheen, en bij Confidential Computing is het technisch buitengesloten.
• Break-glass als uitzondering, niet als achterdeur – Er is altijd een noodprocedure, maar het gebruik daarvan zet alarmen af, is achteraf volledig te reconstrueren en wordt standaard onderzocht.
• Geen mensen aan de knoppen, maar code – Dit is misschien wel het belangrijkste en tegelijk het minst begrepen. Beheer gebeurt niet door in te loggen en commando’s te typen, maar door een wijziging aan te bieden aan een geautomatiseerde pijplijn: code review, geautomatiseerde tests, gefaseerde uitrol over zones en regio’s, automatische terugrol bij afwijkende signalen. De engineer heeft geen rechten op het systeem; de pijplijn heeft ze. Daarmee is elke wijziging per definitie beoordeeld, gelogd en herleidbaar tot een persoon en een reden.

Wat je hier ziet is dat “niemand met te veel rechten” niet een kwestie van vertrouwen is, maar van ontwerp. En hier zit een ongemakkelijk punt voor de soevereiniteitsdiscussie. De eis die je in aanbestedingen vaak ziet, “alleen EU-personeel met EU-nationaliteit mag toegang hebben tot het beheer”, meet nationaliteit. Wat er werkelijk toe doet is of er überhaupt iemand is die iets kan zonder tweede persoon, zonder ticket, zonder logging en zonder tijdslimiet. Een kleine soevereine “cloud” met tien volledig Nederlandse beheerders die permanente rootrechten hebben, is aantoonbaar kwetsbaarder dan een omgeving waar niemand standaard rechten heeft, ongeacht paspoort.

En hier zit nog een ander operationeel aspect aan. Als je toegang op deze manier kunt waarborgen, is het mogelijk om beheerders te hebben over de hele wereld, hetgeen voor 24×7 operatie een groot voordeel is, omdat je daarmee kosten kunt beperken (bijvoorbeeld geen extra kosten voor nachtdienst) en de beste experts in de wereld operaties kan laten uitvoeren op een veilige, gecontroleerde manier.

Automatisering en monitoring: waarmee de schaal mogelijk wordt

In deel 1 schreef ik dat het securitysignaal van een hyperscaler wereldwijd is en dat een afgeschermd nationaal eiland slechts een fractie daarvan ziet. Op de platformlaag wordt concreet waarom dat zo veel uitmaakt, want het zijn juist automatisering en monitoring die elkaar hier versterken.

Monitoring zonder automatisering levert alarmen op die door mensen afgehandeld moeten worden. Dat schaalt niet. Meer systemen betekent meer alarmen betekent meer ruis betekent alarmmoeheid, en alarmmoeheid is hoe echte incidenten gemist worden. Automatisering zonder monitoring is blind. Je rolt fouten net zo efficiënt uit als verbeteringen. En dit is ook waarom de monitoring data zo belangrijk is. Het is de motor van constante verbeteringen.

De combinatie is wat het verschil maakt. Bij een hyperscaler is het platform zelf de bron van de waarheid. Het weet exact welke configuratie er hoort te draaien en elke afwijking daarvan is per definitie verdacht. Een server die van de norm afwijkt wordt niet onderzocht maar automatisch uit rotatie gehaald en opnieuw opgebouwd. Een gedragspatroon dat afwijkt (een beheeraccount dat op een ongebruikelijk tijdstip een ongebruikelijke API aanroept) is detecteerbaar juist omdat het normale gedrag zo strak gedefinieerd is.

Daar komt het volumeargument bovenop, en dat is geen marketing maar statistiek. Detectie van afwijkend gedrag vereist een betrouwbaar beeld van normaal gedrag. Hoe meer signaal, hoe scherper dat beeld en hoe kleiner de afwijking die je nog betrouwbaar kunt opmerken. Een omgeving met duizend servers ziet te weinig om subtiele patronen boven de ruis uit te tillen. Een omgeving met miljoenen ziet ze wel, en kan een detectieregel die bij één klant werkt binnen minuten wereldwijd uitrollen. Datzelfde geldt voor patchen. Bij volledig geautomatiseerd vlootbeheer kan in uren tot dagen de hele vloot bijgewerkt zijn, met bewijs dat het overal gebeurd is. Bij (deels) handmatig patchen duur dit veel langer en moet bewijs verzameld worden.

En dan is er nog het personele argument, dat ik in deel 1 al aanstipte. Een securityteam dat 24/7 dekking moet bieden heeft, met vakantie, ziekte en verloop, al gauw acht tot tien mensen nodig voor één functie. Voor een volwaardig operationeel securitycentrum met detectie, respons, threat intelligence, forensics en red teaming zit je op tientallen tot honderden mensen. Bij de hyperscalers zijn dat er duizenden. Voor een Europese speler met een paar duizend medewerkers in totaal is dat niet een kwestie van willen, maar van kunnen, in een arbeidsmarkt waar deze mensen structureel schaars zijn.

Ik zeg dit niet om kleine partijen af te schrijven, maar om te laten zien dat schaal op zichzelf een factor is. Om een serieuze Europese cloud te hebben, moet je niet alleen de supply chain en operatie onder controle hebben, maar is schaal een voorwaarde voor succes. Dat levert een kip-ei probleem op, want de schaal is nodig om lagere kosten en hogere kwaliteit te realiseren, maar die schaal haal je alleen maar als je kosten-kwaliteit verhouding niet te ver uit de pas loopt met wat de Amerikaanse clouds kunnen leveren.

De bouwvraag: welke opties zijn er?

Er zijn verschillende routes om de control plane op te bouwen. Zo zou je kunnen beginnen met een virtualisatieplatform zoals VMWare en Nutanix, of een open source alternatief daarvoor zoals Proxmox. Ook zou je op basis van Kubernetes aan de slag kunnen gaan en KubeVirt gebruiken voor als je toch virtuele machines moet ondersteunen (en dat moet je). Aangezien Kubernetes open source is, en ook nog eens een defacto standard voor cloud-native applicaties, zijn er voldoende opties. Maar een virtualisatie- en containerplatform is nog geen cloud. Ten eerste is een dergelijke omgeving vooral bedoeld voor één organisatie en niet een multi-tenant omgeving voor vele organisaties. Ten tweede doet de control plane meer dan alleen wat gevirtualiseerde compute, opslag en network optuigen. Het is het hart van de cloud en er zit een ribbenkast aan zaken omheen om de cloud robuust en veilig te houden, en om Andere diensten bovenop aan te kunnen bieden. Hier zijn wel een aantal opties voor.

OpenStack is de bekendste. Het project startte in 2010 en het wordt beheerd door de Open Infrastructure Foundation. Het is uitgegroeid tot een verzameling van losjes gekoppelde diensten: Nova voor compute, Neutron voor netwerken, Cinder en Swift voor opslag, Keystone voor identiteit, Ironic voor bare metal. Een aantal Europese providers gebruikt OpenStack: OVHcloud, T-Systems, Cleura en kleinere nationale spelers. De kracht is de modulariteit en het feit dat het bewezen is op grote schaal. De prijs is complexiteit: OpenStack is berucht om zijn operationele zwaarte, en de kennis om het op grote schaal draaiend te houden is een schaars en duur goed. Het is geen product dat je installeert, het is een discipline die je opbouwt.

OpenNebula is de tegenpool van OpenStack. Het veel eenvoudiger van opzet en ontworpen om met een klein team een aanzienlijke omgeving te beheren. Het schaalt prima naar duizenden hosts en is sterk in edge- en gedistribueerde scenario’s. Precies daarom is het interessant voor een Europese speler die niet de personele diepte van een hyperscaler heeft. Wat het niet doet, is de breedte van diensten leveren die klanten van een hyperscaler verwachten.

Apache CloudStack valt in dezelfde categorie als OpenNebula. Het is een volwassen alternatief dat vooral bij hostingproviders gebruikt wordt en aanzienlijk eenvoudiger te bedienen is dan OpenStack.

Dat deze platformen open source zijn heeft het voordeel dat er iets is waarop voortgebouwd kan worden. Maar dit verschilt wezenlijk van hoe een hyperscaler werkt. De platformsoftware is bij een hyperscaler sterk geintegreerd met de hardware, wat het geheel sneller, robuuster en veiliger maakt dan het bij elkaar brengen van onderdelen die niet op elkaar afgestemd zijn. Dat is geen open source, maar zoals aangegeven zijn er allerlei andere waarborgen voor klanten die misschien wel belangrijker zijn.

De eerlijke conclusie voor de bouwvraag: op de platformlaag is SEAL‑4 technisch haalbaar. De software kan Europees zijn, de code kan in Europa geschreven worden, en de open projecten liggen er. Wat ontbreekt is niet de blauwdruk, maar de jaren aan operationele ervaring die nodig zijn om zo’n platform op hyperscale betrouwbaar te maken. Dat is niet te kopen, dat moet je meemaken. En dan kom je bij de operatie en de toeleveringsketen.

De operatie en toeleveringsketen

Dat het de platform software open source kan zijn en daarmee Europees gemaakt kan worden is natuurlijk mooi. Maar hoewel de software an sich belangrijk is, gaat het in deze laag vooral de constante verbeteringen om de operatie nog robuuster, nog veiliger, en met nog minder overhead te kunnen maken. Open source is daar een belangrijke component in, ook voor hyperscalers, maar niet de enige. Het open source deel bestaat uit de Linux-kernel, KVM, de container-runtimes, cryptografische bibliotheken, honderden pakketten die elk hun eigen afhankelijkheden meebrengen. Formeel gezien is dat geen SOV‑5-probleem, want een open licentie kent geen jurisdictie en kan niet met terugwerkende kracht ingetrokken worden. Praktisch gezien is het wel degelijk een afhankelijkheid, alleen een andere dan het framework meet. Want een licentie kun je niet intrekken, maar de mensen die de code onderhouden kun je wel kwijtraken, overnemen, of onder druk zetten.

Verder gaat het om de operatie van de schil eromheen: capaciteitsplanning die maanden vooruit kijkt, geautomatiseerde uitrol van nieuwe hardware zonder downtime, live migration van honderdduizenden workloads tijdens onderhoud, foutdomeinen die zo ontworpen zijn dat een defecte hardware geen klant raakt, en een control plane dat zelf ook nog eens over drie availability zones verdeeld is en een quorum vormt (precies de reden waarom er in deel 2 drie zones stonden en geen twee). Die laag is bij de hyperscalers geen open source, en dat is meteen het echte gat.

De maintainer als kritieke component… en risico

Dit is de laag waar de toeleveringsketen niet uit fabrieken bestaat maar uit mensen, en dat maakt hem lastiger te meten en makkelijker te negeren.

Het beeld dat de meeste bestuurders van open source hebben, is dat van een wereldwijde massa vrijwilligers die elkaars werk controleert: veel ogen, dus weinig bugs. Voor de grootste projecten klopt dat ook. Voor het overgrote deel van wat er in je stack zit, klopt het niet. Het Census II-onderzoek van Harvard en de Linux Foundation keek naar de vijftig meest gebruikte niet-npm-componenten en vond dat bij 23% van die projecten één enkele ontwikkelaar meer dan 80% van de toegevoegde regels code schreef, en dat bij 94% van de projecten minder dan tien ontwikkelaars goed waren voor meer dan 90% van de code. Dat is de werkelijke vorm van deze afhankelijkheid. Niet een land dat een kraan dichtdraait, maar een handvol mensen dat het volhoudt. En dat is precies waar het XZ Utils-incident van 2024 op inhaakte: een bijdrager bouwde jarenlang geduldig vertrouwen op bij een uitgeputte solo-maintainer van een breed gebruikte compressiebibliotheek, nam het onderhoud over en plaatste er een achterdeur in die tot in de authenticatieketen van vrijwel elke Linux-distributie zou hebben gereikt. Het werd ontdekt doordat een ingenieur van Microsoft een prestatieafwijking van een halve seconde bij het inloggen te vreemd vond en ging graven. Toeval, met andere woorden. De kwetsbaarheid zat niet in de code, maar in het onderhoudsmodel: één overbelaste vrijwilliger op een pakket waar de halve wereld op leunt.

Voor het soevereiniteitsdebat is dit belangrijker dan het lijkt. Een EU-aanbesteding kan eisen dat de leverancier Europees is en dat het beheer in de EU plaatsvindt, en beide vinkjes kunnen groen staan terwijl de kritieke afhankelijkheid bestaat uit een niet-Europese vrijwilliger die geen contract, geen SLA en geen opvolger heeft. En dan hebben we het nog niet eens gehad over een scenario waar kwaadwillenden zich op de open source software supply chain richten. Dat is met AI (gelukkig) steeds beter op te sporen, maar vooralsnog is dat niet 100% waterdicht. Closed source in eigen beheer kan daarom in sommige gevallen veiliger zijn.

Wie draagt er dan werkelijk bij?

De cijfers zijn hier confronterender dan de open-sourceretoriek suggereert. Neem de Linux-kernel, het fundament van elk cloudplatform dat we in dit deel besproken hebben. In 2025 werd 84,3% van alle kernelcommits geschreven door mensen die daarvoor betaald worden, verdeeld over ruim 1.780 organisaties. Slechts zo’n 16% kwam van onafhankelijke of niet-toewijsbare bijdragers. De kernel is dus geen vrijwilligersproject meer, maar een industrieel samenwerkingsverband, en de vraag wie er bijdraagt is daarmee de vraag welke bedrijven erin investeren. Google, Intel, Meta en Oracle tekenenen voor meer dan 60% van de bijdragen, en daar komen partijen als AMD, Huawei, en Red Hat nog bovenop.

Zoom je uit naar open source in het algemeen, dan wordt het beeld niet anders. De Open Source Contributor Index, die bedrijven rangschikt naar het aantal actieve bijdragers op GitHub, wordt medio 2026 aangevoerd door 8 Amerikaanse bedrijven, gevolgd door Huawei en op plaats 10 SUSE. Reken je die tien tegen elkaar af, dan komt ruim 90% van de actieve bijdragers uit Amerikaanse bedrijven, ongeveer 4,8% uit China en ongeveer 4,5% uit Europa, en dat laatste percentage bestaat vrijwel volledig uit één bedrijf: SUSE.

Bij OpenStack, het platform waar de Europese cloudsector het meest op leunt, ligt de verdeling gunstiger: Red Hat en SUSE zijn er groot, en Europese providers als OVHcloud, T‑Systems, Cleura en het Duitse SysEleven dragen daadwerkelijk bij. Maar OpenStack is ook een project waar de commerciële energie sinds het vertrek van een aantal grote Amerikaanse en Chinese sponsors juist is teruggelopen, en dat is niet zonder risico als je er je hele platformlaag op bouwt. OpenNebula is een van de weinige echt Europese cloudprojecten met een Europese onderneming eromheen, maar de contribuerende gemeenschap is naar verhouding klein, en dat is precies het patroon uit Census II in het klein.

Één belangrijke nuance bij al deze cijfers: ze meten werkgever, niet nationaliteit. Een Duitse ontwikkelaar in dienst van Google in München telt in deze statistiek als Google. Er is opvallend weinig betrouwbare data over waar bijdragers fysiek zitten, en dat is op zichzelf al een bevinding: de discussie over “wie schrijft de code die wij draaien” wordt gevoerd zonder dat iemand er goede meetgegevens over heeft. Wat we wél weten is wie de rekening betaalt, en dat is overweldigend niet-Europees.

Wat betekent dat nu echt?

Ik wil twee verkeerde conclusies voorkomen:

• De paniekconclusie: “de code is Amerikaans, dus we zijn niet soeverein”. Zo werkt open source niet. De GPL en de Apache-licentie zijn onherroepelijk voor code die al vrijgegeven is, en de kernelbroncode staat op honderdduizenden plekken. Niemand kan Linux uitzetten. Als Intel morgen zou stoppen met bijdragen, blijft alles draaien wat er draait.
• De geruststellingsconclusie: “het is open source, dus het is van iedereen en er is geen probleem”. Ook dat klopt niet, want de afhankelijkheid zit niet in de code van vandaag maar in de ontwikkeling van morgen. Wie de bijdragen domineert, bepaalt de richting: welke hardware ondersteund wordt, welke beveiligingsfuncties er komen, welke architectuur prioriteit krijgt en hoe snel een kwetsbaarheid gepatcht is. Als Europa 4,5% van de bijdragen levert, heeft Europa 4,5% van de stem over waar het fundament van zijn eigen cloud heen beweegt. En het praktische risico is scherper dan het principiële: raakt een project onderhouden door een handvol mensen wiens werkgever de stekker eruit trekt, dan heb je code die formeel vrij is maar feitelijk een risico vormt.

Er is bovendien een asymmetrie die zelden benoemd wordt: de Amerikaanse hyperscalers financieren een groot deel van het open-source-onderhoud waar de Europese providers gratis van profiteren. Elke Europese OpenStack-cloud draait op een kernel die voor het overgrote deel door Intel, Google, Red Hat, Oracle, Meta en AMD onderhouden wordt. Dat is geen verwijt aan die providers, het is hoe open source hoort te werken, maar het maakt de retoriek van “onafhankelijk van de Amerikanen” wel wat minder stevig dan ze klinkt.

Wat je eraan kunt doen

Het goede nieuws is dat dit, anders dan een chipfabriek, een probleem is dat met relatief bescheiden bedragen wél op te lossen valt. De maatregelen zijn bekend en grotendeels dezelfde beweging als bij hardware in deel 3: van herkomst naar integriteit, en van consumeren naar bijdragen.

Aan de technische kant: reproduceerbare builds, ondertekende artefacten, een software bill of materials die vastlegt wat er precies in een image zit, geautomatiseerde controle daarop bij elke uitrol, en een eigen gecontroleerde bouwketen in plaats van pakketten rechtstreeks van internet trekken.

Aan de menselijke kant: in kaart brengen welke componenten in je platform door minder dan een handvol mensen worden onderhouden (dat is te automatiseren), en daar structureel geld en menskracht in stoppen. Initiatieven als het Sovereign Tech Agency in Duitsland, dat rechtstreeks investeert in het onderhoud van kritieke open-sourcecomponenten, en het Nederlandse en Europese beleid om open source in de publieke sector te bevorderen, zijn hier veel effectiever besteed geld dan menig soeverein datacenterproject.

Dat is, denk ik, de meest onderschatte investeringskans in dit hele soevereiniteitsdebat. Een fabriek voor geavanceerde chips kost tientallen miljarden en een decennium. Een serieuze Europese positie in het onderhoud van de open source waar de platformlaag op draait, kost een paar honderd miljoen en een paar jaar, en levert directe zeggenschap op over de richting van de software die je hoe dan ook gaat draaien.

Wat betekent dit voor SEAL‑4?

De platformlaag kan in theorie Europees zijn. De software kan Europees zijn, de open bouwstenen liggen er, de code kan in Europa geschreven en beheerd worden, en de operatie kan volledig onder EU-recht vallen. Anders dan bij de hardware is er hier geen fysieke onmogelijkheid. Er zijn echter wel een aantal belangrijke kanttekeningen.

De beveiliging van deze laag zwaar op de laag eronder. Measured boot, attestatie en confidential computing zijn platformfuncties die alleen werken dankzij eigenschappen van hardware die overwegend niet-Europees is. Een soeverein platform op niet-soevereine hardware is prima verdedigbaar, maar het is conform het framework geen SEAL‑4.

Ten tweede is het echte onderscheid van een hyperscaler op deze laag niet de virtualisatie maar de operatie eromheen: de automatisering, het vlootbeheer, de detectiecapaciteit en de toegangsdiscipline. Dat is geen software die je installeert, het is een organisatie die je opbouwt, en daar gaan jaren overheen. Het bestaat uit geïnstutionaliseerde kennis en processen. Hier is ook nog wel wat goed nieuws. De mensen die dat opgebouwd hebben zijn niet uitsluitend Amerikanen in de VS. De hyperscalers hebben allerlei nationaliteiten in dienst en op meerdere plaatsen. Zo zijn er ook ontwikkelteams in verschillende Europese landen. De mensen die dit al eens gedaan hebben, wonen ook in Europa. Aandachtspunt daarbij is wel is dat kleinere Europese providers vaak bij lange na niet dezelfde beloningen kunnen bieden.

Ten derde is de open source waarop het hele verhaal rust maar in beperkte mate Europees. Je kunt een volledig Europees platform bouwen op een fundament waarvan meer dan negen van de tien bijdragen uit Amerikaanse bedrijven komen. Dat is geen kill-switch-risico, maar het is wel een zeggenschapsrisico, en op de langere termijn een continuïteitsrisico bij de kleinere componenten. Bijdragen is hier het enige echte antwoord: soevereiniteit in software koop je niet, die verdien je met commits.

Ten vierde, en dat is het punt dat ik het liefst zou willen dat de aanbestedingspraktijk overneemt: op deze laag is de belangrijkste beveiligingsvraag niet “wie is de eigenaar” maar “wie kan er technisch bij, en onder welke voorwaarden”. Zero standing access, goedkeuring door een tweede persoon, volledige logging en beheer via geautomatiseerde pijplijnen leveren aantoonbaar meer beveiliging op dan een nationaliteitseis. Ze zijn ook nog eens goed te meten en te auditen. Vraag beide, maar begin bij de tweede.

Daarmee eindigt deze laag waar de vorige twee ook eindigden: het framework is uitstekend in het blootleggen van waar de kwetsbaarheden zitten, en gevaarlijk zodra je het dogmatisch toepast. In het volgende deel klimmen we naar de kerndiensten: VM’s, containers, storage, networking, identity en keys, waar de belofte van soevereiniteit voor het eerst rechtstreeks in aanraking komt met wat klanten daadwerkelijk afnemen.

In dit deel klimmen we één laag omhoog, naar de infrastructuur: de compute-, storage- en netwerkhardware die in de datacenters staat. En hier wordt het framework pas echt interessant. Dit is de laag waar toeleveringsketen-soevereiniteit (SOV‑5, met 20% de zwaarst wegende doelstelling in CSF) van een abstract begrip verandert in een keiharde landkaart van fabrieken, machines en octrooien. Op die kaart is Europa vooralsnog grotendeels toeschouwer.

Zoals beloofd stel ga ik bij elke laag in op dezelfde twee vragen: hoe ziet de toeleveringsketen eruit wanneer je het bouwt, en wanneer je het exploiteert?

De toeleveringsketen bij het bouwen

Een moderne server lijkt een doos met onderdelen, maar is in werkelijkheid het eindpunt van een uiterst complexe toeleveringsketen die bestaat uit meerdere delen:

• Electronic Design Automation-software: Dit is de gereedschapskist waarmee chips ontworpen worden. De marktleiders zijn Synopsys (VS), Cadence (VS), Siemens EDA (Duitsland).
• Instructiesets: Zonder instructies doet een chip niets en dus is het intellectueel eigendom van de instructieset van belang. x86 valt onder gedeelde controle van Intel en AMD (beide VS), Arm is van Arm Holdings (VK, maar met een Japanse eigenaar). RISC‑V is een open standaard maar heeft nog geen volwassen ecosysteem. Dit is potentieel waar Europa zich op zou moeten richten.
• Chipontwerp: Chips worden ontworpen door Nvidia, AMD, Intel, Ampere, Broadcom, plus de eigen chips van de hyperscalers zelf (AWS Graviton/Trainium, Google TPU, Microsoft Maia/Cobalt). Dit is daarmee grotendeels Amerikaans.
• Fabricage: De daadwerkelijke productie van chips gebeurt bij TSMC (Taiwan), Samsung (Zuid-Korea) en in mindere mate Intel (VS). Geheugen (DRAM, HBM) komt van Samsung, SK hynix en Micron (Korea, VS).

Deze keten SEAL-4 compliant maken is een enorme onderneming die heel veel investeringen vergt en een lange adem. Maar er is nog een cruciaal onderdeel van de keten…

De rol van ASML

In deel 1 noemde ik het al kort: Nederland heeft met ASML een enorme troef in handen. Tijd om die kaart om te draaien en goed te bekijken, want ASML is het beste bewijs dat “soevereiniteit” en “afhankelijkheid” twee kanten van dezelfde medaille zijn.

ASML is de enige fabrikant ter wereld die EUV-lithografie kan leveren. Dit zijn de machines waarmee de geavanceerde chips gemaakt worden die elke moderne GPU en CPU nodig heeft. Niet de grootste, niet de beste: de enige. Zonder ASML staan de fabrieken van TSMC en Samsung stil. ASML komt dichtbij een monopolie.

De EUV-systemen die ASML maakt bestaat uit honderdduizenden componenten. De optiek komt van Carl Zeiss SMT (Duitsland). Dit gaat om spiegels die zo perfect gepolijst zijn dat de afwijkingen op de schaal van een atoom worden gemeten, en waar Zeiss een de-facto monopolie op heeft. De techniek om druppeltjes tin vijftigduizend keer per seconde door een laser te raken om plasma te maken komt van Cymer (Amerikaans, maar in bezit van ASML) en Trumpf (Duits). De machines van ASML zijn daarom meer dan een product, het is een ecosysteem dat in twee decennia is opgebouwd. Dat is niet zo 1-2-3 te repliceren (later meer daarover).

Nu de nuance, want dit is waar het interessant wordt voor het framework. Het feit dat ASML Nederlands is, betekent niet dat Europa soevereine compute heeft. ASML verkoopt zijn machines aan TSMC in Taiwan en Samsung in Korea, en die fabriceren chips die door Nvidia (VS) zijn ontworpen met Amerikaanse EDA-software op een Britse of Amerikaanse instructieset. ASML is dus maar één schakel in een keten die verder overweldigend niet-Europees is.

Het laat wel zien dat afhankelijkheid twee kanten op werkt, precies zoals ik in deel 1 aanstipte. De hele wereld heeft Europa nodig voor de bovenkant van de chipketen, net zo hard als Europa de rest van de wereld nodig heeft voor de onderkant. Dat is geen soevereiniteit, maar het is wel onderhandelingspositie. In een geopolitiek spel is een geloofwaardige troef aan de onderhandelingstafel meer waard dan een dogmatisch nagestreefde autarkie die je economisch de das omdoet. De recente berichten dat China eigen DUV-machines in productie neemt (juli 2026) laten meteen zien hoe kwetsbaar zelfs een monopolie is zodra iemand bereid is er tientallen miljarden en een decennium (of twee) tegenaan te gooien. Een voorsprong is geen eeuwigdurend bezit.

De eerlijke conclusie voor de bouwvraag: op de hardwarelaag is een SEAL‑4-keten vandaag simpelweg niet te bouwen. Niet omdat Europa dom of lui is, maar omdat de keten fysiek verspreid is over Taiwan, Korea, de VS en Japan, en het jaren tot decennia duurt om die schakels te dupliceren, als het al kan. Het European Processor Initiative en RISC‑V zijn serieuze pogingen om bij te komen, maar het zal echt een heleboel vergen voor ze hyperscale-volume en -prestaties kunnen bieden. Het framework rapporteert dat eerlijk, en dat is precies zijn waarde: het liegt niet over waar we staan.

Open Compute Project

Als de chips zelf de moeilijkste laag zijn, dan is de manier waarop hyperscalers die chips tot servers, racks en netwerken smeden juist het meest verrassend open. Dat komt door het Open Compute Project (OCP). OCP is in 2011 opgericht door Facebook (nu Meta), dat besloot zijn serverontwerpen niet als bedrijfsgeheim te behandelen maar openbaar te maken. Het idee: als iedereen dezelfde open specificaties gebruikt voor moederborden, voedingen, racks, koeling en netwerkswitches, dan wordt hardware een commodity, gaat de prijs omlaag en gaat de kwaliteit omhoog. Microsoft, Google en vrijwel iedere serieuze speler droegen hun eigen ontwerpen bij. Een groot deel van wat een hyperscaler “hyper” maakt aan de hardwarekant (racks, gedisaggregeerde storage, hot-swappable alles) is publiek beschikbaar via OCP.

Voor het soevereiniteitsdebat is dat een dubbelzinnig cadeau. Aan de ene kant verlaagt het de drempel enorm: een Europese partij die een hyperscalebasis wil bouwen, hoeft het wiel niet opnieuw uit te vinden. De ontwerpen liggen klaar. Je hoeft niet te bedenken hoe je een efficiënt rack bouwt; dat is een opgelost probleem. Ironisch genoeg maken de huidige Europese partijen niet of nauwelijks gebruik van OCP en daarmee laten ze een grote mate aan innovatie en (kosten)efficiëntie liggen, ook al komt de hardware van buiten Europa.

Echter, open hardware lost precies niets op aan het probleem van een puur Europese toeleveringsketen: OCP is een verzameling open specificaties, maar nog geen fabriek. De blauwdruk delen is gratis, maar de productie blijft de bottleneck. Waar OCP de laatste jaren wel iets doet dat er voor soevereiniteit echt toe doet, is beveiliging, hetgeen on brengt bij de exploitatie.

De toeleveringsketen bij het exploiteren

Stel dat je op magische wijze al je hardware soeverein zou kunnen inkopen. Dan nog is er een risico dat losstaat van waar de chip vandaan komt: is er onderweg mee geknoeid? Een server passeert tientallen handen (o.a. fabriek, assemblage, transport, distributie, installatie) en op elk van die punten kan iemand in theorie een kwaadaardig component bijplaatsen of een firmware-image vervangen. Dit is het klassieke schrikbeeld van de “hardware-implant”, jaren geleden groot geworden door een omstreden (en door alle betrokken partijen ontkend) verhaal over een spionagechip op serverboards. Of dat specifieke verhaal nu klopte of niet, het maakte de industrie in één klap wakker: firmware en hardware die je niet kunt verifiëren, moet je niet vertrouwen.

Hier is een belangrijk onderscheid dat in het soevereiniteitsdebat vaak door elkaar loopt: herkomst (waar is het gemaakt — de SOV‑5-vraag) is iets anders dan integriteit (is het onderweg ongemoeid gebleven). Het framework hamert op herkomst, maar in de dagelijkse praktijk is integriteit vaak de relevantere beveiligingsvraag. En het mooie is dat je integriteit kunt afdwingen, ongeacht waar de onderdelen vandaan komen.

Precies dat is wat de hyperscalers op enorme schaal doen, met een aanpak die “hardware root of trust” heet. Project Cerberus (Microsoft), Nitro (AWS), en Titan (Google) zijn hier allemaal varianten van. Ze zorgen voor hardware root of trust met een identiteit die niet te klonen is, die voor het opstarten elke firmware-image op de server controleert en niet te opstart als er ook maar één bit niet klopt. Omdat de hardware root of trust cryptografisch geverifieerd wordt, hoef je de leverancier niet te vertrouwen. Je vertrouwt de wiskunde.

En hier komt OCP terug in beeld, want deze root of trust hoeft geen gesloten bedrijfsgeheim te zijn. Caliptra is een open-source silicon root of trust: een specificatie, silicium-logica, ROM en firmware voor een geïntegreerd vertrouwensblok, bedoeld voor datacenter-klasse chips als CPU’s, GPU’s, DPU’s en TPU’s. Met andere woorden: het recept om te verifiëren dat er niet met je hardware is geknoeid, ligt open op tafel. Via de OCP Security-werkgroep (met initiatieven rond veilige firmware en attestatie) wordt dit stukje bij beetje een gedeelde standaard.

Waarom is dit voor het soevereiniteitsverhaal zo belangrijk? Omdat het laat zien dat de meest concrete beveiligingsmaatregel op de hardwarelaag, weten dat er niet met je spullen is geknoeid, niet afhankelijk is van SEAL‑4-herkomst. Je kunt een chip uit Taiwan in een server bouwen en er alsnog wiskundig zeker van zijn dat de firmware onaangetast is. Een land dat zich blindstaart op “waar komt de chip vandaan?” en ondertussen geen root of trust en geen attestatie inricht, heeft het verkeerde probleem opgelost. Dat is exact dezelfde weeffout die ik in deel 1 beschreef: het verdedigen tegen een juridisch of herkomst-risico terwijl je je feitelijke security laat versloffen.

Wat betekent dit voor SEAL‑4?

De hardwarelaag is de waar CSF het hardst bijt en waar Europa het minst te vertellen heeft. Herkomst-soevereiniteit is hier vandaag simpelweg onhaalbaar. Het grootste deel van de keten is overweldigend niet-Europees, en zelfs onze grootste troef, ASML, bewijst vooral hoe internationaal verweven de keten is.

Maar er zitten twee lichtpuntjes in dit sombere verhaal::

• De hardwarebasis van een hyperscaler dankzij OCP verrassend open en dus in principe reproduceerbaar. Het probleem is niet het ontwerp, maar de investeringen en de tijd die nodig is om op grote schaal en met hoge kwaliteit de benodigde zaken te produceren.
• Hardware-integriteit is te bereiken zonder soevereine herkomst. Voor veel kritieke systemen is dat de beveiliging die er werkelijk toe doet. Daarmee is de herkomst pas een probleem als de levering niet meer kan of mag en is er geen kill-switch op reeds in gebruik genomen infrastructuur.

De les blijft dus dezelfde als in de vorige delen: gebruik het Cloud Sovereignty Framework om te zien waar de gaten zitten, maar zet het niet dogmatisch in, want dan kom je van een koude kermis thuis. Een SEAL‑4-eis op de compute-laag afdwingen betekent vandaag simpelweg dat je geen moderne hyperscalecloud hebt, punt.

De vraag is vervolgens of we daar wat aan moeten doen. Als we dat echt willen, dan moet daar beleid op gemaakt worden waarmee dit in de komende decennia wordt opgelost. Dergelijk beleid zou enorm ambitieus zijn en investeringen vergen die zo nodig nog ambitieuzer zijn. Vooralsnog is het in ieder geval verstanding om ASML als strategische troef te koesteren.

In het volgende deel klimmen we opnieuw een laag omhoog, naar het platform: het control plane dat al die hardware automatiseert, orkestreert en beveiligt. Dit is de laag waar hardware verandert in een cloud, en waar soevereiniteit een heel ander gezicht krijgt.

We beginnen onderaan, bij de laag die in het soevereiniteitsdebat meestal alleen gesproken wordt over eigenaarschap: het datacenter. Gebouwen, stroom, koeling en glasvezel. Geen software, geen chips, maar beton, koper en water. Dit is de laag waar Europese soevereiniteit het best haalbaar is. Er zijn echter wel fysieke en financiële obstakels zijn. Het voordeel van een datacenter an sich is dat deze genationaliseerd kan worden en daarmee onttrokken kan worden aan eventuele overheidsinmenging vanuit het buitenland. Zoals de casus met Nexperia in 2025 laat zien is dit wel diplomatiek complex.

De anatomie van een hyperscale regio

Voor een hyperscale cloud is een datacenter wel een bouwblok, maar vanuit de organisatie denkt een hyperscale cloud niet in datacenters, maar in regio’s. Een regio is niet een enkel datacenter, maar een cluster van datacenters, doorgaans opgedeeld in drie zogenaamde availability zones. Elke zone is een op zichzelf staande verzameling datacenters met eigen stroom, eigen koeling en eigen netwerk. Een storing in de één mag de ander niet raken. De zones liggen ver genoeg uit elkaar om niet door dezelfde overstroming, brand of stroomstoring te worden geveld (meestal enkele kilometers tot maximaal zo’n 100 kilometer), maar dichtbij genoeg om via glasvezel met minder dan zo’n 2 milliseconden heen en weer te praten. Die 2 milliseconden zijn geen willekeurig getal: het is de grens waaronder je synchroon kunt repliceren, dus waaronder een database in zone 1 en zijn kopie in zone 2 zich als één systeem gedragen.

Waarom drie, en niet twee? Omdat je met drie een meerderheid, een quorum, kunt vormen. Valt één zone weg, dan houden de andere twee samen de waarheid vast en draait de dienst door. Twee zones geven je redundantie, maar geen meerderheid: bij een netwerksplitsing weet geen van beide of hij nog de baas is. Drie is het minimum voor een systeem dat zichzelf overeind houdt zonder menselijk ingrijpen. Dat is meteen de kern van waarom een hyperscale regio duurder is dan “een datacenter”: je bouwt de capaciteit feitelijk anderhalf tot drie keer.

Verbinding met andere regio’s

Eén regio, hoe robuust ook, is nog beperkt tot een bepaalde locatie. Om te beschermen tegen rampen die een hele regio kunnen raken, zoals een langdurige regionale stroomcrisis, een overstroming, of een menselijke fout die zich door de hele regio verspreidt, heb je meerdere regio’s nodig. Anders dan tussen zones is die verbinding niet synchroon: over honderden kilometers is de lichtsnelheid simpelweg te traag voor die 2 milliseconden, dus repliceer je asynchroon. Je accepteert dat de kopie in de andere regio(‘s) een fractie achterloopt, in ruil voor de zekerheid dat je data op meerdere plekken staat.

En hier raakt de fysieke laag ineens de soevereiniteit. Hyperscalers bieden mogelijkheden om te repliceren met andere regio’s binnen dezelfde jurisdictie. Voor data‑residency is dat precies wat je wilt: je uitwijk valt onder hetzelfde recht als je primaire regio. Op deze laag is “data blijft in de EU” dus geen belofte maar een architectuurkeuze die je op de kaart kunt aanwijzen. De verbindingen zelf, met name de  glasvezel‑backbone en de zeekabels liggen voor Europa in Europa en kunnen dus, als ze al niet van een Europese partij zijn, Europees gemaakt worden.

Soevereiniteit gaat echter ook over resilience, het beschikbaar houden van systemen onder extreme omstandigheden. Oekraïne heeft daarom juist veel van hun systemen buiten het land, en dus hun expliciete jurisdictie, geplaatst. Om Johan Cruijff aan te halen: “elk nadeel heb z’n voordeel”.

Beveiliging

Data is het nieuwe goud en dat is wel te zien aan de beveiliging van datacenters. Dat begint met fysieke beveiligingsmaatregelen die niet misstaan op een legerbasis, zoals hekwerk wat een vrachtwagen tegen kan houden, videobewaking en mensen. Een datacenter inkomen gaat ook niet zomaar en soms zijn verschillende delen van een datacenter ook nog gescheiden en vereisen doorgang door een toegangspoort die meerdere vormen van authenticatie vereisen. Ook wordt alle toegang gelogd en kan dus altijd nagegaan worden wie op welk moment binnen was. En ook het verlaten van het gebouw (of een deel daarvan) gaat via een poort of sluis, waardoor het ook niet mogelijk is om zomaar spullen mee te nemen. Binnenin een datacenter is er ook videobewaking en kunnen er nog andere beveiliging op de infrastructuur zitten (maar dat is iets voor het volgende deel). Er is derhalve zeer veel controle over wie waar in een datacenter kan komen, hetgeen zowel vanuit het oogpunt van beveiliging als soevereiniteit van belang is.

Energie: de echte bottleneck

Nu de rekening. Eén hyperscale datacenter trekt al gauw tientallen megawatt, genoeg om honderdduizenden huishoudens van stroom te voorzien. Een regio met drie zones en meerdere gebouwen per zone zit dus al snel op enkele honderden megawatts, en de nieuwste AI‑regio’s koersen richting een gigawatt of meer. Ter vergelijking: dat is de orde van grootte van een middelgrote elektriciteitscentrale, permanent, dag en nacht, voor één regio.

Voor Nederland is dit moment het grootste knelpunt. Ons hoogspanningsnet zit in grote delen van het land tegen of over zijn grens. De netcongestie waar TenneT al jaren voor waarschuwde is een feit. Nieuwe grootverbruikers staan in de wachtrij, en die wachtrij is geen weken maar jaren. In sommige markten loopt de aansluittermijn voor een grote afnemer op tot wel acht jaar. Je kunt de snelste chips ter wereld bestellen, maar zonder aansluiting op het net kan een datacenter niets. Energie is daarmee niet de duurste regel op de begroting, het is de regel die bepaalt of het project er überhaupt komt, en wanneer. Het verklaart ook waarom energie zo centraal staat in het Nederlandse beleid. Een hyperscaler concurreert om exact dezelfde schaarse duurzame energie als de energietransitie van huishoudens en industrie. Tegelijkertijd zijn het juist hyperscalers die de investeringen in (hernieuwbare) energie aanjagen en er zijn plaatsen waar ze een rol spelen bij het in balans houden van het stroomnet door stroom terug te leveren.

Wat hyperscalers doen om energie te besparen

De hyperscalers zijn zich pijnlijk bewust van die rekening, al is het maar omdat elektriciteit hun grootste operationele kostenpost is. Efficiëntie meet je met PUE (Power Usage Effectiveness): de verhouding tussen de totale stroom en de stroom die daadwerkelijk naar de servers gaat. Een gemiddeld bedrijfsdatacenter zit rond 1,5 à 2,0. De hyperscalers hebben in de laatste twee decennia allerlei ontwikkelingen gedaan om dit terug te brengen naar 1,1 tot 1,2. Dat verschil, de “overhead” die niet naar rekenen maar naar koelen en verliezen gaat, is precies waar de winst zit, en waar een kleine speler het aflegt tegen schaal. Kleine “soevereine” datacenters bouwen kan daarmee direct ingaan tegen het belang om energie te besparen.

Hyperscalers gebruiken allerlei methoden om energie te besparen, zoals koelen met buitenlucht (free cooling) wanneer het klimaat het toelaat (een reden waarom Nederland een interessante plaats is voor een datacenter), hardware die hogere temperaturen aan kan zodat er minder gekoeld hoeft te worden, en AI die de koeling realtime optimaliseert. Hier speelt schaal opnieuw in hun voordeel. Een verbetering van 0,01 op de PUE levert op de schaal van honderden megawatts enorm veel besparing op.

Water en koeling

Koeling is de tweelingzus van energie, en vereist vooral water. Klassieke datacenterkoeling verdampt water om warmte af te voeren. Dat is gunstig voor de stroomrekening, maar het verbruikt miljoenen liters per jaar per locatie, vaak gewoon drinkwater. Gezien er steeds meer waterkrapte is, is dit een steeds groter (maatschappelijk) probleem en daarom verschuift de industrie in rap tempo. Microsoft is bijvoorbeeld medio 2024 begonnen met het uitrollen van een gesloten koelsysteem op chipniveau dat verdampingswater volledig overbodig maakt. Het wordt één keer gevuld bij de bouw en circuleert daarna rond, wat miljoenen liters per locatie per jaar bespaart. Andere sporen zijn luchtkoeling, koelen met niet‑drinkbaar, regen- of gerecycled water.

En dan is er nog de restwarmte. Afgevoerde warmte hoeft niet zomaar de lucht in te verdwijnen. Zo kan restwarmte bijvoorbeeld gebruikt worden voor kassen of woningen verwarmen via aansluiting op een warmtenet. Voor dat laatste moet een datacenter dan wel dicht bij de stad staan, waar de ruimtelijke druk en daarmee de grondkosten het hoogst is. Ook hier moeten voor- en nadelen tegen elkaar afgewogen worden.

De toeleveringsketen van een datacenter

Terug naar de twee vragen uit de routekaart: hoe ziet de keten eruit bij het bouwen, en bij het exploiteren?

Bij het bouwen heb je een verrassend lange lijst zware, kritieke componenten nodig: transformatoren en middenspanningsschakelaars om het netvermogen om te zetten en te verdelen, noodstroomaggregaten (meestal diesel) voor als het net wegvalt, batterijen om de seconden te overbruggen tot die aggregaten draaien, en koelinstallaties, leidingwerk. En uiteraard ook gewoon beton, staal, koper en glasvezel.

En hier zit het lichtpuntje voor het soevereiniteitsverhaal. Anders dan bij chips of geavanceerde software is dit een keten die Europa grotendeels zelf beheerst. Transformatoren en schakelmateriaal komen van Europese spelers als Siemens Energy, Hitachi Energy, Schneider Electric en ABB. Noodstroomaggregaten komen van het voornamelijk Duitse MTU en ook koeltechniek komt van overwegend Europese partijen als STULZ, Munters en Schneider. Beton en staal zijn in principe lokaal. De grote uitzondering zijn de batterijen. De lithium‑ioncellen die nodig zijn komen overwegend uit Azië (CATL, LG, Samsung SDI, Panasonic). Er bestaan wat alternatieven en er is een opkomende Europese productie, maar dit blijft het zwakke Europese punt in een verder goed te dekken keten.

Die zal verder opgeschaald moeten worden, om leveringsproblemen te verminderen. Een onderzoek van AFCOM geeft aan dat 94% van de datacenteroperators tegen leveringsproblemen aanloopt, met aggregaten, transformatoren en schakelmateriaal als grootste knelpunten. Levertijden voor grote noodstroomaggregaten zijn opgelopen tot tussen de 72 en 104 weken. Hier valt dus veel te winnen.

Bij het exploiteren verschuift de afhankelijkheid van spullen naar stromen: elektriciteit, dieselbrandstof voor de aggregaten, water, reserveonderdelen en de monteurs die het draaiend houden. Geen van die stromen zijn een direct soevereiniteitsprobleem, hoewel delen van die keten (momenteel) buiten Europa (kunnen) vallen.

Vergunningen en de fysieke werkelijkheid

Naast de technische werkelijkheid, is er ook nog een proces dat doorlopen moet worden om de nodige vergunningen te krijgen. En daar zit ook nog een politieke component aan.

In februari 2022 nam de Nederlandse overheid een voorbereidingsbesluit dat de vestiging van hyperscale datacenters landelijk aan banden legde. De motivering was expliciet en verraadt precies het spanningsveld uit de energieparagraaf: hyperscale datacenters leggen “een onevenredig groot beslag op de beschikbare duurzame energie in verhouding tot de maatschappelijke en/of economische meerwaarde”. De rijksoverheid trok de regie naar zich toe en stelde toelatingscriteria bij de vergunningverlening. De bekendste casus, de geplande megavestiging bij Zeewolde, werd een nationale splijtzwam en liep vast. Geen technisch probleem, maar een maatschappelijk en bestuurlijk probleem.

Bovenop dat besluit stapelen zich de bekende Nederlandse dossiers: de stikstofcrisis die vrijwel elke grote bouwvergunning vertraagt, de netcongestie die een aansluiting jaren kan uitstellen, de ruimtelijke druk in een vol land, en de wateronttrekking die lokaal op verzet stuit. Elk van die dossiers kan een project op zichzelf stilleggen. Samen vormen ze een vergunningentraject dat langer duurt en onzekerder is dan het bestellen van welke lange‑levertijd‑component dan ook. Voor een daadwerkelijk Europese hyperscaler hoeft dit een veel kleiner probleem te zijn. Er zijn immers meer landen waar datacenters kunnen staan. Dan komen we echter weer uit op een van de eerdere onderdelen: de netwerkverbinding. Datacenters bouwen op plekken waar geen digitale snelweg ligt heeft weinig nut en tientallen kilometers aan kabel leggen, over meerdere routes vanwege redundantie, vergt ook vergunningen en mogelijk toestemming van landeigenaren. En dan moeten de kabels ook nog gelegd worden.

Moeten we datacenters dan zelf bouwen?

Terug naar de hoofdvraag: is een SEAL‑4‑datacenterlaag te bouwen? Op de soevereiniteits‑as luidt het antwoord positief. Het gebouw, de stroominfrastructuur, de koeling en de glasvezel kunnen grotendeels binnen de EU worden ontworpen, geleverd en geëxploiteerd. De enige echte niet‑EU‑afhankelijkheid van betekenis is de batterijcel, en zelfs die is geen showstopper.

Dat er niet heel veel soevereine hyperscale datacenters gebouwd worden heeft dus eigenlijk weinig te maken met de datacenterlaag an sich. Het is de wisselwerking met de andere lagen plus de politieke en financiële barrières. Niemand wil miljarden investeren als er geen voorspelbaar rendement uitkomt. De Amerikaanse hyperscalers daarentegen hebben het geld zelf en doordat ze alle lagen beheren is het rendement voorspelbaar. Dat neemt niet weg dat er allerlei partijen zijn die datacenters bouwen, onder andere om deze te verhuren aan hyperscalers. En als deze bedrijven niet Europees zijn, zouden ze in een crisis Europees gemaakt kunnen worden. Aangezien de datacenterprovider over het algemeen ook geen toegang heeft tot de servers zelf, is het ook minder van belang wie de eigenaar is van het gebouw.

Het Cloud Sovereignty Framework wat DG DIGIT van de Europese Commissie in oktober 2025 presenteerde is een poging om die vraag te beantwoorden. Het framework is geen keurmerk, maar een aanbestedingsinstrument om te meten hoe soeverein een dienst werkelijk is. Het beoordeelt acht soevereiniteitsdoelstellingen (SOV‑1 tot en met SOV‑8) en kent aan elk daarvan een Sovereignty Effectiveness Assurance Level (SEAL) toe, van 0 tot 4:

• SEAL‑0 – Geen soevereiniteit.
• SEAL‑1 – EU-recht geldt in theorie; het afdwingen ervan kent uitdagingen.
• SEAL‑2 – Datasoevereiniteit: EU-recht is afdwingbaar over je data, zonder bijzondere inspanning van de klant.
• SEAL‑3 – Digitale weerbaarheid: echte EU-invloed, en niemand in het buitenland kan je uitknop omzetten.
• SEAL‑4 – Volledige digitale soevereiniteit: technologie én operatie volledig onder EU-controle, uitsluitend EU-recht, geen kritieke niet-EU-afhankelijkheden. Dit laatste betekent dat de gehele toeleveringsketen, van chips tot software volledig in de EU moet liggen.

De weging verklapt waar het werkelijk om draait, want toeleveringsketen-soevereiniteit(SOV‑5) telt voor 20% mee, de zwaarste doelstelling. Je kunt je niet juridisch of via certificering naar soevereiniteit toe redeneren. De bepalende factor is waar het silicium wordt geproduceerd en waar de code wordt geschreven. Dit verraad mogelijk ook een onderliggend doel van de EU, namelijk een manier om de economie een impuls te geven door productie van deze zaken naar de interne markt te duwen. Aangezien dit deels om specialistische kennis gaat die niet in Europa beschikbaar is, is de vraag hoe kansrijk dat is. Een poging van het om Taiwanese TSMC om een chipfabriek in de Verenigde Staten te bouwen gaat op zijn zachtst gezegd stroef.

De realitycheck van april 2026

Inmiddels is het framework geen theorie meer. Op 17 april 2026 gunde de Europese Commissie een Sovereign Cloud-aanbesteding van €180 miljoen (over een periode van zes jaar) aan vier aanbieders. De toelatingsdrempel was SEAL‑2; de meeste winnaars haalden SEAL‑3; niemand haalde SEAL‑4. Geen enkele partij. Dat betekent niet dat de inschrijvers faalden, maar dat het framework eerlijk rapporteert dat Europa afhankelijkheden heeft die op dit moment niet te omzeilen zijn.

Een kleine olifant in de kamer: zijn dit eigenlijk wel hyperscale clouds?

Het is hierbij ook nog wel even goed om stil te staan bij de omvang van de providers die de aanbesteding gegund is, in vergelijking met de Amerikaanse hyperscalers. Hyperscale gaat niet over ambitie, maar over schaal: miljoenen servers, regio’s op verschillende continenten, en investeringsbudgetten die lezen als defensiebegrotingen. Langs die meetlat is zelfs OVHcloud, Europa’s grootste cloudspeler, een orde van grootte (of twee, of drie) kleiner dan welke afzonderlijke Amerikaanse hyperscaler dan ook. Die hyperscalers geven elk in één kwartaal meer uit aan infrastructuur in Europa, dan Europa’s eigen cloudsector in jaren omzet. De ongemakkelijke waarheid: Europa heeft geen hyperscalecloud. Het heeft goede cloudproviders, maar geen hyperscaler. Een SEAL‑4-hyperscalecloud zou dus betekenen dat je tegelijk de hyperscalebasis bouwt én die soeverein maakt. Dat is nogal een onderneming en vereist enorme investeringen, investeringen waarvan je je kunt afvragen of die ooit zullen renderen, aangezien het ook jaren gaat duren om de nodige schaal en bijbehorende processen op te bouwen. Iets waar ik in volgende posts dieper op in zal gaan.

Waarom is hyperscale belangrijk?

Soevereiniteit heeft twee gezichten: juridisch (wie kan toegang rechtmatig afdwingen of blokkeren) en security (wie kan technisch binnendringen, ongeacht de regels). Het framework beoordeelt die afzonderlijk via SOV-2 en SOV-7, maar in architectuur zitten ze elkaar in de weg. Een deel van wat hyperscale hyper maakt, is dat het securitysignaal wereldwijd is en bestaat uit biljoenen dagelijkse signalen die geanalyseerd worden door een gigantisch AI-gedreven systeem op basis van de meest geavanceerde AI-modellen. Een aanval die bij één klant wordt gezien, beschermt minuten later iedereen. Een afgeschermde nationale cloud ziet slechts een fractie van dat signaal en patcht met minder collectieve wijsheid erachter. Daarnaast hebben de hyperscalers duizenden security professionals in dienst om hun cloud zo veilig mogelijk te houden, meer mensen dan het eerder genoemde OVHcloud in z’n geheel in dienst heeft.

Dat betekent dat het verdedigen tegen een juridisch risico je security kan ondermijnen en in de praktijk je daadwerkelijke soevereiniteit. Zet een workload op een klein, relatief licht geïnstrumenteerd eiland om een theoretische buitenlandse wet te vermijden, en je kunt de feitelijke weerbaarheid tegen aanvallen verlagen. Een gehackte ‘soevereine’ cloud is niet soeverein. Die heeft simpelweg een zichtbaar, juridisch en betwistbaar risico ingeruild voor een onzichtbaar, technisch, niet-betwistbaar en vaak groter risico. Voor werkelijk kritieke systemen waarbij juridische dwang de dreiging is, verdient SEAL‑3/4 zijn kosten; voor bijna al het andere is wereldwijde schaal wat de kwaadwillenden buiten houdt.

Is SEAL-4 wel nodig? En voor wie dan?

Ondanks dat ik juist daar dieper op in ga in volgende posts, is de interessante vraag niet “kan het worden gebouwd?” De juiste vraag om te stellen is of SEAL‑4 überhaupt vereist is, voor welke systemen, en onder welke omstandigheden. De oorlog in Oekraïne heeft laten zien dat de regels in oorlogstijd het raam uit gaan. Zelfs als je een SEAL‑4-cloud hebt draaien voor je kroonjuwelen, is een back-up in een SEAL‑0-cloud misschien wel wenselijk, zodat je kunt blijven opereren als je SEAL-4 cloud(je) platgebombardeerd is.

Voor de meeste workloads is zelfs SEAL‑2 overdreven. En voordat we buitenlandse juridische reikwijdte behandelen als het monster onder elk bed: hoe vaak doet dat zich voor? Zelden. Extraterritoriale verzoeken om EU-klantdata zijn uiterst ongebruikelijk en worden juist eindeloos aangehaald omdat ze zeldzaam genoeg zijn om bij naam te noemen. Sancties die een hele organisatie afsluiten zijn geopolitieke uitzonderingen. Reëel voor een kleine groep entiteiten die meestal al weten wie ze zijn. Risico is kans maal impact, en in deze debatten wordt graag een angstaanjagende impact gekoppeld aan het idee dat de kans daarop groot is, terwijl dat niet het geval is. Wie sec een risicoberekening doet, zonder de emotie, merkt dat SEAL‑0- of SEAL‑1-commoditycloud voor de meeste workloads geen compromis is, maar de juiste, verdedigbare keuze.

En dan is er nog de rekening

Die aanbesteding van €180 miljoen betekent gemiddeld ongeveer €7,5 miljoen per aanbieder per jaar, en omdat het om een raamcontract gaat, is zelfs dat een plafond, geen cheque. Ondertussen pompt elke grote Amerikaanse hyperscaler jaarlijks tientallen miljarden in Europese datacenters. De aanbesteding van de Commissie is daarmee een druppel op een gloeiende plaat: een vraagsignaal, geen industriebeleid. Maar een industriesignaal is niet genoeg. Als Europa de kloof echt wil overbruggen, moet er serieus geïnvesteerd worden (denk Chips Act, European Processor Initiative).

Bij gebrek aan die investeringen, is het beter om strategisch te kijken naar waar afhankelijkheden acceptabel zijn en hoe clouds met verschillende SEAL-levels met elkaar verbonden kunnen worden om zo verschillende dreigingen het hoofd te bieden. We moeten daarbij niet vergeten dat de supply chain afhankelijkheden ook de andere kant op werken. Nederland heeft met ASML een enorme troef in handen als het gaat om de gehele supply chain van computerchips.

Waar we voor moeten waken is dat we het Cloud Sovereignty Framework dogmatisch in gaan zetten, want dat doet veel meer kwaad dan goed. Het mooie van het Cloud Sovereignty Framework is dat het inzichtelijk maakt waar de kwetsbaarheden zitten en daarmee is het een uitstekend instrument voor gedegen risicomanagement. Dat is alleen politiek niet erg sexy en niet samen te vatten in een one-liner.

De routekaart

Het zal zo onderhand duidelijk zijn dat een SEAL-4 hyperscale cloud bouwen een enorme onderneming is, waarvan de vraag is of het überhaupt gaat lukken en of het wel de juiste oplossing is. In volgende posts ga ik dieper in op wat er nodig is om een hyperscalecloud te bouwen. We klimmen van onder naar boven, langs zes lagen, en stellen op elke verdieping dezelfde twee vragen: hoe ziet de toeleveringsketen eruit wanneer je het bouwt, en wanneer je het exploiteert?

1. Datacenters: gebouwen, stroom, koeling, glasvezel.
2. Infrastructuur: compute-, storage- en netwerkhardware.
3. Platform: het control plane dat alles automatiseert en beveiligt.
4. Kerndiensten: IaaS: VM’s, containers, storage, networking, identity, keys.
5. Diensten op hoger niveau: PaaS: messaging, databases, IoT, analytics, AI.
6. Ecosysteem: ISV’s, integrators en managed-servicepartners.

Door die vragen te stellen, kunnen we kijken naar waar de gaten zitten, hoe erg dat eigenlijk is en wat we eraan kunnen doen.