The question buyers forget to ask until it's too late

There is a question every public sector organisation should put to an AI supplier early - and that, too often, only surfaces when a data protection officer raises it late in the process: “Where does our data live, who can touch it, and will it ever be used to train your models?” For an organisation handling sensitive personal and case data, those are not technical footnotes. They are the whole conversation.

In 2026, sovereignty has moved from a nice-to-have to a precondition. Across regulated sectors, organisations are increasingly unwilling to scale generative AI without sovereign guarantees - and the goalposts have shifted. Sovereignty is no longer just about which country a server sits in; it has become an architecture decision spanning the entire AI lifecycle. This article explains what sovereign AI really means for public services, why “it's stored in the UK” is necessary but not sufficient, the questions to ask any vendor, and how to tell genuine sovereignty from a marketing label.

Why sovereignty stopped being optional in 2026

Three forces have turned data sovereignty from a procurement preference into a baseline expectation.

National strategy put sovereignty at the centre

The UK's AI Opportunities Action Plan placed sovereign capability - including sovereign compute and a National Data Library to unlock public sector data safely - at the heart of the national agenda. The signal to the public sector is clear: control over data and the infrastructure that processes it is treated as a strategic priority, not just an organisational preference.

The market raced to offer residency - so it became table stakes

Cloud providers have responded at speed. Microsoft, for example, began offering in-country processing for Microsoft 365 Copilot interactions in the UK from the end of 2025, and has expanded its Sovereign Cloud with public, private and local deployment options, customer-managed encryption keys, and controls that restrict operator access to data. The practical consequence is important: UK data residency is now widely available from the major platforms. Because almost any supplier can now claim it, residency alone no longer distinguishes a trustworthy solution from a risky one.

Regulation raised the bar on proof

UK data protection law - UK GDPR, the Data Protection Act 2018 and the Data (Use and Access) Act 2025 - together with the EU AI Act's obligations for high-risk systems taking effect in August 2026, mean buyers are now expected to evidence where data goes and who controls it. “Trust us” is no longer an acceptable answer; demonstrable control is.

The net effect is that the central question has moved on - from “is our data in the UK?” to “who controls it across its whole lifecycle, and is it ever reused?”

Residency is necessary but not sufficient: the three layers of sovereign AI

Genuine sovereignty is not a single feature. It is three layers, and a solution is only as sovereign as its weakest one.

1. Data residency - where it lives

The first layer is geographic: data is stored and processed in the UK. But region-pinning is necessary, not sufficient. Buyers should confirm that processing - every step of an AI request, not just storage - stays in-region, and that the specific models and features they rely on are actually available there rather than quietly routing elsewhere. Where data sits at rest is the easy part; where it travels mid-process is where assurances often quietly break down.

2. Operational sovereignty - who can reach it

The second layer is control. Sovereignty is about who can access data, not only where it sits. That means customer-managed encryption keys; encryption at rest, in transit and in use; strict limits on any provider or operator access, with tamper-evident logging when it occurs; and role-based access governed by the organisation's own identity. A solution hosted in the UK but operable by people outside the organisation's control, with no audit trail, is not sovereign in any meaningful sense.

3. Model and lifecycle sovereignty - what happens to your data and what it creates

The third layer is the clincher, and the one most often glossed over. First: a contractual guarantee that your data - and anything derived from it - is never used to train the vendor's or any third party's models. Second, a subtler point that catches many buyers out: the artefacts AI creates from your data are themselves sensitive. Transcripts, summaries, embeddings and vector search indexes should be treated as regulated data objects, subject to the same residency, access and audit rules as the source records they came from. The strongest position, and increasingly the 2026 best practice, is to deploy AI inside the organisation's own cloud tenancy - so the data, and everything generated from it, stays within a boundary the organisation actually controls.

The questions every public sector buyer must ask

Use this as a due-diligence tool. A genuinely sovereign supplier answers each without hedging; vagueness on any of them is the finding.

In which country is our data stored - and in which country is it processed at every step of an AI request?

Will our data, or anything derived from it, ever be used to train your models or a third party's? Is that guaranteed in the contract?

Does the solution run inside our own cloud tenancy, under our identity and our encryption keys?

Who on your side can access our data, under what circumstances, and can we see an audit trail when they do?

How are derived artefacts - transcripts, summaries, embeddings, search indexes - stored, secured and governed?

Is our data encrypted at rest, in transit and in use?

At the end of the contract, can we extract everything, and will all your copies be deleted?

Which residency and security accreditations do you hold or align to - UK data-centre regions, ISO/IEC 27001, and AI-specific standards such as ISO/IEC 42001?

Why “it runs on Azure” is not the answer

Now that sovereign-cloud tiers and in-country processing are widely available, almost any supplier can say their solution “runs on Azure” or “is hosted in the UK.” That is reassuring - and no longer differentiating. Worse, it can mask the questions that actually decide whether data is safe.

The platform is not the same as the deployment

Two solutions can run on the very same UK cloud region and still differ enormously: one deployed in the vendor's multi-tenant environment, with your data flowing through systems they operate; the other deployed inside your own tenancy, under your keys and identity, with nothing crossing your boundary. The cloud region is identical; the sovereignty is not.

The cloud supplies building blocks; it does not, by itself, deliver sovereignty

As the 2026 consensus puts it, sovereignty is an architecture decision, not a feature you switch on. Someone has to design the deployment, configure the controls, govern the keys, contain the data flows and prove it end to end - and that is the work of a capable delivery partner, not the platform alone. So the right test is not “do you use a UK cloud?” It is: “is our data deployed in our own controlled environment, never reused, and provably governed across its whole lifecycle?”

Sovereignty is an enabler, not a constraint

Treated well, sovereignty speeds adoption rather than slowing it. Assurance accelerates delivery: clear, demonstrable sovereignty moves a project through DPIA, information governance and security assurance far faster - those reviews are where deployments otherwise stall. It earns public trust: residents engage more readily with services when they can be assured their information stays under public control. It future-proofs: with structural change and tightening regulation on the horizon, sovereign-by-design architecture transfers and scales cleanly between organisations, while data entangled in a vendor's environment does not. Sovereignty is not the price of doing AI safely; it is what makes doing AI at scale possible at all.

Build it in, don't bolt it on

The clearest sign of a genuinely sovereign AI partner is that control is designed into the deployment, not promised in the brochure. Our own approach reflects that: we deploy inside the customer's own cloud tenancy, in the UK region, under their identity and encryption keys; their data - and everything derived from it, including transcripts, summaries and search indexes - never leaves that boundary and is never used to train external models; and access is least-privilege and fully audited. Sovereignty as the default state of the system, not a premium bolt-on.

For public services, sovereignty is no longer a box ticked at the end. It is the foundation that decides whether AI can be trusted with the data that matters most. Residency is where the conversation starts, not where it ends - and the organisations that get this right ask the harder questions early, and choose partners who can answer every one of them without hesitation.

If you are setting your data-sovereignty requirements, or testing a supplier against them, we would be glad to share how we design AI to keep public sector data under public control.