De Cloud and AI Development Act: wat Europa werkelijk probeert op te lossen

De Cloud and AI Development Act laat duidelijker dan wat ook zien wat het Europese technologiebeleid inmiddels is geworden. Het is geen consumentenbeschermingswet en geen veiligheidswet. Het is industriebeleid, gericht op één probleem: Europa draait het grootste deel van zijn digitale economie op infrastructuur die het niet in handen heeft.

Dat is een ander soort regulering dan de AVG of de AI-verordening, en de wet bereikt u ook via een ander mechanisme. Begrijpen welk mechanisme dat is, levert u meer op dan de overwegingen lezen.

Het probleem waarop de wet reageert

De cijfers erachter worden door niemand betwist. Het overgrote deel van de Europese clouduitgaven gaat naar niet-Europese aanbieders. De grootste AI-modellen die Europese bedrijven gebruiken, worden buiten Europa getraind en gehost. De Europese rekencapaciteit is een fractie van het wereldtotaal.

Tien jaar lang gold dat als een uitkomst van de markt. Sinds 2022 geldt het als een strategische kwetsbaarheid, om redenen die niets met techniek te maken hebben: handelsspanningen, exportcontroles, en het besef dat afhankelijkheid van infrastructuur een drukmiddel is.

De Cloud and AI Development Act is de wetgevende arm van die herwaardering. Hij staat naast het actieplan voor het AI-continent, het InvestAI-initiatief, het programma voor AI-gigafabrieken en de bredere agenda voor concurrentievermogen die uit het Draghi-rapport is voortgekomen.

Wat het voorstel doet

De Commissie publiceerde het voorstel op 3 juni 2026 als COM(2026) 502, samen met een Chips Act 2.0. Het is een verordening, opgebouwd rond drie doelen en een reeks maatregelen voor de publieke sector:

Onderzoek en innovatie. Cloud and AI Leadership Initiatives voor grote sectoroverstijgende projecten, een netwerk van AI Experience and Acceleration Centres dat voortbouwt op de Europese digitale-innovatiehubs, rekenkracht voor prioritaire frontier-AI-projecten, en een nationale cloud- en AI-strategie in elke lidstaat binnen een jaar na de inwerkingtreding.

Datacentercapaciteit. Lidstaten wijzen versnellingsgebieden voor datacenters aan, met één centraal informatiepunt en snellere vergunningverlening, en de Commissie kan strategische datacenterprojecten aanwijzen. Het gestelde doel is de datacentercapaciteit van de EU tegen 2030 minstens te verdrievoudigen, waarbij elke vergunning voor een nieuw datacenter binnen 18 maanden te krijgen moet zijn.

Een soevereiniteitskader voor cloud. Vier zekerheidsniveaus van de Unie. Niveau 1 is een zelfbeoordeling; niveaus 2 tot en met 4 worden door derden geaudit. Niveau 3 vereist dat de aanbieder niet vanuit een derde land wordt gecontroleerd, tenzij de Commissie heeft erkend dat dat land voldoende waarborgen biedt. Erkende diensten komen in een centraal EU-register.

Gebruik door de publieke sector. Dit is het onderdeel met echte doorzettingsmacht. Overheidsinkopers moeten clouddiensten afnemen die minstens op niveau 1 erkend zijn. Als een risicobeoordeling uitwijst dat een activiteit bijdraagt aan de openbare orde (onder meer in NIS2-sectoren, nationale veiligheid, defensie, justitie en rechtshandhaving), zijn alleen niveaus 2, 3 of 4 toegestaan. Lidstaten moeten daarnaast criteria voor meerwaarde voor de Unie toepassen wanneer ze cloud en AI inkopen, via een EuroCloud Federation kunnen publieke instanties clouddiensten delen, en publieke instanties moeten het gebruik van open source boven propriëtaire software stimuleren en faciliteren.

Weinig dat private kopers bindt. Bedrijven in NIS2-sectoren kunnen dezelfde risicobeoordeling vrijwillig uitvoeren, en de Commissie zou die via een gedelegeerde handeling verplicht kunnen maken voor zeer kritieke sectoren. Zoals voorgesteld gaat de verordening een jaar na inwerkingtreding gelden, maar ze moet nog door Parlement en Raad.

Via welk mechanisme dit u echt bereikt

Dit is het punt dat u van dit dossier moet begrijpen. De meeste technologieregulering bereikt private bedrijven rechtstreeks: u verwerkt persoonsgegevens, dus geldt de AVG voor u. De Cloud and AI Development Act zal de meeste bedrijven veel eerder indirect bereiken, via de aanbesteding.

De publieke sector in de EU geeft enorme bedragen uit aan technologie. Worden publieke instanties in de lidstaten verplicht of sterk aangemoedigd om Europese cloud te kopen, dan verandert dat het marktpotentieel van elke leverancier die aan de overheid verkoopt, en werkt dat via hoofdaannemers door naar hun toeleveranciers.

Dat patroon kennen we van toegankelijkheid. De Europese toegankelijkheidsrichtlijn kent directe verplichtingen, maar in de praktijk kwam veel toegankelijkheidswerk voort uit aanbestedingsregels die leveranciers zonder conform product uitsloten, ruim voordat de richtlijn van toepassing werd.

Reken hier op hetzelfde. Verkoopt u software aan Europese overheden, dan schuiven vragen over waar uw infrastructuur draait, wie die beheert en of ze te migreren valt op van de beveiligingsvragenlijst naar de geschiktheidscriteria.

Wat dit betekent voor uw architectuur

De eerste reflex bij soevereiniteitsbeleid is het te negeren of in paniek te gaan migreren. Geen van beide is verstandig. Wat wel verstandig is: zorgen dat u de vraag kunt beantwoorden.

Weet waar uw data en rekenkracht werkelijk staan

Dat klinkt triviaal, en dat is het niet. In een volwassen systeem omvat het eerlijke antwoord op "waar draait dit" vaak een primaire regio, een uitwijkregio, een CDN met onduidelijke edgelocaties, een beheerde database, drie SaaS-afhankelijkheden met hun eigen subverwerkers, een observability-leverancier en een AI-API waarvan de inferentielocatie nergens gedocumenteerd staat.

Een kloppende kaart maken is het eerste echte werk, en het is dezelfde kaart die u nodig hebt voor analyse van AVG-doorgiftes en voor de ketenvragen uit NIS2. Doe het één keer goed.

Scheid wat verplaatsbaar is van wat dat niet is

Vrijwel elk systeem heeft een verplaatsbare kern en daarnaast een reeks afhankelijkheden die aan één aanbieder vastzitten. Die kern is meestal de applicatie zelf. Het vastzittende deel bestaat meestal uit beheerde diensten: propriëtaire databases, serverlessruntimes, wachtrijen, identiteit en steeds vaker ook model-API's.

U hoeft die niet weg te werken. U moet wel weten welke het zijn, want die lijst is het eerlijke antwoord op de vraag hoe zwaar een migratie zou uitpakken, en het is ook waar een inkoopvragenlijst in werkelijkheid naar peilt.

Behandel modelaanbieders als een abstractiegrens

Dit punt is het nieuwst en wordt het vaakst overgeslagen. Applicaties die de model-API van één aanbieder rechtstreeks aanroepen, met aanbiederspecifieke promptformaten en responsafhandeling verspreid door de codebase, hebben ongemerkt een beslissing over afhankelijkheid genomen.

Een dunne abstractie over modelaanroepen kost bij de bouw bijna niets en levert u de vrijheid op om te routeren naar een Europese aanbieder, naar een model met open gewichten op Europese infrastructuur, of naar een heel andere partij. Gezien de snelheid waarmee het modellandschap beweegt, is dat op commerciële gronden alleen al de moeite waard.

Test de exit, beschrijf hem niet alleen

De dataverordening geeft u nu al het recht om van cloudaanbieder te wisselen, en per 12 januari 2027 verdwijnen de overstapkosten volledig. Maar weinig afnemers maken van dat recht gebruik, en nog minder testen of de export waar ze recht op hebben hun dienst ook werkelijk weer overeind krijgt.

Voer die export dus uit. Probeer hem te lezen. Precies in het gat tussen wat een aanbieder exporteerbaar noemt en wat bruikbaar is, zit de lock-in, en daar ligt ook het eerlijke antwoord op een soevereiniteitsvraag.

Wat de wet niet is

Enige scepsis is terecht, en u kunt beter nu nuchter kijken dan u later laten verrassen.

Dit is geen verbod op Amerikaanse cloud. Niets in het voorstel verbiedt private bedrijven om niet-Europese aanbieders te gebruiken. Het mechanisme is voorkeur bij inkoop en opbouw van capaciteit, geen verbod.

Capaciteit ontstaat niet doordat een wet dat opschrijft. De Europese cloudcapaciteit is beperkt omdat datacenters bouwen en grensverleggende modellen trainen kapitaalintensief is, en Europa heeft tot voor kort nooit kapitaal op die schaal toegezegd. De financieringsprogramma's uit onze gids voor EU-technologiefinanciering zijn hier het eigenlijke instrument. De wet is het kader eromheen.

Een soevereiniteitslabel is nog geen soevereiniteit. Diverse aanbiedingen presenteren zich als soevereine cloud maar draaien op niet-Europese technologie in licentie, met wisselende gradaties van operationele onafhankelijkheid. Het antwoord van het voorstel zijn de zekerheidsniveaus: controle vanuit een derde land houdt een dienst buiten niveau 3 en hoger, tenzij de Commissie dat land erkent. Waar de grens tussen niveau 2 en 3 uiteindelijk komt te liggen, beslissen de onderhandelingen.

Het is een voorstel. Er ligt nu een tekst, maar op 10 oktober 2026 hebben Raad noch Parlement er een standpunt over, en in het Parlement ligt het dossier nog bij de commissies ITRE en IMCO. De zekerheidsniveaus zijn het deel dat het meest waarschijnlijk nog verschuift. De richting is in drie jaar communicatie vanuit de Commissie niet veranderd.

Hoe dit samenhangt met de rest

De Cloud and AI Development Act is één onderdeel van een gecoördineerde beweging, en wie hem los van de rest leest, schat hem zwakker in dan hij is.

De AI-verordening regelt hoe AI-systemen zich gedragen. De dataverordening pakt cloudlock-in contractueel aan. NIS2 duwt de toetsing van de toeleveringsketen door naar de leveranciers. De verordening cyberweerbaarheid legt beveiligingsplichten op producten. InvestAI en het gigafabriekenprogramma steken geld in rekencapaciteit. De Cloud and AI Development Act voegt daar de laag van inkoop en soevereiniteit aan toe.

Los van elkaar lijkt elk stuk vooral extra last. Bij elkaar beschrijven ze een tamelijk samenhangende gok: dat Europa zich naar een eigen technologiebasis kan reguleren door markttoegangsregels te combineren met publiek geld.

Of die gok uitpakt, is een legitieme vraag. Dát hij gemaakt wordt, staat niet ter discussie.

Wat u de komende twaalf maanden kunt doen

Maak de infrastructuurkaart. Waar draait alles, wie beheert het, en wat is contractueel het pad naar buiten. Die kaart heeft nog vier andere toepassingen.

Breng in kaart welke afhankelijkheden echt niet te verplaatsen zijn en zet er een eerlijk prijskaartje op, ook als u nooit gaat migreren. Dat is het antwoord op de inkoopvraag en het is sowieso goede architectuurhygiëne.

Leg een abstractielaag over uw modelaanbieders als die er nog niet is. Nu goedkoop, later duur, en nuttig om redenen die niets met beleid te maken hebben.

Verkoopt u aan Europese overheden, zoek dan uit welk zekerheidsniveau uw dienst zou kunnen halen. In de inkoopregels van de wet zou de eis het eerst opduiken, als geschiktheidscriterium, en de Public Procurement Act die op 9 september 2026 is voorgesteld, legt daar een algemeen kader voor Europese voorkeur bovenop.

Migreer niet op basis van speculatie. Infrastructuur verplaatsen vanwege een voorstel waarover nog niemand heeft onderhandeld, is de manier waarop organisaties een jaar en een fors budget kwijtraken aan iets wat achteraf helemaal niet hoefde.

Hulp krijgen

Wij ontwerpen en bouwen cloudinfrastructuur, dataplatforms en AI-integraties voor bedrijven die in Europa actief zijn, inclusief het weinig spectaculaire werk om een systeem echt verplaatsbaar te maken in plaats van alleen op papier.

Hebt u een infrastructuur- en afhankelijkheidskaart nodig, een exittest bij uw huidige aanbieder of een abstractielaag over modelaanbieders, schrijf dan naar office@c9group.dev. Meer over ons infrastructuurwerk op de pagina AWS-kostenoptimalisatie en over ons Europese werk op de pagina EU-markttoetreding.

Het bredere wetgevende beeld staat in onze EU-wetgevingspijplijn, en het geld achter deze agenda is in kaart gebracht in onze gids voor EU-technologiefinanciering.

Wij zijn ingenieurs en geen beleidsadviseurs. Dit is een planningsbeeld van een voorstel, geen juridisch advies.