Cloud and AI Development Act: vad Europa egentligen försöker lösa

Cloud and AI Development Act är det hittills tydligaste beviset på vad europeisk teknikpolitik har blivit. Det är ingen konsumentskyddslag och ingen säkerhetslag. Det är industripolitik riktad mot ett enda problem: Europa driver större delen av sin digitala ekonomi på infrastruktur som Europa inte kontrollerar.
Det är en annan sorts reglering än dataskyddsförordningen (GDPR) eller AI-förordningen (AI Act), och den kommer att nå dig genom en annan mekanism. Att förstå vilken mekanism är viktigare än att läsa skälen i ingressen.
Problemet förslaget svarar på
Siffrorna bakom det här ifrågasätts inte av någon. Den överväldigande delen av Europas utgifter för molninfrastruktur går till icke-europeiska leverantörer. De största AI-modellerna som europeiska företag använder tränas och driftas utanför Europa. Europas beräkningskapacitet är en liten bråkdel av den globala.
I ett decennium sågs det som ett marknadsutfall. Sedan 2022 har det setts som en strategisk sårbarhet, av skäl som inte har med teknik att göra: handelsspänningar, exportkontroller och insikten att beroende av infrastruktur är ett påtryckningsmedel.
Cloud and AI Development Act är lagstiftningsdelen av den omprövningen. Den hör ihop med AI Continent Action Plan, initiativet InvestAI, programmet för AI-gigafabriker och den bredare konkurrenskraftsagendan som kom ur Draghirapporten.
Vad förslaget gör
Kommissionen publicerade förslaget den 3 juni 2026 som COM(2026) 502, tillsammans med en Chips Act 2.0. Det är en förordning, uppbyggd kring tre mål och en uppsättning åtgärder för offentlig sektor:
Forskning och innovation. Cloud and AI Leadership Initiatives för stora sektorsövergripande projekt, ett nätverk av AI Experience and Acceleration Centres som bygger på de europeiska digitala innovationsnaven (European Digital Innovation Hubs), beräkningskapacitet som fördelas till prioriterade projekt inom spjutspets-AI, och en nationell moln- och AI-strategi i varje medlemsstat inom ett år från ikraftträdandet.
Kapacitet i datacenter. Medlemsstaterna utser accelerationszoner för datacenter med en gemensam informationspunkt och snabbare tillståndsprövning, och kommissionen kan utse strategiska datacenterprojekt. Det uttalade målet är att åtminstone tredubbla EU:s datacenterkapacitet till 2030, och att varje tillstånd för ett nytt datacenter ska kunna fås på under 18 månader.
Ett suveränitetsramverk för moln. Fyra säkerhetsnivåer på unionsnivå (Union assurance levels). Nivå 1 är en självbedömning; nivå 2 till 4 granskas av tredje part. Nivå 3 kräver att leverantören inte kontrolleras från ett tredjeland, om inte kommissionen har erkänt att det landet ger tillräckliga garantier. Erkända tjänster förs in i ett centralt EU-register.
Användning i offentlig sektor. Det är här det biter. Offentliga köpare måste upphandla molntjänster som är erkända på minst nivå 1. Där en riskbedömning visar att en verksamhet bidrar till allmän ordning (bland annat i NIS2-sektorer, nationell säkerhet, försvar, rättsväsende och brottsbekämpning) är bara nivå 2, 3 eller 4 tillåtna. Medlemsstaterna måste också tillämpa kriterier för europeiskt mervärde (Union added value) när de köper moln och AI, en EuroCloud Federation låter offentliga organ dela molntjänster, och offentliga organ ska uppmuntra och underlätta användning av öppen källkod framför proprietär programvara.
Lite som binder privata köpare. Företag i NIS2-sektorer får göra samma riskbedömning frivilligt, och kommissionen skulle genom en delegerad akt kunna göra den obligatorisk för mycket kritiska sektorer. Enligt förslaget ska förordningen börja tillämpas ett år efter ikraftträdandet, men den måste fortfarande gå igenom parlamentet och rådet.
Mekanismen som faktiskt kommer att nå dig
Här är det som är värt att förstå med det här ärendet. Det mesta av teknikregleringen når privata företag direkt: du behandlar personuppgifter, alltså gäller GDPR för dig. Cloud and AI Development Act kommer mycket mer sannolikt att nå de flesta företag indirekt, via upphandling.
Den offentliga sektorns teknikutgifter i EU är enorma. Om offentliga organ i medlemsstaterna åläggs eller kraftigt uppmuntras att köpa europeiska molntjänster förändrar det den adresserbara marknaden för varje leverantör som säljer till offentlig sektor, och det sprider sig nedåt via huvudleverantörerna till deras underleverantörer.
Mönstret känns igen från tillgänglighet. Tillgänglighetsdirektivet (European Accessibility Act) har direkta skyldigheter, men en stor del av tillgänglighetsarbetet drevs i praktiken av regler för offentlig upphandling som uteslöt leverantörer som inte uppfyllde kraven långt innan direktivet började gälla.
Räkna med samma sak här. Om du säljer programvara till europeiska offentliga köpare kommer frågor om var din infrastruktur körs, vem som kontrollerar den och om den går att migrera att flytta från säkerhetsformuläret in i kvalificeringskraven.
Vad det betyder för arkitekturen
Den instinktiva reaktionen på en suveränitetspolicy är antingen att ignorera den eller att migrera i panik. Inget av det är rätt. Det rimliga är att se till att frågan går att besvara.
Vet var dina data och din beräkningskapacitet faktiskt finns
Det låter trivialt och är det inte. I ett moget system innehåller det ärliga svaret på ”var körs det här” ofta en primär region, en reservregion, ett CDN med oklara edge-platser, en hanterad databas, tre SaaS-beroenden med egna underbiträden, en leverantör för observerbarhet och ett AI-API vars inferensplats inte är dokumenterad.
Att bygga en korrekt karta är det första verkliga arbetet, och det är samma karta som du behöver för GDPR-analysen av överföringar och för NIS2-frågor om leveranskedjan. Gör det en gång.
Skilj det som går att flytta från det som inte gör det
Nästan varje system har en flyttbar kärna och en uppsättning leverantörsspecifika beroenden. Den flyttbara kärnan är oftast applikationen. De delar som inte går att flytta är oftast hanterade tjänster: proprietära databaser, serverlösa körmiljöer, köer, identitet och i allt högre grad modell-API:er.
Du behöver inte göra dig av med dem. Men du måste veta vilka de är, eftersom den listan är det ärliga svaret på hur svår en migrering skulle vara, och det är vad ett upphandlingsformulär egentligen frågar efter.
Behandla modellleverantörer som en abstraktionsgräns
Det här är den nyaste punkten och den som oftast hoppas över. Applikationer som anropar en enda leverantörs modell-API direkt, med leverantörsspecifika promptformat och svarshantering utspridda i kodbasen, har fattat ett beslut om beroende utan att märka det.
Ett tunt abstraktionslager över modellanropen kostar väldigt lite när du bygger det och ger dig möjligheten att styra trafiken till en europeisk leverantör, en modell med öppna vikter på europeisk infrastruktur eller en helt annan leverantör. Med tanke på hur snabbt modellandskapet rör sig är det värt att göra enbart av affärsmässiga skäl.
Testa utgången, dokumentera den inte bara
Dataförordningen (Data Act) ger dig redan rätt att byta molnleverantör, och avgifterna för byte försvinner helt från 12 januari 2027. Mycket få köpare använder den rätten, och ännu färre testar om den export de har rätt till faktiskt skulle kunna återskapa deras tjänst.
Kör exporten. Försök tolka den. Glappet mellan vad en leverantör säger går att exportera och vad som går att använda är där inlåsningen finns, och det är också det ärliga svaret på en suveränitetsfråga.
Vad förslaget inte är
En viss sund skepsis är befogad, och det är bättre att se klart nu än att bli överraskad senare.
Det är inget förbud mot amerikanska molntjänster. Ingenting i förslaget hindrar privata företag från att använda icke-europeiska leverantörer. Mekanismen är upphandlingspreferenser och kapacitetsuppbyggnad, inte förbud.
Kapacitet uppstår inte för att en lag säger det. Den europeiska molnkapaciteten är begränsad eftersom det kräver mycket kapital att bygga datacenter och träna spjutspetsmodeller, och Europa har fram till nyligen inte satsat kapital i den omfattning som krävs. Finansieringsprogrammen som vi går igenom i vår guide till EU:s teknikfinansiering är det faktiska verktyget här. Lagen är ramen runt dem.
Suveräna etiketter är inte suveränitet. Flera upplägg marknadsför sig som suveränt moln samtidigt som de kör på icke-europeisk teknik under licens, med varierande grad av operativt oberoende. Förslagets svar är säkerhetsnivåerna: kontroll från ett tredjeland håller en tjänst utanför nivå 3 och uppåt, om inte kommissionen erkänner det landet. Var gränsen mellan nivå 2 och 3 till slut hamnar är vad förhandlingarna kommer att avgöra.
Det är ett förslag. Det finns nu en text, men per 10 oktober 2026 har varken rådet eller parlamentet någon ståndpunkt, och i parlamentet ligger ärendet fortfarande hos utskotten ITRE och IMCO. Säkerhetsnivåerna är den del som mest sannolikt kommer att ändras. Riktningen har varit konsekvent i tre års kommunikation från kommissionen.
Hur det hänger ihop med allt annat
Cloud and AI Development Act är en del av en samordnad satsning, och läser man den isolerat ser den svagare ut än den är.
AI-förordningen (AI Act) reglerar hur AI-system beter sig. Dataförordningen (Data Act) angriper inlåsning i molnet genom avtalen. NIS2 driver granskningen av leveranskedjan nedåt via leverantörerna. Cyberresiliensförordningen (Cyber Resilience Act) lägger säkerhetskrav på produkter. InvestAI och programmet för gigafabriker satsar pengar på beräkningskapacitet. Cloud and AI Development Act lägger till lagret för upphandling och suveränitet.
Var för sig ser de ut som en stegvis ökande börda. Tillsammans beskriver de en ganska sammanhängande satsning: att Europa kan reglera sig fram till en egen teknikbas genom att kombinera regler för marknadstillträde med offentliga pengar.
Om satsningen fungerar är en befogad fråga. Att den görs är det inte.
Vad du ska göra de närmaste tolv månaderna
Bygg infrastrukturkartan. Var körs allt, vem driftar det, vilken är den avtalsenliga vägen ut. Kartan har fyra andra användningsområden.
Identifiera dina beroenden som verkligen inte går att flytta och räkna ärligt på vad migreringen skulle kosta, även om du aldrig genomför den. Det är svaret på upphandlingsfrågan och dessutom helt enkelt god arkitekturhygien.
Lägg ett abstraktionslager över modellleverantörerna om du inte redan har gjort det. Billigt nu, dyrt senare, och användbart av skäl som inte har med politik att göra.
Om du säljer till europeisk offentlig sektor, ta reda på vilken säkerhetsnivå din tjänst skulle kunna nå. Upphandlingsreglerna i förslaget är där kravet först skulle dyka upp som ett kvalificeringskriterium, och Public Procurement Act som föreslogs den 9 september 2026 lägger ett generellt ramverk för europeisk preferens ovanpå.
Migrera inte på spekulation. Att flytta infrastruktur på grund av ett förslag som ingen ännu har förhandlat om är hur organisationer lägger ett år och en stor budget på något som visar sig inte ha krävts.
Få hjälp
Vi designar och bygger molninfrastruktur, dataplattformar och AI-integrationer för företag som verkar i Europa, inklusive det oglamorösa arbetet med att göra ett system ärligt flyttbart i stället för flyttbart på papperet.
Om du behöver en karta över infrastruktur och beroenden, ett utgångstest mot din nuvarande leverantör eller ett abstraktionslager över modellleverantörer, skriv till office@c9group.dev. Mer om vårt infrastrukturarbete finns på sidan om kostnadsoptimering i AWS och om vårt europeiska arbete på sidan om etablering på EU-marknaden.
Den bredare lagstiftningsbilden finns i vår översikt över kommande digital lagstiftning i EU, och pengarna bakom agendan kartläggs i vår guide till EU:s teknikfinansiering.
Vi är ingenjörer, inte policyrådgivare. Det här är en planeringsbild av ett förslag, inte juridisk rådgivning.
Data och moln
Nya guider och regeländringar via mejl
När en regel ändras, en deadline flyttas eller vi publicerar en ny guide skickar vi det till dig via mejl.