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 regulatory ground shifting – GDPR transfer rules, CLOUD Act exposure and new AI Act obligations together pushing those models and pipelines toward 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.

This is why solving today’s sovereignty problem isn’t enough.

The same three questions come up in almost every customer conversation. None are new – they’ve just become impossible to ignore. And the right response to all three is the same. Not a one-time solution, but a way of designing for what you don’t yet know.

Question 1: Do I meet all regulatory requirements?

This one looks straightforward on paper. GDPR for personal data. The EU AI Act for AI systems. Sector-specific regulations layered on top. Each has clear requirements. Each can be documented and audited.

In practice it gets harder fast, because regulations apply to data, but data moves. Backup paths that touch the wrong region. Fail-over decisions made by automated systems that don’t read regulations. Cross-border flows hidden inside SaaS providers’ own infrastructure.

Compliance isn’t a property of your data store. It’s a property of the entire path your data takes: Every node, every link, every contingency.

Question 2: Who can access or use my data?

This usually gets framed through one specific lens – the CLOUD Act, FISA 702, or whichever extraterritorial law has been in the news lately. The concern is real. But the framing is too narrow.

The real question is broader: who, under any conditions, could reach your data or compel its disclosure?

Legal reach is part of it. So is operational reach – who in your supplier’s organization, or your supplier’s supplier’s organization, has technical access. So is the access that doesn’t exist today but could exist tomorrow, because your supplier was acquired or restructured or moved its headquarters.

The honest answer is rarely a list of names. It’s a set of conditions.

Question 3: What could stop my business from running?

This is where the conversation shifts to resilience and autonomy.

The visible part is technical: can the service keep running through outages, attacks, failures? Frameworks like DORA make this explicit for financial services. Backup, redundancy, multi-region fail-over, disaster recovery. These are well-understood and increasingly well-implemented.

The deeper question is about leverage. The service may still be technically running while you’ve lost the ability to use it. A contract change. A sanctions regime. A political dispute. A supplier consolidation that quietly removes the alternative you used to have. Your servers are up; your business is down.

This often gets labeled as a “kill switch” discussion, which underclaims it. A kill switch implies someone flipping a single, visible lever. The reality is messier: legal, commercial, geopolitical, and technical dependencies entangled.

A practical three-step approach

Sovereignty isn’t going to get simpler. Regulations will multiply, dependencies will deepen, and the geopolitical and commercial conditions will keep shifting. But the response doesn’t have to be reactive.

Step one: Know your levers. Map them by asking yourself the three questions above. What are my regulatory exposures, today and across the jurisdictions I touch? Who could reach my data, under what conditions, and how would I know? What could stop my business from running – technically, commercially, or legally?

Step two: Choose an architecture that can adapt to changing levers. Once you can see the levers, design for the fact that they will move. That means real choice across the stack – no single dependencies you can’t unwind. Modularity, abstraction, portable data, exit paths that work in practice and not just on paper, alternatives that can be activated when conditions shift. The architecture choice happens upfront. The verdict comes later, when something changes and you find out whether what you built has room to move.

Step three: Make resilience and sovereignty an ongoing practice. Sovereignty isn’t a project that completes, but a discipline you revisit as conditions change.

Organizations that design for adaptability – and keep adapting – will be the ones that handle sovereignty well.

Originally published on LinkedIn