Data sovereignty has ceased to be an infrastructure debate and has become a question of advice: where does the company's data reside, what legislation applies to it, who can access it, and what happens operationally if the provider's conditions change tomorrow.
This is not an ideological issue, nor is it a matter of preferring local suppliers. It is a continuity risk assessment, just like the one conducted with any critical supplier in the supply chain.
Three factors have converged in a short time.
The European regulatory framework has become more complex. GDPR, the AI Regulation, the Data Act, and industry-specific regulations require precise knowledge of where data is stored and who processes it. Vague answers will no longer pass an audit.
Supplier terms change rapidly. Model prices, usage policies, version withdrawals, changes in data processing terms. What was agreed upon eighteen months ago may not be what is in effect today.
The market has reacted. In August 2026, Reuters analyzed how established European companies—SAP, Capgemini, Sopra Steria, and OVHcloud—have become winners in the AI cycle precisely because businesses need technology that works with their existing data and processes. According to the same analysis, SAP is investing over €20 billion in sovereign cloud and AI.
When the market invests on that scale in a category, it's because the demand is real.
Ask | Why it matters | Insufficient response |
|---|---|---|
Where does the data physically reside? | Determine the applicable law | «"In the cloud"» |
Which legal entity handles them and under what jurisdiction? | It may differ from the physical location | «"A European supplier"» |
Is our data used to train models? | It affects confidentiality and IP. | «"They are protected"» |
What happens if the supplier changes terms or goes out of business? | Business continuity | «"It's not going to happen"» |
Can we take the data with us, and in what format? | Actual exit cost | «"Export is available"» |
The second row is the one that produces the most surprises. The physical location of a server and the jurisdiction of the entity that operates it may not coincide, and what determines third-party access obligations is usually the latter.
The fifth problem is the one that's discovered late. "Export is available" can mean a dump without structure or relationships, useless without months of work. The useful question is what format, with what data model, and how long it would take the team to work with it again.
It's important to dispel a common misconception. Claiming sovereignty over data doesn't mean abandoning international providers or building everything in-house. It implies three concrete and quite reasonable things:
Knowing where everything is. A map of what data lives in which system, under which contract, and with which jurisdiction.
Maintain the ability to move. The architecture should allow switching providers without redoing the business. This is a design property, not a contractual one.
Keep at home what defines the company. Customer data, business rules, assessment sets, and the differentiating logic. The rest can live wherever it's most efficient.
The third is the strategic decision. A company whose business logic resides within the configuration of an external supplier doesn't have a sovereignty problem: it has an ownership problem. We have addressed this in Technological dependence and business risks
Sovereignty isn't achieved with a clause, it's achieved with a layer. Four elements:
Model provider abstraction. Changing your model should be a configuration, not a project. Prices and capacities fluctuate several times a year; an architecture that doesn't allow you to take advantage of these changes is permanently overpaying.
Data in proprietary systems. The original system is yours; external services consult, but do not safeguard, the original.
Proprietary assessment sets. The repertoire of cases with the correct answer according to your business is yours and is what allows you to compare suppliers objectively.
Documented contracts and integrations. So that another team can take over without depending on who built it.
With these four elements, the decision about which supplier to use becomes what it should be: a price and quality comparison that can be reviewed every year.
The common mistake is to present it as a geopolitical risk, which turns the conversation into speculation. The effective approach is operational and can be summarized in one question:
If tomorrow this provider doubles the price, changes its data processing conditions, or stops offering the service, how long would it take us to be operational with another one, and how much would it cost?
If the answer is "weeks and a limited cost," the exposure is managed. If the answer is "we don't know," then there's an unquantified risk with a critical supplier, which is exactly the kind of thing a board needs to know about.
And if the answer is "we couldn't," then the conversation is no longer about data sovereignty. It's about who really controls the company's operations.
It's about effective control over where data resides, what legislation applies to it, who can access it, and what happens if the provider's terms change. It matters because it determines regulatory compliance and operational continuity, not for ideological reasons.
Five: where the data physically resides, what legal entity processes it and under what jurisdiction, whether it is used to train models, what happens if the provider changes conditions or ceases service, and in what format and at what cost it could be recovered.
No. It means knowing where each piece of data is located and under what contract, maintaining an architecture that allows changing providers without redoing the business, and keeping in its own systems what differentiates the company: customer data, business rules, and assessment sets.
One with four elements: abstraction of the model provider so that replacing it is a configuration and not a project, data held in own systems, own evaluation sets that allow comparing alternatives objectively, and documented contracts and integrations.
Because the jurisdiction of the entity operating the service may differ from the physical location of the servers, and third-party access obligations typically stem from the former. Therefore, it's essential to inquire about the legal entity handling the data, not just the data center.
With a practical question: if tomorrow this supplier were to double its price, change its terms, or cease operations, how long would it take us to switch to another supplier, and what would the cost be? A quantified answer indicates managed risk; no answer indicates unknown exposure to a critical supplier.
How long would it take you to switch providers if conditions changed tomorrow? We analyze dependency, data residency, and the real cost of exiting, and design the layer that gives you back freedom of movement. Let's talk →
Español Español 
English
Français
العربية
Português
Deutsch
Italiano
