AI sovereignty has become a boardroom word, and somewhere on the way it picked up the wrong definition: build everything yourself. Your own models, your own GPUs, your own datacenters, no outside dependency anywhere. Framed like that, it's a project only a government or a hyperscaler could finish, so most enterprises decide it isn't for them.
The numbers show what that costs. In the EMEA Enterprise AI Sovereignty Index 2026, only 17% of organizations design their AI systems to be replaceable from the start. The other 83% haven't decided against sovereignty. They've decided they can't afford the version they've been sold.
So let's fix the definition. AI sovereignty is the freedom to change: to swap a model, a cloud or a vendor on your own terms and your own timeline, without rebuilding the business logic that made the system worth having. You get there through architecture, and any enterprise can design for it.
Below: the definition the index uses, why replaceability is the test, what DORA and the EU AI Act add for European organizations, and what designing for it involves.
What does AI sovereignty actually mean?
The index defines AI sovereignty across four dimensions. Each one asks what the enterprise can do; none of them asks what it owns.
Control
Deciding where data is processed, who can see it, what it's used for, and under which jurisdiction's law. Jurisdiction and region are two different things here. An EU region of a US provider can still fall under US law, such as the CLOUD Act, so "we picked Frankfurt" doesn't settle the question on its own.
Portability
Moving the system (the data, the context, the workflows and the governance) to a different provider or environment without rebuilding it.
Resilience
Keeping operations running through the loss, degradation or forced replacement of a provider.
Strategic autonomy
Choosing models and vendors based on what's best for the business, rather than on what the current stack happens to allow.
Look at what's missing. Nothing in that definition requires you to train your own foundation model, run your own GPUs or build your own orchestration layer. An enterprise running a commercial model in a public cloud can be fully sovereign by this definition, as long as it could change either one without a rebuild. And an enterprise that built everything in-house doesn't qualify if what it built only runs in one place and nobody could replace it.
Why is replaceability the real test?
Because it's the only one of the four you can measure before the day you need it. Control, resilience and autonomy stay claims until a provider changes its pricing, withdraws from a region or gets acquired. Replaceability is a number: the share of the original build you'd have to redo to run the system somewhere else.
The index makes the gap concrete. 54% of organizations believe they could recover from losing a critical AI provider within 30 days. Only 8% say they could switch with less than 10% of the work redone.
The 46 points between those figures are the distance between confidence and capability, and most of it is rework nobody has estimated. Independent research points the same way: in IBM's 2026 study, 90% of EMEA executives said they don't fully understand their organization's dependencies across AI vendors, models and infrastructure, and nearly three-quarters said switching their main AI vendor or model would be difficult.
That changes what sovereignty costs. Owning it all is a huge capital project with an uncertain payoff. Designing for replaceability is a discipline you apply to systems you were going to build anyway. It isn't free, but it's a fraction of the alternative, and it's the version an enterprise can actually finish.
Why do teams confuse ownership with sovereignty?
Because the word came from national security. For a government, sovereignty does mean domestic capability at every layer, since its threat model includes a foreign power cutting off access. Enterprises borrowed the word and inherited that threat model with it.
The enterprise threat model used to be purely commercial: a provider raises prices, changes its terms on training and retention, drops a region your regulator requires, or gets bought by someone you'd rather not do business with. This year it picked up a geopolitical layer too. In June, US export controls forced one of the leading frontier labs to suspend access to its top models for nearly three weeks, and another lab's flagship launched as a limited preview for the same reason. Neither had anything to do with what customers did.
Owning more of the stack wouldn't have prevented any of those events. Being able to switch would have contained every one of them.
The ownership framing does a second kind of damage: it sets the bar so high that teams stop trying. The index found that 87% of organizations have delayed, redesigned or dropped an AI initiative over concerns about control or jurisdiction. Many of those could have gone ahead on a replaceable architecture. They stalled because the only alternative anyone could picture was building it all, and that was never on the table.
What do DORA, the EU AI Act and the Data Act change?
For European organizations, replaceability is turning from good practice into an obligation. Three pieces of EU regulation point the same way.
DORA: your regulator already expects a paper exit
If you're a bank or an insurer in the EU, this isn't a design choice anymore. Under DORA, which has applied since January 2025, the AI model, API or platform you buy from a vendor is an ICT third-party service. It goes into your register of information, gets a concentration-risk assessment and, where it supports a critical or important function, needs a documented exit strategy that you test (Article 28(8)).
So the paper exit this article recommends is something your regulator already expects. The real question is whether yours describes a switch or a rebuild. If only 8% of organizations could switch with less than 10% of the work redone, most exit plans describe a rebuild and call it a strategy.
Concentration risk is the other half. In November 2025, the European Supervisory Authorities designated 19 critical ICT third-party providers for direct oversight, including the hyperscale clouds most enterprise AI runs on. Put your model, your vector store and your orchestration with one of them, and you've concentrated everything in a provider your regulator already treats as systemically important.
The EU AI Act: your compliance evidence has to move with you
The AI Act adds a less obvious dependency: your evidence. After this year's Digital Omnibus, obligations for high-risk systems apply from 2 December 2027, and transparency obligations have applied since August 2026. If your logs, human-oversight records and documentation sit in one provider's tooling, switching provider means losing your compliance trail along with it. That's why governance has to belong to your platform, not to a provider account, and why it can't wait for the deadline.
The Data Act: leaving the cloud gets cheaper, for data at least
The EU Data Act helps at the cloud layer. It obliges cloud providers to support customers who switch, and switching charges, including egress fees, are being phased out, ending entirely in January 2027. That lowers the cost of moving data. It does nothing for your context, workflows and governance, which only move if you designed them to.
Sovereignty isn't a financial-services concern alone, either. In Red Hat's survey of more than 900 IT leaders across nine EMEA countries, 63% named sovereignty concerns the biggest barrier to cloud adoption, and 80% of German organizations rank sovereignty a top IT priority for the next 18 months.
Which dependency should you tackle first?
The cloud. In the index, 26% of organizations named their cloud provider as the hardest part of their AI stack to replace, against 18% for the model. Yet most sovereignty effort goes to the model.
Model replaceability is comparatively well solved. An LLM-agnostic architecture routes each request to whichever model is best for the task, and lets that choice change without touching anything else. Most organizations want exactly that freedom: 85% said they'd pick a better model even if it deepened their dependence on a provider. It's necessary, but the model is also the easiest layer to swap.
The cloud is where storage, orchestration, identity and monitoring pile up in one provider's own services, so it's where a switch most easily turns into a rebuild. Sovereignty at the cloud layer means deployment is a choice: the same solution runs in a public cloud, a private VPC or fully on-premises, and can move between them when regulation, pricing or strategy changes.
The on-premise AI decision framework is a practical way to decide which workloads need that flexibility today. The architecture should support it for all of them, though, because the workloads that need it later are rarely the ones you'd predict.
What does designing for replaceability involve?
Separating the layers that carry the business from the layers that carry compute, and making sure the first set stays portable whatever happens to the second. You make those decisions once, at platform level, instead of re-arguing them in every project.
| Layer | Durable or disposable | Where it should live |
|---|---|---|
| Data and derived artifacts | Durable | Open formats, under your control |
| Business context: entity definitions, terminology, decision rules, accumulated corrections | Durable | A layer independent of any provider's search or vector product, since it's the most expensive thing to rebuild |
| Workflows and guardrails | Durable | Composable building blocks, rather than one cloud's pipeline tooling |
| Governance: permissions, audit trails, human review | Durable | Your platform, rather than a provider account (this is also where your AI Act evidence lives) |
| Models | Disposable | Chosen per task for performance and cost, replaced when something better arrives |
| Compute | Disposable | Wherever regulation, price and strategy say it should run this year |
Get the durable layers right and the disposable ones can change without the rest of the system noticing. A modular platform built this way has replaceability as a default property.
The final element is measurement. Run a paper exit on your most important use case, estimate the rework, and keep that number current as services get added. If you're under DORA, this is the exit strategy you have to test anyway, so make it a real one. Sovereignty that isn't measured erodes one convenience decision at a time.
What does AI sovereignty look like in practice?
From the outside, pretty ordinary. A sovereign AI program uses commercial models and probably runs in a public cloud, at least for some workloads. The difference is that every one of those choices can be reversed, and the people running the program know what reversing it would cost.
That shows up in the moments that matter:
- The regulator asks where processing happens, and the answer is a decision the enterprise made, not a region on a provider's map.
- A model provider changes its terms, or loses access to a market overnight, and the response is a configuration change rather than a crisis meeting.
- A cloud provider raises prices on the vector store, and the program negotiates from a credible alternative instead of from weakness.
- The DORA exit plan gets tested, and it describes days of work rather than a rebuild.
- A new use case comes up, and it inherits the platform's replaceability instead of reopening the dependency question.
The secure deployment requirements and the data security questions get answered once, at platform level, and stay answered. That's the freedom to change, and it doesn't require owning it all. It requires deciding, before the first use case ships, that the parts of the system worth keeping will never depend on the parts worth replacing.
How does a managed AI delivery platform deliver sovereignty?
By holding the durable layers itself. Replaceability is then built once and inherited by every solution, instead of being left to each project team to design or, more often, to skip.
That's the principle behind Unframe's approach. The platform holds enterprise data and business context in a knowledge fabric, a relational and semantic context layer that's independent of any single model or cloud. Agents, workflows and guardrails are configured on the platform, and governance (permissions, audit trails, human review) lives there too, so your compliance evidence moves with you.
The model layer is fully agnostic, so you use the models you trust and switch when better ones arrive, or when access to one changes. Deployment runs on the hyperscaler of your choice, in a private VPC or fully on-premises. Customer data is never used to train third-party models, and retention is configurable down to immediate deletion; our security page has the details.
The result is a program that passes all four of the index's tests, and gives you an exit plan worth testing, without owning a single GPU. For the full findings, including where enterprises think their dependencies sit and how few have actually tested that, read the EMEA Enterprise AI Sovereignty Index 2026.
What else do enterprise teams ask about AI sovereignty?
What is AI sovereignty?
AI sovereignty is an enterprise's ability to control, move, sustain and freely decide on its AI systems. It covers four dimensions: control over data and jurisdiction, portability across providers, resilience through the loss of a provider, and strategic autonomy in choosing models and vendors. It comes from architecture rather than ownership.
Does AI sovereignty mean building your own models?
No. A proprietary model doesn't make a program sovereign if the system around it only runs in one place. A program using commercial models in a public cloud can be fully sovereign, as long as its data, context, workflows and governance could move to another provider without a rebuild.
What's the difference between AI sovereignty and data sovereignty?
Data sovereignty covers where data is stored and processed, and which law applies. AI sovereignty includes that and adds portability of the whole system, resilience against losing a provider, and freedom of model and vendor choice. You can meet data residency rules and still be unable to leave your AI provider.
Does DORA require an exit strategy for AI providers?
For EU financial entities, yes, where the AI service supports a critical or important function. DORA treats AI models, APIs and platforms bought from vendors as ICT third-party services, which means they belong in the register of information, need a concentration-risk assessment and, for critical or important functions, a documented and tested exit strategy under Article 28(8).
How do you measure AI sovereignty?
Measure replaceability. Run a paper exit on a critical use case, estimate the rework needed to run it on a different provider, and express it as a share of the original build. The EMEA Enterprise AI Sovereignty Index 2026 used less than 10% rework as the threshold for a clean switch; only 8% of organizations met it.
Explore more blog posts from Unframe.
