AI needs a sovereign layer too. Can federated infrastructure deliver it?

AI raises sovereignty stakes beyond cloud alone: training data provenance, model weight custody, and GPU supply chains all carry jurisdictional exposure that cloud sovereignty frameworks were not built to answer on their own. Federated infrastructure, in which no single operator or jurisdiction holds unilateral control, is one credible response. Europe is already building this institutionally through projects like EURO-3C. Blockchain-coordinated networks offer a second, more permissionless path, with real trade-offs that neither approach avoids.

This article treats federation as the property that matters, not any particular technology as the answer, and looks honestly at where each path currently falls short.

Why doesn't cloud sovereignty automatically cover AI sovereignty?

The three-layer model set out in this publication's cover feature, jurisdictional, operational, technical, still applies to AI workloads. But AI introduces exposure that a general cloud sovereignty assessment does not automatically capture.

**Training data provenance** is its own question, separate from where the data is stored today. Where was it collected, under whose legal authority was it processed, and does its use in training carry obligations that travel with the resulting model rather than staying with the original dataset.

**Model weight custody** is a genuinely new category. A trained model is a compressed, exportable, valuable asset in its own right, and where its weights physically sit, and who can access or copy them, raises sovereignty questions that have no direct analogue in ordinary data storage.

**Inference logs** may be more sensitive than the data that trained the model. What an organisation asked a model, and what it was told in response, can reveal more about intent, strategy, and vulnerability than the underlying training corpus ever did.

**Hardware supply chains** add a further layer that sits outside the cloud sovereignty conversation entirely. GPU access is itself constrained by export controls and global supply dynamics beyond any individual buyer's control, a structural dependency that the EU Cloud Sovereignty Framework's SOV-5 objective already flags as the heaviest-weighted risk in cloud generally, and one that applies with even more force to AI-specific hardware.

This is no longer a speculative concern. The EU AI Act's provisions on systemic-risk models and the compute thresholds attached to them, and the Cloud and AI Development Act now moving through the same policy process that produced SEAL, both treat AI infrastructure as a distinct regulatory subject, not simply cloud infrastructure with a different workload running on it.

What does federation actually mean as a sovereignty property?

Before comparing approaches, the term needs a precise definition, because it gets used loosely.

Federated infrastructure distributes operational and jurisdictional control across multiple independent parties, such that no single entity, and no single jurisdiction, can unilaterally compel access or shut the system down. That is a specific and testable property, not a synonym for 'distributed' or 'not one company.' Multiple data centres owned by the same operator, however geographically spread, is redundancy, not federation. Federation requires genuine independence between the parties holding control.

That distinction matters because it is the yardstick both paths below need to be measured against, not just whether they involve many participants, but whether those participants are genuinely independent of one another.

The institutional path: what Europe is already building.

The clearest evidence that federation is a serious European infrastructure strategy, not a theoretical alternative, is EURO-3C. Announced at Mobile World Congress in March 2026, the project is a Commission-backed initiative worth 75 million euros, led by Telefonica, connecting more than 70 organisations and over 70 edge and cloud nodes across 13 European countries into what its architects describe as Europe's first large-scale federated Telco-Edge-Cloud infrastructure. Rather than building new centralised capacity, EURO-3C connects existing national infrastructure into a cross-border federated network, financed through institutional debt rather than venture capital, a detail worth noting because it signals infrastructure-grade commitment rather than research-stage experimentation.

A related and more AI-specific effort is the FedEU.ai initiative, developed under the 8ra programme, which applies federated learning directly to AI model training: organisations train shared models across separately held datasets without centralising the underlying data itself, aiming to make data sovereignty and AI capability mutually reinforcing rather than competing goals.

Both are early. EURO-3C's infrastructure is expected online through 2026, and neither project has yet been tested at the scale or under the adversarial conditions that would prove out the sovereignty claims made for it. This publication's companion piece, 'The Gaia-X question,' examines the record of institutional federation in Europe over the five years since Gaia-X launched, and the honest lesson there is that institutional federation is hard to coordinate and slow to deliver, even when the sovereignty logic behind it is sound. EURO-3C is the newest attempt at the same underlying strategy, not proof that the coordination problem has been solved.

The decentralised path: what DePIN and blockchain-coordinated networks offer.

A different category of federation has emerged from outside traditional infrastructure procurement entirely: Decentralised Physical Infrastructure Networks, or DePIN, which use blockchain to coordinate and verify contributions from many independent hardware operators, often anonymous, without a central company owning or managing the underlying resources.

Applied to AI compute specifically, networks such as io.net, Render Network, and Akash aggregate GPU capacity from independent operators and route workloads across it, while Bittensor coordinates decentralised machine intelligence more directly across independently run subnets. None of these are cited here as endorsements; they are the concrete, named examples of a real and growing category, not a hypothetical one.

The hard engineering problem these networks exist to solve is verification. When a workload is sent to an anonymous, independently operated node, the network needs a way to confirm the node actually performed the claimed computation rather than returning fabricated results to save on power costs. Standard cryptographic hashing does not solve this for AI inference, because AI outputs are inherently non-deterministic; the same prompt run twice on identical hardware will not always produce byte-identical output. The mechanisms that have emerged instead include proof-of-useful-work schemes, trusted execution environments that allow verifiable computation inside hardware-isolated enclaves, and multi-oracle consensus, where several independent checks must agree before a result is accepted. These are genuine technical answers to a genuine problem, not hand-waving, and they are worth naming precisely rather than gesturing vaguely at 'the blockchain.'

Where decentralised infrastructure genuinely helps, and where it doesn't.

Both directions deserve equal weight here, because the honest answer cuts each way.

**Where it plausibly helps.** Inference workloads, which industry estimates suggest already account for the majority of global GPU demand, are atomizable: individual requests can be split across many independent, unsynchronised nodes without requiring those nodes to coordinate with each other. That property suits decentralised networks well, and placing inference closer to the end user can also help with latency and, in principle, with keeping processing within a given region. Resilience against a single point of failure or a single jurisdiction's compulsion is a real structural benefit of genuine decentralisation, and aggregating underused hardware from many small operators can lower costs relative to hyperscale capacity built and owned by one company.

**Where it does not obviously help, and may work against the sovereignty goals this publication has set out.** This is the section that has to be said plainly rather than softened. A permissionless network of globally distributed, frequently anonymous node operators is close to the opposite of what the SEAL framework's operational and jurisdictional objectives, SOV-2 and SOV-4, actually require. Those objectives ask who runs the infrastructure, under which legal entity, in which jurisdiction, and with what staff, questions that are straightforward to answer for a single European operator and close to unanswerable for a network whose nodes are pseudonymous wallet addresses that could be located anywhere. Training workloads, unlike inference, generally require tighter synchronisation between compute nodes than most current DePIN architectures handle well, which limits where decentralised infrastructure can substitute for centralised training capacity today. The regulatory treatment of token-incentivised infrastructure under MiCA and EU data protection law remains genuinely unsettled, not a solved problem being ignored for convenience. And the DePIN stack itself is still fragmented in practice: compute, storage, and verification frequently live on separate, loosely integrated protocols, which raises real engineering overhead for anyone trying to build production systems on top of them.

The conclusion this publication draws is a deliberately narrow one: decentralisation and sovereignty are not the same axis. A network can be highly decentralised in a technical sense while being poorly aligned with what European regulators currently mean by sovereign, because sovereignty as SEAL defines it depends on auditable jurisdiction and accountable operators, not merely on the absence of a single central owner.

Can the two paths converge?

The more interesting question is not which path wins, but whether they can be combined. A federation that adopted DePIN-style cryptographic verification and incentive design, while restricting participation to vetted operators within known EU jurisdictions rather than opening the network permissionlessly to anyone globally, would be answering the operational-control objection directly while retaining the resilience benefit that makes decentralisation attractive in the first place. Call it a permissioned federation rather than a permissionless one.

This is not yet built at meaningful scale, and this publication is not aware of a live implementation that has proven the model works under real conditions. It is a direction worth watching, not a claim being made on its behalf. If EURO-3C and its successors mature technically while borrowing the verification rigour that DePIN networks have had to develop out of necessity, that convergence, rather than either path alone, may be where AI's sovereign infrastructure layer actually ends up.