Skip to Content

Why European industry needs the Cloud and AI Development Act to succeed

For the first time, "sovereign cloud" would have a binding legal definition instead of a marketing one. That is worth more to European buyers than to European providers.

Ask five cloud providers whether they are sovereign and you will get five yes answers and no way to compare them. The word currently means whatever the marketing department needs it to mean: data stored in the EU, or a European subsidiary of a foreign parent, or a contractual promise that nobody will look at your data. These are wildly different things, and today a public buyer has no common yardstick to tell them apart.

The Cloud and AI Development Act would replace that word with four measurable levels and tie them to who gets to bid for public contracts. We are a European provider, so we have an obvious interest in this passing. The argument stands on its own, and we will also say where we think the proposal could go wrong.

What is actually on the table

The European Commission published the proposal on 3 June 2026, as the centrepiece of its technological sovereignty package. It rests on three pillars - research and innovation, capacity, and autonomy - and two of its mechanisms matter to anyone buying or selling infrastructure in Europe.

Capacity. The stated goal is to at least triple the EU's data centre capacity within five to seven years, supported by faster permitting: acceleration zones for data centre projects and a twelve-month "green corridor" for approvals. Whatever one thinks of the sovereignty debate, the physical constraint is real. AI workloads are limited today by buildings, power connections and cooling, not by ambition.

Assurance levels. The proposal defines four levels of assurance, from L1 to L4, and lets public bodies require a level appropriate to the risk of what they are buying:

Level In short
L1 Infrastructure, assets and customer data in the EU; self-assessment plus state-of-the-art security; the provider must not be obliged to report vulnerabilities to a foreign authority.
L2 All operational staff, infrastructure and assets in the EU; EU cloud certification; no third-country access to data.
L3 The provider must not be controlled from a third country, with derogations only for countries holding an EU adequacy decision; EU ownership and control, plus criteria such as staff nationality.
L4 No third-country control, without derogation; European cybersecurity certification at "high"; effective control over all software components; vetted personnel; no AI inference data leaving the EU; third-party audit verified by national authorities.

The distribution matters more than the top level. Estimates suggest around 70 % of public data contracts would fall under L1, and roughly 1 % - mainly defence - under L4. This is not a plan to exclude foreign providers from the European market. It is a plan to make the question answerable.

Why a buyer should want this

Because "sovereign" is currently unfalsifiable. A procurement officer who wants EU-only data handling has to invent their own criteria, write them into a tender, and then evaluate answers that were written by people better at tenders than they are. Every authority does this independently, badly, and differently. A common set of levels turns a debate into a checkbox with an audit behind it.

Because comparison is impossible without a shared scale. Today a bid from a European operator and a bid from a European subsidiary of a foreign hyperscaler look similar on paper and differ enormously in what happens when a foreign court issues an order. That difference should be visible before signing, not discovered afterwards.

Because capacity determines price. A market where European buyers have realistic alternatives is a market where the incumbents' pricing is disciplined by something other than goodwill. That benefits buyers who never leave a hyperscaler at all.

Why a provider should want it, and why that is not the strongest argument

For a company like ours the appeal is obvious: clear rules reward operators who already run their own infrastructure in Europe, and make it harder to win a "sovereign" contract with a press release. We are not going to pretend otherwise.

But self-interest is a weak argument, so here is the better one. What European providers actually lack is not protection - it is predictability. Building data centre capacity is a decade-long capital commitment. Nobody makes that commitment against a definition of sovereignty that changes with each tender and each political cycle. A binding framework is what turns "Europe should have its own capacity" into something a finance committee can approve.

Where it could go wrong

Being in favour of a regulation is not the same as being uncritical of it, and three risks are worth naming.

It could become origin labelling instead of technical substance. Industry critics warn that origin-based restrictions risk fragmenting the market and shutting out trustworthy foreign providers. That criticism has force precisely where the levels rely on ownership structure rather than verifiable technical control. The tiers are only worth having if what they certify is demonstrable - who can access which system, where keys are held, which components can be audited - rather than which flag is on the parent company.

It could price out the companies it is supposed to help. If reaching a level requires a certification regime affordable only to large operators, the framework will consolidate the European market rather than diversify it. Audit and certification costs need a path that a fifty-person provider can actually walk.

It could be diluted into self-declaration. The assurance levels are expected to be the main battleground in the negotiations ahead. A level that anyone can claim on their own say-so is worse than no level at all, because it launders marketing claims into regulatory language.

There is also plenty still undefined: the thresholds behind the levels are to be worked out during the legislative process, and the file is a proposal, not law. The indicative target for adoption is late 2027.

What we are not claiming

We are not going to tell you which level Cybermindnet would reach. The criteria are not final, self-assessment against a moving draft is worth nothing, and a provider announcing its own tier before the standard exists is doing exactly the thing this regulation is meant to stop.

What we can tell you is what is true today, independently of any regulation: we operate our own Kubernetes clusters, our own ERP, our own identity provider and our own mail infrastructure, on servers in the EU, on open-source components you could run yourself. That was our answer before CADA and it will be our answer afterwards. The value of the Act, for us, is that it would let a buyer verify such a claim instead of taking it on trust.

What happens next

The proposal now goes through the ordinary legislative procedure - Parliament and Council each form a position before negotiating a final text. The assurance framework is where the substantive fight will be, and the outcome will decide whether European buyers get a usable instrument or another vocabulary.

If you are a public buyer, this is the moment to look at how your current contracts would map onto the levels. If you are a provider, it is the moment to find out which requirements you would fail today. Either way, the answer takes longer to produce than the deadline will allow if you start when the rules are final.

Happy to compare notes - info@cybermindnet.eu.

We sell operations, not installation - what running your cluster actually looks like
Three backup layers, alerts for the failures that really take services down, and storage sized so it can still grow.