Local government work is mostly text. Requests arrive as text, get answered as text, and are recorded as text, which is why current AI tools fit the sector better than they fit many others. It is also why the useful applications are unglamorous, and why the glamorous ones are mostly the ones to avoid.
What follows is ordered by how straightforward each candidate is to do well, not by how impressive it sounds. For each one the questions that decide feasibility are the same: where does the information live, can a machine read it, and who checks the output.
Internal knowledge search
Ordinances, resolutions, procedures, council decisions, prior correspondence and departmental guidance are spread across a website, a records system, a shared drive and several inboxes. Staff answer questions from memory or ask a colleague, because finding the authoritative version takes longer than the question is worth.
A search assistant over that material is the strongest first candidate in most jurisdictions. The content is largely public or internal rather than personal, a wrong answer is caught by somebody who knows the subject, and the benefit lands on staff who are already stretched.
There is a side effect worth having: building it requires deciding which version of each document is authoritative, and most organizations discover during that exercise that several are not what anybody assumed.
Helping residents find an answer
Cities receive the same questions continually, phrased differently, through phone, email, counter and web. Improving how a resident finds an answer on your own site displaces a meaningful share of that contact, and it is contained: the content is already published, so the failure mode is an unhelpful answer rather than a disclosure.
Two rules make this work. Ground the answers in your own published content rather than a general model, so the system is summarizing what you actually said. And make the route to a human obvious rather than buried, because the residents who most need help are the ones the automated answer will serve worst.
Where the website itself is the constraint, LABUSA's AI-powered content management practice covers search and content operations in depth.
Drafting responses staff will review
Correspondence, standard replies, first drafts of routine letters and the acknowledgement layer of resident contact.
The realistic benefit is the draft, and a person edits and sends everything. Write that down as a rule rather than assuming it, and decide which categories of correspondence are excluded entirely: anything conveying a determination about a person's rights, eligibility or obligations belongs to a human from the first word.
Translation deserves the same treatment as in districts. It is high value for multilingual communities and needs a competent reviewer for anything with legal or safety content.
Document and records processing
Extracting information from submitted forms, classifying incoming correspondence, summarizing long documents, and preparing first passes at agendas and minutes.
Records requests are the highest value candidate in this group and the one that needs the most care. Assisting a records officer to locate and review potentially responsive material is a genuine improvement on searching by hand. Deciding what is responsive, and what is exempt, is a judgment with legal consequence and must stay with the officer. Build it as a retrieval aid, never as a redaction or exemption engine.
Permitting, licensing and inspection support
Checking an application for completeness before it reaches a reviewer, drafting standard correspondence, and helping applicants understand what is required.
The boundary is firm and worth stating in the policy rather than only in the design: completeness checking is administrative, and an approval or a denial is a decision about a person's property or livelihood that a named human makes. A system that flags an application as incomplete is helping. A system that declines it is not.
Scheduling and routing for inspections is a separate, well-behaved optimization problem that has nothing to do with language models and is often the better investment.
IT service management
Ticket triage and categorization, drafting first responses to common problems, and self-service answers drawn from an existing knowledge base.
Small IT teams supporting large user populations get real value here, and there is a learning benefit: the IT team can evaluate the output competently, which makes this a sensible place for a jurisdiction to find out what these tools do well and badly before deploying somewhere the reviewers are less able to judge.
Operations and asset management
Maintenance scheduling, demand forecasting for services, route optimization for collections, and analysis of sensor or meter data where a jurisdiction has it.
These are analytical applications rather than generative ones, and they are consistently underrated because they do not demonstrate well. They also have the clearest success criteria in this list, which makes them good candidates for showing a council that the investment produced something.
The constraint is almost always data access: the information sits in an operational system that may or may not permit programmatic access, which is a question to settle before scoping. That is one of the things a readiness assessment for a city or county establishes.
Public safety, kept narrow on purpose
This section is short, and that is the point.
The defensible applications in a public safety context are administrative: drafting routine reports for an officer to review and correct, transcribing and summarizing recorded material, helping staff search policy and procedure, and analyzing call volumes for staffing and scheduling. Each assists a person doing their job and each leaves the judgment with them.
We do not recommend, and will not help build, systems that direct enforcement attention toward individuals or areas, that assess a person's risk, or that make or materially shape a decision affecting someone's liberty. The evidence on those systems is contested, the potential for harm is not, and a jurisdiction that deploys one will be answering for it publicly.
Anything in this area needs human decision making that is real rather than nominal, reliability appropriate to the consequence, data governance settled in advance, and a clear-eyed view of what happens when the system is wrong about a person. If those cannot be satisfied, the finding is that it should not be built yet.
Meetings, agendas and the public record
Agenda preparation, drafting minutes from a recording, producing summaries of long staff reports, and helping the public find what was decided about a topic across several years of meetings.
The last one is genuinely useful and rarely on anybody's list. Council and commission decisions accumulate in a form that is technically public and practically unsearchable, and both residents and staff give up looking. Making that history findable is a service improvement with no personal information involved.
Minutes need a firm rule. A draft produced from a recording is a draft, and the clerk approves the record. Where minutes are a legal record of proceedings, the approval process that already exists applies unchanged, and the tool sits before it rather than replacing any part of it. Check also what the transcription service retains and where, because a recording of a meeting held in closed session is not material to hand to an external processor without deciding to.
What not to automate
Three boundaries, applicable across every department.
Determinations about individuals. Eligibility, enforcement, permitting, benefits and anything affecting a person's rights or property. AI may assist the person deciding; it may not decide.
Anything a resident cannot appeal to a human. If an automated step can produce an adverse outcome, there must be a route to a person with the authority to change it, and residents must be told it exists.
Anything the organization cannot explain. A jurisdiction will be asked why an outcome happened. If the honest answer is that nobody knows, the system should not be in that position.
Choosing the first one
Pick the candidate where the information is already accessible, the reviewer is competent to judge the output, and abandoning it would cost nothing. Internal knowledge search meets all three in most jurisdictions.
Agree what success looks like and the number you would look at before anything is built, because a pilot without a stopping condition becomes permanent by default. And write down what you decided not to do and why, because that document is what makes the purchase defensible when somebody examines it a year later.
The groundwork comes first: AI readiness for cities and counties covers what needs to be true before any of this, the governance framework covers the position to write down, and the security risks covers what to check before deploying.
For a score across the seven dimensions, the AI Readiness Self-Assessment takes about eight minutes. Where a jurisdiction wants its candidates tested against its own systems rather than assessed on paper, a structured readiness review does that and produces a prioritized roadmap. Cooperative purchasing is covered on the TIPS members page, or tell us what your departments are asking for.