Around 45% of UK public sector AI initiatives run as standalone experiments rather than sitting inside the workflows that actually deliver services, according to a Censuswide survey of 1,000 public sector staff, commissioned by Appian and published in February 2026. In the same research, only 29% of those staff said their department was meeting the bulk of what it had promised on AI. Those two numbers are usually read as a strategy failure. They are better read as an infrastructure invoice that nobody has agreed to pay.
The problem is not which model you buy
Writing in THINK Digital Partners this month, Appian’s UK public sector lead Peter Corpe argued that the sector “does not have an AI problem” but rather “an orchestration problem”: technology fixed to the outside of a service inherits that service’s existing fragmentation instead of removing it. That diagnosis is right, and it is a useful corrective to a debate that has spent eighteen months arguing about which frontier model a department should license.
Where it stops short is the next question. If the answer is to redesign the process and build AI into it, what is the process actually made of? In a UK department, the process is not a diagram. It is a stack of systems of record, some of them older than the policy they now administer, connected by exports, spreadsheets and people re-keying data between screens. Redesigning that is not a workshop. It is a capital programme.
Strategic Reality: Embed AI in the process and rebuild the integration layer between six systems of record, two of which are out of vendor support are the same sentence. Only one of them can be costed, and it is not the one that appears in the business case.
This is what separates the integration constraint from the two adjacent arguments Resultsense has made elsewhere. The accountability question is about whether the law already binds automated decisions and whether departments are designing around it. The procurement and delivery question is about how Whitehall buys and governs digital change. Both are real. Neither is what stops a working pilot from reaching production. What stops it is that the pilot read from a copy of the data and production would have to read from the source.
The numbers that matter
| Measure | Figure | Source |
|---|---|---|
| Central government technology estate classified as legacy | 28% in 2024, up from 26% in 2023 (range 10-60%) | State of digital government review, Jan 2025 |
| Legacy share across NHS trusts and police forces | 10-50% and 10-70% respectively | Same review |
| Bodies unable to put a number on their own legacy estate | ~15% of survey respondents | Same review |
| Red-rated legacy systems with no remediation funding | 28% | Same review |
| UK government bodies carrying Windows technical debt | 84% | Cloudhouse, State of Technical Debt 2025 |
| Public sector AI deployed as a bolt-on or standalone tool | 45% | Appian/Censuswide, Feb 2026 |
| Staff saying their department meets most of its AI promises | 29% | Appian/Censuswide, Feb 2026 |
| UK adults unable to identify any government use of AI | 75% | Appian/Censuswide, Feb 2026 |
What “bolt-on” actually looks like inside a department
The government’s own State of digital government review, published in January 2025, has a better phrase for this than anything in the vendor literature. It describes services with a “digital veneer”: a modern front end resting on manual operations underneath. Its worked example is Pension Credit, where the citizen completes an online application and a case worker then re-enters the information into several separate legacy systems.
Put a copilot in front of that service and you speed up the case worker’s typing. The re-keying remains, because the re-keying is not a productivity defect. It is the integration layer. It exists because the systems cannot talk to each other and a human is cheaper to deploy than an interface.
The review is blunt about how deep this goes. HMRC’s COBOL systems need additional software before they can share data over an API at all. Defra estimated that 60% of its contact centre calls come from broken or unclear digital pathways. Councils, the review notes, struggle to make systems interoperable because incumbent suppliers obstruct it or price the APIs beyond reach. Resultsense covered the same pattern from the supplier side in February, when Cloudhouse research found 84% of government organisations carrying Windows technical debt and three in five saying legacy platforms were already blocking AI adoption.
Critical Context: A department can buy a state of the art model and still have no lawful, reliable, real-time way to give it the record it needs to reason about. Model capability has not been the binding constraint in UK public services for at least two years. Data access has.
This is also the most plausible explanation for the finding that 75% of UK adults could not identify any way in which government currently uses AI. It is not a communications failure. Work that never reaches the citizen-facing pathway is genuinely invisible, because nothing the citizen experiences has changed.
Why the integration bill never gets paid
Here the argument has to go somewhere the source article does not. Departments are not choosing bolt-on deployment because they misunderstand transformation. They are choosing it because it is the only shape of AI work the funding model will reliably approve.
The review sets this out plainly. Across the Spending Reviews of 2020 and 2021, just 43-46% of the new digital and data money going to departments was day-to-day resource funding, against a Gartner public sector benchmark of 78%. Around 65% of the digital and data leaders surveyed said the funding model was not built to let them both invest in services and keep the current ones running. Half said that where legacy remediation money exists at all, it is routinely diverted to something more urgent. The DVLA example in the review is a remediation programme for a red-rated system deferred to fund an electric vehicle policy change.
So the incentives point one way. A chatbot is a discrete project with a demo at the end. An integration layer is years of unglamorous resource spend with no ribbon to cut, competing against statutory pressures that arrive without their own budget. Meanwhile legacy maintenance runs at three to four times the cost of modern alternatives, so deferral compounds: each year of delay makes the eventual bill larger and the case for deferring it again stronger.
Hidden Cost: Every bolt-on tool adds a new integration surface to an estate that already cannot fund the integrations it has. The pilot is cheap. The eleventh pilot, each with its own data extract and its own access route into a system of record, is a second legacy estate being built in real time.
Who carries the cost
| Stakeholder | What they experience | What actually changed |
|---|---|---|
| Case workers | A drafting assistant that speeds up one step | Still re-keying between systems; the queue is unchanged |
| Digital leadership | Adoption metrics rising, delivery metrics flat | Nothing structural; 89% of surveyed staff say their organisation cannot fully use AI |
| Finance | Discrete project costs, visible and bounded | Unfunded integration debt accruing off the ledger |
| Citizens | Service timelines broadly as before | Nothing; hence the 75% who can point to no government use |
| Incumbent suppliers | Continued relevance of the system of record | Position strengthened, since API access is theirs to price |
What to do instead
The Appian research found that 55% of public sector workers and 56% of citizens agree existing processes need fixing before new AI is introduced. That is a rare alignment, and it is worth taking literally rather than as a slogan. Three things follow.
Fund the pipes as an asset, not as a project overhead. Integration and data quality work needs its own line, its own owner and multi-year resource funding, assessed on whether services can read and write each other’s records rather than on how many tools were shipped. If it is a cost inside someone else’s AI business case, it is the first thing cut when the case gets challenged.
Make data access a condition of deployment, not a discovery. Before a pilot begins, establish which system of record holds the authoritative data, whether it can be read in real time, who owns write access, and what the API costs. Where the answer is “the supplier will quote”, that quote is part of the total cost of the AI programme and belongs in the paper.
Test at the pathway, not the task. A tool that saves eleven minutes per case in a pathway with a nine-week bottleneck elsewhere has saved nothing a citizen can perceive. Measure end to end or the measurement will flatter the pilot.
Implementation Note: The sequencing question is not process first or AI first. It is whether that integration work is a dependency of the AI programme or a separate programme the AI programme assumes has already happened. Almost every stalled public sector pilot has made the second assumption.
Maturity changes the emphasis. An organisation with no legacy register should start there, because the review found roughly 15% of respondents could not put a number on their own legacy estate, and you cannot plan around an unmeasured constraint. An organisation with a register and a red-rated backlog should be protecting remediation funding from reallocation before it commissions anything new. An organisation that has already built a working integration layer is the one for which model choice finally becomes the interesting question, and there are not many of them.
Four things that make this harder than it looks
The vendor and the diagnosis share an interest. The research behind the September commentary is Appian’s own, run by Censuswide and published in February 2026, and Appian sells process automation. That does not make the 45% figure wrong; the survey method is disclosed and the finding is consistent with the government’s own review. It does mean the prescription arrives pre-shaped, and buyers should notice that orchestration is also a product category.
Integration work is politically illegible. A minister can open a chatbot. Nobody opens an API gateway. The work that would unblock delivery is the work least able to generate the evidence of progress that sustains its own funding, which is why it keeps losing to the work that can.
Agentic AI raises the stakes rather than routing around them. A drafting assistant that reads stale data produces a document a human checks. An agent that acts on stale data produces an action against a citizen’s record. The tolerance for fragmented data falls sharply the moment a system is permitted to do something rather than suggest it.
Retrieval-augmented generation is often sold as the integration fix and is not one. Pointing a model at a document store improves what it can cite. It does not make the model able to read a live case record, write back to it, or know which of four conflicting addresses is the current one. Retrieval solves a knowledge problem. Most public sector AI failures are transaction problems.
⚠️ Warning: The most common route to a false green status is a pilot run against an exported snapshot. It demonstrates that the model works and proves nothing about whether the service can be changed, because the hard part - live, governed, bidirectional access to the system of record - was the part the export removed.
What this means for anyone buying AI into a public body
The gap between 29% and the ambition in every published AI strategy is not going to be closed by better models, and it is not going to be closed by faster procurement either. Both of those have improved measurably in the last two years and delivery has not followed. What has not improved is the proportion of the estate that can participate in an automated workflow at all, which the government measured at 28% legacy in central departments and rising.
Three things separate the organisations that get past pilots from the ones that do not. They know the size and condition of their own estate. They have funded integration as a standing capability rather than as a line item inside someone else’s project. And they judge AI on whether a citizen’s journey through a service got shorter, not on whether staff report that a tool is useful.
Take Action: Before the next AI business case is approved, ask three questions of it. Which system of record does this need, and can it be read live? Who is paying for that access, and is the cost in this paper? If the answer to either of the first two is unresolved, the case is for a pilot, and it should say so.
None of this is an argument against public sector AI. It is an argument that the sector has spent two years optimising the visible half of the problem whilst the invisible half, the part that determines whether anything reaches a citizen, has been getting slowly worse. Until the integration layer is funded like the asset it is, government will keep buying intelligence it cannot connect to anything.
Source: Why government must move beyond bolt-on AI by Peter Corpe, Appian’s UK public sector industry lead (THINK Digital Partners, 10 September 2026). Survey figures verified against Appian’s research release (24 February 2026), reporting the 2026 UK Public Sector AI Adoption Outlook. Appian commissioned that study; Censuswide ran the fieldwork, polling 1,000 public sector staff and 1,000 UK adults. Legacy estate, funding and service pathway figures are from the State of digital government review (CP 1251, published 21 January 2025).
This strategic analysis was written by Resultsense, a UK-focused AI news and analysis publication. Read more analysis at Insights, or get in touch.