De kerndiensten uit het vorige deel zijn, als je de operatie niet meetelt, huur van hardware. Functioneel moet je alles zelf nog regelen. Dat verandert in deze laag en dit is waar klanten echt voordeel halen uit cloud. In deze laag krijg je namelijk geen componenten maar uitkomsten: een database die zichzelf beheert, een berichtenplatform dat altijd draait, een complete applicatie voor HR, financiën of samenwerking. Hier wordt de lock-in ook snel groter. Virtuele machines, containers, en opslag kun je met wat moeite nog ergens anders naartoe verhuizen. Met PaaS- en SaaS-diensten hangt dat af van keuzes die je maakt (of in het verleden gemaakt hebt).

Ik stel weer dezelfde twee vragen: wat heb je nodig om het te bouwen, en wat heb je nodig om het te opereren? Op deze laag komt er een derde vraag bij: wat kost het om weg te gaan?

Van componenten naar uitkomsten

PaaS en SaaS liggen op hetzelfde spectrum en schuiven allebei verantwoordelijkheid van de klant naar de leverancier. Bij IaaS beheer je zelf het besturingssysteem, de middleware, de applicatie en de data. Bij PaaS neemt de leverancier het besturingssysteem en de middleware over: je krijgt een database, een integratieplatform, een analyseomgeving of een AI-dienst als API. Bij SaaS neemt de leverancier ook de applicatie over. Je levert alleen nog je gebruikers, je configuratie en je data aan.

Elke stap op dat spectrum levert efficiëntie op. Beveiliging, schaalbaarheid, en continuïteit zijn niet meer jouw probleem. Elke stap levert ook controle in. Je wisselt operationele last in voor afhankelijkheid, en voor de meeste organisaties en de meeste toepassingen is dat een uitstekende ruil. Daar gaat deze serie steeds over: voor de meeste toepassingen zijn hoge soevereiniteitseisen niet nodig. Maar voor de toepassingen waar ze wel nodig zijn, moet je weten wat je inlevert.

Er gebeurt in deze laag ook iets met de stapeling uit de vorige delen. Een PaaS- of SaaS-dienst bestaat uit tientallen kerndiensten met een flinke laag eigen logica erboven. Alle afhankelijkheden uit deel 2 tot en met 5 zitten er nog onder, en de leverancier van de dienst voegt er een eigen laag aan toe: eigen code, eigen operatie, eigen jurisdictie. Het soevereiniteitsniveau van een dienst is hooguit zo hoog als de zwakste schakel in die stapel. Als het al mogelijk is om een SaaS-dienst van een niet-Europese leverancier op een Europese/soevereine cloud te krijgen, is deze dienst zelf niet soeverein. Andersom is een Europese SaaS-applicatie op een niet-Europese hyperscaler dat ook niet, al zijn er wel maatregelen te treffen om te wapenen tegen dataverzoeken.

Drie vormen van lock‑in

Lock‑in wordt vaak als één ding behandeld, maar op deze laag komt hij in drie vormen voor. Elke vorm vraagt om een ander antwoord.

De eerste vorm is de interface. Gebruik je een dienst via een open standaard, zoals een PostgreSQL-protocol, een Kafka-API, S3 of de Kubernetes-API uit deel 5, of via een eigen API van de leverancier? Bij een open standaard is een tweede aanbieder of zelf draaien een realistische uitweg. Bij een eigen API betekent vertrekken herschrijven. Dat is niet per se slecht, want eigen diensten kunnen technisch beter zijn. Het moet alleen wel een bewuste keuze zijn.

De tweede vorm is de data. Data heeft “zwaartekracht” omdat diensten die de data nodig hebben vaak dichtbij moeten staan om de latency laag te houden. Voor AI geldt dit nog sterker dan voor meer traditionele toepassingen. Hierdoor is het zo dat hoe meer data er ergens staat, hoe meer er omheen gaat draaien en hoe lastiger het wordt om het geheel te verplaatsen. Data (distributie) ontwerp wordt daardoor steeds belangrijker en bij een multi-cloud strategie onmisbaar. Open formaten helpen hier deels bij. De zwaartekracht wordt er niet direct minder door, maar data is makkelijker te verplaatsen omdat er een knip ligt tussen de opslag en dat wat die data gebruikt. Bij bijvoorbeeld analytics platformen is dit steeds meer de norm. Data staat steeds vaker in open bestands- en tabelformaten in objectopslag, en de analyses die erop rekenen zijn verwisselbaar. Opslag en rekenkracht zijn daarmee niet alleen technisch maar ook contractueel van elkaar losgemaakt.

De derde vorm is de lastigste en wordt het vaakst onderschat: de betekenis. Ik bedoel alles wat je in de loop der jaren in een dienst hebt gestopt naast de data zelf. Configuratie, workflows, autorisatiemodellen, rapportages, integraties, en vooral de manier waarop mensen hun werk zijn gaan doen. Bij SaaS is dit de belangrijkste vorm van lock‑in. Een volledige data-export uit een SaaS-applicatie geeft je de gegevens terug, maar niet de processen. Vertrekken bij een SaaS-leverancier is daarom zelden een IT-project. Het is een veranderprogramma in de organisatie.

Voor het framework raakt dit vooral SOV‑3 en SOV‑6. Het gaat dan minder om de vraag of iemand bij je data kan, en meer om de vraag of je zonder deze dienst verder kunt.

PaaS: open kern, gesloten randen

Bij PaaS is het goede nieuws dat er voor bijna elke categorie een volwassen open alternatief bestaat. Voor databases, messaging, analytics, integratie en steeds meer AI-tooling zijn er open-sourceprojecten die zich met commerciële diensten kunnen meten. Een beheerde dienst die op zo’n project is gebaseerd, heeft een ingebouwde uitweg.

Grotendeels, want het patroon uit deel 5 bij Kubernetes geldt hier ook. De kern is portabel, de randen niet. Wat een PaaS-dienst waardevol maakt, zijn juist de randen: de koppeling met identiteit, het sleutelbeheer, de back-ups en point-in-time restore, de monitoring, de automatische failover, extensies die alleen bij die ene leverancier bestaan. De applicatie verhuist prima, het operationele model eromheen niet. Portabiliteit is ook hier geen eigenschap die je krijgt, maar een eigenschap die je test.

Daar komt een minder zichtbare afhankelijkheid bij. Achter veel open-sourceprojecten zitten commerciële partijen die het meeste ontwikkelwerk doen, vaak niet-Europese. Een aantal van hen heeft de afgelopen jaren de licentie aangepast om te voorkomen dat cloudproviders hun software als dienst aanbieden. “Open source” betekent dus niet automatisch “voor altijd vrij te gebruiken als dienst”. Voor SOV‑5 en SOV‑6 telt niet alleen of de code open is, maar ook wie het project bestuurt. Projecten onder een neutrale stichting zijn wezenlijk robuuster dan projecten die van één bedrijf afhangen.

SaaS: de leverancier is de operatie

Bij SaaS verschuift de soevereiniteitsvraag nog verder. Je beheert niets meer zelf. De leverancier schrijft de code, draait de operatie, bepaalt de releasekalender en beslist welke functionaliteit er komt en welke verdwijnt. In het framework kijk je bij SaaS dus niet alleen naar waar de data staat, maar vooral naar wie de operatie doet (SOV‑4) en onder welke jurisdictie die mensen werken (SOV‑2).

Interessant is dat Europa op deze laag relatief goed meedoet. Waar Europa in hardware vooral toeschouwer is, zijn er in bedrijfssoftware grote Europese spelers, zoals Amadeus, SAP en TomTom. Verder is er een levendig ecosysteem van kleinere SaaS-leveranciers en open-sourcealternatieven voor bijvoorbeeld samenwerking en documentbeheer. Voor een groot deel van de functionaliteit die organisaties nodig hebben, bestaat een Europees alternatief. Daarmee is dit, net als HSM’s in deel 5, een van de plekken waar Europa meespeelt. Daar zit wel een kanttekening aan, want die SaaS-diensten zijn alleen soeverein te noemen als ze draaien op eigen infrastructuur, met eigen operatie. Veel SaaS-diensten draaien echter op een van de hyperscalers, vanwege de kosten efficiency en de focus op de eigen functionaliteit.

De soevereiniteitsvraag gaat regelrecht tegen die efficiency in. SaaS is goedkoop en goed omdat het multi-tenant is: één codebase, één operatie, duizenden of miljoenen klanten. Elke verbetering en elke beveiligingsupdate komt meteen bij iedereen terecht. Die dienst op meerdere clouds aanbieden, of zelfs in een soevereine private cloud vereist op z’n minst een uitbreiding van het operationele team en vaak zelfs een apart operationeel team, eventueel met nationaliteitseisen mensen die gescreend zijn. Dat breekt de efficiency en in feite het bedrijfsmodel van SaaS. En dat is niet het enige probleem. Hier komt ook weer het beperkte security signaal besproken in de eerdere delen om de hoek kijken. Bovendien loopt een aparte instantie achter met updates, wat de kwetsbaarheid nog groter maakt. Je krijgt dan wel meer controle, maar een minder goed product tegen een hogere prijs. Soms is dat de juiste ruil, vaak niet.

Bij SaaS is ook nauwelijks te scheiden wat je zelf in de hand hebt. Bij PaaS kun je met architectuurkeuzes nog veel regelen: open standaarden, open formaten, eigen sleutels. Bij SaaS blijft daar grotendeels het contract van over, met eigen identiteit via federatie en eigen sleutels waar de leverancier dat ondersteunt. En de spanning uit deel 5 is hier op z’n scherpst: een SaaS-applicatie die iets zinnigs met je data moet doen, zoals zoeken, analyseren of AI erop loslaten, moet die data kunnen lezen. Volledige controle over sleutels en volledige functionaliteit gaan slecht samen.

AI: waar alles samenkomt

AI moet hier apart genoemd worden, omdat daar alles uit deze serie samenkomt. AI-diensten zijn er als IaaS (hardware om zelf modellen op te ontwikkelen en uit te voeren, PaaS (modellen en inference als API) en SaaS (assistenten en agents in applicaties) tegelijk. Deze diensten vereisen specifieke hardware, waarvan uit deel 3 al bleek dat die vrijwel volledig niet-Europees is. Door de hoeveelheid energie die ze gebruiken en warmte die daarbij gegenereerd wordt, hebben ze ook de modernste datacenter innovaties nodig. Innovaties die vooral gedreven worden door de hyperscale cloud providers, zoals behandeld in deel 2. De daarmee gepaarde innovatiesnelheid is waar Europa moeite mee heeft. De krachtigste modellen zijn grotendeels niet-Europees en niet zelf te draaien. En de tooling eromheen ontwikkelt zich in een tempo dat geen enkele andere dienst haalt.

Tegelijk is AI ook een goed voorbeeld van hoe je met architectuur ruimte kunt maken. Een open-weight model in je eigen omgeving kan niet worden uitgezet, niet ongemerkt worden aangepast en niet worden ingetrokken. Voor veel toepassingen is zo’n model ruim voldoende. De afweging is dus dezelfde als overal op deze laag: het beste wat er is, of wat je in de hand hebt. En die keuze kun je per toepassing anders maken.

De bouw

Voor wie een hyperscale cloud wil bieden is met name het aantal diensten en de rijkheid daarvan een uitdaging. De hyperscalers bieden honderden PaaS-diensten met een uitgebreide feature set, daar waar Europese cloud providers zich veelal beperken tot de kerndiensten uit het vorige deel en een beperkt aantal PaaS-diensten. Die set aan diensten groeit wel, maar relatief langzaam omdat voor elk van die diensten mankracht nodig is om deze te bouwen, te certificeren en te opereren. Zelfs als de dienst gebruik maakt van open source is dit niet eenvoudig, omdat je er niet zomaar vanuit kunt gaan dat alles goed is. De bouw is dus veel meer dan het installeren op een paar servers.

Een soevereine cloud moet dus keuzes maken en kan zich daardoor alleen richten op die must-have diensten. Een soevereine cloud met tien goed beheerde diensten is beter dan een met honderd die het maar half doen, maar heeft wel het nadeel dat het moeilijker voor een derde partij om daar een SaaS-dienst op te bouwen. De meeste SaaS-diensten bouwen namelijk niet een eigen cloud, maar bouwen bovenop een bestaande cloud, omdat die een heleboel complexiteit wegneemt. Er zijn maar weinig SaaS-diensten die op verschillende clouds beschikbaar zijn, aangezien elke extra versie extra expertise en mankracht vereist, wat ten koste gaat van efficiency.

Het goede nieuws is wel dat het greenfield-voordeel uit deel 5 hier ook geldt. Wie vandaag begint, kan portabiliteit, open formaten en crypto-agility vanaf dag één in het ontwerp opnemen, in plaats van ze er later in te moeten bakken.

De operatie

Bij de operatie zit opnieuw de echte rekening, en op deze laag wordt die nog hoger. Elke dienst voert deels een eigen operatie met eigen experts. Een team dat een databasedienst op schaal beheert, is niet hetzelfde team dat een integratieplatform of een AI-dienst draaiende houdt. De certificeringslast kan wel bouwen op de gedeelde basis uit deel 4 en 5, maar uiteindelijk moet elke dienst afzonderlijk gecertificeerd worden. Dit betekent dat ook dit proces geïndustrialiseerd moet worden om de inspanning zo laag mogelijk te houden.

Dit alles vereist veel (specialistische) kennis. De mensen die dit soort diensten op schaal kunnen bouwen en bedienen, zijn schaars en wereldwijd gewild. Een soevereine aanbieder concurreert om die mensen met de grootste werkgevers in de techsector. En omdat SEAL‑4 vereist dat de operatie volledig binnen de EU en onder EU-recht plaatsvindt, is de vijver waarin gevist kan worden nog kleiner.

Klanten hebben natuurlijk ook eisen. Van kerndiensten verwachten ze stabiliteit. Van PaaS en vooral SaaS verwachten ze vernieuwing: nieuwe functies, betere integraties en nu nieuwe AI-toepassingen. Hier zit een bedrijfsrisico in wat een vicieuze cirkel is:  een soevereine aanbieder die niet kan innoveren verliest klanten terwijl klanten juist nodig zijn voor de vereiste schaal om te investeren in de benodigde stabiliteit en vernieuwing.

En dan is er nog het security aspect. Meer diensten betekent een groter aanvalsoppervlak en tegelijk zien we dat AI steeds sneller lekken weet te exploiteren. Dit manifesteert zich in druk op de operatie om snel en vaak (zo nodig dagelijks) te kunnen patchen. Een ander aspect is dat de datalekken waar je het meest over leest vaak veroorzaakt worden door verkeerde configuraties van software, en dat gaat dan met name over PaaS- en SaaS-diensten. Wie configuratiefouten bij duizenden klanten tegelijk ziet en kan verhelpen, heeft een voorsprong die een kleine omgeving niet heeft. Schaal is hier dus van levensbelang.

Exit: de vraag die hier het zwaarst weegt

In deel 5 noemde ik portabiliteit het meest onderschatte soevereiniteitsinstrument. Op deze laag weegt het het zwaarst, omdat hier de keuzes vallen die bepalen of een exit überhaupt kan. Praktisch komt het neer op een handvol vragen die je bij elke PaaS- of SaaS-dienst zou moeten stellen:

• Is de interface een open standaard of een eigen API?
• Staat de data in een open formaat, en kun je die volledig exporteren?
• Kun je je configuratie, workflows en autorisaties ook meenemen, of alleen de data?
• Bestaat er een tweede aanbieder, of kun je het zelf draaien?
• Heb je de exit ooit getest?

Die laatste vraag wordt nog wel eens over het hoofd gezien. Een exitplan dat nooit is uitgevoerd, is een aanname. Bij SaaS moet je er bovendien een organisatievraag aan toevoegen: hoe lang heeft je organisatie nodig om op een andere applicatie over te stappen? Dat zit niet in de techniek en het contract, maar het bepaalt wel hoe soeverein je werkelijk bent.

Wat betekent dit voor SEAL‑4?

Op deze laag liggen hoop en ontnuchtering dicht bij elkaar. Voor PaaS op open standaarden en voor een deel van het SaaS-aanbod is SEAL‑4 op softwareniveau niet onrealistisch. De software is er, Europese leveranciers zijn er, en de markt beweegt uit zichzelf en onder druk van regelgeving naar open formaten, functies en contractvoorwaarden die een exit vergemakkelijken. Wat ontbreekt zijn schaal, operationele volwassenheid en een scherpe keuze welke diensten je wel en niet aanbiedt. Daarnaast blijft de stapeling gelden. Hoe soeverein een dienst ook is gebouwd, hij draait op de lagen uit deel 2 tot en met 5, en voor veel diensten is dit door de hyperscalers zelf of door partijen die hun diensten daar bovenop gebouwd hebben.

In dit deel klimmen we weer een laag omhoog, naar de kerndiensten. Dit is de eerste laag die de klant daadwerkelijk ziet. Alles daaronder is onzichtbaar mits het werkt; vanaf hier praat je met de cloud. Compute, containers, opslag, netwerk, identiteit en sleutelbeheer: de dingen waar vrijwel elke applicatie op leunt, hoe simpel of hoe complex die ook is.

En omdat het ook hier om software gaat, is de reflex opnieuw: “dít kunnen we zelf.” Dat is deels waar, maar net als in de vorige laag zit de complexititeit niet in het bouwen van de software, maar om de operationele discipline er omheen. Daarom kijken we wederom naar dezelfde twee vragen: wat heb je nodig voor de bouw, en wat heb je nodig voor de operatie?

Wat zijn kerndiensten?

Kerndiensten zijn die diensten die nodig zijn vrijwel voor alle PaaS en SaaS diensten en klantapplicaties. We hebben het dan over virtuele machines, containers, opslag, network, identiteit, encryptie en sleutelbeheer. Dat klinkt beperkt en daarmee relatief eenvoudig. Wat dit complex maakt is dat een dienst meer is dan alleen dan de capability. Een virtuele machine starten is een capability en dat kan iedereen met een hypervisor wel organiseren. Een volwaardige compute-dienst is de toezegging dat je er over een aantal maanden of jaren nog duizenden per minuut kunt starten, in meerdere regio’s, en dat terwijl de onderliggende hardwaregeneraties vervangen worden zonder dat de klant het merkt.

Opslag is het duidelijkste voorbeeld. Objectopslag lijkt aan de buitenkant een emmer waar je bestanden in gooit. Aan de binnenkant is het een gedistribueerd systeem dat elk object opknipt en met erasure coding over racks en zones verspreidt, continu achtergrondcontroles doet op bitrot, kapotte schijven vervangt zonder dat er iemand naar kijkt, en dat tegelijk drie of meer consistentiemodellen moet bedienen. Hyperscalers geven hier een absurd hoge duurzaamheids SLA op. Die SLA is geen marketing, het is een ontwerpdoel waar jaren engineering en heel veel operationele data achter zit. Het is ook precies het soort eigenschap dat je niet kunt kopiëren door de broncode over te nemen, want het zijn de operationele processen die de SLA mogelijk maken.

Netwerk is hetzelfde verhaal in een ander jasje. Software-defined networking betekent dat elke klant zijn eigen adresruimte heeft, zijn eigen routering, zijn eigen firewallregels, en dat die van tienduizenden klanten tegelijk op dezelfde fysieke kabels liggen zonder ooit in elkaars verkeer te kijken.

Identiteit: de echte perimeter

Als het control plane de macht is, zoals ik in deel 4 betoogde, dan is identiteit de sleutel tot die macht. Identity is de enige kerndienst waar een storing of een compromittering meteen alles raakt: zonder identiteit kun je niet inloggen, niet autoriseren, en dus niets.

Dat maakt identiteit de dienst met de scherpste soevereiniteitsvraag van deze hele laag. Niet “waar staat mijn data”, maar “wie bepaalt wie ik ben”. Een organisatie die haar data netjes onder eigen controle heeft maar haar identiteitsprovider niet, heeft alsnog een soevereiniteitsrisico. Omgekeerd is een eigen identiteitsdienst optuigen technisch goed te doen (Keycloak en verwanten zijn volwassen), maar deze 24×7 overeind houden op het niveau waarop de rest van je organisatie ervan afhankelijk is, is een compleet andere discipline. Identity is de dienst waar zelf doen het aantrekkelijkst is vanuit een soevereiniteitsgedachte en het slechtst uitpakt als je het onderschat. Want wordt de identiteitsdienst gecompromiteerd, dan ben je alles behalve soeverein.

Voor het framework zit dit vooral bij SOV‑2 en SOV‑3: wie kan rechtmatig toegang afdwingen, en wie kan de deur dichtgooien. En anders dan bij de hardwarelaag is dit een vraag waar je architectonisch iets aan kunt doen: federatie, eigen identity provider, meerdere vertrouwensankers. Dit is een van de weinige plekken waar een soevereiniteitseis zich vertaalt in een concrete, uitvoerbare ontwerpkeuze in plaats van in een vinkje in een aanbesteding.

Sleutels: waar soevereiniteit wiskunde wordt

Sleutelbeheer is de kerndienst waar het soevereiniteitsdebat het dichtst bij een echt antwoord komt, en waar het tegelijk het vaakst misgaat. De redenering uit deel 3 en 4 geldt hier onverkort: je hoeft de leverancier niet te vertrouwen als de wiskunde het overneemt. Als de versleutelingssleutel van jouw data in een HSM zit die jij beheert, is de vraag “kan een buitenlandse overheid bij mijn data” niet langer juridisch maar technisch. Zonder sleutel is de data ruis, hoe rechtmatig het verzoek ook is.

Hier zit bovendien het vrolijkste nieuws voor Europa: in HSM’s staat Europa er goed voor. Thales (Frans) en Utimaco (Duits) zijn echte spelers in een markt waar de rest van de keten overweldigend niet-Europees is. Dit is een van de weinige plaatsen op de kaart uit deel 3 waar Europa geen toeschouwer is maar meespeelt.

En dan de nuance, want die is er altijd. Sleutels volledig buiten de cloud houden klinkt als maximale soevereiniteit, maar er zitten twee serieuze nadelen aan. Ten eerste hebben een heleboel diensten de sleutel nodig om überhaupt te kunnen functioneren. Een zoekfunctie kan niets zoeken als de data die het doorzoekt versleuteld is. Hetzelfde geldt voor indexeren, analyseren, backups maken, en tegenwoordig heel belangrijk AI. Om bruikbaar te zijn moet data in de cloud ontsleuteld kunnen worden en moet de cloud dus toegang hebben tot de sleutelopslag. Confidential Computing kan hier een rol spelen, maar is nog niet zover dat we dit eenvoudig voor alles kunnen gebruiken. Ten tweede wordt de eigen sleutelbeheer omgeving de enige single point of failure. Wie zijn sleutels kwijtraakt, raakt zijn data kwijt, en dat is geen theoretisch risico maar een van de meest voorkomende manieren waarop organisaties permanent data verliezen. Sleutelbeheer geheel zelf doen kan precies de juiste keuze zijn, maar dan wel als bewuste risicoafweging en niet als reflex.

Kubernetes

Hoewel Kubernetes strikt genomen geen kerndienst is, het draait immers boven de andere kerndiensten, verdient het hier toch een plekje. Containers en daarmee containerorchestratie speelt een steeds belangrijkere rol als kerndienst, omdat steeds meer applicaties gemoderniseerd worden naar containers. Ook cloud provider zelf draaien steeds meer van hun PaaS en SaaS diensten containers.

Voor soevereiniteit is Kubernetes tegelijk het beste en het meest misleidende argument van deze hele laag. Het beste, omdat het een van de weinige echte open standaarden is die de industrie heeft: de API is dezelfde bij elke provider en bij jezelf op kantoor. Dat is geen de‑facto standaard zoals S3, maar een daadwerkelijk gezamenlijk beheerd project onder een neutrale stichting, met conformance-tests die meten of een specifieke distributie zich ook echt als Kubernetes gedraagt. Wie zijn applicaties hierop bouwt, heeft een uitgang die niet van de goede wil van zijn leverancier afhangt. Dat is SOV‑3 in de praktijk in plaats van op papier.

En meteen het meest misleidende, want “het draait op Kubernetes, dus het is portabel” is zelden helemaal waar. Zodra je cluster gebruikmaakt van de load balancer, de opslagklassen, de identiteitskoppeling, de secrets-store en de monitoring van je provider, hangt er onder die neutrale API alsnog een serie leverancierspecifieke haken. De applicatie verhuist prima; het platform eromheen verhuist niet vanzelf mee. Portabiliteit is geen eigenschap die je krijgt, het is er een die je test. Wie nooit geprobeerd heeft zijn cluster ergens anders op te bouwen, weet simpelweg niet of hij kan vertrekken. CNCF projecten als Radius en Dapr zijn gericht op deze afhankelijkheid nog verder te beperken en applicaties echt portabel te maken, maar die worden nog weinig gebruikt.

Quantum-safe: de verbouwing die je nu moet organiseren

En dan is er iets wat in het hele soevereiniteitsdebat opvallend weinig aandacht krijgt, terwijl het de fundering onder alle bovenstaande redeneringen raakt. Al die “je vertrouwt de wiskunde”-argumenten uit deel 3, deel 4 en deze post leunen op asymmetrische cryptografie die door een voldoende grote quantumcomputer gebroken wordt. Dit raakt RSA en elliptische krommen die de basis vormen van TLS, code-signing, attestatie, en de hardware root of trust, van vrijwel elke sleuteluitwisseling in de stack.

Wanneer die quantum machine er staat, weet niemand. Dat het een risico is dat je nu moet organiseren, is desondanks geen speculatie, en wel om twee redenen die los staan van elke voorspelling.

De eerste is harvest now, decrypt later. Versleuteld verkeer dat vandaag wordt afgetapt en opgeslagen, kan in de toekomst alsnog ontsleuteld worden. Voor het overgrote deel van de data maakt dat niets uit, maar voor staatsgeheimen, medische dossiers, justitiële informatie en alles wat decennialang vertrouwelijk moet blijven, is de aanval feitelijk al aan de gang. Dit is precies de categorie waar het SEAL‑4-gesprek over gaat. Wie SEAL‑4 eist vanwege langdurige vertrouwelijkheid en ondertussen geen quantum-safe migratieplan heeft, verdedigt de voordeur tegen een juridisch risico terwijl de achterdeur cryptografisch openstaat.

De tweede reden is de looptijd van de verbouwing zelf. Cryptografie zit niet op één plek; het zit overal. In protocollen, in firmware, in certificaten met lange geldigheidsduur, in HSM’s, in chips die er tien jaar staan, in applicaties die niemand meer durft aan te raken. Je vervangt dat niet met een patchronde. De standaarden zijn er inmiddels wel (o.a. ML‑KEM, ML‑DSA en SLH‑DSA) dus de discussie gaat niet meer over welke wiskunde, maar over de inventarisatie en de volgorde. De EU-aanbeveling en de bijbehorende routekaart zetten daar ook concrete jaartallen op, met de zwaarste use cases voorop.

Praktisch betekent dat drie dingen, in deze volgorde. Weten wáár je cryptografie zit, want de meeste organisaties hebben geen volledig beeld en dat is het echte werk. Zorgen dat je systemen crypto-agile zijn, dus dat een algoritme vervangen kan worden zonder de applicatie open te breken. Dat is een architectuurprincipe, geen product. En hybride uitrollen, waarbij klassieke en post-quantum sleuteluitwisseling naast elkaar draaien, zodat je niets verliest als een van beide tegenvalt.

Voor deze laag is dat concreet. Je sleutelbeheerdienst moet post-quantum algoritmen ondersteunen, je HSM’s moeten ze aankunnen, en je certificaatketen moet vervangbaar zijn. Dat het Europese HSM-aanbod hier meespeelt, is meer dan een leuke bijkomstigheid: het is een van de weinige plekken waar “Europees” en “toekomstbestendig” samenvallen zonder dat je iets inlevert.

En dan de nuchtere kanttekening, want die hoort erbij. Hyperscalers zijn hier al jaren mee bezig en rollen post-quantum sleuteluitwisseling grotendeels ongemerkt uit over hun hele vloot. Dat is opnieuw schaalvoordeel: een migratie die voor een individuele organisatie een meerjarig programma is, is voor hen een uitrol over een pijplijn zoals beschreven in deel 4. Een kleine soevereine cloud moet diezelfde verbouwing zelf doen, met eigen mensen, voor een fractie van het aantal klanten. Dat is precies het soort verborgen kostenpost wat vaak over het hoofd wordt gezien.

De toeleveringsketen bij het bouwen

Goed nieuws en slecht nieuws.

Het goede nieuws: de bouwstenen liggen open op tafel. OpenStack, Kubernetes, Ceph, Keycloak, een volwassen ecosysteem van open cryptografie waarin de post-quantum algoritmen inmiddels gewoon meekomen. Een Europese partij die kerndiensten wil bouwen, hoeft geen enkel fundamenteel probleem opnieuw op te lossen. Net als bij OCP in deel 3 zijn de ontwerpen er; en net als bij OCP is dat maar de helft van het verhaal.

Het slechte nieuws is dat het verschil tussen open source en een dienst precies datgene is wat je niet kunt downloaden. Quotabeheer, capaciteitsplanning, throttling die eerlijk is onder druk, degradatiegedrag dat voorspelbaar is als een zone wegvalt, facturering die tot op de seconde klopt, en een foutmodel dat klanten begrijpen. Dat zijn de dingen waar jarenlang aan geschaafd is met data die je alleen krijgt als je op schaal draait. Je bouwt geen kerndienst, die slijp je in je organisatie.

Kubernetes is daar meteen de scherpste illustratie van. De software is gratis en van iedereen, maar een beheerde dienst eromheen betekent dat je voor duizenden klusters tegelijk garandeert dat een upgrade niet omvalt, dat een kapotte node binnen minuten vervangen is, en dat een beveiligingslek in de container-runtime binnen dagen overal gedicht is. Dat is geen product dat je bouwt, dat is een operatie die je opzet.

Wie vandaag begint te bouwen heeft overigens één voordeel dat de gevestigde partijen niet hebben: je kunt crypto-agility er vanaf dag één in ontwerpen in plaats van er twintig jaar aan legacy doorheen te moeten trekken. Dat is een van de weinige echte greenfield-voordelen op deze laag, en het zou hoog op de eisenlijst moeten staan van iedereen die zo’n bouw overweegt.

En de keten eronder blijft staan. Elke VM en elke node die je uitdeelt, draait op de hardware uit deel 3. Elke soevereine kerndienst is een Europese software‑laag op een niet‑Europees fundament. Dat maakt de software‑laag niet waardeloos maar SOV‑5 laat zich hier niet repareren.

De toeleveringsketen bij het exploiteren

Hier zit de echte rekening, en het is dezelfde als in deel 4: niet de bouw maar de operatie.

Klanten gebruiken de cloud niet alleen voor de functionaliteit, maar ook voor de betrouwbaarheid. Dat gaat niet alleen over dat de operatie ervoor zorgt dat er zelden onderbrekingen zijn in de dienstverlening, maar ook over de stabiliteit van hoe klanten diensten afnemen. Belangrijk daarbij is van belang hoelang diensten beschikbaar blijven en interfaces daarvan onveranderd blijven. Voor kerndiensten speelt dit nog meer dan voor meer experimentele diensten of diensten gericht op een veld waar de ontwikkelingen zich in een enorm tempo opvolgen (zoals momenteel AI).

Voor Kubernetes komt er een bijzonderheid bij die de andere diensten niet hebben: je bent niet de baas over je eigen releasekalender. Het upstream-project bepaalt het tempo, en jij mag volgen. Dat is de prijs van een open standaard, en het is een prijs die je alleen kunt betalen met een team dat structureel meedraait in dat project in plaats van er alleen uit consumeert. Doordat AI nu met grote regelmaat en snelheid gaten vindt in bestaande software maakt dit nog complexer, omdat je vaker met een zero-day lek geconfronteerd kan worden.

Daarnaast draagt deze laag de certificeringslast uit deel 4 door naar buiten. ISO 27001, SOC, PCI‑DSS en de rest gelden per dienst, niet per bedrijf. Elke nieuwe kerndienst moet die molen door en daarna periodiek opnieuw. Dat is geen bijkomstigheid maar een vaste, aanzienlijke kostenpost die schaal nodig heeft om betaalbaar te blijven.

En dan is er portabiliteit, in mijn ogen het meest onderschatte soevereiniteitsinstrument van deze hele laag. Een aantoonbare exit binnen redelijke tijd doet voor werkelijke soevereiniteit meer dan de meeste herkomstvereisten: het maakt van “wie kan mijn diensten uitzetten” een vraag met een antwoord in plaats van een angst. Gelukkig wordt een geteste exit steeds vaker een onderdeel van aanbestedingen en dit is mijns inziens een belangrijker vraag dan die van herkomst. Want in een oorlogsscenario zou je applicaties misschien wel willen verplaatsen naar een ander continent. Er zijn een aantal initiatieven om een standaard te maken voor kerndiensten, maar behoudens Kubernetes zijn deze nog niet klaar, laat staan algemeen geaccepteerd.

Wat betekent dit voor SEAL‑4?

Dit is de eerste laag in deze serie waar SEAL‑4 niet bij voorbaat onhaalbaar is. Software kun je in Europa schrijven, cryptografie beheersen we, in HSM’s hebben we echte thuisspelers, en met Kubernetes ligt er een open standaard waar geen enkele leverancier eigenaar van is. Wie hier een SEAL‑4‑ambitie neerlegt, vraagt niet het onmogelijke. De keten eronder is waar een groot deel van de uitdaging ligt, want die is grotendeels niet‑Europees en dus is SOV‑5 hier niet volledig af te vinken. De andere uitdaging zit niet in het ontwerp maar in de operatie, de schaal en het tempo, en dat zijn precies de dingen die serieuze investeringen en jaren van arbeid kosten in plaats van een besluit.

En dat brengt ons weer bij hetzelfde advies uit de vorige delen: gebruik het framework niet dogmatisch. Kijk waar een bepaald SEAL niveau echt nodig is, hetgeen aan de ene kant gaat over welke applicaties welk niveau nodig hebben en aan de andere kant over welke delen van de applicatie (inclusief aanpalende functies zoals beveiligingsdiensten) welk niveau nodig hebben. Een applicatie kan vereisen om in omgeving met een hoog SEAL niveau te draaien, maar die kan vaak best gebruik maken van (vervangbare) diensten er omheen zoals een DDoS beveiliging.

In het volgende deel klimmen we opnieuw een laag omhoog, naar de diensten op hoger niveau: databases, messaging, analytics en AI. Dat is de laag waar klanten hun daadwerkelijke voordeel halen, maar ook waar lock‑in echt begint.

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.