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 it is expected to do

The proposal was targeted for the first part of 2026 as a flagship of the Commission Work Programme. The stated objectives are consistent across the announcements:

Strengthen European capacity to develop, deploy and scale cloud and AI. In practice this is about compute, data centres and the ability to train and serve large models within the EU.

Address regulatory gaps. The existing framework treats cloud largely through the Data Act's switching provisions and NIS2's security obligations. Neither addresses capacity or strategic dependency.

Promote interoperability. Reducing the technical cost of moving between providers, which is the same policy objective the Data Act attacks from the contractual side.

Establish an EU-wide cloud policy for public administrations and public procurement. This is the one with teeth. A common approach to how member state public bodies buy cloud, with a European preference dimension.

Support a secure and competitive European cloud and AI ecosystem. The catch-all.

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 announced suggests private companies will be prohibited 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. Whether that satisfies a future procurement rule is precisely the question the Act will have to answer, and it has not answered it yet.

It is a proposal. Until there is a text with Council and Parliament positions around it, the detail is not knowable. What is knowable is the direction, which 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 interoperability 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, watch the procurement track more closely than the Act itself. That is where the requirement will first appear as a qualification criterion.

Do not migrate on speculation. Moving infrastructure because of an unpublished proposal 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.