How Should Cities Buy AI Software Without Locking In the Wrong Vendor?

What Municipal AI Procurement Actually Requires

Municipal AI procurement is the process a city uses to evaluate, select, contract for, and manage artificial-intelligence software or services for public administration. It covers more than comparing model accuracy: a buyer must test data rights, security, accessibility, bias, auditability, operating costs, vendor claims, and the consequences of service failure. The direct answer is that cities should buy a bounded administrative task before buying a broad “AI transformation,” while reserving the right to reject outputs that lack a lawful, explainable basis. As of September 26, 2026, that approach matters because procurement delays can themselves become policy. New York City’s reported effort to pause some school software purchases until AI guidance is final illustrates the central tension: emerging rules may justify a pause, but a prolonged pause can also allow unexamined purchasing to continue elsewhere. Atlanta’s city framework for AI use similarly suggests that cities increasingly need rules before individual departments improvise. A sound municipal AI procurement process therefore combines competitive purchasing with a separate approval gate for high-risk uses.

Also worth reading: Which AI Planning Software Should Cities Compare in 2026? · How can cities implement AI permitting software to reduce housing delays and what are the practical steps for adoption? · What is AI zoning compliance software for cities and how does it work?

The buying unit should be a specific workflow, not a vendor platform. For example, a planning department might evaluate tools that identify changes in building permits, compare zoning-code revisions, or summarize public comments, while excluding decisions that automatically approve, deny, inspect, or enforce anything. This framing improves competition because several vendors may solve the same workflow without requiring the city to accept one vendor’s data model. It also makes cancellation less painful if performance is poor. Cities should document the baseline before procurement: current staff hours, error rate, turnaround time, complaint volume, and the manual checks performed today. A tool that reduces a 40-hour review to 20 hours but introduces 10 hours of verification has not delivered a 50% productivity gain; it has delivered a 25% net gain. Procurement should measure realized value after verification, not the vendor’s gross automation rate.

Why Traditional Vendor Selection Is Not Enough

Conventional procurement often treats software as a relatively fixed product: compare licenses, features, implementation schedules, and references. AI systems differ because their behavior can change with prompts, source documents, user behavior, model updates, and the composition of local data. A system that performs well on a demonstration may produce unstable results when a rare application, translated document, incomplete permit, or unfamiliar neighborhood enters the workflow. Contract language should therefore define the service outcome, test data, monitoring duties, and remedies rather than relying only on feature names. Model accuracy should be tested on cases representative of the city, including edge cases that are missing from vendor-selected examples. The city should also identify which components are automated, which require human judgment, and who is legally responsible when the output is wrong.

A second problem is that procurement rules designed for visible products are poorly matched to data and model services. A city may be purchasing access to a model, but it still must decide whether staff may upload public records, personally identifiable information, confidential plans, or information covered by attorney-client or intergovernmental restrictions. The vendor may retain prompts for improvement, train on customer information, use subcontractors, or transfer data across borders. Those practices can change after the contract is signed, so the agreement needs continuing controls, not merely a one-time security questionnaire. Security questionnaires also tend to ask whether encryption exists, while a city must ask what data is collected, why it is collected, how long it is retained, whether it can be used for training, and how deletion can be verified. Atlanta’s public work on an AI-use framework and New York City’s examination of AI policy demonstrate why these rules need to exist before departments negotiate independently.

A Practical Municipal AI Procurement Process

The first step is to classify the proposed use by potential harm and reversibility. A low-risk tool that tags council agenda documents is different from software recommending zoning enforcement or eligibility determinations. Cities can set approval thresholds: for example, advisory uses with no direct eligibility or enforcement effect may receive a departmental review, while systems making or materially recommending decisions about people may require legal, civil-rights, records, cybersecurity, accessibility, and public consultation review. A useful trigger is the prospect of affecting access to housing, education, employment, public benefits, safety investigation, or due process. Classification should be recorded in a one-page use case naming the owner, users, affected residents, data categories, decisions supported, and a planned end date for a pilot. This creates accountability without demanding the same expensive review for every harmless text-formatting tool.

The next step is a controlled test using representative data. The city should divide known cases into development and acceptance sets, with the acceptance set unavailable to the vendor until testing begins. Acceptance criteria should include an agreed accuracy or extraction target, a maximum error rate for consequential fields, a response-time requirement, accessibility conformance, complete audit logs, and mandatory human review. For example, a permit-review system might be required to reach at least 95% classification accuracy, while a field affecting payments might face a stricter threshold and a “no adverse action without human confirmation” rule. The test should include adversarial or poor-quality inputs, not merely clean historical documents. Procurement teams should also observe the vendor correcting errors rather than only seeing a polished demonstration. A 60- to 90-day pilot is often enough to test a bounded workflow, but it should be extended if the city lacks enough representative cases to make a reliable judgment.

Before issuing a solicitation, the city should decide which data may be used and whether synthetic or de-identified samples are sufficient. Contract terms should prohibit training on municipal data without separate written approval, define retention and deletion periods, require disclosure of subprocessors, and give the city audit and incident-notification rights. Incident reporting may need to occur within a fixed period such as 24 to 72 hours, depending on the system’s risk. The agreement should state who owns work product, whether the city can export logs and data in usable formats, and whether service can be terminated without losing operational records. If switching vendors costs more than the annual license, the city may have an ineffective exit. Exit planning is therefore a procurement requirement, not an afterthought.

Comparing the Main Procurement Alternatives

Cities have several defensible routes, and the cheapest option is not always the quickest. The table below compares the most common approaches. No option should be selected solely by acquisition price, because staff time, integration, review, legal work, and switching costs can dominate the first-year expense.

A direct purchase is reasonable for a narrow, low-risk product below the city’s formal competitive threshold, but the threshold should be reset for AI because token, data-processing, and integration costs can be undervalued. An RFP is usually preferable when several vendors claim similar capabilities and the city can define measurable acceptance criteria. Cooperative purchasing can reduce price and contract-development effort when cities need similar document, permitting, or constituent-service tools, although a regional buyer may not adequately represent one city’s languages, neighborhoods, or legal rules. Building internally is rarely justified for a generic summarization feature when mature products already exist. It becomes more plausible when the capability depends on unique local knowledge, when external processing of source material is prohibited, or when the city has a durable team capable of operating it for at least three to five years.

Costs, Pricing, and Contract Structure

There is no reliable universal price for municipal AI procurement because a city can buy anything from a narrow document assistant to an enterprise workflow platform. Limited departmental tools may start around $20,000 to $100,000 annually, while planning, permitting, records, or customer-service deployments can run from $100,000 to more than $1 million in the first year. Those figures are planning ranges rather than official quotes, and integration, security review, data preparation, training, and model usage can exceed the subscription. Usage-based pricing introduces another risk: if the vendor prices each document, query, or automated action, a successful system may become more expensive as adoption rises. Contracts should state usage units, included allowances, historical reports, price-review dates, and annual increase caps. A three-year commitment should not be used merely to obtain a discount if the underlying model, vendor ownership, or data terms could change.

TCO should include at least 36 months of operating expense, although five years may be more realistic for planning tools because data must remain accessible after a contract ends. Procurement staff should add software fees, infrastructure, integration, licenses for connected systems, annotation and evaluation work, staff training, legal review, monitoring, security testing, and the estimated cost of correcting erroneous outputs. The calculation should assign a conservative value to human review; if an employee spends 15 minutes checking every automated record, that labor belongs in the model. Cities should also quantify lock-in through estimated data-export hours, replacement integration cost, and the number of proprietary formats involved. Free open-source software is not free to operate. It still needs security updates, model hosting or local compute, maintenance, documentation, and accountable staff ownership.

Payment should follow evidence rather than a large share based only on go-live. A practical structure might reserve 10%–20% of fees for an acceptance period, release part of the fee after agreed accuracy and accessibility tests pass, and retain 5%–10% for a limited warranty or transition obligation. Exact percentages depend on local law and contract policy. The city should avoid accepting claims that a system is “secure,” “fair,” or “explainable” without a definition and evidence. “Explainable” may mean displaying source citations, while in another context it may mean disclosing model architecture or producing a legally meaningful reason for an adverse decision. The contract should identify which meaning is required. Vendors offering a pilot should clarify whether pilot data becomes production data, whether the service level survives conversion, and whether prices automatically change after the trial.

Common Procurement Mistakes and How to Avoid Them

One common mistake is beginning with a famous product rather than a public problem. A demonstration can make AI appear necessary even when a search index, rules-based form, or better data workflow would solve the problem at lower risk. Cities should require a “non-AI alternative” assessment and compare the proposed system with improved manuals, staff training, process redesign, and conventional software. Another mistake is using vendor benchmark accuracy as if it measured local performance. General benchmarks do not represent local zoning terminology, historical documents, language communities, or rare case types. Procurement should ask vendors to test against a city-defined acceptance set and should preserve the right to repeat the test after a material model update.

The second major mistake is treating human review as permission to automate any decision. A person who receives 200 unreviewed recommendations for 30 minutes is unlikely to independently verify each one. Human-in-the-loop controls require authority, time, training, and documentation. Cities must also avoid hidden shadow decisions, such as purchase orders, staffing allocations, or enforcement priorities, where AI output affects a person without appearing in the formal process. Bias testing is often incomplete because aggregate accuracy can conceal poor results for smaller groups. A city should examine false-positive and false-negative rates by relevant language, neighborhood, disability status, or other lawful criteria, while recognizing that collecting demographic data for testing also requires protection. Procurement and civil-rights staff should determine which comparisons are legally and ethically appropriate.

A third mistake is negotiating only the signature page. Terms on retention, model training, subcontractors, updates, breach notice, records, deletion, audit rights, and termination determine ongoing exposure. Cities should coordinate procurement counsel, privacy personnel, information security, records management, accessibility specialists, and the operational owner from the start. Departments should also budget for contract management after award. A system that launches but is not monitored can become a shadow dependency, particularly when staff turnover leaves only one person who understands its limitations. The city should require a named owner, quarterly performance reporting for consequential systems, an annual risk review, and a documented offboarding plan. A pause can be useful during rule development, as discussed in New York, but it should have a deadline and a public decision owner; indefinite uncertainty encourages circumvention rather than good governance.

When Cities Should Act, Pilot, or Wait

Cities should act now when the task is bounded, the value can be measured, and appropriate data already exists. A planning department can responsibly pilot automated document indexing or draft permit-data summaries if outputs remain advisory and staff verify the underlying records. The city should also act when delay carries a real public cost, such as staff spending hours manually locating information needed for an application. A limited 90-day pilot with a fixed budget and no production decision authority can be safer than immediate automation. The pilot should have written success criteria, a security review, a date for an affirmative continuation decision, and a requirement to delete test data. A failed pilot can then produce useful evidence rather than turning into a multi-year platform commitment.

Cities should pause when the intended use would materially affect individual rights and governance rules remain unsettled. This includes automated eligibility, enforcement, housing or education recommendations, predictive policing, or systems that combine sensitive datasets without a clear legal basis. Pause does not mean buying nothing; it means separating low-risk productivity tools from decisions requiring new policy. Cities should publish an interim rule that prohibits high-risk autonomous uses while allowing advisory experiments under defined controls. New York City’s school-software concerns show why procurement can be used to enforce a governance boundary, while Atlanta’s framework indicates that broader municipal policy is becoming necessary. The best time to establish a review process is before a compelling pilot attracts senior sponsorship.

A city is also wise to wait for clearer vendor terms when data ownership, model training, or deletion cannot be resolved. If a vendor will not commit that municipal data will not be used to train shared models, or cannot export logs in a usable format, operational dependence may be unacceptable. The city should not rush merely to meet a grant deadline; the grant’s savings can be consumed by integration and review. Conversely, a city should not wait for perfect regulation before testing low-risk applications. The practical position is to permit reversible experiments, impose thresholds by potential harm, and scale only after evidence. That approach gives procurement teams a defensible way to move without treating every AI purchase as either inevitable or forbidden.

The Best Policy for Urban Planning and Public Administration

The strongest municipal AI procurement model separates four questions: whether the city may use AI, whether a particular vendor satisfies security and data requirements, whether the proposed workflow is accurate and useful, and whether affected people receive appropriate notice or review. One approval does not answer all four. Legal permission does not prove local performance, and a successful pilot does not authorize broader use. This separation allows a planning department to test document assistance while preventing that success from being cited as proof that the same vendor can safely determine zoning outcomes or allocate inspections.

For urban planners specifically, the first use cases should support, rather than replace, professional judgment. They may help search plans, reconcile ordinance versions, identify missing application fields, compare grant conditions, and flag inconsistencies in submitted documents. The city should not permit a model to silently change a parcel designation, declare a project compliant, select inspection targets, or convert predictive analysis into a permit decision. Even in advisory settings, planners need source links, version dates, confidence or quality warnings, and a record of corrections. Public explanations should describe the role of the system in plain language; they should not flood residents with technical claims about model size or accuracy. If the tool cannot explain which source led to a statement, staff should not rely on that statement as a formal finding.

The defensible city strategy is therefore neither “buy AI quickly” nor “wait for all uncertainty to disappear.” Set a risk threshold, test on local work, require meaningful data and exit rights, and expand only when evidence justifies it. A city that applies these controls can gain efficiency while preserving public authority. A city that treats the software contract as the entire policy is likely to acquire tools faster than it can govern them. Procurement is valuable here because it turns broad AI debate into a specific, reviewable decision: what task, what data, what performance standard, what human control, and what remedy if the system fails.