It’s late on a Tuesday and an FOI officer is scrolling a spreadsheet of overdue requests, the cursor sliding past rows that have gone the pale grey of things that have waited too long. Half of them are numbers and dates and a one-line summary typed by whoever logged the request. She knows most of the stories anyway.

One row, near the bottom, is a woman trying to get her own records. She lodged the request in autumn. The thirty-day clock that the FOI Act starts the moment a request lands, by operation of law, ran out weeks ago. Nobody decided to be late. The request just sat in the queue behind the ones that came before it, waiting for a person to have the hours, and the hours didn’t exist.

That’s the part I want to say plainly before anything else. The row is a person. She is owed an answer by law, and the reason she doesn’t have one isn’t that anyone failed to care or forgot how to do the work. It’s that the work of moving the queue is manual, and there is more queue than there are hours. Across the sector, 63% of agencies still run Freedom of Information on spreadsheets and static records; only 26% have a case-management system doing the lifting (OAIC FOI Practitioners’ Survey, 2024). The clock is automated. The queue is not.

The queue is not one queue

Walk down the corridor and it’s the same shape wearing different clothes. In the grants team, someone is hand-checking eligibility against criteria for the fourth application this morning, and a community group is waiting to hear whether their acquittal cleared. On the enquiry line, a message that should take thirty seconds to route is sitting in an inbox because the person who knows the answer is three roles away. In policy, a consultation submission is due and the first draft doesn’t exist yet, because writing it means reading everything first.

These land on different desks, in different committees, under different headings on the board report. They are the same problem. Every one of them is a person on the other end owed a decision, and a skilled public servant in the middle doing the reading, classifying, re-keying and drafting by hand before any decision can be made. The bottleneck is never the decision itself. It’s everything that has to happen before the officer can make it.

Why it keeps happening

Here’s where most people reach for the wrong fix. They assume the gap is a chatbot the council doesn’t have yet, and go looking for one. But look at what’s actually in a council’s stack and the story changes.

The vendor “AI” is already there, and it can’t help with this. TechnologyOne’s Guide, Esri’s ArcGIS AI Assistants, OpenText’s Aviator, Microsoft 365 Copilot, Granicus GXA — all of it is in-product only. None of it is documented as reachable by anything outside its own product, and a verification sweep of the sector found no externally agent-reachable vendor AI at all. So a chatbot bolted to one system does nothing about a request that has to move across five.

The real constraint is reading and writing across systems that were never built to talk. And the honest map of what can be reached is smaller than the sales decks suggest. The integration path runs through the records spine and the M365/GIS layer, not the council ERP. Microsoft SharePoint (through the Graph API) and Esri ArcGIS are the only fully self-serve, read-and-write surfaces in a typical council stack. The core ERPs and records systems — TechnologyOne OneCouncil, Civica Authority, the OpenText and Objective records spines, Brightly’s asset tools — are real, genuine integration points, but they’re provisioned per tenant at implementation, not switched on self-serve. Knowing that difference is the whole game. It’s the line between a build that ships in weeks and a systems-integration project that never lands.

The fear, named

None of this is what stops councils, though. What stops councils is a fear, and it’s worth saying out loud: AI in government is reckless. Put a citizen’s decision in the hands of a black box and you’ve handed away accountability that a public servant is legally meant to carry. It’s a good instinct. It’s also built on an assumption that quietly does all the damage — the assumption that for AI to be worth anything, it has to be the one that decides.

It doesn’t. And once you drop that assumption, the four myths that follow fall with it.

“The algorithm decides.” It never does — not in a design worth buying. AI reads the request, classifies it, retrieves the relevant documents and drafts the response up to the decision line. The officer applies the legal test — the FOI exemption, the grant criterion, the escalation call — and signs. On the FOI clock specifically: the tool records and flags the statutory deadline for the officer to confirm. It never runs the deadline unattended, because the deadline is a matter of law, not a thing a machine should be trusted to hold.

“Our citizens’ data will train someone’s chatbot, or leave the country.” Not in this build. It sits inside the council’s own M365 and SharePoint tenancy. Inference and processing stay onshore in Australia. The data is never used to train any third-party or public model, and every answer is cited back to the source document it came from. That’s the exact line OVIC and the NSW AI Assessment Framework draw, and it’s the line the build is designed to stay inside.

“Our software already has AI, so we’re covered.” That’s the in-product AI again — useful inside its own walls, useless across them. The reachable win isn’t another vendor chatbot. It’s the data-API layer you already own.

“It’s a probity and public-trust nightmare — too risky for public money.” Held to triage-and-draft with a named officer on every output, the opposite is true: the governance falls out of the build as a by-product. The AI register entry, the transparency statement, the privacy impact assessment the Commonwealth policy expects, a cited audit trail an FOI applicant or OVIC could actually read — all of it is generated as you go. And the council owns the code, prompts, config and audit trail when the engagement ends. The risk is governed by where AI is allowed to act: before the decision, never on it.

What actually changes at the queue

So picture the FOI queue again, with the tedious part lifted. A new request lands and the triage assistant reads it, proposes a category, surfaces the likely documents, and flags the statutory deadline on the officer’s screen with the clock already ticking. Classification that used to eat half a day is done in under two hours, and the officer spends the saved time on the judgement calls, not the sorting. Grant eligibility gets a first-pass check against the criteria before a human confirms it. Enquiries route themselves to the right desk. A consultation submission that took three to five days to first-draft arrives in one, as a draft to review rather than a blank page to fill.

The reason a person stays on every one of these isn’t caution for its own sake. The MAV found AI-drafted planning reports that quietly missed statutory triggers — exactly the kind of error that looks fine until it’s in the public domain. That’s why the machine drafts and retrieves, and a named officer decides and signs. Not who decides — that never changes. What changes is whether the request behind the grey row gets seen and moved while it still means something.

This isn’t hypothetical elsewhere in the sector, though the results below are independent, published benchmarks, not RMAI client results — we’re new to this sector and won’t pretend otherwise. The DTA’s whole-of-government Copilot trial put 7,769 licences across around 60 agencies and saw roughly an hour a day saved on summarising, searching and first drafts, with 40% of that time reallocated to higher-value work (DTA, 2024). Moorabool Shire (~331 staff) cut five-to-ten-minute reformatting jobs to under a minute, a projected twelve weeks of staff time a year (IPWEA/Datacom case study, 2025, vendor-reported). Hutt City in New Zealand measured around 38 minutes a day saved per participant, and projected LIM turnaround falling from up to ten days to minutes (Hutt City Council, 2024–25). Wyndham City, fielding 200,000-plus enquiries a year for 290,000 residents, scaled its contact centre with a secure 24/7 assistant rather than more headcount (inGenious AI, 2024, vendor-reported).

The honest part

I know the trust isn’t there yet. Australia ranked last of 47 countries on this: only 30% believe AI’s benefits outweigh its risks, only 36% are willing to trust AI applications (KPMG / University of Melbourne, 2025). In a government context specifically, just 11% would completely trust it (Publicis Sapient, 2025). Good. That scepticism is the right starting posture for a public servant, and a design that keeps a human on every citizen-affecting decision is built to earn its way past it, not to argue you out of it.

Where to start

You don’t need a transformation programme to test whether this is real. You need one honest look at where a request actually goes from the moment it lands to the moment someone with authority acts on it.

Two low-risk ways in:

• Read the map first. We’ve written a plain-English brief on the council software landscape — which of your systems can actually be reached, by what mechanism, and what “closed” really costs you. → https://realmindsai.com.au/guides/civic-gov/
• Book a free 30-minute discovery call. We walk one real path — a request in, a release out — find where the queue stalls in your stack, and name the three highest-value places to close it. Any build is quoted fixed-scope after that, on your numbers. → https://outlook.office.com/book/[email protected]/?ismsaljsauthenabled

There’s a row in a spreadsheet somewhere in your organisation right now that is a person owed an answer by law. The only question worth asking is whether anything in your systems is going to move it before the clock runs out — with your officer’s name on the release, where it belongs.