AI Sovereignty in Government: challenging questions that need serious consideration


The IBM Institute for Business Value recently published research on what they call the calculus of AI sovereignty. Their headline finding is striking: only 9% of executives say they have an excellent understanding of their AI dependencies, yet 71% say switching their primary AI vendor or model would be difficult today. Most organisations, the report concludes, are not in control of their AI estate and the gap between adoption and control is widening at exactly the moment AI is becoming indispensable.

It is a well argued paper. But it is written for enterprise leaders in commercial organisations, where the consequences of getting sovereignty wrong are measured in margin pressure and dependence on a single vendor. In UK government, the consequences are different. We are talking about citizen data, public accountability, and the kind of ministerial risk that ends programmes. That changes the conversation considerably.

I have been working at the intersection of AI and government digital delivery for the past two years. Here is what I am actually seeing.

The inheritance problem

Government AI is not being built on a blank canvas. It is being layered onto infrastructure that was designed to answer a different question.

The cloud journey in government is well understood. Departments moved to AWS, Azure, or GCP for scalability, resilience, and cost efficiency. Those were the right decisions for the problems they were solving at the time. But that infrastructure is now the foundation on which AI environments are being built, and the original design decisions shape what is possible, what is constrained, and what requires significant reengineering to get right.

This is not unique to government. The IBM IBV research makes the same observation about enterprise AI more broadly: most AI ecosystems are not the result of deliberate design. They are the accumulation of constraints, workarounds, and inherited decisions. What is different in government is that the white space is real. Many of the programmes I work on are genuinely new there is no legacy AI to unpick. But that does not mean the design decisions are unconstrained. They are shaped by the infrastructure choices that came before, and by governance frameworks that were built for a world that did not include foundation models.

The risk is that AI gets bolted onto existing architecture rather than designed into it. The opportunity, and the discipline required, is to treat the AI design decision as a primary question, not an extension of what is already there.

Data management is challenging

The IBM IBV research identifies three dimensions of AI sovereignty: data, models, and infrastructure. In my experience, data causes the most friction and for a reason the report touches on but does not fully explore in a government context.

Cloud infrastructure sovereignty is largely solved. Cloud regions based in the UK exist. Data residency for storage is understood and contractually manageable. What is not well understood is what happens at the model layer.

If a department wants to use a large language model to power a natural language query interface over its operational data a genuinely useful capability the question that stops the programme is not where is the data stored? It is when a query is processed by a global model, does citizen data leave UK jurisdiction?” That is a different question, and it does not have a simple answer. It depends on the model, the deployment architecture, the API configuration, and the contractual terms with the model provider.

That single question can halt a programme. And it needs to be answered before the budget is set, not after the build has started. The IBM IBV research notes that executives estimate an average of 145 days to move their AI training data to a different environment. In government, the equivalent risk is not migration time. It is discovering during the programme that the architecture does not meet data handling requirements. That is a much more expensive problem.

The expectation gap

There is a tension in government AI delivery that I suspect many practitioners recognise but few say plainly.

For the past two years, the industry including IBM has been selling the power of AI. We have run demonstrations, built proof of concepts, and shown what is possible. That work has been valuable. It has created genuine appetite and genuine ambition in government clients who want to use AI to improve public services.

But it has also created an expectation gap. Clients now want to see the output. And they are not as interested in hearing about sovereignty constraints and governance frameworks as reasons why it cannot be immediately applied. The conversation about doing AI properly is increasingly heard as the conversation about why it cannot be done quickly.

This is a supplier problem as much as a client problem. Building with AI is now simple and fast enough that almost any supplier can produce a working prototype. The differentiator is not the ability to build something that looks impressive in a demonstration. It is the engineering rigour and design discipline to build something that can operate at enterprise scale, be audited, and remain sovereign. That is harder to show in a demo. But it is the thing that determines whether a programme succeeds at scale or accumulates technical debt that eventually stops it.

The IBM IBV research makes a useful point here: organisations with the strongest practical control across their AI stack protect 55% more operating profit from disruption driven by AI. The government equivalent is protecting programme continuity, ministerial confidence, and public trust. The investment in getting the foundations right is not a constraint on ambition. It is what makes ambition sustainable.

Government is taking this seriously but policy has not caught up

I want to be clear about something: government is not asleep on AI sovereignty. The departments and programmes I work with are taking these questions seriously. They are balancing the risk of getting it wrong against the very real opportunity cost of not using the best available tooling to deliver better public services. That is a genuinely difficult balance, and the people making those decisions are doing so thoughtfully.

What makes it harder is that different stakeholders carry different risk appetites. A digital delivery team and a data protection officer and a senior responsible owner will each weigh the same AI design decision differently. That is appropriate it is how good governance works. But it creates friction that needs to be managed, not avoided.

The deeper challenge is that policy has not kept pace with the technology. The frameworks that govern how government buys, deploys, and operates AI were not written with foundation models in mind. That gap is being filled, in practice, by the judgement of delivery teams and the governance frameworks that suppliers bring to the table. Trust in suppliers who can demonstrate mature and considered approaches to these questions is becoming a critical variable in whether AI programmes move forward.

What good looks like

The most effective approach I have seen is using proof of concepts deliberately not to demonstrate capability, but to force sovereignty and governance questions into design authority conversations early.

A well constructed POC does not just show what the AI can do. It surfaces the questions that need answering before an enterprise solution can be built: Where does the data go? Which model is being used, under what terms, and what happens if those terms change? What does the audit trail look like? How does this interact with existing data classification? These are not blockers. They are the design questions that determine whether the thing you build is fit for purpose at scale.

Treating these questions as investment rather than overhead and building the governance frameworks to answer them as part of the delivery process is what separates programmes that scale from programmes that stall.

The organisations that will benefit most

The IBM IBV research closes with a point I think applies directly to government: AI sovereignty is not about controlling everything. It is about knowing exactly what you control, where you are exposed, and ensuring critical operations can keep running no matter what the future brings.

In government, I would put it slightly differently. The organisations that will get the most from AI are those that ask the hard questions now about data, about models, about the infrastructure decisions already made and build the governance frameworks to answer them before the budget is committed and the build has started.

That requires suppliers who bring engineering rigour alongside delivery pace. It requires clients who are willing to invest time in the foundations even when the pressure is to show quick output.