The more important question is this: if an organisation becomes dependent on any single provider for its infrastructure, data or critical capability, does it still have meaningful control if circumstances change?
I’ve written before that sovereignty isn’t about building walls. I think the same principle applies here.
Start with the risk, not the provider
Recent reporting by The Guardian has put this issue firmly back on the agenda. Its investigation reported that sensitive information from more than 40 UK police forces is held on Microsoft Azure and revisited a 2017 police security assessment that identified potential risks from foreign actors and US government access.
Those findings are disputed. Microsoft says it has never provided UK government data in response to a US or other government request, while policing representatives have pointed to UK data-centre requirements and strict controls around access.
That distinction matters. This shouldn’t become an argument built on the assumption that sensitive UK police data is routinely being accessed by a foreign government. There is no evidence presented that this is happening.
But for policing and the wider national security environment, risk planning isn’t only about what has happened. It is also about what could happen, who can make it happen and what control you retain if circumstances change.
That is where the sovereignty question becomes much more interesting.
Hyperscalers and sovereignty are not mutually exclusive
Microsoft is an important partner to Whitespace, and its technology is already deeply embedded across UK public services.
There will be plenty of workloads where Azure is exactly the right environment. The same is true of other hyperscalers.
But being a good technology partner shouldn’t require pretending that one architecture is right for every problem.
Some workloads may be entirely appropriate for public cloud. Others may require tighter controls over data, infrastructure and access. Some may need to operate at the edge. The most sensitive may need to work in completely disconnected and air-gapped environments.
The decision should follow the requirement.
That is what technology agnosticism means in practice. It isn’t refusing to work with the major technology providers. It is retaining the ability to use them where they are the right answer without making them the only answer.
Residency is only part of the question
For years, conversations about sovereignty have often started and ended with data residency: where is the server and where does the data physically live?
That matters, but it doesn’t tell you everything you need to know.
I think there are three questions that start with residency:
Where does my data live?
Who can access or control it?
Who ultimately decides where it goes and how it is used?
If you can answer all three confidently, you are much closer to understanding your actual level of sovereignty.
And as AI becomes embedded into policing, defence and national security workflows, we need to apply the same thinking beyond data.
Which models are being used? Who can change them? Where does inference happen? What infrastructure does the capability depend on? Can the organisation move the workload elsewhere? Can it continue operating if connectivity disappears? And can it understand and audit what the system has done?
AI sovereignty is therefore not simply a cloud-security question. It is an architectural and operational one.
Dependency is the part we need to talk about
No serious organisation is going to eliminate technology dependency.
Nor should it try.
Modern technology depends on global infrastructure, specialist suppliers, foundation models, hardware and engineering talent. Trying to recreate every layer domestically would be enormously expensive and, in many cases, unnecessary.
The goal should instead be to understand where dependency exists and where dependency becomes unacceptable.
A productivity tool going offline is inconvenient.
Losing access to a capability supporting a high-consequence policing or national security workflow is something very different.
Those workloads deserve a different conversation.
For the most sensitive applications, organisations need to know that they retain sufficient control over the data, models, applications and infrastructure that matter most — including the ability to change supplier, deployment environment or model without rebuilding everything around them.
That is one of the reasons we have taken an agnostic approach at Whitespace.
Collective, our sovereign AI operating system, is designed to support AI capabilities across different models, infrastructure and deployment environments. Our Solutions Engineering approach then starts with the problem, the users, the data and the constraints before determining what should actually be built and where it should operate.
Sometimes the answer may involve Microsoft technology. Sometimes another environment will make more sense. Sometimes the requirement will dictate something far more controlled or completely disconnected.
The important thing is that the architecture hasn’t made that decision for you before you have even understood the problem.
One uncomfortable truth
There is no such thing as complete independence.
Even the most sovereign system will contain dependencies somewhere: chips, software libraries, hardware, models, people or supply chains.
So I don’t think the useful question is: “Is this system 100% sovereign?”
A better question is: “Are we sovereign at the layers where losing control would actually matter?”
For policing and national security, that threshold will rightly be higher than it is for most organisations.
That doesn’t mean turning away from global technology companies. It means working with them from a position of architectural choice rather than unavoidable dependency.
The distinction matters.
The future of sovereign technology shouldn’t be about choosing between global innovation and national control. We need both.
For me, the principle remains the same: interoperability without dependency.
Use the best technology available. Collaborate with partners and allies. Take advantage of hyperscale infrastructure where it makes sense.
But for the systems and data that carry national risk, make sure you still hold the keys.
