# What Rules Should Cities Follow for AI Procurement in 2026?

urbanplanadvisor.com · September 24, 2026

> There is no single federal rule called the “urban AI procurement rules,” and no universal checklist that automatically makes a city’s artificial...

There is no single federal rule called the “urban AI procurement rules,” and no universal checklist that automatically makes a city’s artificial intelligence purchasing program lawful, effective, or fair. Instead, cities must combine federal procurement constraints, state law, local purchasing authority, privacy and civil-rights obligations, records rules, security controls, and contract terms. By September 24, 2026, the defensible approach is a risk-tiered framework: match oversight to the consequences of the system rather than applying one review process to every spreadsheet tool or every automated decision affecting housing, benefits, transportation, or public safety. A city does not need to prohibit all AI, but it should not delegate public-policy decisions to an unexplained vendor model. The best rule is a documented process requiring an accountable owner, measurable purpose, affected-community participation, independent testing, a human appeal path, and an exit plan before the contract is signed.

## Why Cities Need Their Own AI Procurement Standards

**Also worth reading:** [What are municipal AI procurement guidelines and how do cities implement them for technology contracts?](https://urbanplanadvisor.com/knowledge/what_are_municipal_ai_procurement_guidelines_and_how_do_cities_implement_them_for_technology_contracts.php) · [What should be on a digital twin procurement checklist for cities in 2026?](https://urbanplanadvisor.com/knowledge/what_should_be_on_a_digital_twin_procurement_checklist_for_cities_in_2026.php) · [What are the ethical AI in urban planning guidelines cities should actually follow in 2026?](https://urbanplanadvisor.com/knowledge/what_are_the_ethical_ai_in_urban_planning_guidelines_cities_should_actually_follow_in_2026.php)

City governments are buying tools that can influence permit queues, inspections, service requests, hiring, policing, benefits navigation, infrastructure maintenance, and emergency response. Those uses differ enormously in reversibility and public exposure, so a universal set of vendor questions is insufficient. A planning dashboard used to summarize public comments deserves ordinary data-security review; software recommending which developments receive staff review may require legal analysis, bias testing, and a route for applicants to contest an unfavorable result. The procurement process should therefore classify systems by the decisions they affect, the personal data they process, the people who cannot opt out, and the difficulty of correcting an error.

Existing procurement law supplies important boundaries rather than a complete AI governance model. Federal purchasing rules may apply when federal money is involved, including competition requirements, recordkeeping, labor provisions, domestic-content rules, accessibility duties, and restrictions on certain communications technologies. Oregon’s reported development of executive-order safeguards for state AI purchasing illustrates how governments can add centralized review and purchasing conditions beyond the bare statutory minimum. That development is instructive, but an executive order does not automatically govern every city, contractor, or later policy change. Cities need rules grounded in authority they actually possess and procedures that contractors can understand before bidding.

## How to Classify Risk Before Choosing a Vendor

A practical city rule should use a four-tier classification. Tier 1 covers low-risk administrative uses, such as drafting a nonbinding permit FAQ or grouping already-public maintenance records. Tier 2 covers operational assistance, such as prioritizing inspection visits or routing service requests, where staff retains meaningful control. Tier 3 covers consequential recommendations involving health, safety, employment, housing, or civil-rights exposure. Tier 4 covers autonomous systems that make or directly determine eligibility, enforcement, or access to essential services without adequate human review. The purpose is not to create a new certification industry; it is to make the procurement burden proportional to the harm that could occur.

Several thresholds can trigger enhanced review. A rule might apply whenever a system processes personal information, uses location or biometric data, ranks residents, generates enforcement or eligibility recommendations, or substitutes for a legally exercised government decision. Projects receiving federal assistance must also be screened for applicable federal requirements rather than assumed to fall outside city control because a commercial platform supplied the software. A useful classification record should identify the vendor’s claimed function, the city’s actual operating rules, the data categories involved, and whether residents can challenge the outcome. If staff cannot describe those elements in plain language, the procurement file is not ready for committee review.

| Feature | Lower-risk administrative system | Higher-risk decision-support system |
| --- | --- | --- |
| Typical use | Drafting, search, document summarization | Permit ranking, benefits triage, safety recommendations |
| Human control | Staff edits nearly every output | Staff can override but may face operational pressure to follow the model |
| Data | Primarily public or nonpersonal records | Personal, location, biometric, or legally sensitive data |
| Testing | Functionality, security, accessibility | Accuracy, subgroup error rates, adversarial misuse, appeal testing |
| Contract term | 6–12 months with a pilot option | Staged term with renewal gates, audit rights, data deletion, and termination assistance |
| Public reporting | Basic usage and incident record | Decision volume, error findings, override rates, appeals, costs, and vendor performance |

## What Minimum Safeguards Should Be Written Into the Contract?
Every contract should state that the city remains responsible for public decisions and cannot transfer its legal obligations to the provider. This is especially important when a vendor offers a “human in the loop” that has no real authority, no training, or no time to investigate disagreements. The purchaser should document who reviews outputs, how that person can reject a recommendation, whether overrides are monitored, and what happens when the vendor updates a model. A contract that names a product but does not control model changes is incomplete because the relevant service may change without a new competitive purchase.

Data provisions should cover collection, purpose limitation, retention, secondary use, model training, subcontractors, breach notification, and deletion. Many AI services do not need a city’s full data set, and routine procurement should begin with the smallest workable dataset. Contracts should normally prohibit a provider from using public-agency records to train a general commercial model unless the agency and the procurement authority have expressly approved that use. They should also require return or verified deletion of city data at termination, subject to documented legal retention requirements, rather than leaving records indefinitely in a vendor account for unspecified product improvement.

The city should also reserve audit rights sufficient to examine relevant model documentation, validation results, security incidents, and data flows, subject to legitimate confidentiality limits. Reporting should include the number of automated recommendations, adoption or override rates, error rates by relevant subgroup where legally and technically appropriate, appeals, and service availability. A 95% overall accuracy figure can conceal serious failure among a smaller population, which is why a contract should specify the test population and the consequences of materially higher error rates for any defined group. These provisions are more useful than a generic promise that the vendor uses “responsible AI principles.”

## Why Federal Funding Does Not Remove Local Accountability

Federal assistance can bring money, technical support, and pressure to modernize permitting, but it can also add compliance complexity. A city using AI to address delays should map each federal grant to the applicable purchasing terms before relying on a vendor’s certification. Depending on the funding and project, federal law may bring competition, labor, domestic preference, accessibility, cybersecurity, reporting, or records obligations into play. The StateScoop discussion of using federal funds for permitting delays is therefore a useful operational story, not proof that a procurement can be accelerated by simply buying an AI product. Faster software is of little value if the process produces unreliable reviews or undermines due process.

Public-law scholars also warn that rigid or poorly designed procurement controls can restrict agencies’ ability to exercise reasoned judgment. A rule demanding an algorithm be treated as ordinary equipment may ignore whether it effectively makes policy, while a rule requiring extensive review of every harmless tool can waste scarce legal and technical capacity. Cities should define exceptions narrowly, document them, and require senior approval for higher-risk exceptions. Expiration dates are useful because procurement policies often depend on technical conditions that change faster than ordinances; an annual review or a triggered review after a major vendor update can be more realistic than pretending a 2026 model will remain current in 2030.

A city should not cite an existing federal grant, state action, or private code of conduct as a substitute for its own acceptance criteria. Vendor ethics codes can be referenced, but they are usually designed around the company’s own risk management rather than a resident’s ability to contest a government decision. Conversely, a city should not claim that vendor documentation alone proves legal compliance. The agency needs records showing who evaluated the system, which alternatives it considered, how comments were handled, and why the selected method advances the public purpose at a reasonable cost.

## How Public Notice and Community Review Should Work

Public participation is most valuable when it occurs before the system’s operating assumptions are fixed. A city can publish the intended use, data categories, vendor name once selected, evaluation criteria, known limitations, and consultation process in ordinary language. Drafting a question at a council meeting is insufficient if residents have only days to understand a complex permit-ranking proposal. A 30-day initial consultation period is a reasonable starting point for a high-risk city deployment, with extension when the city lacks sufficient testing or evaluation information. A shorter period may be justified for an immediate security matter, but the record should explain the urgency and limit the system’s scope.

Participation does not mean giving every resident unlimited access to proprietary model weights. The right is to obtain information that enables meaningful scrutiny: what factors influence results, what data are absent, how residents can correct their records, and how an erroneous outcome can be challenged. Cities should also consult staff who will use the system because operational incentives often determine whether a nominal human review works. If workers are evaluated on automation speed, a rule allowing overrides may exist on paper but fail in practice. Procurement should therefore examine queue design, training time, performance measures, and staffing before launch.

The contract and implementation schedule should reserve time for testing with representative cases. A 60- to 90-day limited pilot can be useful for lower operational risk, while consequential systems may need several months and should never be tested primarily on the most convenient applicants. No pilot duration, however, can compensate for undocumented data quality, selective reporting, or a design that never intended to produce equitable results. Public reporting should explain sample size, known gaps, complaint outcomes, and whether leaders chose to renew, revise, or stop the system.

## Common Procurement Mistakes Cities Should Avoid

One common mistake is buying before defining the problem. A procurement framed as “acquire generative AI” encourages vendors to demonstrate broad product features rather than solve a verified delay or backlog. Cities should document the baseline first, such as the current median time for a selected permit review, the number of incomplete applications, or the cost of manually routing inspections. If no reliable baseline exists, the project may still be justified, but officials should not promise a numerical reduction they cannot measure. A useful target is framed over time, with a defined review date, rather than as an unsupported assertion of instant efficiency.

Another mistake is treating pilot success as final acceptance. A vendor can perform well on a curated demonstration and poorly on rare cases, multilingual requests, disability-related documents, or neighborhoods underrepresented in historical records. Accuracy must be separated from service speed, and both must be compared with the existing process. Cities also err by centralizing all oversight too early, creating a review body without capacity to test technical claims, or decentralizing it so much that each department adopts incompatible rules. A central purchasing function can set common contract conditions, while legal, privacy, accessibility, civil-rights, and subject-matter experts participate according to risk.

The most damaging error is automating institutional bias and then calling the result objective. A model can reproduce historical inspection, lending, hiring, policing, or enforcement patterns while presenting them in polished software. The relevant question is not whether a tool uses neutral language; it is whether its objectives, inputs, error patterns, and institutional consequences are acceptable. Government-by-algorithm analysis in Honolulu and the wider research on urban decision systems point to this recurring problem. Cities should fund evaluation and maintenance, not just acquisition, because monitoring is an operating expense rather than an optional feature added after launch.

## Budgeting, Staffing, and Realistic Cost Ranges

AI procurement costs extend beyond licenses. A limited departmental pilot may require roughly $25,000 to $100,000 during its first year for configuration, integration, security review, accessibility testing, and staff training. A production deployment with data migration, vendor integration, independent evaluation, and records redesign can range from $100,000 to several million dollars. A complex platform supporting thousands of users may exceed that range, especially when the city must purchase specialized computing, ongoing model support, or custom software. Prices are not publicly standardized, so any estimate should separate subscription fees, implementation work, internal labor, and annual review costs.

Cities should require transparent total-cost figures rather than accepting a low first-year quote. The contract should state seat or transaction pricing, overage charges, data-export fees, support levels, and the expense of changing vendors. Renewal increases above an agreed percentage can be difficult to justify if the underlying dataset and market have not changed; a useful term may include price protection during an initial term and a later renegotiation or competitive review. Small governments can sometimes pool requirements through regional purchasing cooperatives, but pooling reduces administrative duplication only if participants still test each proposed use and retain control over local decisions.

Staffing is frequently the larger constraint. One responsible program manager, a privacy or records specialist, a procurement official, a civil-rights or legal reviewer, an accessibility lead, and a domain expert may be needed for a serious deployment, although one person can hold several roles in a smaller city. Cities without those capacities can buy managed evaluation, use a shared state framework, or begin with a lower-risk tool. The Oregon action by Governor Tina Kotek, as reported by KATU, fits the broader movement toward state purchasing guardrails, but cities should verify the order’s scope and current status before treating it as a binding rule for their own purchases.

## When to Act and When to Pause

A city should move promptly when a clear service problem exists, a lawful use case is defined, responsible staff are available, and a reversible pilot can answer material questions. Waiting is not automatically safer: unresolved queues and manual routing can impose real costs on residents and staff. A useful initial schedule might include 30 days for problem definition and baseline measurement, 30 to 45 days for requirements and market research, a 45- to 90-day procurement and pilot preparation period, and a limited pilot lasting 60 to 90 days. High-risk or federally assisted projects should expect a longer process, particularly when legal review, public consultation, accessibility testing, or data agreements are incomplete.

A city should pause when the city cannot identify an accountable owner, the vendor will not disclose enough information to evaluate consequential errors, the system lacks a meaningful appeal route, or performance measures reward speed over correctness. It should also pause when using the data would create a new privacy purpose without authority, when the proposed contract prevents independent auditing, or when a pilot would place affected residents under real consequences before basic controls are tested. A 30-day delay is usually less costly than deploying a system that cannot explain or reverse its decisions.

The strongest policy is thus procurement by consequence. Publicly state which systems are allowed, require greater safeguards for decisions affecting rights and essential services, and give officials a defensible record before deployment. Require a contract that names the accountable human, restricts data use, preserves audit and appeal rights, and allows termination if performance fails. Review the framework at least annually and immediately after a major model change. This approach does not guarantee perfect outcomes, and no procurement rule can remove political choices about what a city values; it can, however, make those choices visible before technology turns them into administrative action.

## Quick answers

### Do federal rules govern every AI purchase made by a city?

No. Applicable requirements depend on the purchaser, funding source, transaction, product, and subject matter. Federal grant terms, federal procurement statutes, accessibility duties, and civil-rights obligations may apply in some projects, but a city buying a vendor’s software with locally appropriated funds should verify its own legal authority and obligations rather than assuming either total exemption or total federal control.

### Does Oregon’s executive order require cities to follow the same AI procurement process?

An Oregon executive order primarily governs agencies covered by its text and does not automatically apply to every city in the state or country. Cities should examine the order’s scope, effective date, contracting exceptions, and any implementing documents, while also following applicable state statutes and local purchasing rules.

### What is the most important safeguard for city-used AI?

The central safeguard is meaningful human accountability: an authorized official must understand the system, consider evidence, and be able to reject or correct its output. A nominal approval button is insufficient if staff lack training, time, information, or authority to challenge the result.

### Should cities publish the source code of every AI system?

Not necessarily. Source code can be proprietary, extremely technical, and less informative than documentation about data, decision factors, testing, errors, and appeal procedures. Cities should first obtain the information needed to evaluate risk and public accountability, and separately address security, trade-secret, and legal constraints.

### How much does responsible AI procurement cost?

A limited pilot may cost about $25,000 to $100,000 in its first year, while an integrated production system can range from $100,000 to several million dollars. Costs vary with users, data complexity, integration, evaluation, staffing, and vendor pricing, so cities should require multi-year total-cost disclosure rather than compare headline subscription fees alone.

Canonical: https://urbanplanadvisor.com/knowledge/what_rules_should_cities_follow_for_ai_procurement_in_2026.php
Markdown: https://urbanplanadvisor.com/knowledge/what_rules_should_cities_follow_for_ai_procurement_in_2026.php/index.md