New unitary councils can’t be AI-ready if their data isn’t merge-ready
There is a lot of excitement in local government about AI, automation and predictive insight. Understandably so. Councils are under pressure to meet rising demand with shrinking budgets, and better use of innovative technology is one of the few levers available.
But in my view, the more urgent question is not whether councils are ready for AI. It is whether their data is ready to support better decisions at all.
For many councils in England, local government reorganisation makes that question far more urgent. County and District councils are preparing to bring services, systems, teams and records together into new Unitary authorities. Every future ambition those councils have, from improving resident experience to targeting support earlier, will depend on whether that data can be trusted.
The challenge is that those records were created by different teams, for different services, under different pressures. They may all be accurate in their own context, but that does not mean they will make sense when brought together.
Here’s an unglamorous truth about local government IT: every council’s data estate is a kind of archaeological dig. Layers of it. There’s the current system, the system before that, kept for retention purposes, the Access database someone in revenues built in 2011 that turned out to be load-bearing, and the spreadsheet one Officer maintains because the “proper” system never quite handled that one exception.
None of this is a criticism. It’s what twenty years of doing more with less actually looks like up close. But when several of these estates must become one, all of that quiet improvisation surfaces at once.
And the differences run deeper than file formats. Two neighbouring districts can both run council tax and still mean subtly different things by the same field. Different discount schemes, different write-off policies, different local codes that made perfect sense to the team that invented them and to absolutely nobody else. Merge those records too quickly and the problem does not disappear. It just becomes harder to see. You end up with one dataset, but several different sets of assumptions hiding inside it.
Now imagine pointing an AI model at that. Any model grounded on merged-but-not-reconciled records will inherit every one of those buried contradictions and reproduce them at scale, confidently, in front of residents. I talk a lot about AI hallucination. I talk much less about AI faithfully telling the truth about data that is itself wrong.
Then there’s the question that should keep programme leads up at night; how many of your residents exist more than once?
A family might have a council tax account with the district, a social care file with the county, a housing application here, a blue badge there. Today those records live in separate organisations and nobody expects them to match. After vesting day, they belong to the same council, and residents will reasonably expect that council to have all of their information on one place.
This matters for everyday service delivery before AI even enters the picture. For future council services to feel joined-up, the front-end experience has to sit on top of structured, reconciled data and well-understood integrations. A single resident journey might need to check an address, capture a change in circumstances, assess eligibility, request evidence and pass information into several back-office systems. To the resident, that should feel simple. To the council, it only works if the data underneath has been properly understood.
Building that single view is hard, careful, sometimes manual work, and it cannot be left until the final month before go-live. The councils that come out of reorganisation AI-ready will be the ones that started this work before they’d chosen a single piece of software.
This isn’t only a back-office problem. It shows up the moment you try to put a service in front of an AI model, not just a database.
I was recently with a council walking through how an AI-driven portal could interpret a resident’s request and route it through the right policy and process. The conversation should have been about workflow design. Instead, the customer’s response was more revealing: he didn’t think the service itself had ever been mapped clearly enough to be put through something like that.
He was right, and it’s a more honest answer than most councils would give.
I talk about merging “data” as if it only means records: addresses, account numbers, case files. But every service carries a second, less visible layer underneath: the rules, exceptions, fee schedules and thresholds that decide what actually happens to a request once it lands.
Two merging councils won’t just have different codes in their council tax system. They’ll have genuinely different eligibility rules, different fee structures, different escalation logic, different exceptions that made sense to whoever built them and to nobody else since. None of that lives in a table you can export. Most of it lives in people’s heads.
That matters with or without AI in the picture. You can buy the best low-code platform or AI rules engine on the market, but if nobody in the service can say plainly “this is our eligibility logic, this is the fee schedule, this is what happens in this edge case,” the tool has nothing solid to configure. You can’t automate a decision that has never been made explicit. The constraint isn’t the technology. It’s the absence of a service definition for the technology to sit on.
It’s arguably the sharpest version of the data problem in this piece. The records need cleaning, yes, but the service logic itself often needs to be written down for the first time, in a form a non-technical service lead can own and adjust, before any of it can be merged, automated, or handed to an AI model with confidence.
There’s a comforting belief that data problems get fixed during migration, because that’s when you’re touching everything anyway. In my experience, the opposite happens. Migration is the worst possible moment to discover your data quality issues, because by then the vesting date won’t move and every anomaly becomes a decision made under pressure.
I’d go further. A new unitary council that has mapped its data estate, agreed ownership and cleaned its core records can make almost any sensible technology choice work, AI included. One that hasn’t will struggle no matter how good the tools are. The AI market is moving fast and the software market for local government is mature. The data underneath them usually isn’t.
So, what should councils in scope for reorganisation be doing now?
Audit before you architect. You can’t plan a migration, or an AI strategy, from systems you haven’t catalogued. Most councils are surprised by what an honest audit turns up, and it’s far better to be surprised now than in the month before vesting day.
Give the data an owner. Not the IT department by default, but service leads who actually understand what the records mean. The revenues team knows why those 400 accounts carry a code nobody else recognises. That knowledge walks out the door in every restructure, so capture it while you can.
Agree your definitions early. What counts as an active case? When does an address become historical? These sound like pedantic questions until five organisations answer them five different ways, and until a model starts making decisions based on the answer.
It’s also important to be honest about retention. Mergers are a rare chance to stop dragging forward data you have no reason to keep. Less data migrated means less risk, less cost, and a far cleaner foundation for anything intelligent built on top of it.
This isn’t doom-mongering. Reorganisation is disruptive, but it’s also the first time in a generation that councils get to redesign their information landscape from first principles. The new authorities that treat data as the first workstream won’t just inherit merged datasets. They’ll have cleaner, better-understood, better-governed data than any of their predecessors ever had, and that is precisely the foundation that responsible, useful public sector AI requires. But, the data conversation decides whether any of it works. Start there.
Read More Data & Decision Making
