The sovereignty trap: why most businesses buying "sovereign AI" don't need to

On 3 June 2026 the European Commission proposed the Cloud and AI Development Act. Strip away the acronym and it does something simple: it creates four tiers of cloud and AI procurement for the public sector, and the top two are effectively closed to any provider who can't prove EU jurisdiction, EU control, and no interference from a non-EU parent company. AWS, Microsoft Azure and Google Cloud can't currently meet that bar, because the US CLOUD Act compels them to hand data to US authorities on request, wherever it physically sits. That's a direct conflict with GDPR, and Brussels has just built a procurement framework around resolving it in its own favour.

The UK isn't bound by that legislation. But the anxiety behind it isn't a Brussels invention. MoD, policing, health, and anyone handling genuinely sensitive data in this country has been asking versions of the same question for years. What the EU's move does is turn a vague unease into a formal, funded procurement category almost overnight. "Sovereign AI" has gone from a marketing phrase to a procurement requirement, and every vendor with anything to sell is now reaching for the word. That's where the trouble starts.

Most of the noise conflates three separate layers of the AI stack, and conflating them is exactly how businesses end up buying more sovereignty than they need, at a price and complexity they didn't need to pay. The first is infrastructure: where the compute physically sits, who owns the hardware, and under whose legal jurisdiction. This is the layer the EU's new rules are actually about, and it matters enormously for defence, for national infrastructure, for anyone processing data where the question "could a foreign government compel access to this" has a real, serious answer.

The second layer is platform: how AI agents are built, orchestrated, monitored and governed on top of that infrastructure. This is where audit trails, evaluation, and control over how a model behaves in production live. It matters when you're running AI at scale across regulated workflows and need to prove, not just claim, that it behaves consistently.

The third layer is application: what data goes in, what contractual terms govern retention and access, what a provider is and isn't allowed to do with what you send it. For the overwhelming majority of businesses, this is where the real exposure sits, and it's solved with discipline and the right contracts, not with a different data centre. Most organisations only have a genuine problem at one of these three layers, if any. Most vendors only sell one. The mismatch between the two is where money gets wasted.

I'll state plainly where Bield sits in that picture. Bield is platform independent and works mainly with Claude and Microsoft Copilot. I'm not going to pretend otherwise, and I'm not going to dress that up as something it isn't. For the advisory work I do, that's the right call: application-layer discipline, done properly, covers the risk that actually exists for most businesses. Bield is independent because it has no platform to sell, not because it's adopted infrastructure it doesn't need. For the small number of organisations where the exposure genuinely sits at the infrastructure or platform layer, that's a different conversation and a different set of providers entirely, and my job there is to help a business work out that it's actually in that minority, not to sell it something I don't offer.

Before anyone signs up for "sovereign AI" of any flavour, three questions are worth asking honestly. What's the actual data, specifically, not categorically, because customer service transcripts and internal drafting sit in a different risk category to defence-adjacent IP or regulated patient records. Who's the realistic adversary, because a jurisdictional dispute over server location only matters if there's a plausible actor who'd act on it, and for most SMEs there isn't. And which layer does the answer actually live in: if it's "we need better contracts and clearer internal policy," you don't need new infrastructure, and if it's "we can't demonstrate control over where this specific workload runs," infrastructure is where the spend needs to go.

The direction of travel behind the EU's move isn't going away. But the businesses that do well out of this shift will be the ones who worked out which layer they actually needed to worry about, not the ones who bought the loudest version of "sovereign" on offer.

Source reference: European Commission, Cloud and AI Development Act proposal, 3 June 2026.