Your AI Is Quietly Moving Your Data Across Borders

By Slava Girin, CEO of EGO Digital

Ask most executives whether their data is sovereign and you'll get an answer about geography. "It's in a data center in Frankfurt." "We host in-region." "It never leaves the country." All reasonable. All beside the point.

Where your data physically sits and whose laws it actually answers to are two different questions. In regulated industries — banking, insurance, aviation, healthcare, the public sector — confusing the two isn't a technicality. It's how you fail an audit, breach a regulation you didn't know applied, or discover that "our data is in-region" was never the guarantee you thought it was.

And then AI arrived and made the question sharper, because you're no longer just storing sensitive data. You're feeding it to systems that reason over it and act on it — and that changes what sovereignty has to cover.

Three words people use interchangeably, and shouldn't

Start with the vocabulary, because most of the confusion lives here.

Data residency is where your data is stored — the physical or geographic location. Data localization is the act of complying with the laws that govern residency in a given place. Data sovereignty is the bigger idea: that your data is subject to the laws and jurisdiction of the place where it lives — and, uncomfortably, often to more than one jurisdiction at once.

Here's the trap. A team picks an in-region data center, checks the residency box, and declares victory on sovereignty. But residency is one input to sovereignty, not the whole of it. Sovereignty is also about which laws govern the data, who and what can access it, whether you hold the keys, and whether you can prove any of it to a regulator. You can be perfectly compliant on residency and still not be in control.

A concrete version: the EU's GDPR doesn't only care where an EU citizen's data is stored — it governs how that data is handled wherever it travels, and it expects a named, accountable person keeping it confidential, intact, and available. Residency alone satisfies none of that. And when the same dataset is generated in one country, stored in a second, and processed in a third, you are answerable to all three at once. That is the normal case, not the edge case.

Sovereignty is three things, not one

The cleaner way to think about it — and the framing IBM uses — is that a real sovereign posture has three parts, and most "sovereign" claims cover only one.

Data sovereignty is the legal layer: whose jurisdiction governs the data. Operational sovereignty is the availability layer: your critical infrastructure stays resilient and running under local rules, with real recovery and failover, so a regional outage or disaster doesn't take your operation down with it. Digital sovereignty is the control layer: you decide who can access your digital assets, you enforce those rules as policy rather than as good intentions, and you can audit what actually happened.

Miss any one of the three and the word "sovereign" is doing more work in your marketing than in your architecture. A system can sit in the right country, under the right law, and still fail on sovereignty because nobody can prove who accessed what — or because it falls over the first time the region has a bad day.

• Data sovereignty — the legal layer: whose jurisdiction governs the data.
• Operational sovereignty — the availability layer: resilient infrastructure with real recovery and failover.
• Digital sovereignty — the control layer: enforced access policy and provable audit.

AI didn't create the problem. It multiplied it.

Borders were already a weak proxy for protection. AI makes that acute.

When you put an agent into a regulated operation, sovereignty can no longer stop at the storage layer — because the data doesn't stop there either. Every prompt is data. Every document the agent retrieves for context is data. Every payload it sends to a tool is data. Every execution trace and evaluation log — the exact records you need for the observability and audit I've written about before — is data. Each of those has a location, a governing law, and an access question of its own.

Picture an insurer that did everything right on paper. Customer records sit in an in-country data center; the residency box is green. Then an AI agent starts handling claims, and to do it, the claim details, the retrieved policy documents, and every reasoning trace are sent to a model and a logging pipeline running abroad. Nothing looks wrong in the storage audit. But the moment a regulator asks where the customer's data was actually processed, and who could have seen it along the way, the in-region story falls apart. The data at rest was sovereign. The data in motion never was.

This is the part most AI deployments quietly get wrong. They lock down the database, satisfy themselves that storage is in-region, and then route the sensitive context out to a model endpoint sitting in another jurisdiction entirely. A sovereign storage layer with a non-sovereign AI layer bolted on top is not sovereign. It just hasn't been asked the right question yet. For a bank or an insurer, that gap is the whole difference between an automation the risk committee approves and one it can't touch.

What actually being in control requires

Strip it down, and genuine data sovereignty for AI comes down to a short, hard list.

Choose the jurisdiction — and keep both the storage and the processing inside it. Control precisely who and what can reach the data, enforced as policy you can point to, not access that lives in someone's head. Hold the encryption and the keys, so access is a technical guarantee rather than a contractual promise — the difference between "they said they wouldn't" and "they can't." Stay resilient, with recovery and failover built into each compliance zone. And be able to audit and prove all of it, on demand, months later, to someone whose entire job is to doubt you.

1. Choose the jurisdiction — and keep both storage and processing inside it.
2. Control precisely who and what can reach the data, enforced as policy.
3. Hold the encryption and the keys, so access is a technical guarantee.
4. Stay resilient, with recovery and failover in each compliance zone.
5. Be able to audit and prove all of it, on demand, months later.

Underneath every one of those sits a decision about deployment topology. You cannot promise sovereignty if you can only run in one place. You need the option to run where your obligations demand — dedicated and isolated in a chosen region, inside your own cloud, or entirely on your own premises, air-gapped from the outside world when the data is sensitive enough to warrant it.

Two honest caveats, because sovereignty gets oversold

First, it's a shared responsibility. No platform hands you compliance in a box. A good provider gives you the controls, the deployment options, and the technical assurances; you still own the decision about which jurisdiction applies, and — together with that provider — the ongoing work of tracking rules that change faster than most roadmaps. The right relationship isn't "they made us compliant." It's "they gave us the levers, and we share the job of keeping them set correctly."

Second, sovereignty is a tradeoff, not a free good. The most sovereign option — fully on-premises, air-gapped, keys in your own hands — can also cut you off from the newest models and the conveniences of someone else's cloud. The least sovereign — shared multi-tenant SaaS — is cheaper and often perfectly fine for data that carries no real obligation. Most enterprises need different points on that curve for different workloads: the frontier for the low-stakes, the fortress for the regulated. The mistake is treating it as one global switch instead of a per-workload decision.

Why we built Mashu AI OS the way we did

This is exactly the problem we set out to solve, and it shaped the architecture from the start.

Mashu AI OS is built on IBM watsonx Orchestrate — a trusted, enterprise-grade foundation that regulated industries already recognize, and one designed for secure, sovereign deployment across environments. Building on IBM rather than reinventing the base layer is a deliberate choice: it lets us offer sovereignty as genuine technical assurance, inherited from infrastructure with decades of enterprise security behind it, instead of a promise we ask clients to take on faith.

In practice, that means the client decides where their data and its AI processing live — not us, and workload by workload rather than one switch for everything. Mashu runs across a spectrum of deployment models: multi-tenant SaaS where cost is the priority and the data allows it; a dedicated, single-tenant environment in a chosen region — for us, EU-region on IBM Cloud — where isolation matters; private cloud inside the client's own AWS, Azure, or GCP; and full on-premises, including air-gapped, for the most sensitive workloads. The same agent, the same orchestration, deployed under the regime the client's regulator requires.

And because sovereignty is also the control and audit layers, the governance and observability I've written about before aren't separate products here — they're part of the same fabric. Every action an agent takes and every piece of data it touches stays controllable, traceable, and provable, inside the jurisdiction the client chose. That is what turns "we host in-region" into something a compliance officer can actually sign.

The question was never "where is our data"

In regulated industries, sovereignty isn't a feature you retrofit once the AI is already running. It's a precondition for letting AI near real operations at all.

And the question was never really where your data lives. It's whose laws it answers to, who can reach it, and whether you can prove — to a regulator, an auditor, a board — that you are the one in control. The enterprises that get this right don't stumble into it. They choose their jurisdiction deliberately, they build so they can defend that choice, and they treat sovereignty as seriously as the capability it protects.

The data was always going to end up somewhere. Sovereignty is deciding, on purpose, that "somewhere" is a place you control.

Frequently Asked Questions

What is data sovereignty?

Data sovereignty is the principle that data is subject to the laws and jurisdiction of the country where it is stored or generated. It goes beyond physical location: it concerns whose laws govern the data, who can legally access it, and whether an organization can prove it stays under a legal regime it controls. In regulated industries, it often determines whether a deployment is compliant at all.

What is the difference between data residency, data localization, and data sovereignty?

Data residency is where your data is physically stored, data localization is the act of complying with laws that require data to stay in a specific place, and data sovereignty is the broader question of whose laws govern the data and who can access it. The common mistake is treating them as the same thing. You can satisfy residency by choosing an in-region data center and still fall short on sovereignty, which also depends on access control, key ownership, and provability.

Does storing data in-region make it sovereign?

No. Storing data in a specific region satisfies data residency, but residency is only one component of sovereignty. True sovereignty also requires controlling who can access the data, holding the encryption keys, keeping the infrastructure resilient, and being able to prove all of it to an auditor. In-region storage alone does not guarantee your data is under a legal regime you actually control.

Why does AI make data sovereignty harder?

AI extends the sovereignty problem from stored data to data in motion. When an AI agent runs, the prompts, retrieved documents, tool payloads, and execution logs are all data, each with its own location and governing law. A frequent failure is securing the storage layer in-region while routing sensitive context to a model endpoint or logging pipeline in another jurisdiction, which quietly breaks sovereignty even when the database looks compliant.

How can enterprises keep their AI data sovereign?

Enterprises need to keep both the storage and the AI processing inside a chosen jurisdiction, control precisely who and what can access the data, hold their own encryption keys, and be able to audit every action. In practice this depends on deployment flexibility: the ability to run in a dedicated in-region environment, in a private cloud, or fully on-premises (including air-gapped) depending on how sensitive each workload is. Mashu AI OS is built for this, offering that spectrum of deployment models on a trusted IBM watsonx foundation.

Is in-region cloud storage enough to satisfy GDPR?

Not necessarily. GDPR governs how EU citizens' data is handled wherever it travels, not only where it is stored, and it expects a named, accountable owner for keeping that data protected. Meeting residency requirements is a starting point, but compliance also depends on access control, where the data is processed, and demonstrable governance across the full data lifecycle, including any AI processing.