Cities using AI tools without a documented classification system and reviewer lanes face legal exposure, equity liability, and public trust risk that a policy document alone won't fix.
This page is for everyone who gets asked — or who needs to ask — hard questions about how the city is using AI. It lays out how AI uses get classified by risk, who reviews what, what the city is not allowed to do, and how decisions get documented. Every city that uses this toolkit starts here. And every city can shape these rules to fit their own standards, values, and legal obligations.
The city classifies every proposed AI use before it moves forward. Classification determines who reviews it, what conditions apply, and whether it's allowed at all. These tiers are a starting point — your city can tighten them, add sub-categories, or apply different review requirements based on your own standards and obligations.
Internal drafting or support work that does not affect resident rights, service eligibility, or formal records — and does not require human review before use.
Examples: Drafting a staff memo. Summarizing a meeting. Generating talking points for an internal briefing. Writing a first draft of a policy section for human review.
These uses go through a lighter review path. They are still documented. They are still subject to monitoring if scope grows.
Resident-facing tools, service delivery decisions, enforcement-related support, or any use that creates legal, records, equity, or public trust concerns. These require full multi-stakeholder review before going live.
Examples: AI that helps screen benefits applications. Tools that support code enforcement decisions. Chatbots that answer resident questions about city services. Any use that touches hiring, discipline, or employee evaluation.
Legal, DEI, security, and community trust review are all required here. No high-risk use goes live without documented sign-off from each relevant lane.
Any use that bypasses required human review, hides the city's use of AI from residents or staff, or creates harm that outweighs any operational benefit. These are not subject to review — they are off the table.
Examples: Using AI to make final decisions on benefits without human review. Deploying AI tools without disclosing them to affected residents. Using AI outputs as official records without human verification.
If a proposed use falls here, it stops. The city does not need a workaround — it needs a different approach.
Every city has different staff and structures. This is the starting framework. Your city maps its own reviewers to these lanes.
Trigger: Any high-risk use, any use touching resident records, contracts, or liability.
What they review: Legal exposure, public records obligations, vendor contract terms, and whether the use creates any rights or due process concerns.
Trigger: Any use that affects resident-facing decisions, hiring, or service delivery.
What they review: Whether the AI use could produce discriminatory outcomes, whether affected communities were considered, and whether equity conditions are built into the review.
Trigger: Any use involving external vendors, data storage, API access, or system integration.
What they review: Data handling practices, vendor security posture, access controls, and whether resident or employee data is protected appropriately.
Trigger: Any use that affects how employees work, are evaluated, or are monitored — and any use that may trigger labor agreement review.
What they review: Workforce impact, training obligations, union notification requirements, and whether staff have been prepared and informed.
Trigger: Any resident-facing use, or any use likely to generate public questions.
What they review: Whether residents will be informed, how the city will explain the use publicly, and whether the communication plan is in place before launch.
Every proposed AI use — low or high risk — follows this path. The depth of review scales with the risk tier.
Most AI risk enters a city through vendor contracts. The risk tier framework applies to purchased tools the same way it applies to internally built ones — but vendor use adds a second layer of questions the city needs to answer before signing.
Before any AI tool is purchased or contracted, three functions should sign off: procurement or contracts (budget and compliance), IT or security (data architecture and access controls), and the CAIO or policy lead (alignment with the city's risk framework and training implications).
All three reviews should happen before contract terms are finalized, not after.
Price is not the only criterion. Before committing, the city should have answers to:
Every AI vendor contract should include at minimum:
The risk tiers and reviewer lanes are the framework. Documentation is what makes the framework real in a legal or regulatory challenge. A city that can show its process — not just its rules — is in a fundamentally stronger position than one that can only point to a policy document.
This documentation is not bureaucracy for its own sake. It is what allows the city to show it made a considered decision — and to explain that decision clearly if it is ever questioned.
The risk tiers and review steps on this page don't live only here. The public GitHub repo includes templates for documenting review decisions, checklists for each stakeholder lane, and evaluation rubrics that flag risk before a tool goes live. These materials are what turn a policy framework into something a real city team can actually use.
Use the repo when your city is ready to draft the governance language, risk tiers, review triggers, and supporting materials that make the rules usable. If the city still needs help mapping reviewers, resolving risk disagreements, or setting the governance shape, use the guided help path here.