IBM sovereignty index: can your firm prove where its AI data goes?

What IBM published

On 11 November 2026, IBM released Proof, Not Promises: The IBM Digital Sovereignty Index. IBM built the index with Edelman Intelligence from a survey of 2,003 senior decision-makers at large enterprises. According to IBM's UK release, the survey ran from 17 July to 11 August 2026 and covered the United States, the United Kingdom, Germany, France, Saudi Arabia, India and Japan. The sample didn't include New Zealand or Australia, so the numbers describe big overseas organisations. We still think NZ firms should pay attention, because the gap IBM measured comes from habits we see in organisations of every size.

The main finding is a gap between confidence and proof. On average, 82% of respondents said they were very or extremely confident they could produce evidence of sovereign control. Only 26% reached the index's top "Leading" tier, and 33% regularly test whether they can demonstrate control. Most respondents had already been asked for proof. Over three years, 94% had faced at least one sovereignty challenge, and 81% of those had to give formal evidence to regulators, customers, auditors or internal stakeholders. AI-related issues were the most common single challenge, reported by 44%.

The UK results show the AI gap most clearly. UK respondents were 84% confident they could show accountability for their AI systems, but only 27% had shown it through an audit, regulatory review, assurance work or operational testing. The UK's AI pillar scored 70 out of 100, its lowest of the four pillars IBM measured.

IBM sells sovereignty assessments, and its campaign page points readers to IBM's own assessment. Hardware Upgrade's coverage repeated the same figures without any third-party analysis, so the numbers haven't been checked independently. We treat the index as a self-reported snapshot of large enterprises, with the usual limits of a vendor survey.

Why the evidence gap matters more than the confidence

The barriers respondents named are ordinary administrative problems. According to IBM's release, 56% said collecting evidence is manual or slow. Fragmented evidence, relying on third parties for records, and legacy systems or inconsistent standards were each cited by 53%. Half said their controls, recovery plans or exit arrangements had never been tested. Firms in the Leading tier were more than twice as likely to get through their hardest sovereignty event without material disruption: 52%, against 22% for firms at the "establishing" stage.

IBM organises the index around six questions an organisation should be able to answer with proof. The exit question asks: "Can you prove you could change provider or recover operations if needed?" We expect many NZ businesses that use AI through software subscriptions would struggle to answer that question with evidence, because few have ever rehearsed moving an AI workload off its current platform.

What the gap means under NZ privacy law

New Zealand has no general rule requiring data to stay onshore. The Privacy Act puts responsibility on the organisation that holds the information. The Privacy Commissioner's guidance on disclosing information overseas says that when a provider holds personal information as your agent, for storage or processing, the law treats your organisation as the holder. You remain responsible for the personal information you put in the cloud. If the provider uses or discloses the information for its own purposes, the law treats both parties as holding it. A customer or the Commissioner asking where a prompt with personal details went therefore needs an answer from your own records and contracts.

Where AI data ends up depends on configuration as much as on the vendor. OpenAI offers at-rest data residency to eligible ChatGPT Enterprise, Edu and API customers in ten regions, including Australia. New Zealand isn't one of them. On Amazon Bedrock in Auckland, the AU geographic inference profile can serve a request from Auckland, Sydney or Melbourne. The global profile sends requests to commercial AWS regions worldwide, depending on available capacity. AWS says it logs every cross-region request in CloudTrail in the source region. An Auckland-based team therefore has a record of each call, provided logging is switched on and the logs are kept.

The Bedrock example shows why confidence on its own counts for little. A manager can believe the company's AI use stays in Australia while a developer has chosen the global profile for extra throughput. The only way to settle the question is to check configuration settings and logs, which few small firms review.

Practical steps for NZ firms

Small and mid-sized firms don't need IBM's full framework to act on the finding. A short evidence routine, repeated regularly, covers most of what a customer due diligence questionnaire or a privacy complaint would ask for.

• List every AI tool that handles customer or staff data, including AI features switched on inside software you already use. For each tool, record the processing region and whether the contract lets the provider use your data for its own purposes.
• Each quarter, collect proof that the settings haven't changed, such as a screenshot of the residency setting and a sample of audit logs. Store the proof where an auditor can find it without asking the person who set the tool up.
• Where the platform allows, enforce region choices with policy. One example is AWS service control policies that limit Bedrock to the regions you've approved.
• Once a year, test exit on one AI workload. Export the prompts and configuration, run the workload on another model or a private AI server, and record how long the move took and what broke.
• Make one named person responsible for the evidence file, and add AI data handling questions to supplier reviews so the record keeps up with vendor contract changes.

If you want this inventory and testing built into your wider AI governance, our AI consultancy page explains how we approach that work.