A council AI assistant that guesses is worse than no assistant

Councils are sitting on exactly the kind of problem AI is supposed to be good at. Policies, planning documents, forms, meeting papers, service request histories, asset records, local laws, community information. Staff and residents both need answers out of that pile, and the pile is miserable to search. So an assistant makes obvious sense.

Right up until it confidently tells a resident the wrong thing about a permit, or a burn-off rule, or a rates deadline, in the council’s own voice, and someone acts on it. That’s the part the chatbot pitch skips. For a business, a wrong AI answer is an annoyance. For a council, it’s a written statement from the authority, and “the chatbot said” is not a defence anyone wants to be running. The bar here isn’t convenience. It’s accountability, and it changes how the whole thing has to be built.

Here’s the shape of the problem on an ordinary Tuesday. A customer service officer at a Darling Downs council takes a call about burning off on a rural block before the weekend. The answer lives somewhere across a local law, a state fire restriction that may or may not be current, and a fact sheet last touched in 2021. She searches the intranet, gets four PDFs and a broken link, puts the resident on hold, and the one colleague who knows fire permits cold is at lunch. The call ends in a promised call-back that becomes an email that becomes two days. Multiply that by every counter, phone queue and after-hours contact form, and the case for an assistant that has read the whole pile writes itself.

The case for building it carefully is the same scene one step later, where a tool answers instantly, confidently and wrongly, and the resident lights the fire.

Internal and public are two different products

The first mistake is trying to build one assistant that serves both staff and residents. They need opposite things. An internal assistant can search policies, procedures, service histories and internal notes that no resident should ever glimpse. It’s also where the unglamorous wins are: a planner finding the right clause in minutes, a new starter getting answers that used to live in a veteran’s head, the counter call above resolved while the resident is still on the line. A public assistant needs a deliberately narrow source set, plain disclaimers, firm moderation, and a clear path to a human the moment it’s out of its depth.

Try to make one tool do both and you get the worst of each: a public assistant with access it shouldn’t have, or an internal one so locked down it’s useless. Build them as two things with two source sets and two permission models. It’s less clever and far safer.

Approved sources only, with the receipt attached

A council assistant has no business answering from the open web. Ask it about bin collection, permits, local laws, venue hire or a form, and the answer has to come from the council’s own current material, not something it absorbed off the internet two years ago. An assistant grounded in approved documents is the only version worth deploying.

And every answer needs to show its working: which document it came from, when that document was last updated, with a link a person can open and check. This does two jobs. It lets a resident or officer verify the answer instead of trusting a fluent paragraph, and it keeps the source document as the authority rather than the chatbot’s summary of it. An assistant that can’t cite where an answer came from is an assistant you can’t stand behind, and a council can’t afford to stand behind guesses.

The pilot will audit your documents, like it or not

The first thing an internal assistant surfaces is rarely an efficiency. It’s the state of the source material. Three versions of the fees and charges schedule, each slightly different. A procedure that references a form retired in 2019. A policy on the public website that contradicts the one on the intranet because somebody updated one and not the other. The assistant didn’t create any of that. It reads everything at once and stops pretending, which no human searcher ever did, because humans stop at the first plausible document and never see the conflict.

Awkward as that fortnight is, it’s half the value of the project. A council can’t fix contradictions nobody has found, and an assistant finds them at a pace no manual document review ever managed. So budget real time for the cleanup: deciding which document is authoritative for each topic, retiring the dead ones, and putting an owner and a review date on what remains. That’s data work as much as AI work, and skipping it means the assistant answers fluently from the unsorted pile, which just automates the confusion.

Knowing when to shut up is a feature

The most important thing a council assistant does is recognise the questions it must not answer. Complaints. Disputes. Anything legal. Safety issues. Personal information. A planning interpretation. An urgent service request. None of those belong to a model having a go. They belong to a person or an existing official process, and the assistant’s job is to route them there quickly, not to improvise something helpful-sounding.

A good build treats “I can’t help with that, here’s who can” as a correct answer, not a failure. That restraint is exactly what earns trust, because the fastest way to torch confidence in a council tool is one screenshot of it confidently mishandling a complaint or guessing at a planning rule. Design the handoffs as carefully as the answers. A blunt test for any pilot: ask it about a live complaint, a planning dispute and a barking dog three doors down, then watch what it does. If it has a go at any of them, the guardrails are decorative.

Permissions have to survive contact with a clever question

Service histories and customer records hold personal information, and the access rules around them have to carry straight through to the assistant, enforced in the retrieval layer, not painted on the interface. A staff member should only ever be able to surface what their role allows. A member of the public should not be able to coax a private record out of the thing with a cleverly worded question, and people will absolutely try.

A warning notice in the chat window does nothing to stop this. Only the engineering does: the assistant physically cannot retrieve what the person isn’t cleared to see. If a vendor’s answer to “how are permissions enforced?” is about the interface rather than the retrieval, that’s a leak waiting for a Right to Information request.

The questions that sort builders from chatbot resellers

Procurement will make you ask about price, insurance and references. Ask these as well, and keep pushing until the answers get specific.

Where does a question go when someone types it, and where does the model run? If any part of a staff query or a source document leaves the country or feeds a vendor’s training data, the council should know before signing, not after an RTI request. For the sensitive internal material there are private setups where the council controls exactly where documents and queries live, and a serious vendor can price one.

What happens when a source document changes? If the honest answer is a manual re-index every quarter, the assistant will spend most of the year confidently serving the old fee schedule. Updates should flow through in days at worst.

And ask to see the answer trail. When a resident says the assistant told them they could do something, the council needs the log: what was asked, what was answered, which document version was cited, and when. A vendor who can’t show you that log hasn’t thought about the day it’ll be needed.

On money, a scoped internal pilot over a defined document set is a five-figure project measured in weeks. If the first proposal arrives as a multi-year transformation roadmap, you’re being sold the vendor’s ambitions rather than the council’s problem.

Start inside, prove it, then face the public

For almost every council the sensible first project is an internal knowledge assistant over a defined, tidy set of policies and procedures. Staff can push on the answers, find the gaps in the source documents themselves, and build real confidence before anything faces a resident. Low stakes, fast feedback, and the failures stay in-house where they belong.

Only after that, a resident-facing assistant on one narrow topic, waste services or facility bookings, with a tightly scoped source set and escalation paths built in from the start. A council AI assistant that’s accurate, restrained and accountable is worth having. Getting there is careful engineering, not a weekend chatbot, and the councils that treat it as the latter are the ones that end up in the local paper. And if the bigger pain is service requests going missing rather than questions going unanswered, that’s a related but different build. If you’re weighing an assistant up, tell us the source documents and who the audience is and we’ll scope the internal version first.