How to Write an AI Use Policy for City Government, Step by Step

In most cities, AI arrived before the rules did. A planner uses a chatbot to tighten the wording of a public notice. A department head tries the transcription feature that appeared in a meeting app. A software vendor switches on a summary feature inside a system the city has licensed for years. None of these is necessarily a problem. The problem comes later, when someone asks what data went into the tool, who checked the output before it went out, and whether the exchange is now a public record, and nobody has a clear answer.

An AI use policy for city government exists to answer those questions before anyone asks them. It does not need to be long or technical. It needs to tell staff what they may do, what they may not do, and what they must do every time, in language a new hire can follow during their first week.

This guide walks through drafting one, section by section: purpose and scope, approved and prohibited uses, data handling, human review, disclosure, records retention, vendor requirements, training, and a schedule for revisiting it all. Near the end is an outline you can adapt and a checklist for the adoption stage. One point runs through every section, so it is worth stating now: involve your city attorney from the start. Public records, open meetings, privacy, employment, and procurement law all touch this policy, and all of them vary by state.

What a policy can and cannot do

Before drafting, be clear about what the document is for. A written policy does a few concrete things:

• It gives staff a consistent answer. Without one, each department invents its own rules, or none, and the city ends up with as many practices as it has supervisors.
• It protects employees who are trying to do the right thing. A clear rule is easier to follow than a vague sense that AI might be frowned upon.
• It connects AI use to obligations the city already has, especially public records and privacy, so those obligations do not get lost because the tool is new.
• It gives procurement and IT something to point to when a vendor proposes a contract or adds an AI feature to an existing product.
• It shows residents and council that the city has approached this deliberately.

A policy cannot make a tool accurate. It cannot guarantee that every staff member reads every output carefully. And it cannot keep pace with a fast-moving market if it tries to name every product. The practical answer to that last problem is structure. Keep the policy itself focused on principles and requirements that will hold for several years, and put the parts that change often, such as the list of approved tools, in an appendix or administrative procedure that can be updated without restarting the adoption process.

Whether the policy is adopted by council resolution, issued by the city manager, or both depends on your charter, your form of government, and local practice. Ask your city attorney which route fits.

Build the drafting group and take inventory

Who should be involved

AI use cuts across departments, so the drafting group should too. Keep it small enough to meet regularly, often somewhere around 4 to 7 people, and make sure these perspectives are represented:

• City attorney or assigned counsel. Reviews every section and flags where state rules differ from general guidance.
• City clerk or records manager. Owns public records, retention schedules, and meeting materials.
• IT or information security. Evaluates tools, data flows, accounts, and vendor security claims.
• Human resources. Covers conduct, discipline, training, and any AI use in personnel matters.
• One or two department representatives. Ideally people already using these tools, so the policy reflects how work actually happens.
• Communications or the public information officer. Advises on disclosure and public-facing content.
• Procurement or finance. Connects vendor requirements to purchasing rules.

In a small city where one person wears three of these hats, that is fine. The point is that each perspective gets considered, not that each has its own seat.

Find out what is already happening

The most useful first task is an inventory, not a draft. Ask departments a few plain questions:

• Which AI tools are you using for city work, including free or personal accounts?
• Which software the city already licenses has added AI features, such as summaries, transcription, drafting, or search?
• What tasks are you using these tools for?
• What kinds of information have gone into them?

Frame the inventory as fact-finding, not an audit. If staff expect discipline for honest answers, you will get incomplete ones, and the policy will be written for a city that does not exist. Inventories often surface two things worth special attention: embedded features nobody thought of as AI, and personal accounts used for city business. Both need specific treatment in the policy.

Define purpose, scope, and terms

Purpose statement

Open with two or three sentences on why the policy exists. A workable model: the city permits responsible use of AI tools to improve the quality and efficiency of public service, while protecting confidential information, meeting public records and transparency obligations, and keeping staff accountable for all work products. Adjust the wording to your city's voice, but keep the core idea that people remain responsible.

Scope

Scope answers three questions: who, what, and where.

Who is covered. Employees, certainly. Consider contractors, interns, and volunteers who handle city information. Elected officials are a separate question. An administrative policy may not bind council members, so some councils adopt a parallel policy or resolution applying similar rules to themselves. Your attorney can advise.

What tools are covered. Write the scope broadly enough to include:

• Standalone generative AI tools, such as general-purpose chat and drafting tools
• AI features built into software the city already uses
• AI services vendors provide on the city's behalf, such as transcription or translation

Where it applies. State that the policy applies to any use involving city business or city information, regardless of device or account. This closes the gap where someone uses a personal account at home to draft something that ends up in a council packet.

Definitions

Keep definitions few and plain. Technical definitions age quickly and invite arguments about whether a particular product counts. Most cities need only a handful:

• AI tool: software that generates text, images, audio, summaries, translations, or recommendations, including features embedded in other software.
• Approved tool: a tool listed in the current approved tools appendix, configured and contracted by the city.
• Confidential information: information exempt from disclosure or protected by law, contract, or city policy. Cross-reference existing data classification rules if you have them.
• Public record: as defined by state law. Do not write your own definition; point to the statute your attorney identifies.
• Responsible reviewer: the staff member accountable for checking and approving an AI-assisted work product before it is used.

Sort uses into approved, conditional, and prohibited

Staff want to know quickly whether a task is allowed. A three-tier structure answers that better than a page of principles. Approved uses proceed under the general rules. Conditional uses are allowed with specific extra steps. Prohibited uses are off limits regardless of tool.

The examples below are a starting point. Adjust them based on your inventory, your state's laws, and your city's tolerance for risk.

A few notes on this structure. Decisions about individuals deserve particular care because they affect people's rights and livelihoods, and some states have adopted or proposed rules on automated tools in exactly these areas. Have your attorney review this tier against current state law.

Do not try to make the prohibited list exhaustive. Add a catch-all instead: when a use is not listed, staff ask their supervisor or the policy owner before proceeding. That one sentence handles the cases nobody anticipated.

Finally, include a path for moving a use between tiers. A department that wants to try something new should know who to ask and what information to provide.

Set rules for data handling and human review

These two sections carry most of the policy's protective weight. If staff remember nothing else, they should remember what not to put into a tool, and that they own whatever comes out.

Data handling

The cleanest approach ties AI use to a data classification scheme. If your city has one, reference it. If not, a simple version works:

• Public: information already published or clearly disclosable, such as adopted ordinances, posted agendas, and press releases.
• Internal: routine work information that is not published but not protected, such as draft schedules or process notes.
• Confidential: information exempt from disclosure or protected by law, such as personnel files, residents' personal identifying information, health information, law enforcement records, security details, and attorney-client communications.

Then state which classes may go into which tools. A common pattern: public information in any approved tool, internal information in approved tools under city contracts, and confidential information only in tools specifically approved for it, if at all.

The difference between consumer accounts and city-contracted tools matters here. A free personal account is governed by the provider's general terms, which the city did not negotiate and which can change. A city-contracted tool is governed by terms your attorney reviewed. Whether a provider retains inputs, uses them to improve its models, or stores them in a particular location should be confirmed in the contract, not assumed from marketing material.

For staff, a plain rule of thumb helps: if you would not post it on the city website, do not paste it into a tool that is not approved for confidential data.

Human review

Every AI policy says a person must review the output. Fewer explain what review means. Spell it out.

Name the reviewer. Every AI-assisted work product has a responsible reviewer, usually the person whose name goes on it or their supervisor. "The tool wrote it" is never an explanation for an error.

Define what the reviewer checks:

• Facts, dates, names, dollar amounts, and vote counts match the source documents
• Cited sources exist and actually say what the draft claims
• Legal references are correct and current, with attorney review where appropriate
• Tone and content suit the audience
• The output does not treat any group unfairly or rely on stereotypes
• Nothing confidential has slipped in

Scale review to the stakes. An internal email needs a careful read. A resolution going to council needs line-by-line verification against the record. A translated emergency notice needs someone fluent in the language. Say so in the policy so staff do not apply the same light touch to everything.

Value verifiability, but do not rely on it. Tools that show where each statement came from, down to the document and page, make review faster because the reviewer can check claims directly. They do not make review optional. A citation can point to the right document while the draft paraphrases it incorrectly, so the reviewer should open the source.

Address disclosure and records retention

Disclosure

Disclosure policies tend to fail in one of two directions: nothing is ever disclosed, or a boilerplate label goes on everything and residents learn to ignore it. A middle path ties disclosure to the nature of the interaction.

• Always disclose when residents interact directly with an automated system, such as a chatbot on the city website. People should know they are not talking to a person, and how to reach one.
• Consider disclosing when AI substantially generated public-facing content, such as a translated notice, particularly if no one with subject knowledge reviewed it word for word.
• Generally not required for internal drafts, routine editing, or first drafts that staff have substantially revised and verified.

Also decide whether staff reports to council should note AI assistance. Some cities may prefer a short line in the report; others may treat a verified, staff-approved report as staff work regardless of how it was drafted. Either can be defensible if the city chooses deliberately and applies the choice consistently. Ask your attorney whether your state has disclosure requirements for government AI use, since rules here are still developing.

Records retention

This is the section most often skipped and the one most likely to cause trouble later. Whether prompts, outputs, and chat histories are public records depends on your state's public records law and on what they contain. In many jurisdictions, records status turns on content and function rather than format, but confirm the rule with your city attorney and your state archives or records program.

The policy should address:

• Classification. Treat prompts and outputs like other work materials. A chat used to develop a council item may fall under the same schedule as other drafts and working files.
• Location. Where are prompts and outputs stored, and for how long? City-contracted tools may keep logs the city controls. Consumer tools may not.
• Personal accounts. City business conducted in personal accounts can create records the city is still responsible for, which is a strong argument for requiring city-managed tools.
• Public records requests. Staff responding to requests need to know whether AI materials are in scope and how to retrieve them.
• Litigation holds. A hold should reach AI tool logs as well as email and files.

Your clerk or records manager, with the attorney, should map AI materials to existing retention categories. You may not need new categories, only clarity about which existing ones apply.

Write vendor requirements, training, and a review cadence

Vendor requirements

Much of a city's AI exposure comes through vendors, either new products or new features in existing ones. Require that any AI tool, or AI feature added to a current product, go through IT and legal review before use with city data. Then list what contracts should address:

• The city owns its data, inputs, and outputs
• The vendor does not use city data to train models without explicit written consent
• Where data is stored and processed, and which subcontractors have access
• Security practices, breach notification, and incident cooperation
• How each customer's data is separated from other customers' data
• Audit logs of user actions, available to the city
• Data export in usable formats and deletion at contract end
• Accessibility for staff and, where relevant, residents
• Whether and how the tool shows the sources behind its output
• Advance notice before AI features are added or changed

Capabilities change and vendors describe them differently. Confirm each point in a live demonstration using your own documents and in the written contract, not from a sales sheet. CISA publishes security resources IT staff may find useful when framing questions.

Training

A policy staff have not read is not doing anything. Require short, practical training before anyone gets access to an approved tool:

• What the policy allows and prohibits, with examples from city work
• How to recognize confidential information
• What a confident but wrong answer looks like, using a real example from a tool the city uses
• How to verify output against sources
• How records and retention apply
• Who to ask, and how to report a problem

Add role-specific material where it matters: records and minutes for clerks, personnel decisions for HR, disclosure and translation for communications. Track completion like other required training, and repeat it when the policy changes meaningfully.

Incident reporting and review cadence

Include a simple process for reporting problems, such as an output that went out with an error or confidential data entered into the wrong tool. Make reporting easy and non-punitive for good-faith mistakes. Early, honest reports show where the policy needs work.

Set a review date in the policy itself. An annual review of the main policy is a reasonable baseline, with more frequent updates to the approved tools appendix. List triggers for an earlier review:

• A change in state or federal law affecting government AI use
• A significant incident
• A new category of tool the policy did not anticipate
• A recommendation from the attorney, IT, or the records manager

Name a policy owner, a specific role rather than a committee, responsible for scheduling reviews, maintaining the appendix, and answering questions. The NIST AI Risk Management Framework is a voluntary reference some organizations consult for structuring ongoing risk review, and your drafting group may find it helpful.

An outline you can adapt

Here is a skeleton that pulls these sections together. Rename, reorder, and trim to fit your city.

1. Purpose. Why the policy exists and the principle that staff remain responsible.
2. Scope. Who is covered, which tools, and application to all city business regardless of device or account.
3. Definitions. A short list, with public record defined by reference to state law.
4. Roles and responsibilities. Policy owner, IT, legal, records, supervisors, and individual staff.
5. Permitted uses. Approved and conditional tiers with conditions, and a process for requesting new uses.
6. Prohibited uses. The prohibited tier and the instruction to ask when unsure.
7. Data handling. Classification levels and which levels may go into which tools.
8. Human review. Responsible reviewer, what review covers, and scaling to stakes.
9. Disclosure. When residents and council are told about AI use.
10. Records and retention. Records status, storage, personal accounts, requests, and holds.
11. Vendor requirements. Review before use and minimum contract terms.
12. Training. Required training, role-specific additions, and tracking.
13. Incident reporting. How to report and what happens next.
14. Compliance. How violations are handled, coordinated with existing personnel policies.
15. Review and revision. Cadence, triggers, and policy owner.
16. Appendix A: Approved tools. Tool name, approved data classes, approved uses, date approved.
17. Appendix B: Staff acknowledgment. Confirmation that the employee read the policy and completed training.

Before adoption checklist

• City attorney has reviewed every section against state law on public records, open meetings, privacy, employment, and procurement
• Records manager has mapped AI materials to existing retention categories
• IT has reviewed every approved tool and its contract terms
• HR has reviewed compliance and training sections against personnel policies, and has checked with the attorney whether any labor agreements require discussion first
• Department representatives have confirmed the draft reflects real work
• The adoption route (council action, administrative policy, or both) is confirmed
• A policy owner is named
• Training materials are ready before the policy takes effect
• A first review date is on the calendar

Next steps

You do not need to finish everything at once. A realistic sequence:

• Form the drafting group and send out the inventory questions.
• Draft purpose, scope, prohibited uses, and data handling first. These carry the most protective value and can go out as interim guidance while the rest is completed.
• Fill in review, disclosure, records, vendor, and training sections, then route the full draft to your city attorney.
• Adopt, train, and put the first review on the calendar.

Your state clerk association, municipal league, and networks such as IIMC and ICMA can often connect you with peers who have worked through these questions under your state's laws. If you are evaluating tools while you draft, including Govera, which drafts from a city's own records with citations, keeps each city's data in its own database schema, and audit logs every action, test each tool against your draft policy's requirements rather than shaping the policy around a tool.