Guide

AI in local authorities: what can be automated safely

A local authority can safely hand AI the work around a decision: reading documents, checking them against rules the authority has approved, asking a resident for one specific missing document, and gathering the information into a single case. The decision itself, meaning every approval, rejection and exception, stays with an employee at the start. This guide draws on Liba’s work with municipal and utility services, and sets out what to automate, what not to, and how to begin.

What can AI do safely in a local authority?

Municipal services run on applications, supporting documents and rules that differ by category. Most of the work is checking, not deciding. That part can be handed to a system, with every action recorded:

• Reading documents and extracting details. The documents attached to an application are classified, and details such as the applicant, address and other key fields are extracted.
• Checking against approved rules. Whether the documents required for the eligibility route are present, whether the details agree across the application and the documents, and which validity period and fee apply under the rules table the authority has approved.
• Asking for exactly what is missing. When a document is missing, the resident is asked for that document only, using approved wording. When it arrives, it is attached to the original request and the checks run again.
• One case view. Supporting information from several systems is gathered in one place, so the employee does not have to search for it.
• A complete record. Documents, check results, the rule and model versions, the recommendation and the employee’s decision are kept together in the case history. A decision made months ago can be reviewed from the case instead of being reconstructed from memory.

What should stay with an employee?

A sound design gives each part one job: AI reads and extracts, rules approved by the authority determine what the checks mean, and an employee decides. At the start, these stay with the employee:

• Every approval and rejection. The system recommends and an employee confirms. A rejection cites the approved rule it relies on, and an employee reviews it before it is sent.
• Every exception or conflict. When documents disagree, or a case does not fit a defined outcome, it goes to an employee with all the evidence attached.
• Any non-default outcome. For example, a validity period other than the standard one for that route, with the reason recorded.
• Changes to rules and thresholds. Each one is an approved, documented action with the date from which it applies.

If the authority later wants routine approvals carried out automatically, that is its decision to make, after it has reviewed the shadow-mode results. For more detail, see where human approval belongs in a municipal AI workflow.

Which services make a good start?

A good first service is one where applications arrive steadily, the documents are familiar and the rules differ by eligibility route. Most of the work is checking that the documents agree with each other and with the rules.

A municipality worked with Liba on exactly this kind of service, to cut hours of repetitive work and reduce costly errors. The workflow covers the most common eligibility route. Exceptions and intake by post or at the reception desk stay with employees.

Utilities have the same kind of work. In one utility mapping, most of a team’s billing cycle went on exporting reports to spreadsheets and reviewing accounts one by one, although only some accounts needed judgement. For the full criteria, see choosing your first business process for AI implementation.

What has to be decided before building?

Some questions are policy rather than technology, and the authority has to settle them before development. In this project they included:

• the exact fee version and its exceptions;
• the approved validity period for each eligibility route;
• the documents required for special categories;
• which notices go by email, by SMS or by both;
• which information sources may be queried in real time, and with what permissions;
• whether the pilot only recommends or also carries out approvals.

Each of these needs an owner and a date. Until they are settled, the workflow can be built but should not be relied on.

How do you start without putting the service at risk?

1. Close the rules. Owners, documents, validity and fees agreed in writing.
2. Build the first version for one route.
3. Shadow mode. The system proposes a decision but changes nothing in the system of record. Its recommendations are compared with employees’ actual decisions.
4. Controlled pilot. Employees approve with the system’s support, and time and accuracy are measured.
5. Expand to further routes, intake channels and integrations only after accuracy has been shown.

The criteria for leaving shadow mode are agreed in advance. In this project they are demonstrated accuracy, no incorrect approvals in the review sample, and high agreement with employee decisions. If an automated step fails or times out, the case goes back to an employee rather than stalling.

How does it connect to the authority’s systems?

The workflow sits on top of the systems the authority already runs and does not replace the system of record. The first choice is the system’s own interface (API). Where there is none, we look at a database view or a scheduled file exchange, and only as a last resort at time-limited screen automation. In that project, only one step writes to the system of record: updating the case after an employee has approved. Every other step reads or prepares. Access to sources such as the resident registry is subject to the authority’s permissions and approvals.

Where does it run, and what happens to residents’ data?

The authority chooses: a sovereign cloud, its own cloud tenancy, its own data centre, or a fully disconnected network running open models on its own hardware. Every capability is available in every deployment. Controls are designed with ISO 27001, SOC 2, the GDPR and local data protection law in mind. Designing against a framework is not certification. The system is built in the languages people work in, including right-to-left ones such as Hebrew, and accessibility follows WCAG 2.1 AA.

How long does it take?

Mapping across several departments usually takes one to two weeks, depending on people’s availability. First processes are planned at roughly five to nine weeks including adoption. The pilot measures the baseline and the actual result.

Limits

Regulatory duties, notice periods and retention rules differ by service. A workflow can help make sure they are met on time; it does not shorten them. Each authority decides its own approval points, and legal review is part of that decision.