The Sovereignty Series

Don’t solve your current sovereignty problem. Three examples to make this concrete. An organization fine-tuning AI models on European customer data finds the EU AI Act now requires those models and pipelines to live within EU jurisdiction. The training infrastructure built in 2023 wasn’t designed for that constraint. The remediation isn’t a configuration change; it’s an architecture rebuild. A European enterprise places R&D and strategic plans in a US-headquartered cloud provider’s EU region. The data sits in Frankfurt or Dublin. The contract specifies EU jurisdiction. But the parent company can be compelled by its home government to provide access – and the enterprise has no visibility into whether, when, or how often that happens. A sub-sea cable cut between mainland Europe and Scandinavia reroutes traffic through paths with significantly higher latency and reduced bandwidth. The infrastructure is still running. The DR strategy assumed those links would behave the way they did when it was designed. They don’t anymore. Three different scenarios, three different surfaces – legal, access, operational. But the same underlying pattern: the conditions the architecture was designed for keep changing, and what was a solid solution at procurement quietly becomes tomorrow’s liability. ...

Sovereignty is no longer just a privacy or data-residency question. It has become a question of strategic control, resilience, and competitiveness across the entire digital stack. The debate is not about decoupling. It is about understanding the levers that others hold over critical operations, and deciding deliberately which ones to accept, mitigate, or neutralize. For CIOs and risk leaders, sovereignty decisions now shape uptime, legal exposure, cost trajectories, and time‑to‑market – not just compliance. ...

— or rather, what looks like control is often just ownership April 2025. The Iberian peninsula loses power. Spain, Portugal, parts of southern France – one of the largest blackouts in European history. The grid is gone for hours in some regions, days in others. When power goes out for long enough, diesel reserves run down. Standard reserves last 24 to 72 hours. Beyond that, every operator depends on resupply. And resupply, during a regional crisis, doesn’t happen on first-come-first-served terms. ...

This is the second of two articles on a sovereignty paradox. The first, Control Isn’t Sovereignty?, argued that delegating to systems with broader resilience can produce more outcome sovereignty than direct ownership. This one is about the harder question underneath. Most sovereignty design follows the same logic. To protect operations against grid failures: Install generators on site. Stock diesel reserves to keep them running through an extended outage. Arrange supply contracts with fuel suppliers for resupply during a crisis. ...

How do you measure whether something is sovereign? Ask it about a real system and the question splits. Can you keep running if conditions turn, or does someone else decide when you stop? Who holds the levers – the access, the keys, the legal authority? And how deep does it go: your provider may be sovereign, but what about their suppliers three layers down? These have different answers, and they don’t move together. A service can be operationally solid and legally exposed. Jurisdictionally clean at the top and dependent on a single foreign supplier underneath. “Is it sovereign?” has no single answer, because sovereignty was never a single property – which is exactly why you can’t put one number on it. ...

A cloud that passed the sovereignty test, storage that passed it, a model on top that passed it too. Each piece certified, so the sum must be too. It isn’t necessarily. The sum may have parts no certificate covered – the pieces someone adds, the way they’re joined, the provider’s own dependencies, whoever operates the result. Any one of them can make the whole not sovereign. Sovereignty doesn’t add up from the parts. ...

Sovereignty done right makes you resilient. But sovereignty you don’t operate is the opposite: a risk. You move a workload in-house to be more sovereign. Your jurisdiction, your rules, no outside provider in the loop. More control – which is the whole point. But the provider you left wasn’t only running the service. They were also keeping it up, patching it, and making sure you could still reach it when something broke. You didn’t see that part, because you never had to. ...

A chip maker’s engineers pasted proprietary source code and a confidential meeting transcript into a public AI assistant – three times in twenty days. They couldn’t take it back, and the terms at the time allowed the provider to train on it. The company banned the tools outright and started building its own. That’s the first worry: what you send to a model leaves your building, and you can’t get it back. Confidentiality, IP, trade secrets – handed to a company in the business of learning from data. ...

A global company decides to become fully sovereign. Every system in its own data centers, in its own jurisdiction. Foreign providers out, cross-border transfers stopped, the estate air-gapped. Customer data untouchable, IP locked down. Then it goes bankrupt. It was in the pizza delivery business, and the ordering platform was inside the air gap with everything else. Of course nobody would do this. But notice what went wrong: not the ambition, not the execution. They applied it uniformly. The recipe and the order line got the same treatment, and only one of them needed it. ...