Part 1 of four. Each briefing in this series takes one of the four sovereignty questions from our full guide, Making Sense of Sovereign AI, and makes it usable on its own.
Question 1: Where Is Your Data Located and Processed?
What this actually means
For many non-technical leaders, “data location” sounds deceptively simple:
Which country is the server in?
For AI systems, that question is incomplete.
To understand sovereignty risk, leaders need to look at four distinct but tightly connected layers:
- Where your data is stored
The physical or regional data centers where raw data, embeddings, and model artifacts live. - Where your data is used to train or fine-tune models
Training is not passive storage. It is active processing that can expose patterns, relationships, and intellectual property embedded in the data. - Where inference happens
Every time an AI system generates an output – answering a question, making a recommendation, flagging a transaction – data is processed again, often in real time and sometimes in locations different from storage or training. - Which legal jurisdictions can claim authority over those environments
Jurisdiction does not always follow geography. It often follows corporate control, contractual arrangements, and extraterritorial laws.
This is where many sovereignty assumptions quietly break down.
A system can store data in Europe, train models in Europe, and still be subject to foreign legal access because of who operates the platform or which laws apply to the provider.
Why leaders should care
From a compliance perspective, different stages of the AI lifecycle can trigger different legal obligations. Regulations may restrict not only where data is stored, but also where it is processed, trained on, and used to generate decisions. The EU AI Act, for example, introduces obligations tied to how and where AI systems are developed, deployed, and operated – not just where the data sits.
From a choice perspective, organizations may decide that certain phases – especially training and inference – carry higher strategic risk than raw storage. Training data can encode proprietary know-how; inference can expose sensitive operational or customer behavior in real time.
From a cost perspective, separating storage, training, and inference across sovereign environments is expensive. It often means duplicating infrastructure, limiting access to advanced services, and accepting slower iteration cycles.
The leadership challenge is deciding which of these phases genuinely require sovereignty—and which do not.
A more vivid, end-to-end example
Storage, Training, Inference – and Jurisdiction Colliding
Imagine a European financial institution deploying AI across its operations.
1. Data storage: seemingly straightforward
Customer documents, policies, and transaction histories are stored in EU-based data centers. On paper, this satisfies data residency requirements. The vendor contract explicitly states “EU data storage.”
Many leaders stop the analysis here.
2. Model training: where sovereignty quietly weakens
The same data is used to fine-tune large language models for internal copilots and fraud detection. Training jobs run on infrastructure operated by a U.S.-headquartered cloud provider, even though the compute physically sits in Europe.
At this stage, the data is no longer just “stored.” It is actively processed, transformed, and embedded into model weights.
Under the U.S. CLOUD Act, U.S. authorities can compel U.S.-based providers to hand over data they control – even if that data is processed or stored outside the United States. This creates a legal tension: complying with such a request could directly conflict with EU data protection and banking secrecy obligations.
What looked like a compliant setup at rest now carries jurisdictional risk during training.
3. Inference: real-time exposure
Next, the bank deploys the model to support live decision-making – answering employee queries, flagging suspicious transactions, assisting customer service.
Inference requests may be routed dynamically for performance or cost reasons. Some prompts, metadata, or outputs may pass through shared services, global endpoints, or centralized optimization layers operated by the provider.
This means sensitive data can be processed:
- At different times
- In different systems
- Under different operational controls
Even if storage and training were carefully designed, inference can reintroduce cross-border exposure if not explicitly governed.
4. Jurisdiction: the invisible layer
Finally, leadership realizes the hardest truth: sovereignty is not only about where systems run, but about who can be legally forced to act.
The EU AI Act places obligations on how AI systems are used, governed, and audited within the EU. At the same time, extraterritorial laws like the CLOUD Act attach legal authority to the service provider itself.
This means the institution is navigating overlapping and sometimes conflicting legal regimes – not because of negligence, but because sovereignty was assessed only at the storage layer, not across the full AI lifecycle.
The practical insight for leaders
The takeaway is not that global cloud platforms are “bad” or that everything must be national.
It is this:
- Data sovereignty cannot be assessed at storage alone
- Training and inference are often where the real sovereignty risk sits
- Jurisdiction follows control and legal authority—not just geography
For business leaders, the right question is no longer:
“Is our data stored in the right place?”
But:
“Across storage, training, and inference—where are we exposed, and where does that exposure actually matter?”
That is the level of clarity required to make sovereignty a deliberate investment decision, rather than an assumption that unravels under scrutiny.
Next in the series: Question 2 — who controls the keys to your data at rest?