The question usually arrives informally. A caseworker asks whether it is acceptable to use a chatbot to draft letters. A department head wants to summarise public comment. Someone in IT mentions that the permitting team has already been doing this for months.

If you are a county administrator, a city clerk or a district IT director, you are being asked to answer that without a compliance department, a general counsel who specialises in emerging technology, or a risk function that can absorb another workstream. Most published guidance assumes you have all three.

First: federal AI rules do not apply to you

This is worth stating plainly, because a great deal of the material a search will surface is about federal requirements, and it does not bind local government.

OMB memoranda — M-25-21 on how agencies use AI, M-25-22 on how they buy it, M-26-04 on language models — are directed to federal executive departments and agencies. A county is not one. Neither is a city, a school district or a special district. You cannot be out of compliance with a memorandum that was never addressed to you.

That does not make them useless. M-25-21's structure — a named accountable officer, a governance body, an inventory, heavier controls on higher-impact uses — is a sensible shape for any public body, and adopting it voluntarily is defensible. Just be clear internally that you are borrowing a structure, not meeting a requirement, so nobody later believes the county was legally obliged to do something it chose to do.

What does apply

Your state's AI statute, if it has one

This is the layer that can create real duties, and it varies sharply. Some statutes are scoped by use — Illinois addresses AI in employment decisions, which reaches you as an employer. Colorado's replacement act regulates automated decision-making technology in consequential decisions, which is framed around the decision rather than the technology and may reach systems nobody calls AI.

Check whether your state has a statute, whether public bodies are in or out of scope, and whether it is scoped by technology, by use or by organisation size. Our state AI law map sets out what is in force and when.

The law that already governs your decisions

This is the part most often missed, and it is the part most likely to cause an actual problem:

  • Anti-discrimination law applies to a decision regardless of how it was reached. A screening process that produces a disparate outcome is not defensible because a vendor's model produced it.
  • Due process obligations attach to determinations affecting benefits, licences or enforcement. If a resident is entitled to an explanation, "the system flagged it" is not one.
  • Public records law reaches AI-assisted work. Prompts and outputs may well be disclosable, and staff generally assume they are not.
  • Records retention schedules apply to records created with AI assistance the same way they apply to anything else.
  • Procurement rules apply when you buy an AI tool, including where it arrives inside a product you already use.

Nothing here is new law. It is existing law meeting a new way of working, and it is where most real exposure sits.

Scope by decision, not by tool

The instinct is to write a policy about ChatGPT. That policy is out of date within a quarter, and it misses the systems that matter most — the scoring rule in your permitting software, the risk flag in a case management system, the ranking in an applicant tracker.

Ask instead: where does an automated system take part in a decision that materially affects a resident or an employee? Benefits determinations, code enforcement, hiring, housing, permitting, school placement, anything touching law enforcement. That list is your actual scope. It rarely matches the list of tools anyone has procured.

What a first policy should contain

Short enough to be read. Six sections is usually enough:

  1. What this covers. Define it by decision and by system, not by product name, so the policy survives the next tool.
  2. Permitted uses. Say yes to something. A policy that only prohibits gets ignored, and driving use underground is worse than governing it. Drafting, summarising, translating and reformatting are reasonable starting permissions.
  3. Prohibited uses. Be specific and short. Typically: entering confidential, personally identifiable or law-enforcement-sensitive information into a public tool; using AI as the sole basis for a determination affecting a resident's rights or benefits; and generating anything presented as a person's own words without disclosure.
  4. Uses requiring review. Anything in the consequential-decision list above. Name who reviews and what "review" means in practice.
  5. Human accountability. The single most important clause. A named person remains accountable for every decision, and AI involvement never transfers that. Say it once, plainly, and mean it.
  6. Records and disclosure. State that AI-assisted work is a public record, that retention schedules apply, and when residents will be told AI was involved.

Resist writing more. A five-page policy that departments actually follow is worth more than a thirty-page one that lives on the intranet unread — and you will learn what the real questions are only once people start bringing them to you.

The problem nobody procured

Most local-government AI use does not arrive through procurement. It arrives because a staff member opened a free tool in a browser, or because a vendor added an AI feature to software you already had.

Two consequences follow. Your inventory cannot be built from your contract list, so you will have to ask people — and you will only get honest answers if asking does not feel like an accusation. And your policy has to address personal-account use explicitly, because that is where confidential information most often leaves the organisation.

A practical approach: amnesty first, inventory second, policy third. Tell staff you need to know what is being used and that nobody is in trouble for having answered a question with a tool. You will learn more in a fortnight than an audit would surface in a quarter.

Making human review real

"A human reviews the output" is the clause most likely to be true on paper and false in practice. A reviewer who sees a recommendation, a confidence score and a queue of two hundred cases is approving, not reviewing. Our guide to meaningful human oversight sets out the conditions in full.

Three things make review meaningful:

  • The reviewer can see what the system saw, not only what it concluded.
  • The reviewer has time. If throughput expectations rose when the tool arrived, review has already been designed out.
  • Disagreeing is normal. If nobody has ever overridden the system, that is a finding, not a reassurance.

Where to borrow structure

You do not need to invent a framework. The NIST AI Risk Management Framework is free, voluntary and organised around four functions — govern, map, measure and manage — that translate reasonably to a small public body. Using it also means that when a state agency, an insurer or a resident asks how you decided, you can name a recognised reference rather than describing something bespoke.

For the committee side of this, our guide to standing up an AI governance committee is written for organisations without a compliance function, which describes most local governments.

A realistic first ninety days

  1. Weeks 1–2. Name the accountable person. One name, not a committee.
  2. Weeks 2–4. Run the amnesty and build the inventory of what is actually in use.
  3. Weeks 3–5. Check your state statute and whether public bodies are in scope.
  4. Weeks 4–6. List the consequential decisions in your organisation. This is the scope.
  5. Weeks 6–9. Draft the six-section policy. Circulate to legal, HR, IT and one department that will actually use it.
  6. Weeks 9–12. Adopt, publish, and tell staff. A policy nobody has read is not in effect in any meaningful sense.
  7. Ongoing. Revisit when your state law changes — which, as Colorado demonstrated in 2026, it can do abruptly.

On explaining this to residents

Local government has a trust advantage worth protecting: people can turn up to a meeting and ask. Being able to say plainly what AI is used for, what it is not used for, and who remains accountable is worth more than any technical control, and it is far easier to say before an incident than after one.

Our county AI ethics guides set out the local concerns most relevant to each US county, which can be a useful starting point for framing that conversation in terms your community already recognises.

Nothing here is legal advice. State law varies considerably, and whether a specific statute reaches your organisation is a question for your county or city attorney.