Sovereign AI has quickly moved from policy language into boardroom planning. For CIOs, the appeal is easy to understand: more control over where data goes, which systems can access it, and how far an organization depends on overseas providers for increasingly critical AI workloads.
In 2026, the pressure is only growing. Governments want national AI capacity, regulators want clearer accountability, and enterprises want to know whether their data, models, and infrastructure are exposed to legal or operational risks that they cannot easily see.
In that context, regional hosting, sovereign cloud services, and local AI infrastructure can all look like a sensible response.
Gartner has predicted that 35% of countries will be locked into region-specific AI platforms by 2027, up from 5% in 2026, underlining how quickly sovereignty is becoming a question of procurement, platform choice, and long-term flexibility.
But sovereignty is not a single switch that makes an AI deployment safer, simpler, or more compliant, and can actually narrow model choice, add procurement friction, raise costs, complicate integration, and create fresh dependencies.
The real question for IT leaders is what level of control each workload actually needs, what the organization is prepared to give up in return, and whether a sovereign approach reduces risk or simply moves it somewhere less obvious, not whether sovereign AI is “good or bad”.
To help understand these tradeoffs, ITPro spoke to Forrester senior analyst Dario Maisto about what enterprises really mean when they talk about “sovereign AI”, where local control can reduce risk, and where it can create fresh complexity.
What enterprises really mean by “sovereign AI”
For many businesses, sovereign AI still starts with a fairly narrow concern: keeping data in the right place, which might mean running inference in a specific region, storing prompts and outputs locally, or making sure sensitive data is processed under a particular legal regime.
While these are important controls, especially for regulated sectors, they are only one part of the sovereignty picture.
Maisto says most enterprise projects have not yet reached the point where organizations are wrestling with sovereign AI at full production scale. “Clients' journeys are not that advanced in AI deployments that they can worry about the depth of sovereign AI at scale for production environments,” he says. “They have mostly data residency concerns.”
Maisto’s insight explains why the term can become slippery. A vendor might describe an AI service as “sovereign” because the data is hosted in-country; a public sector buyer might use the same term to mean local legal accountability or domestic infrastructure; and so on.
Distinctions like this are important because AI does not sit neatly in one place. A single deployment can involve cloud infrastructure, foundation models, APIs, orchestration tools, identity systems, logging, monitoring, and a lot more besides.
Once AI agents – perhaps 2026’s buzziest trend – enter the picture, the stack becomes even harder to contain, as systems start pulling from enterprise data sources and triggering actions across multiple applications.
Why local hosting is not the same as control
The first trap is assuming that sovereignty begins and ends with location. Keeping data in a specific country or region can be important, but local hosting does not automatically decide who controls the service, which laws apply, or who can access the underlying systems.
Maisto is blunt on this point: “Local hosting does not protect workloads and data with regard to sovereignty concerns. This is where organizations overestimate the potential of local hosting and in-region infrastructure to improve their digital sovereignty posture.”
“If the infrastructure and the tools are owned by a third party operating under a different jurisdiction, the sovereignty risk is not mitigated,” he says.
None of these makes regional hosting pointless. It can still help with latency, regulatory alignment, audit requirements, and internal assurance, and can also reduce the number of cross-border transfers and make it easier to show that sensitive workloads are being handled within a defined legal environment.
The problem comes when residency is treated as a substitute for sovereignty. For CIOs, the due diligence needs to go beyond the region on the invoice and into the architecture behind the service.
Sovereignty can limit choice
The next cost to businesses is flexibility. AI buyers are used to a market that moves quickly (perhaps too quickly), with new models, tools, and managed services appearing every few months or even weeks.
A sovereign AI strategy can slow that down, especially if an organization has to use approved regions, certified providers, local infrastructure, or a smaller set of compliant services, alongside additional procurement, legal, or regulatory scrutiny.
While that trade-off may be perfectly reasonable for the right workload, it still needs to be visible. A government department handling citizen data should not treat model access like a marketing team testing copy variations, and a bank, healthcare provider, or critical infrastructure operator may decide that tighter controls matter more than immediate access to the newest frontier model.
But a sovereign deployment may mean fewer models, less access to specialist AI services, slower feature rollouts, or more integration work for tools that would otherwise be available through a major cloud platform.
That risk is already visible in agentic AI, where ITPro has reported that many UK companies are moving ahead with deployments despite gaps in governance and visibility over where data is stored, processed, and accessed.
Maisto argues this is where buyers can underestimate the knock-on effects. “Organizations mostly tackle this theme from a data residency and inference location perspective, although problems like agents' sovereignty could be more important, and the solutions look very immature as of now in the market,” he says.
“Integration is another underestimated aspect of agentic AI as agents are pervasive and have the potential to increase vendor lock-in with non-sovereign vendors.”
As AI becomes more embedded in enterprise systems, sovereignty becomes harder to separate from day-to-day architecture. The key question is how deeply it connects to the business, and whether those connections can still be governed, audited, or replaced.
Skills and procurement can slow everything down
Even when the case for sovereign AI is clear, delivery can be harder than the strategy suggests. An organization still needs people who can assess suppliers, design the architecture, check operational controls, and so on, and these skills are already scarce in mainstream AI projects, before sovereignty requirements narrow the pool further.
Talent may become one of the biggest constraints, according to Maisto. “According to our forecast, [the] tech workforce is the only sovereignty index that is going to decrease in the next five years,” he adds.
“The more specialized the skills, the less the chance to have the right talent with the needed sovereignty requirements at scale. With an outlook to the future, skills from a sovereign pool of talent would be the most relevant component.”
Procurement adds another layer of friction.
Sovereign AI buyers may need to test where data is stored, how support access works, and many other features of the wider operational chain. Most of the time, the process is likely to be slower than buying a standard AI service from an existing cloud marketplace.
For CIOs, this creates a now-familiar tension: The business wants access to AI quickly, while security, legal, and compliance teams need confidence that the deployment will not create exposure later.
Sovereign AI can reduce some risks, but only if the organization has the skills and procurement discipline to define what “sovereign” means before it buys.
Should companies prioritize sovereign AI?
The safest approach is to treat sovereign AI as a design choice with a defined purpose.
Maisto says Forrester uses a “Minimum Viable Sovereignty Model Decision Framework” to help technology leaders weigh “compliance requirements, risk appetite, budget, tech and business requirements, and available sovereign products and services.”
He adds that they should assess “the tradeoff between sovereignty and functionality, looking at the viability, feasibility and desirability of a sovereign solution.”
Any assessment should include the practical value of sovereignty, the compromises it introduces, and the maturity of the products available. “Not all vendors are scoring equally on AI capabilities and even less so when it comes to sovereign AI capabilities,” says Maisto.
For CIOs, the aim should be proportional control. Some workloads will justify strict sovereignty requirements because the data, operational risk, or public accountability demands it; others may be better served by strong governance, clear deployment controls, and encryption.
The danger comes when enterprises buy sovereign AI too vaguely, without defining which risks they are trying to reduce, which freedoms they are willing to give up, and what they will need back if the strategy changes.
