Skip to main content

The Hidden Workload Behind Public Sector AI Adoption

Your rollout is complete, your benefits case isn't landing, and the reason is sitting in the middle of your org chart.

Avatar
Patrick Joy 23 September 2026 · 4 min read
The Hidden Workload Behind Public Sector AI Adoption

Across every level of government, the same sentence lands in the same status report: rollout complete. The system is live, the milestones are closed, the project team is thanked. Then the benefits quietly fail to arrive, and nobody in the room can explain the gap without sounding as though they have mismanaged something.

The explanation is almost never technical. In the organisations we work with, the platform is usually doing exactly what it was built to do. What has not changed is the way people actually work: the behaviours, judgements and workarounds sitting underneath the process map. Declare a rollout complete without redesigning the lived experience of the work, and people do what people reliably do: they find creative ways around the system.

Our recent study found that 18 per cent of people admitted to using shadow systems and technology. My honest read is that the true figure is far higher. This is a measurement problem, not a compliance one. People understate it because the official way of doing things and the practical way of getting the job done have drifted apart. The ‘magic spreadsheets’ that automation was meant to retire have not disappeared; they have simply gone private. Some are now prettier, having been rebuilt with AI. They are still there, still load-bearing, and still invisible to the benefits report.

Public sector carries more nuance here than private sector, because industrial relations settings have not kept pace with how work has changed. Pay grades and job definitions assume a stability that no longer exists. Jobs are fundamentally changing, and when an agency tells people nothing has changed while changing everything about their day, shadow usage becomes the rational response rather than the deviant one.



Legacy code is the easy half

‘Legacy’ is a sanitised word for something far less flattering: the residual systems nobody knows how to retire. But legacy code is the tractable half of the problem. The harder half is the legacy behaviour that 20 or 30 years of that code has produced. Decommissioning a platform does not decommission the habits, approval reflexes and informal decision rules it created, and that friction surfaces late in delivery, long after the business case was signed.

This exposes the accounting flaw underneath most digital investment. Business cases count hours saved, or a citizen outcome delivered faster. Very few count the hours needed to check what the system produces, or the hours spent redoing work the system got confidently wrong. That is where benefits erode. Most AI errors are not absurd. They are plausible. They read as reasonable, they are delivered with confidence, decisions get made on them, and the correction cost lands somewhere that was never modelled.



The load has a postcode

Checking is also unevenly distributed, in a way that should concern anyone signing a workforce plan. To check an output you need two things: a belief that your judgement matters, and enough experience to know what the right answer looks like. Senior people have both, so they check more and find more errors. Entry-level and junior staff often have neither yet, so they check less and place more faith in the system.

So verification load migrates upwards, into the middle. The middle is not frozen, as it is so often described. It is compressed from both directions. Decisions have been pushed down into it without clear decision trees, and checking has been pushed up into it, at a time when there is very little slack anywhere in public service to absorb either. The phrase ‘human in the loop’ badly undervalues how much effort the human in that loop is expending.

Citizens feel this before any dashboard does. When the middle has no bandwidth, the person meant to help someone through a difficult matter has none either. Worse, many systems strip away the discretion public servants once used to resolve non-conforming cases on the fly. Anything outside the process map stalls. Citizen experience erodes in precisely the programs whose business case promised to improve it.



Three corrections that change the outcome

The good news is that the fix is not another platform. It is a small number of design decisions, and they are available to you on a live program right now.

Name the accountability. For every significant output, decision and quality standard, name the person or level responsible for checking it, then build a system that holds them to it without breaking them. It sounds almost too simple. It is still not done broadly across the market, and its absence is one of the most reliable predictors of a rollout that completes without delivering.

Cost the checking. Put verification and rework into the benefits model as real, funded work, and invest in the capability to do it well. Done properly, checking is not a drag. It is the mechanism that converts a plausible output into a defensible decision, which is the only version of speed that survives scrutiny.

Manage the psychosocial risk deliberately. Cognitive load, job control, role clarity and job security are not soft concerns. They are regulated work health and safety obligations, and they are also, conveniently, the framework for high-performing teams. Change itself consumes cognitive capacity. Yet the standard pattern is to withdraw bandwidth at exactly that moment, either by trimming headcount or running dual systems for verification, when people have the least capacity to absorb it. Removing discretion raises stress. Ambiguous roles slow decisions. And guaranteeing that nobody will lose their job is a promise worth making only if it is certainly true, because trust does not survive being wrong about that.

Give oxygen to the middle layer and success rates lift, because those are the people who make or break delivery.


A final word on why checking earns its keep. Preparing slides for a recent keynote, I asked whether every word in a ‘thank you’ word cloud actually meant thank you. Two did not. Nothing was offensive, but they were wrong, and one was invented outright. Always check the outputs of your systems, and fund the people doing it.

Published by

Patrick Joy Head of Research and Advisory