Ask Copilot, or any other AI chatbot how many service requests are overdue across the municipality and you’ll have an answer inside two seconds. Formatted, split by ward, entirely plausible. Someone will put it in the board pack.
The number is wrong, and Copilot is not at fault. It just doesn’t know about your organisation’s specific dialect.
Consider the term “Overdue”, is there a single definition of the word throughout your council’s workflow?.
There is a status field set in the request system some years ago. There is a due date a workflow calculates, which may or may not exclude weekends depending on how it was configured. There is an SLA clock that pauses when a case is placed on hold pending information from the resident.
Anyone working in the org long enough however would immediately know which of these leadership has in mind. Copilot does not. It found three defensible answers, selected one, and returned it with the uniform confidence it applies to everything.
The reaction I see most often at this point is to either get disillusioned by AI or try to fix the problem ad-hoc. Let’s just tell the chatbot what we mean by overdue, add it to its prompt.
And while that might work, it is a band-aid, not a cure.
Most organisations speak in dialects
Terms that appear standard — “customer,” “active,” “revenue,” “property,” “case,” “closed” — carry different meanings in different systems, because each system was built by different people, at different times, to serve a different purpose.
Property is the example I reach for, because it looks like it should be trivial. In the rating system a property is an assessment against a legal parcel. In GIS it’s a spatial object with a boundary. In planning it’s whatever address got typed onto a development application, by an applicant, at 11pm. There’s no common key across the three. So you match on address, and anyone who has done this knows how it goes: 2/14 Station St, Unit 2 14 Station Street, and 14 Station St Apt 2 are one place to a human being and three rows to a database.
A bank, a hospital or a university would tell the same story with its own vocabulary. The pattern is general: the organisation never settled on shared definitions, because until recently it never had to.
The inconsistency was absorbed by people. Staff know to disregard a column that stopped being populated in 2019, or which of two “monthly figures” reports finance actually relies on. Little of it is documented; it resides with long-serving employees and is transferred informally.
An AI system has access to none of that context. Presented with a question and five fields that could each represent “active request,” it has no institutional knowledge to draw on. It resolves the ambiguity by choosing, and then answers.
Nothing was built to talk to anything else
The second problem is structural, and equally widespread. Most organisations of any size run an estate assembled over decades — systems acquired one at a time, each to address a single need, none designed on the assumption that a single tool would later read across all of them at once.
In a council, that estate can be Pathway, TechnologyOne, Infor, GIS, records and HR, alongside a long tail of smaller applications. Many expose limited interfaces, or none of practical use, so extracting and aligning data is slow, manual and costly. The recurring result is staff reconciling one system against another by hand to answer a routine question, and a tacit acceptance that a whole-of-organisation view is not something that can be queried. The system names differ by sector; the condition does not.
Place an AI layer on top of inconsistent vocabulary and a fragmented estate, and it does not reconcile them. It amplifies them at speed, and with a fluency that makes the output read as settled fact.
Why this is worse for councils and other regulated entities
If a private company’s AI returns a wrong figure, the cost is a bad decision and some wasted time. Unpleasant, recoverable, and the failure mode is essentially commercial.
Public bodies don’t get that. A council has to be able to show how it arrived at a decision, to an auditor, to an FOI request, occasionally to a court or a tribunal. Public records legislation, state privacy law, freedom of information, and the plain administrative law expectation that decisions be fair and explainable all rest on the assumption that the reasoning can be traced backwards. An AI output that can’t be tied to an agreed definition and a source of record doesn’t survive that. Not because it’s necessarily wrong, but because you can’t demonstrate it’s right, and in a public body those amount to the same thing.
The regulatory bar is also rising. The Commonwealth’s National AI Plan was released in December 2025, alongside a revised policy for the responsible use of AI in government that now requires impact assessments, a designated accountable officer for each use case, and a register of where AI is deployed. The National AI Centre’s adoption guidance, aligned to ISO/IEC 42001, sets out the governance practices expected of deployers. Local government is not the direct subject of every one of these instruments, but they are quickly becoming the benchmark against which ratepayers, auditors and state departments assess councils. The question is no longer whether a council uses AI; it is whether the council can explain how that use is governed.
For a council, then, the ability to defend a result to an auditor is not a compliance formality. It determines whether an AI tool can enter production at all.
What resolves it
The remedy is neither novel nor a product to be switched on. It is the foundational work of bringing data into a state an AI system can rely on, and it runs in the opposite order to how most organisations approach the problem. Three stages, in sequence.
First, unify: consolidate the estate so the data has a single place it genuinely lives. Pathway, TechnologyOne, Infor, GIS, records and HR — connected and mapped rather than dispersed. This does not require removing anything. Built on Microsoft Fabric, the approach connects to and virtualises across the existing systems while they continue to operate, producing the joined-up view without a migration programme the organisation has no appetite to run.
Second, curate, which is where the vocabulary problem is addressed directly. A governed glossary and semantic layer assign each term one agreed meaning, mapped to the physical data beneath it, with ownership, sensitivity and lineage that can be presented to an auditor. Microsoft Purview is where this sits. The discipline is to constrain scope: define the ten or fifteen terms on which decisions actually turn and secure genuine agreement on those, rather than producing a four-hundred-term dictionary rendered obsolete within weeks of sign-off.
Only then, empower: allow Copilot and comparable tools to operate on top. Because the AI now draws from a governed layer rather than an undifferentiated body of documents and abandoned fields, it inherits the governance instead of undermining it. Outputs become traceable and consistent, and the tool performs as intended.
The decision in front of you
None of this argues for slowing down on AI. It argues for getting the order of operations right. The councils that derive real value from Copilot will not be those that enabled it first, but those that agreed what their terms meant and connected their systems beneath it, so that the AI arrives with a solid base to operate on.
That is the case to put to an executive: the foundation is not a cost incurred before the AI project begins. It is the first phase of the AI work, and every dollar spent on it is spent making AI safe to use in a public-sector setting.
This was never an AI problem. It is a foundation decision, and one that can begin now.
Leave a Reply