Why Sovereignty Needs Both Centralization and Decentralization
Europe’s cloud strategy is at a crossroads. There’s pressure to take control, to define sovereignty in infrastructure terms, and to reduce exposure to non-European hyperscalers. But somewhere along the way, the conversation fell into a binary trap: either centralize for control or decentralize for autonomy.
That’s not how modern systems work. And it’s not how sovereignty is going to work either.
Europe’s reliance on U.S. hyperscalers remains a security and sovereignty risk. While countries like France, Germany, and Italy invest in local providers, their efforts remain siloed. Without alignment, Europe is left with patchwork sovereignty.
I said it many times already, but let me repeat it. Sovereignty in the cloud isn’t a matter of choosing one path or the other. It’s about building an architecture that combines both centralized coordination with decentralized execution. Anything else either fragments too fast or becomes too rigid to function in a sovereign context.
Centralization Is About Structure, Not Control
Centralization plays a role. A central governance framework helps define what sovereignty means: where data can move, who operates the infrastructure, how compliance is enforced, how identity is managed. Without some level of central alignment, sovereignty collapses into 27 different interpretations with no common ground.
This is where Europe still struggles. They are good at setting principles – GDPR, data residency, trusted cloud labels – but they lack shared operational infrastructure. What they do have is fragmented: agencies, member states, and industry sectors each building their own versions of sovereignty with little interoperability between them.
Centralization brings order, but order alone isn’t resilience.
Sovereign Microzones: Fragmented by Design
The current trajectory in many parts of Europe is toward what could be called sovereign microzones, individually defined, locally controlled, often incompatible cloud environments built by national or sector-specific entities.
These microzones are born out of good intentions: protect critical data, maintain legal oversight, reduce dependency. But most of them don’t scale well. Each implementation introduces its own stack, its own compliance logic, and often its own interpretation of what “sovereign” really means.
In practice, this results in technical fragmentation and governance friction. Cross-border collaboration becomes harder. Data sharing between sectors stalls. Innovation slows as cloud-native capabilities are stripped back to meet narrow compliance targets.
Sovereignty was never meant to be a bunker. If these microzones can’t interoperate, they may become silos. Silos with flags on top.
Operational Autonomy vs. Strategic Realism
One idea gaining momentum is operational autonomy, ensuring that European workloads can continue to run even in the event of a political embargo or legal dispute with a non-EU provider. It’s a serious concept, grounded in real geopolitical concerns. The fear is that U.S. cloud vendors could, under extraordinary circumstances, be forced to restrict services in Europe. I get it.
But let’s be honest: the probability of a coordinated embargo cutting off hundreds of cloud regions across Europe is extremely low. Not zero. But close. The legal, economic, and political blowback would be enormous. The U.S. has more to lose than gain by treating Europe as an adversary in this space.
Still, operational autonomy has value. It’s about having options. The ability to reassign workloads, shift operational control, and decouple governance when needed. But building that autonomy doesn’t mean rejecting foreign technology outright. It means investing in layered sovereignty: trusted deployment models, contractual separation, technical isolation when necessary, and above all – control over the control plane.
Note: Operational autonomy is not the same as autarky.
What Oracle Cloud Enables
Oracle Cloud fits this model in ways that are often overlooked. Not because it’s European—it isn’t—but because it supports the technical and operational diversity that sovereignty requires.
With OCI Dedicated Region and the Cloud@Customer portfolio, institutions can run full-featured or a subset of Oracle Cloud environments inside their own data centers, with some/complete control over operations, updates, and access.
Oracle’s EU Sovereign Cloud further separates European workloads from global infrastructure, with EU-based personnel and compliance boundaries. And unlike some providers, Oracle doesn’t require full-stack standardization to make it work. It’s open, modular, and designed for interoperability.
A good example of this approach is the new partnership between Oracle and Nextcloud. It brings together a leading European open-source collaboration platform with Oracle’s sovereign cloud infrastructure. The result is a deployment model where public sector organizations can run Nextcloud in a scalable, cloud-native environment while maintaining full data control and legal jurisdiction within the EU. It’s an antidote to sovereign fragmentation: a solution that respects both European values and operational pragmatism.
This kind of flexibility matters. It respects the complexity of European sovereignty rather than trying to erase it.
Conclusion: Not Either/Or – Both
Europe shouldn’t have to choose between centralization and decentralization. In fact, it can’t. Real sovereignty (political, technical, operational) lives in the tension between the two.
The false choice only leads to false confidence. The reality is more difficult, but also more durable: structure without rigidity, autonomy without fragmentation.
Sovereignty isn’t built in isolation. It’s coordinated. Together.
