.png)
Six years at a GovTech company has given me a front-row seat to a lot of government AI pilots – not building them, but hearing how projects go and learning from the product and delivery people who run them.
From that seat, one pattern is hard to miss. Across government, pilots look impressive. Yet, most stall before they reach production while only a few succeed. I'm the commercial side of this business, not an engineer. But when I synthesise what our teams keep telling me, it lands on something simple.
The fastest and most accountable way to put AI to work in government isn't a sweeping programme, and it isn't a general-purpose agent on top of everything. It's to automate one task at a time, inside a process the organisation already runs, with a human still accountable for the case.
Government work has a structure
Whenever our teams map a government process, the same shape shows up. A permit, an inspection, a benefit claim or a case file moves through recognisable steps: information comes in, the case is reviewed, a decision is prepared, and the outcome is recorded. The details differ; the logic repeats. Government work is processes made of steps, and steps made of tasks - each with a purpose, an instruction, a responsible role and an expected output. That structure isn't red tape. It's exactly what makes parts of the work safe to automate.
Automate the task, not everything
Our product people describe the trap better than I can. Customers often expect a magic box: put a general AI on top of everything and let it run the place on its own. It doesn't work like that, because the model has no context. It doesn't know which documents belong to a case, who may see them, or when a human must approve.
What they've found works is narrower and far more reliable: automate the specific, repetitive tasks inside a process, one at a time. The task already has an instruction, and that instruction becomes the AI's brief. The AI does a defined job; a case worker still owns the case. You're giving the AI a role, not the keys.
Make compliance a by-product
The people who built our platform have leaned on one principle for twenty years, and it's the part I find myself repeating most: compliance can't depend on someone remembering to do it. Archiving, traceability and record-keeping must happen as a by-product of the work. As a case worker does their job, compliance just happens.
The same must hold when AI is the user - and the bar is higher, because people increasingly expect to understand and challenge automated decisions. If the AI works inside the process, on the same case, under the same access rights, leaving the same audit trail as a person, then every action it takes is recorded automatically. Make the AI a case worker, not a chatbot.
It starts with one process
When I ask our delivery teams what makes a government AI project succeed, they don't talk about models. They talk about scope. Their rule is blunt, and it has stuck with me: start with one small process. Try to automate everything at once and you build what they calla death star project - huge, slow, and doomed to fail. The pattern that worksis almost boringly simple: pick one bounded, repetitive process, automate the repetitive tasks in it, and run a focused pilot of around ten weeks. You get a working version in three or four weeks, iterate to something real by week ten, and then decide whether to go live. Done on a governed platform, that first version isn't a throwaway prototype. It's version one of the real thing.
A process library is how you scale without losing control
One automated process is a proofpoint; many is an operating model. The way our teams keep it from turning into a mess is a process library: define each process once, then reuse and adapt it - a permit process adjusted for another permit type, a document-check task reused elsewhere. The real risk at scale is fragmentation creeping back in, every team running its own pilot with its own tools. A process library keeps one overviewand lets AI expand across the work while accountability and control stay intact.
What this means in practice
I don't write this as the person who built any of it. I write it as the person lucky enough to sit close to the people who did, and to notice the same pattern turning up again and again. Wherever it works, it looks the same: start with one process, automate its repetitive tasks on a proven platform, prove it in weeks, and scale through a library - with every AI action auditable by design. Because public administration is structurally similar from one country to another, an approach proven in one government travels to others.
The one thing I'd pass on
Government AI doesn't have to stall at the pilot. From everything I've seen our teams learn, it scales when you build it one automated task at a time - accountable by design, on a foundation you already trust.
If you're mapping where to start,I'm always happy to compare notes on what has worked elsewhere.
