IBM (NYSE: IBM) has published its Digital Sovereignty Index, reporting that 94% of surveyed enterprises faced at least one sovereignty challenge during the previous three years and arguing that AI is exposing a gap between asserted control and evidence that organizations can actually produce. For IT leaders, the immediate issue is operational: the ability to show who controls data, systems and dependencies when a provider failure, regulation or access dispute interrupts normal service.
IBM calls that gap an overconfidence problem. The company said 82% of respondents were very or extremely confident they could provide evidence of sovereign control, yet only 26% reached the report’s Leading Digital Sovereignty tier. Only 33% said they regularly test those capabilities. The figures describe an IBM-commissioned research program rather than an industry-wide audit, but they point to a familiar weakness in enterprise governance: controls are often documented more thoroughly than they are exercised.
The index places AI at the center of the problem. IBM said AI-provider or AI-governance failures were the most common sovereignty challenge, cited by 44% of respondents. That matters because a production AI service can add dependencies across model providers, cloud regions, data pipelines, identity services, tools and third-party integrations. A policy stating where data should remain is not, by itself, proof that an organization can identify those dependencies, constrain them or keep essential operations running when one fails.
IBM developed the index with Edelman Intelligence through a program that combined a review of 27 sources, qualitative interviews and an international quantitative survey conducted between July 17 and August 11. The company said 81% of enterprises that encountered a sovereignty challenge had to provide formal evidence of control. That framing shifts the discussion away from a broad preference for local infrastructure and toward more practical questions about records, technical controls and resilience tests.
For an IT organization, evidence can include documented data flows, encryption and key-management boundaries, identity and privileged-access records, tested recovery procedures, provider exit plans and audit trails for automated decisions. The appropriate set will depend on the workload and regulation. The important distinction is that a dashboard, contract clause or architecture diagram does not establish that those controls still operate as intended after a service, model or integration changes.
The research also describes sovereignty as more than data residency. Regulatory conflict, government restrictions, critical-vendor disruption and data-access issues were among the challenges organizations reported. In an AI environment, those risks can converge. A change in a model service’s availability or terms could affect application behavior; a regional constraint could alter where processing occurs; and an identity or API dependency could leave a governed workflow unable to operate even if the underlying data remains available.
IBM’s findings should be read as vendor-sponsored research, not a benchmark that independently certifies an organization’s readiness. The report does not establish that every enterprise needs the same control model or that sovereign operation requires eliminating external providers. It does make a useful operational point: confidence in a governance framework is weaker than the ability to demonstrate its controls under a realistic disruption or audit request.
The practical next step for enterprise teams is to treat sovereignty controls like continuity controls. Rather than relying only on architecture reviews, teams can test whether they can locate an AI workload’s data and access paths, revoke a provider or agent credential, preserve logs, fail over an approved component and present evidence of those actions. That approach will not remove dependency risk, but it can expose the difference between a stated control and one that can be used when it matters.