The familiar case for an EU private cloud, in contrast to a US-based hyperscaler, is jurisdictional, and it is a very strong one: Under the CLOUD Act, a US-based provider can be legally compelled to deliver the data whatever its storage location. We detail that argument at length in our article about the sovereign AI mandate.
The present piece concerns the other case, the one that gets less attention and is harder to shrug off, because it relies on nothing about US law.
Putting Europe’s most sensitive computing into a small number of regions run by foreign companies is a precarious setup in its own right. It turns out that the legal issue and the engineering issue are identical problems, viewed from two different angles, and each one counsels against centralization.
Concentration is a single point of failure
Start with reliability, as that is the aspect of the argument that people say everyone took into account but few people have. On 19 and 20 October 2025, a race condition in the automated domain-name system management that is behind AWS’s DynamoDB spread to US-EAST-1 and brought down large parts of the internet, from services such as Snapchat and Slack to those for banking and government, for most of a day.
Outage-tracking sites registered more than 17 million reports of incidents worldwide over some 15 hours. Months later, on 7 May 2026, US-EAST-1 was again out; this time, because of a thermal incident in a single availability zone, knocking services from Coinbase to FanDuel and to CME offline for hours. Same region, different root cause.
The telling aspect of both incidents is who got caught in the collapse. At least four major US-EAST-1 incidents have taken place in recent years, following similar outages in 2020 and 2021, and analysts have repeatedly called out the risk of concentration as a source of systemic danger that people frequently ignore.
Some teams, which had followed the rules by spreading deployments across availability zones just as advised, were still taken offline because basic global services require that one region be available, even for assets located elsewhere. And in the May incident, the availability-zone redundancy was of no use whatsoever to those whose latency-sensitive systems were built to run in one zone alone.
You can do everything right within your own layer if your control plane is centralised, but that does not necessarily help you. That is the very nature of a single point of failure: It is built in, not a mistake that can be fixed.
The same shape shows up in the legal exposure
Now notice that the legal risk has exactly this shape. A US-parented provider concentrates not just technical dependency but legal exposure, because the entity that can be compelled sits upstream of wherever your data physically rests. This is why an EU region is not the reassurance people hope it is.
In June 2025, Microsoft’s French legal director told the French Senate under oath that the company could not guarantee French customer data would be shielded from US authorities, even data held in the EU. The hyperscalers now concede the point on the record.
Sovereignty-washing, and why Europe stopped believing it
The reaction from the industry was a series of so-called sovereign tiers: Regions with an EU presence, billing that is limited to the EU, operations staffed entirely by EU citizens, and separate corporate entities. In Europe’s cloud industry, the concept has a crude label.
In March 2026, the chair of the industry association, the Cloud Infrastructure Services Providers in Europe, and 24 cloud-company chief executives wrote to the Commission to warn against “sovereignty-washing” and to urge that sovereignty be measured in terms of control rather than mere location in the EU because anything less precise would entrench the incumbents it is intended to weaken.
The “sovereign” tiers, to be sure, entail genuine technical disconnection, the sort that requires a team of engineers to build. The trouble is that they miss the point. Sovereignty is about the power of the parent company of the organisation to produce the data, not where the data is, and a subsidiary of an American corporation fails that test even if the organisation looks European.
Operational sovereignty versus legal sovereignty
The useful distinction, now entering EU policy, is between operational and legal sovereignty. Operational sovereignty means the service is run locally, with local controls. Legal sovereignty means the risk of foreign compulsion is removed through ownership and governance. A hyperscaler’s EU region delivers the first and structurally cannot deliver the second. An EU private cloud whose parent and operations both sit inside the bloc is one of the few architectures that delivers both.
Europe has stopped treating this as rhetoric. On 3 June 2026, the Commission proposed the Cloud and AI Development Act, its first legislative proposal aimed specifically at cloud and AI, built around a sovereignty framework with four assurance levels:
- Level 1 asks only that data be processed and stored within the EU.
- Level 2 adds demonstrated independence from third-country law and transparency over the software supply chain.
- Level 3 requires EU ownership and control, with citizenship criteria for the staff.
- Level 4, for the most sensitive workloads such as defence, demands full supply-chain control and no third-country interference.
The framework is a proposal rather than law for now, still to pass through Parliament and Council, and it is explicitly modelled on France’s SecNumCloud regime. Its intent is clear all the same: it encodes the exact distinction the hyperscalers’ marketing tries to blur, moving sovereignty from a claim a vendor can self-certify into a property a buyer can check against an architecture.
The Commission has already run a live test, awarding an €180 million sovereign cloud tender in April 2026 under explicit sovereignty criteria for the first time, and its proposed procurement rules would keep non-compliant providers out of the most sensitive public contracts.
Sovereignty as a design choice, not a purchase
None of this means unplugging from AWS, Azure and Google Cloud, which together hold around two-thirds of the European market and are not going anywhere. The honest position is narrower and more useful: not every workload needs the top tier.
A public marketing site has different requirements from a system handling biometric or health data, and defaulting everything to the cheapest hyperscaler region without a decision is the actual mistake. Sovereignty is a spectrum, and the necessary degree is a per-workload engineering choice.
That reframes the comparison. The question is less “hyperscaler or European provider” as a blanket allegiance and more which workloads carry enough legal and operational risk that centralising them in a foreign-run region is indefensible, and then routing those to infrastructure controlled within the EU.
For sensitive and high-risk AI, the centralised model fails twice over: it concentrates the legal exposure and it concentrates the blast radius. An EU private cloud is a different architecture, one that declines to put both kinds of eggs in a single foreign-run basket.
If you are mapping which AI workloads belong inside a sovereign perimeter, that is the work SkyBiometry is built for. We engineer AI factory environments and run private AI cloud services on EU-resident infrastructure, with ownership and operational control held entirely within the European Union, so the workloads that carry real risk sit in the one architecture that carries neither kind of concentration.
Our guide to data sovereignty in AI sets out the wider picture.
