The Cloud and AI Development Act: What Europe Is Actually Trying to Fix

The Cloud and AI Development Act is the clearest statement yet of what European technology policy has become. It is not a consumer protection law and it is not a safety law. It is industrial policy aimed at a single problem: Europe runs most of its digital economy on infrastructure it does not control.

That is a different kind of regulation from GDPR or the AI Act, and it will reach you through a different mechanism. Understanding which mechanism matters more than reading the recitals.

The problem it is responding to

The numbers behind this are not disputed by anyone. The overwhelming majority of European cloud infrastructure spend goes to non-European providers. The largest AI models used by European companies are trained and hosted outside Europe. European compute capacity is a small fraction of the global total.

For a decade this was treated as a market outcome. Since 2022 it has been treated as a strategic vulnerability, for reasons that have nothing to do with technology: trade tension, export controls, and the discovery that infrastructure dependency is leverage.

The Cloud and AI Development Act is the legislative arm of that reassessment. It sits alongside the AI Continent Action Plan, the InvestAI initiative, the AI gigafactories programme and the wider competitiveness agenda that came out of the Draghi report.

What the proposal does

The Commission published the proposal on 3 June 2026 as COM(2026) 502, together with a Chips Act 2.0. It is a Regulation, built around three objectives and a set of public sector measures:

Research and innovation. Cloud and AI Leadership Initiatives for large cross-sector projects, a network of AI Experience and Acceleration Centres built on the European Digital Innovation Hubs, compute allocated to frontier AI priority projects, and a national cloud and AI strategy in every member state within a year of entry into force.

Data centre capacity. Member states designate data centre acceleration zones with a single information point and faster permitting, and the Commission can designate strategic data centre projects. The stated aim is to at least triple EU data centre capacity by 2030, with every permit for a new data centre obtainable in under 18 months.

A sovereignty framework for cloud. Four Union assurance levels. Level 1 is a self-assessment; levels 2 to 4 are audited by third parties. Level 3 requires that the provider is not controlled from a third country, unless the Commission has recognised that country as offering sufficient guarantees. Recognised services go into a central EU repository.

Public sector adoption. This is the one with teeth. Public buyers must procure cloud services recognised at level 1 at least. Where a risk assessment finds that an activity contributes to public order (in NIS2 sectors, national security, defence, justice and law enforcement, among others), only levels 2, 3 or 4 are allowed. Member states must also apply Union added value criteria when they buy cloud and AI, a EuroCloud Federation lets public bodies share cloud services, and public bodies must encourage and facilitate the use of open source over proprietary software.

Little that binds private buyers. Companies in NIS2 sectors may run the same risk assessment voluntarily, and the Commission could make it compulsory for highly critical sectors by delegated act. As proposed, the Regulation would apply one year after entry into force, but it still has to pass Parliament and Council.

The mechanism that will actually reach you

Here is the thing worth understanding about this file. Most technology regulation reaches private companies directly: you process personal data, therefore GDPR applies to you. The Cloud and AI Development Act is much more likely to reach most companies indirectly, through procurement.

Public sector technology spend in the EU is enormous. If member state public bodies are required or strongly encouraged to buy European cloud, that changes the addressable market for every vendor selling into the public sector, and it cascades down through prime contractors to their suppliers.

The pattern is familiar from accessibility. The European Accessibility Act has direct obligations, but a great deal of accessibility work in practice was driven by public procurement rules that excluded non-compliant suppliers long before the directive applied.

Expect the same here. If you sell software to European public buyers, questions about where your infrastructure runs, who controls it and whether it can be migrated will move from the security questionnaire into the qualification criteria.

What this means for architecture

The instinct when reading a sovereignty policy is either to ignore it or to panic-migrate. Neither is right. What is reasonable is to make sure the question is answerable.

Know where your data and compute actually are

This sounds trivial and is not. In a mature system, the honest answer to "where does this run" often involves a primary region, a backup region, a CDN with unclear edge locations, a managed database, three SaaS dependencies with their own subprocessors, an observability vendor, and an AI API whose inference location is not documented.

Building an accurate map is the first piece of real work, and it is the same map you need for GDPR transfer analysis and for NIS2 supply chain questions. Do it once.

Separate the parts that are portable from the parts that are not

Almost every system has a portable core and a set of provider-specific dependencies. The portable core is usually the application. The non-portable parts are usually managed services: proprietary databases, serverless runtimes, queueing, identity, and increasingly model APIs.

You do not have to eliminate those. You do have to know which ones they are, because that list is the honest answer to how hard a migration would be, and it is what a procurement questionnaire is actually asking about.

Treat model providers as an abstraction boundary

This is the newest and most commonly skipped one. Applications that call a single vendor's model API directly, with vendor-specific prompt formats and response handling scattered through the codebase, have made a dependency decision without noticing.

A thin abstraction over model calls costs very little when you build it and buys you the ability to route to a European provider, an open-weights model on European infrastructure, or a different vendor entirely. Given how quickly the model landscape moves, that is worth doing on commercial grounds alone.

Test the exit, do not just document it

The Data Act already gives you a right to switch cloud providers, with switching charges disappearing entirely from 12 January 2027. Very few buyers use that right, and even fewer test whether the export they are entitled to would actually reconstitute their service.

Run the export. Try to interpret it. The gap between what a provider says is exportable and what is usable is where lock-in lives, and it is also the honest answer to a sovereignty question.

What it is not

Some sensible scepticism is warranted, and it is better to be clear-eyed now than surprised later.

This is not a ban on American cloud. Nothing in the proposal prohibits private companies from using non-European providers. The mechanism is procurement preference and capacity building, not prohibition.

Capacity does not appear because a law says so. European cloud capacity is limited because building data centres and training frontier models is capital-intensive and Europe has not committed capital at the required scale until recently. The funding programmes discussed in our EU technology funding guide are the actual instrument here. The Act is the framework around them.

Sovereign labels are not sovereignty. Several arrangements market themselves as sovereign cloud while running on non-European technology under licence, with varying degrees of operational independence. The proposal's answer is the assurance levels: control from a third country keeps a service out of level 3 and above, unless the Commission recognises that country. Where the line between levels 2 and 3 finally falls is what the negotiations will decide.

It is a proposal. There is now a text, but as of 10 October 2026 neither Council nor Parliament has a position on it, and in Parliament the file is still with the ITRE and IMCO committees. The assurance levels are the part most likely to move. The direction has been consistent across three years of Commission communication.

How this connects to everything else

The Cloud and AI Development Act is one piece of a coordinated push, and reading it in isolation makes it look weaker than it is.

The AI Act regulates how AI systems behave. The Data Act attacks cloud lock-in contractually. NIS2 pushes supply chain scrutiny down through vendors. The Cyber Resilience Act puts security obligations on products. InvestAI and the gigafactories programme put money into compute capacity. The Cloud and AI Development Act adds the procurement and sovereignty layer.

Individually each looks like an incremental burden. Together they describe a fairly coherent bet: that Europe can regulate its way to a domestic technology base by combining market access rules with public money.

Whether that bet works is a legitimate question. That it is being placed is not.

What to do in the next twelve months

Build the infrastructure map. Where does everything run, who operates it, what is the contractual exit path. This has four other uses.

Identify your genuinely non-portable dependencies and price the migration honestly, even if you never do it. This is the answer to the procurement question and it is also just good architectural hygiene.

Put an abstraction over model providers if you have not. Cheap now, expensive later, and useful for reasons unrelated to policy.

If you sell to European public sector buyers, work out which assurance level your service could reach. The procurement rules in the Act are where the requirement would first appear as a qualification criterion, and the Public Procurement Act proposed on 9 September 2026 adds a general European preference framework on top.

Do not migrate on speculation. Moving infrastructure because of a proposal nobody has negotiated yet is how organisations spend a year and a large budget on something that turns out not to have been required.

Getting help

We design and build cloud infrastructure, data platforms and AI integrations for companies operating in Europe, including the unglamorous work of making a system honestly portable rather than nominally portable.

If you need an infrastructure and dependency map, an exit test against your current provider, or an abstraction layer over model providers, write to office@c9group.dev. More about our infrastructure work on the AWS cost optimisation page and our European work on the EU market entry page.

The broader legislative picture is in our EU digital law pipeline, and the money behind this agenda is mapped in our EU technology funding guide.

We are engineers rather than policy advisers. This is a planning view of a proposal, not legal advice.