Writing an ethics checklist for municipal AI means turning broad principles into yes-or-no questions a city can answer before a system touches a resident. A good one covers fairness, privacy, transparency, accountability and public impact, and gives every question a named owner and a review date.
The honest version of this guide: it is a document, not a meeting. Drafting takes a committee of six or seven people, one working session per section, and a council vote if the checklist is going to carry weight in procurement. Teams that skip the writing step end up with a vendor contract and a public meeting full of questions nobody prepared for.
Last reviewed: October 2026.
Table of Contents
- What You Need
- The use case and the decision it touches
- The affected communities
- Data sources and vendor materials
- Legal obligations you already have
- Existing risk assessments and public feedback
- One named owner and one approval route
- Step-by-Step: Build a Practical Municipal AI Ethics Checklist
- 1. Define the public purpose and decision context
- 2. Identify affected groups and unequal impacts
- 3. Assess data quality, privacy and security
- 4. Require transparency and explainability
- 5. Test fairness, accessibility and public impact
- 6. Assign accountability and approval gates
- 7. Review, monitor and revise the checklist
- Common Mistakes
- Frequently Asked Questions
- What are the 5 pillars of AI ethics?
- Who should approve an AI ethics checklist in local government?
- What is the minimum viable AI checklist for a small town with no IT department?
- How do you handle AI vendors during procurement?
- What is the 30% rule for AI?
- How often should a municipal AI policy be reviewed?
What You Need
Before anyone drafts a question, gather the material the questions will be about. Most stalled checklists fail here: the committee starts from principles and then discovers mid-way that nobody knows where the data came from.
The use case and the decision it touches
A one-page description of the system in plain language. What does it do, what decision does it inform, and what happens to a resident if that decision goes the wrong way. A 311 chatbot that misroutes a complaint is a different risk profile from a permit screening tool that flags an application for denial, even when both run on the same vendor’s model.
The affected communities
Who uses this service, who is expected to use it, and who currently does not. Pull call volumes, service request data, language access records, and any complaint or appeal history. If your 311 chatbot logs mostly English requests while a fifth of the city speaks another language at home, that gap belongs in the checklist, not in a footnote.
Data sources and vendor materials
For every data feed: where it originates, who licensed it, what sensitive fields it contains, how long it is retained, and whether it can be linked back to a person. From vendors, ask for model documentation, sub-processor lists, audit rights, incident notification terms, and subgroup performance reports. Public-sector teams frequently cannot see what is inside a vendor’s tool, which is exactly why the question needs to be in writing.
Legal obligations you already have
Your public records policy, open meetings rules, procurement thresholds, retention schedules, accessibility requirements, and any state privacy or consumer data statutes. AI does not create new duties here; it makes existing ones harder to satisfy quietly, because a model output is difficult to explain in a records request or defend in an appeal.
Existing risk assessments and public feedback
Prior privacy impact assessments, cybersecurity reviews, vendor security questionnaires, and any staff complaints or resident correspondence about the current process. That last one is the most useful document on the list, because residents describe broken processes far more precisely than any audit.
One named owner and one approval route
Decide before drafting who owns the checklist and who can say no. A checklist that no one can block is a poster. Practitioner discussions in r/AI_Governance circle the same point from the other direction: committees without the authority to stop a deployment produce documents that get ignored the first time a deadline gets tight.
Step-by-Step: Build a Practical Municipal AI Ethics Checklist
Build it in seven steps, and then use it five times. The same checklist should run at intake when a department proposes a tool, at design review before a pilot, at procurement before a contract, at pilot approval before launch, and at post-deployment review after it has been live. A checklist that only fires once, at legal sign-off, becomes a document nobody reopens.
1. Define the public purpose and decision context
Start with the question the system exists to answer. Write down the public benefit in one sentence, name who benefits, and name who may be worse off. Then mark the boundary of automation: where does the system stop and a named person start.
That boundary is the most contested line in the document. For a permit or benefits decision, the city should be able to point at the human being who reviews the output and who can be called in a hearing. For a translation or a search index, no human decision is involved and the risk profile is different. Classify each system as advisory, assistive, or decisional, and hold the decisional tier to the strictest gates.
2. Identify affected groups and unequal impacts
List the groups who could face unequal access, inaccurate outcomes, or increased monitoring. Neighborhoods, language groups, disabled residents, older adults, low-income households, and people with limited broadband all belong here. Undocumented residents rarely show up in a dataset, and their absence is itself a finding worth recording.
For each group, write the specific harm you are checking: a misrouted request, a denied application, a misread inspection photo, an appointment slot that never opens. Generic language about equity will not survive contact with a procurement question. Specific harm names survive it.
3. Assess data quality, privacy and security
Work through provenance, permission, accuracy, representativeness, retention, and third-party access. Ask whether historical data encodes past enforcement patterns, and whether a person can be re-identified from a combination of fields even when names are stripped.
Data minimization is the practical test: if you did not need a field for the service purpose, do not collect it. Write the retention period and the deletion trigger into the checklist, and require encryption, access logging, and role-based access for anything sensitive. Where a vendor processes resident data, name the contractual terms that make those controls real.
4. Require transparency and explainability
Transparency is disclosure; explainability is the ability to give a reason. You need both, and they are not the same thing. Residents should be told what the system does, what data it uses, what it cannot do, and when a person is involved. Staff and decision-makers should be able to trace a specific output back to its inputs.
Write down what gets published: a public notice when a system is acquired, a description of its purpose and limits, and a point of contact. Write down what staff get: a one-page description of the known failure modes, because a model that invents an answer is a foreseeable problem and staff should not be the ones discovering it for the first time in public.
5. Test fairness, accessibility and public impact
Set the evidence bar before you see results. Subgroup performance has to be measured, not asserted. Language access has to work end to end, including the fallback when the system cannot help. Accessibility review covers screen readers, plain-language output, and residents without reliable internet or a smartphone.
Also decide the pilot metrics and, just as importantly, the consequences of failure. What happens if a permit queue systematically delays applications from one neighborhood? Who tells the council, and does the deployment get paused? A checklist that has no stop condition has quietly decided that the system will continue regardless of what the data shows.
6. Assign accountability and approval gates
For each stage, name the accountable owner, the approving authority, the independent reviewers, and the documentation each one expects. Frontline staff and at least one resident advocate belong on that list, not as observers. A committee that only includes people who approve technology will find nothing wrong with it.
Then write the complaint route. A resident who believes an AI-assisted decision was wrong needs a way to reach a person, a time limit for a response, and a record of the outcome that feeds the next review. Without that, the appeal path exists only in theory, and the strongest safeguard separating AI from enforcement disappears.
7. Review, monitor and revise the checklist
Set a recurring review cadence and a version number, and put the review date on the checklist itself. Post-deployment monitoring needs named measures: volume of overrides, appeal outcomes, subgroup performance drift, and incident reports. Vendor models change underneath you, and a checklist that assumes a fixed version is checking a system you no longer run.
Trigger a full reassessment after any material change: a new use, a new data source, a vendor migration, a model version jump, or an incident. Write the trigger down next to the questions so it is found by the person who needs it.
Common Mistakes
Vague principles. “Promote fairness and inclusion” cannot be audited. Replace it with: “Performance is reported by neighborhood, language, and disability status before launch, and again six months after.”
No named owner. Every question gets a role, not a department. When the role is “IT”, nobody owns the item, because IT owns all of it and none of it.
One-time approval. A checklist signed once and filed is a historical document. Attach review dates, require a sign-off at each of the five gates, and version it.
Treating fairness as one score. A single fairness number hides the group it was computed over. Report per subgroup, and state the group that is hardest to measure so the gap is visible rather than averaged away.
Ignoring disabled and low-connectivity residents. Digital equity means testing the service the way the residents with the fewest options use it. Otherwise the people with the most ways to complain are the ones protected.
Confusing explainability with transparency. Publishing a technical model card is not public transparency, and a chat interface is not explainability. The test is whether a resident can learn what the system did, and whether staff can trace a specific output to its inputs.
No exit path. Write down how a system gets turned off, what happens to the data, and who tells the council. A contract with no termination-for-convenience clause on ethical grounds leaves the city committed to a tool its own checklist has condemned.
Frequently Asked Questions
What are the 5 pillars of AI ethics?
Most municipal checklists collapse into five pillars: fairness, privacy, transparency, accountability, and human oversight. Some frameworks count four by folding accountability into oversight, and others list ten governance areas. The count matters less than the coverage. If a principle has no owner and no evidence attached to it, it is not a pillar, it is a value statement.
Who should approve an AI ethics checklist in local government?
A cross-department group drafts it: city manager or department director, IT, city attorney, procurement, communications, the records or privacy officer, frontline staff, and at least one resident advocate. Approval usually sits with the city manager for internal policy, or with the council by ordinance or resolution when the checklist carries budget and procurement consequences. Name the approver before drafting the first question.
What is the minimum viable AI checklist for a small town with no IT department?
Five questions cover it: what is the system for and who benefits, what data goes in and where did it come from, what happens when the output is wrong and who reviews it, who is accountable and how does a resident appeal, and when will this be reviewed. Small municipalities can run the same process; they just cannot staff it, so borrow a county or state framework rather than writing principles from scratch.
How do you handle AI vendors during procurement?
Write the evidence requirements into the contract before the tool is bought. Ask for training data documentation, subgroup performance reports, access and retention terms, sub-processor lists, audit rights, incident notification timelines, and a commitment to delete city data at contract end. If a vendor will not supply documentation covering the populations your residents belong to, that refusal is your procurement review finding.
What is the 30% rule for AI?
There is no 30% rule in the NIST AI Risk Management Framework, the OECD AI Principles, or the EU AI Act. The phrase shows up in vendor material and internal conversations as an arbitrary threshold for human oversight. Treat it as a prompt to ask how much of a decision actually stays with a person, not as a compliance figure. If a number like that is driving your policy, trace where it came from first.
How often should a municipal AI policy be reviewed?
Most teams settle on a quarterly look at open items and a full rewrite each year, plus an immediate reassessment after an incident, a model update, or a change in use. Vendor model versions change without the council knowing, so the review date belongs on the checklist itself rather than in a separate memo. A checklist with no review date on it is a memo.
Start with the smallest useful version. Pick one system your city already runs, score it through the seven sections this week, and see which questions nobody in the room can answer. Those unanswered questions are your work plan, and they will tell you where the checklist needs to be sharper before a council vote ever comes up.
