Photo: Google Gemini · AI-generated
Every public-sector technology plan for 2026 has AI in it. Chatbots that answer citizen questions. Document processing. Case triage.
Much less of it is running in production.
The reason is usually not the model. It is that the data these systems need lives in separate systems that were never designed to talk to each other. The research keeps landing in the same place: legacy IT and fragmented data are the main brake on public-sector AI, not the AI itself. The OECD’s Digital Government Outlook describes government data ecosystems as fragmented, with weak quality management and little reuse of authoritative datasets. Deloitte’s 2026 GovTech trends make a similar point from the delivery side, and UK public-sector research this year points squarely at legacy IT debt.
So the bottleneck is integration. It is older and less interesting than AI. It is also the actual work.
A resident sees one service. The government runs eleven systems.
A resident wants to pay a fine. That is one task.
Behind it sit a fines system, a vehicle registry, a payments provider and an identity check — often owned by different departments, sometimes by different authorities, each with its own data format and its own idea of what a “notice number” means.
When we built PayCity, which lets residents of South African cities view and pay traffic fines from their phone, the visible product was two native apps. The engineering that made it possible was the layer underneath: an integration that pulls fines data from several local authorities’ back-office systems and normalises it into one consistent view.
That normalisation is the hard part. Not because any single connection is difficult, but because each source disagrees with the others in small ways — and a citizen-facing app cannot show a resident a fine with the wrong amount. Not even once.
No AI feature helps here. A model reading from four systems that disagree gives confident answers that are wrong. That is worse than no feature at all.
Integration is a product, not a project
The common mistake is to treat integration as a one-time cost. You connect the systems, the project closes, the team moves on.
Government systems do not hold still. Formats change. A department migrates. A new authority joins. If the integration was run as a project, it starts decaying the day it ships.
CarLicence takes the opposite approach. It turns South Africa’s licence disc renewal — a manual and tedious process — into a real-time API that businesses embed in their own websites, apps, POS systems and even ATMs. The integration is not a step towards the product. The integration is the product.
So it gets built like one: cloud automation that keeps renewal status current without anyone touching it, monitoring that catches degradation before a partner’s customer does, and a team that stays with it. That is the difference between an integration that works at launch and one that still works in year four.
What to ask before you buy the AI
Three questions will tell you whether a public-sector AI project can actually ship.
Where does the data live, and who owns each system? If the answer spans three departments, that is your timeline — not the model selection.
Is the data reliable enough to act on without a human checking? A chatbot quoting a wrong balance is a trust failure. Trust is the one thing a public service cannot rebuild quickly.
Who maintains the connections after launch? If nobody is named, the project has an expiry date.
None of this is an argument against AI in government. It is an argument about order. The agencies that ship useful AI over the next few years will be the ones doing the dull work now: connecting systems, agreeing what the authoritative record is, and keeping those connections alive.
That work is not new and it does not demo well. It is still the thing that decides whether anything else works.
If you are building citizen services — directly, or as the agency holding the client relationship — we should talk.