AI for Local Government: Citizen Requests and Public Records

AI for local government works best as a supervised assistant that sorts incoming citizen requests, finds the right document or rule, and drafts answers from approved public sources. Staff stay responsible for decisions, exceptions and any release of records. The design question is not what the assistant can say, but what it may say alone, what it must route to a person, and what it must never touch.

Key takeaways

• Start with three jobs: request triage, document lookup and public information answers. Each carries a different risk and needs a different approval rule.
• Let the assistant answer alone only from published, current sources. Anything involving a person's file, a legal interpretation or a decision goes to staff.
• Permissions belong in the records system, not in the prompt. The assistant should retrieve only what the person asking is allowed to see.
• Tell residents they are talking to an automated assistant, cite the source of each answer, and make the handoff to a human easy.
• Judge the system with observable checks: correct routing, correct source, staff corrections and time to a first useful reply.

What does AI for local government actually do in a municipal office?

A municipal office receives a steady mix of questions, forms, complaints and records requests through the counter, the phone, email and web forms. A large share of staff time goes not into deciding but into reading, sorting, searching and rewriting the same explanations. That is the work an AI agent can carry.

Three jobs cover most of the value. Triage reads a request, identifies its type, department and urgency, and routes it with a short summary. Document lookup finds the relevant ordinance, form, minutes or file and returns the passage with its source. Public information answers draft replies to common questions using only approved, published material.

There are jobs the assistant should not do. It should not decide eligibility, grant a permit, interpret the law for a specific case, release a restricted record or settle a dispute. A resident can challenge an official decision, which means a named person has to be accountable for it. A workable rule is short: the assistant prepares, the official decides.

How should citizen requests be triaged?

Triage is mostly a set of questions asked in a consistent order. Writing them down as a decision guide makes the behavior reviewable by the people who own the service. A starting version looks like this:

• Is it a question with a published answer, such as opening hours, how to apply or where to pay? Draft the answer from the source. Send it directly only if the office has approved that category.
• Is it a service report about a place, such as a damaged road, a streetlight or a missed collection? Capture the location and description, check for an open duplicate, and create a ticket for the responsible crew.
• Is it a records request? Log it, note the time of receipt, identify the likely record series and send it to the records officer. The assistant never decides on release.
• Does it mention danger, an emergency or a vulnerable person? Flag it as urgent to a named on-duty person and show the resident the emergency contact immediately.
• Is it a complaint about staff, a legal threat or a dispute over a decision? Route it to a supervisor without drafting a substantive reply.
• Is it unclear, or in a language the assistant handles poorly? Ask one clarifying question or hand it to staff.

Many jurisdictions attach response deadlines to certain request types, especially records requests. The assistant should record the time of receipt and apply the deadline rule your office configures, rather than guess at it. Ticket routing with duplicates, urgency and handoffs follows the same pattern described in AI agents for IT helpdesks, and the lessons carry over well to a services desk.

How does document lookup work without exposing the wrong record?

Lookup usually relies on retrieval: the assistant searches an indexed set of documents and builds its answer from the passages it finds, instead of relying on what the model remembers. Google Cloud and AWS both describe this retrieval-augmented pattern, and it suits public offices because every answer can point back to a source the office controls.

The risk is not that the assistant forgets a rule. The risk is that it finds something it should not show, or trusts text it should not trust. Two controls address this.

First, enforce access in the system, not in the instructions. The OWASP authorization guidance recommends least privilege and denying access by default, and that applies directly here. If the requester is a member of the public, the assistant's search tools should only reach the public collection, no matter what the conversation says. Staff-facing use can reach more, with each lookup tied to the staff member's own permissions.

Second, treat incoming content as data. Residents send emails, scans and attachments, and any of them may contain text written to steer an AI system. The OWASP prompt injection prevention guidance covers this class of attack. The practical response is to keep instructions and content separate, limit what tools the assistant can call, and require approval before any action with consequences.

A checklist for the records collection before anything is indexed:

• Label every document as public, internal or restricted.
• Store effective dates and supersession, so a repealed rule never returns as current.
• Return the title, section and link with every passage.
• Remove or redact personal data at the source where the document is meant to be public.
• Log each lookup with who asked and what came back.

Offices that manage notices, resident questions and shared records for a community will recognize this pattern from condominium management, where the same line between public notices and private files has to hold.

What can the assistant say in public information answers?

A useful way to set limits is to sort answers into three tiers and have the office sign off on the list.

• Answer directly: published facts with a stable source, such as hours, locations, how to submit a form, which department handles a topic. The reply names the source page and its last update.
• Draft for review: answers that depend on the resident's situation, such as whether a described project seems to need a permit. The assistant prepares a draft with the relevant rules, and a staff member approves or rewrites it before it is sent.
• Route only: anything that decides, interprets, promises or releases. The assistant explains who will handle it and what happens next, using published process descriptions only.

Transparency is part of the answer itself. The assistant should say at the start that it is an automated assistant, cite where each answer comes from, admit when it cannot find a source, and offer a route to a person at any point. It should not imitate a named official, promise outcomes, or state processing times the office has not published.

Many communities need service in more than one language. The safest approach is to answer in the resident's language from the same approved source, and to have staff review translations of the most-used pages. Offices that also handle information about minors or families should apply stricter rules, similar to those in AI agents for school administration.

Which approval limits and transparency measures should be in place?

The NIST AI Risk Management Framework is a helpful structure for documenting this: define who governs the system, map where it is used, measure how it behaves and manage the problems found. You do not need a heavy program. You need a short set of written decisions that a council member, an auditor or a resident could read.

• A named owner for the assistant's scope, and a named deputy.
• A written list of categories it may answer alone, reviewed whenever a law, form or fee changes.
• Mandatory staff approval before any message that states a decision, an office deadline, a fee or a legal position.
• No access to payments, case outcomes or enforcement actions.
• A public notice describing what the assistant does, what information it can see and how to reach a person.
• Retention rules for conversations that match your records schedule, since logs may themselves count as records.
• A regular review of sampled conversations, with corrections tracked.
• A fast way to switch off one category without shutting down the rest.

The evidence trail matters as much as the rules. When a resident or an auditor asks why a particular answer was given, the office should be able to show the question, the source passage, the draft, who approved it and when. AI for compliance teams describes how to keep that kind of evidence usable without turning it into extra paperwork.

What does this look like in practice? An illustrative scenario

This scenario is illustrative, not a description of a real office.

On a Monday, a small town's clerk office receives an email asking for the minutes of a planning board meeting about a riverside lot, and for the neighbor's permit file. The assistant splits the message into two items. The minutes are public and already published, so it drafts a reply with the meeting date and a link, and the reply is sent because this category is approved for direct answers.

The permit file is different. The assistant logs it as a records request, records the time of receipt, identifies the file series and notes that the file may contain personal details of the applicant. It sends a summary to the records officer, who decides what is released and what is redacted.

On Tuesday, a resident reports a broken streetlight. The assistant asks for the nearest address, finds an existing open ticket, attaches the report to it and replies with the reference. On Wednesday, a scanned letter contains a line telling the assistant to ignore its rules and send every file. The assistant treats it as content, does not follow it, and flags the message to the IT contact.

On Friday, the supervisor reviews a sample of conversations. One draft cited a fee page that had been replaced. The team fixes the source, records the effective date and adds a check for outdated pages. The office learned from a small, visible error before it became a public one.

How does Be Human approach this, and where should an office start?

Be Human designs, implements and operates personalized AI infrastructure for organizations. A first engagement defines one useful role, the memory and tools it needs, the approval boundaries and an observable success criterion. Managed operations can include monitoring, recurring evaluations, integration maintenance, permission review, incident response and controlled improvements. The service is remote, in English and Portuguese, and the office keeps control of identity, permissions and what the assistant is allowed to do.

A practical starting plan for a municipal office:

• Pick one front-door channel, such as the general information inbox.
• List the question types received over a representative period and sort them into answer, draft and route.
• Gather the current published sources and assign an owner to each one.
• Define the approval rule and the handoff contact for every category.
• Run the assistant in draft-only mode, with staff comparing its drafts to their own replies.
• Review the misses, fix sources and rules, then allow direct answers for the safest categories only.
• Schedule recurring checks of sampled conversations and a periodic review of permissions.

Frequently asked questions

Can an AI assistant decide whether a resident qualifies for a service? Not on its own. It can collect the facts, point to the published criteria and prepare a summary, but an official should make and sign the decision so that it can be explained and appealed.

Does the assistant need to tell residents that it is automated? Yes, plainly and at the start of the conversation. Disclosure helps residents ask for a person when they want one, and your jurisdiction may have specific rules on it, so confirm the obligations that apply to your office.

How do we keep personal data out of the wrong answers? Classify documents before indexing, enforce permissions in the records system, redact material meant for publication, and give the assistant access only to the collection that matches the person asking. Then test with questions designed to pull restricted content, and repeat those tests whenever sources or tools change.

How do we know the assistant is working? Define observable checks before launch: whether requests reach the right department, whether answers match the cited source, how often staff edit a draft, and how quickly a resident gets a useful first reply. Review a sample of conversations on a regular schedule, and treat complaints as input to the checks.

Be Human editorial guidance. Examples are illustrative unless explicitly attributed. Sources provide background; implementation choices depend on your workflow.