Petri first reported the findings this week, and Cohere’s accompanying release identifies the underlying study as an IDC InfoBrief based on more than 500 AI purchasing decision-makers and influencers. The sample was not a cross-section of every business: it covered enterprises with more than $1 billion in annual revenue in the United States, Canada, the United Kingdom, and Germany, with an emphasis on regulated sectors including healthcare, financial services, public sector, energy, manufacturing, and telecommunications.
That framing changes how the results should be read. This is not evidence that every company is abandoning public-cloud AI services. It is evidence that large organizations handling sensitive data are increasingly treating control over models, data, infrastructure, and service continuity as an architecture decision rather than a contract checkbox.
The survey measures concern, not a finished market shift
Cohere and IDC define sovereign AI broadly: an organization’s ability to choose and control the design, development, deployment, accessibility, operation, maintenance, governance, and underlying technical foundations of its AI systems. That is a much larger claim than keeping prompts in a particular country or running a model in a private virtual network.
The distinction matters for Windows and enterprise administrators because a workload can satisfy a narrow data-residency requirement while remaining dependent on an external model provider, a remote control plane, a proprietary vector-search service, or an identity system outside the organization’s operational control. If the provider changes model behavior, retires a version, limits an API, alters geographic availability, or suffers an outage, the organization may still have no practical ability to keep the workflow running.
Cohere says more than half of executive leaders now consider sovereign AI a priority. But the company’s public summary does not identify the “recent model access restrictions” or cybersecurity incidents it cites as catalysts. Nor does it publish the full questionnaire, response distributions, or the number of respondents in each industry. The directional finding is credible enough to report, particularly because IT Pro, Data Center News, and Fierce Network independently covered the same IDC-Cohere study, but the numbers remain results from vendor-sponsored research rather than a neutral measurement of the entire enterprise market.
The more useful conclusion is narrower: large regulated organizations are discovering that AI dependency has several layers, and many have not yet assigned ownership for managing them.
Data residency is only one piece of sovereignty
The term sovereign AI is at risk of becoming an umbrella label for several different requirements. A company may need data sovereignty, meaning it controls where data is stored and processed. It may need operational sovereignty, meaning it can operate core AI workflows if a cloud region, API, or supplier becomes unavailable. It may also need model sovereignty, where it can retain a usable model version, inspect the deployment path, and choose how updates are introduced.
Those needs lead to different designs. A regulated organization may be adequately served by a cloud-hosted model in a region that meets its contractual and legal obligations, with encryption, private connectivity, detailed audit logs, and a tested export path. Another may need self-hosted inference on its own infrastructure because it cannot accept a third party holding the only production route to a clinical, financial, defense, or industrial workflow.
Neither arrangement is automatically “more sovereign” in a meaningful operational sense. An on-premises model that depends on a vendor-managed license server, inaccessible weights, externally operated update feeds, or a single GPU supplier remains dependent. Conversely, a cloud service can offer meaningful control when the customer has enforceable data boundaries, documented portability, independently tested backups, and a second operating path for critical workloads.
IDC made a similar point in its March guidance for CIOs, describing AI sovereignty as control reaching from data and algorithms down to the physical compute layer. That is a useful definition, but it also shows why organizations cannot solve the problem merely by moving a chatbot from a public website to a private tenant.
The dependency map has to include identity and endpoints
For Microsoft-centric enterprises, the AI application is often the visible layer of a longer chain: Entra ID authenticates the user, Microsoft 365 or SharePoint provides the documents, Windows endpoints supply the working environment, a cloud service hosts retrieval and inference, and security tooling monitors access. The operational question is therefore not simply where the large language model runs.
Administrators should map at least five dependencies before describing an AI deployment as sovereign:
- The organization should identify where prompts, uploaded documents, retrieved records, generated outputs, telemetry, and support data are stored, processed, and retained.
- The organization should document which provider controls the model weights, model version, safety policies, API quotas, regional availability, and deprecation schedule.
- The organization should establish whether identity, conditional access, device compliance, secrets management, and privileged administration continue to function during a cloud or supplier disruption.
- The organization should test whether its retrieval-augmented generation pipeline can export embeddings, document indexes, metadata, evaluation data, and access-control mappings in usable formats.
- The organization should determine which workflows can stop temporarily and which require an alternative inference path, a smaller local model, a manual fallback, or a pre-approved degraded mode.
The third item is commonly underestimated. A locally hosted model is of limited use if the organization’s policy requires online identity validation that cannot be reached during the incident the local deployment was supposed to survive. The same applies to endpoint management: a Windows workstation running an approved AI client may still rely on cloud-delivered certificates, network rules, security policies, and data connectors.
This does not mean every AI system needs an air-gapped deployment. Cohere markets private, on-premises, and air-gapped options, so readers should recognize its commercial interest in pushing the conversation toward infrastructure control. It does mean the resilience claim should be tested in the environment where the system will actually operate.
Ownership is the gap behind the awareness gap
The most revealing part of the survey is not the 13% awareness figure. It is the lack of a shared operating model implied by it. If business leadership, security, data governance, procurement, legal, and platform engineering use “sovereignty” to mean different things, a project can pass an early compliance review while leaving basic questions unanswered.
Who approves a model upgrade that changes output behavior? Who owns the evidence that a vendor no longer retains prompt content? Who can retrieve the application, model configuration, prompts, evaluation suite, and access policy after a contract ends? Who decides when a workload may use a public model, a managed private service, or locally operated inference?
Those are governance questions, but they turn into engineering requirements. A policy promising control is meaningless if the AI team cannot pin a production model version, record a reproducible configuration, export its data, observe its dependencies, or fail over a workflow without rebuilding it under pressure.
Cohere says infrastructure was the largest reported readiness barrier in the study, ahead of cost, organizational alignment, and skills. That result fits the practical reality: operating a model yourself requires capacity planning, GPU procurement or leasing, patching, vulnerability management, model evaluation, observability, incident response, and people who understand both the AI stack and the data it touches. The cost is not limited to servers.
For many enterprises, the right result will be a hybrid model. Sensitive or continuity-critical workloads may warrant tightly controlled deployment and a documented fallback. Lower-risk productivity tasks may remain on managed services, provided the data classification, contractual terms, and exit options are acceptable. A blanket rule that all AI must be on-premises creates its own security and operational problems.
What a credible sovereign-AI plan looks like
An enterprise does not need to own every chip, model, and cable to make a defensible decision about AI dependencies. It does need a written threshold for which dependencies are acceptable for each class of workload.
Start by classifying AI use cases according to the data involved, the consequence of inaccurate output, the consequence of downtime, and whether the workflow can be manually performed. Then translate those categories into concrete controls: approved regions, retention limits, encryption requirements, model-change approval, identity dependencies, logging, portability obligations, and recovery objectives.
Before purchasing or expanding an AI platform, insist on an exit exercise rather than accepting a generic assurance of portability. Export a representative application’s documents, indexes, embeddings, prompts, configuration, evaluation set, logs, and role mappings. Measure how much can be re-created elsewhere, how long it takes, and what functionality is lost. If that exercise has never been performed, the organization has a supplier relationship, not a tested continuity plan.
The IDC-Cohere research does not prove that sovereign AI has become the default enterprise deployment model. It does show that the question has moved beyond data location. As AI becomes embedded in Windows-managed endpoints, Microsoft 365 content flows, service desks, engineering systems, and line-of-business operations, the practical measure of sovereignty will be simple: whether the organization can still govern, move, and operate the workload when the external platform is no longer behaving as expected.
