Direct Answer: Treat AI Governance as a Permit Condition, Not a Software Policy
Cities should “permit” AI governance by requiring each operational system to receive a documented authorization decision before it can influence or automate a public decision. That authorization should identify the permitted purpose, users, data, decision rights, performance thresholds, monitoring duties, and conditions for suspension. It should apply to systems used for zoning analysis, permit intake, code review, environmental review, inspection triage, and public-facing advice, while recognizing that a system offering information is different from one making or determining a legal decision. The governing authority—not the vendor—must remain accountable for the result, even when the software is supplied as a service.
Also worth reading: How Should Local Governments Establish Responsible AI Planning Governance? · How Is AI Governance in Municipal Planning Changing City Administration in 2026? · How does sovereign AI reshape urban planning ethics and governance in 2026?
A workable rule separates four functions: administrative support, recommendation, delegated decision, and final legal decision. Administrative support might classify documents or route an application; recommendation might suggest code conflicts; delegated decision might approve applications meeting predefined criteria; a final legal decision requires a person with statutory authority to act. The higher the autonomy and public impact, the stronger the required evidence and approval. A 30-day intake classifier should not face the same review burden as an agent that can reject a permit, alter conditions, or communicate an enforceable decision without human confirmation.
The city should issue a written permit for a defined period—such as 12 months for a low-risk internal tool and 6 months for a higher-risk decision system—with renewal after an independent audit. Thresholds should be measured against actual operations, not only vendor tests. For example, a system could be paused if it changes a recommendation in more than 5% of cases without a documented reason, produces error-rate disparities across applicant groups, or lacks an accessible audit trail for 98% of actions. These numbers are proposed governance thresholds rather than universal legal standards, and each city should calibrate them to the harm involved.
The central principle is conditional authorization: the city permits the AI only while specified controls remain effective. This is stronger than a general code of ethics because it creates a named owner, a decision record, enforceable limits, and an expiration date. It also answers a democratic problem identified in debates about agentic AI: governments cannot transfer public authority to software merely because the software appears neutral, fast, or consistent. Authorization must come through law, procurement, public oversight, or delegated administrative action.
Why Conventional AI Policies Do Not Control Agentic Permit Decisions
Yesterday’s governance controls often focus on whether a model was trained fairly, whether personal data was collected lawfully, and whether a human nominally remained “in the loop.” Those controls become weaker when an agent can call several systems, interpret regulations, retrieve case files, draft a permit decision, submit it to an internal queue, and initiate limited follow-up actions. A static checklist may pass during procurement but fail once the system operates continuously across departments. Governance therefore has to examine the combined technical system, organizational workflow, and legal authority rather than the model alone.
Agentic systems also change the speed and scale at which errors propagate. A human reviewer may handle 20 applications per week, while an automated intake layer can process 2,000 in the same period; an agent that communicates directly with applicants can send thousands of notices before city staff detect a faulty interpretation. Speed itself is not improper, and automation can reduce staff time spent searching records, checking duplicate submissions, and routing incomplete files. The problem arises when the city permits consequential action without testing distribution of errors, defining escalation, and preserving the evidence required to reverse decisions.
The EU Artificial Intelligence Act provides a useful risk framework because it treats systems differently according to use and risk, with additional obligations for certain high-impact uses. However, its structure is primarily regulatory and does not replace city-level authorization procedures. The US regulatory environment is more fragmented, and state or local rules may govern public records, due process, procurement, land use, environment, civil rights, and records retention. Cities therefore need a common internal permit mechanism that points to the applicable legal duties rather than pretending one policy resolves every statute.
A final reason to change governance is that vendors and models update. A system tested in January may use a different model, retrieval source, prompt, integration, or tool permission in September. Procurement language should therefore require advance notice of material changes, prohibit silent replacement, and trigger reauthorization when specified events occur. Examples include a new model family, a new external data source, expanded access to case files, a change affecting appeal rights, or a move from advisory to approval authority. This treats the permitted system as a changing service, not a fixed appliance.
A Risk-Tiered Model for Authorizing AI in Permit Work
A city can begin with a four-tier authorization model, but tiers should depend on the function and consequence rather than the marketing label “AI.” The lowest tier covers deterministic clerical tools such as converting a PDF to searchable text, provided staff verify the conversion before a legal determination. The second covers triage and recommendation, such as identifying missing documents or flagging possible conflicts for a planner. The third covers delegated decisions under tightly defined rules, while the fourth covers systems that make final discretionary decisions, exercise enforcement powers, or represent the city in binding communications.
| Feature | Human-Assisted System | Delegated AI System | Final-Decision AI System |
|---|---|---|---|
| Typical permit role | Search, classify, or flag issues | Approve cases meeting objective criteria | Exercise discretion or enforce land-use law |
| Required authorization | Department manager and privacy/security review | Formal AI permit with legal approval | Council authorization or ordinance-supported delegation |
| Human involvement | Reviewer checks relevant output | Human handles exceptions and appeals | Legally authorized official remains accountable |
| Minimum evidence | Accuracy and privacy test by staff class | Outcome testing, bias analysis, and appeal test | Public hearing, due-process analysis, and emergency suspension plan |
| Renewal interval | 12 months after material change | 6–12 months | 3–6 months until performance is established |
| Permitted action limit | No binding effect | Only defined case classes and volumes | No autonomous final action without expressly granted authority |
Risk assessments should also include reversibility. An incorrect map label is easier to correct than an incorrect demolition approval, while a notice that causes financial loss is harder to remedy than an internal draft. The assessment should ask how quickly the city can detect the error, whether the action can be undone, who bears the loss, and whether an appeal is available. Reversibility can justify a temporary pilot for low-harm functions, but it should not be used to excuse a system from testing when housing, environmental, or civil-rights interests may be affected.
Tiering permits gradual institutional learning. A city can authorize document classification for 90 days, measure routing accuracy, and then consider recommending missing materials. It need not begin with an autonomous permit decision. Each expansion should produce a separate authorization decision showing what changed, what evidence exists, and what remains outside scope. This staged approach is more defensible than approving a broad platform for “future use.”
Required Controls Before an AI Permit Is Issued
The application should describe the exact workflow from applicant submission to final disposition. “Permit review assistant” is too broad; the city needs to know whether the software reads plans, interprets the zoning code, compares parcel data, recommends conditions, or sends notices. The application should identify every model, external service, database, integration, and user role, while listing the decisions the system cannot make. Vendors should disclose subprocessors, data locations, retention periods, training practices, and whether public records or privileged material can be accessed.
Testing must include both technical and institutional performance. A useful test set may contain at least 200 historical cases, including routine approvals, denials, appeals, unusual variances, incomplete applications, and adversarial inputs. Depending on the system and jurisdiction, the city may demand sensitivity analysis for approval rates, false-positive rates, false-negative rates, processing time, and error severity; a 97% overall accuracy figure can hide unacceptable failure in a high-risk subgroup. Thresholds should be tied to harm, with a requirement for human correction before action whenever a critical recommendation is uncertain.
The city also needs enforceable controls over access. Agents should receive only the minimum privileges necessary, and those privileges should be time-limited where possible. An intake agent should not automatically inherit the ability to modify parcel records, inspect permit histories, or send legal notices. High-impact actions should require a second check, a dual-control step, or a qualified official’s approval. Logs should record inputs, model and prompt versions, retrieved sources, tool calls, outputs, human edits, approvals, and final actions in a format that can be exported and preserved.
Public communication is another condition of authorization. The applicant should be told when AI materially assisted review, how to request human review, and how to contest an information or recommendation error. “Decisions are made by city staff” may be misleading if staff merely accept automated recommendations without independent judgment. Conversely, applicants should not receive irrelevant technical disclosures that do not help them understand the process. The practical standard is clear notice at the point where AI use affects timeliness, interpretation, or review.
Public Accountability, Procurement, and Vendor Limits
The AI permit should identify one accountable department and one accountable official even when several agencies use the tool. A permit without a named owner becomes difficult to suspend and often allows each department to blame another. The owner should report quarterly on volume, errors, appeals, manual overrides, disparities, incidents, downtime, vendor changes, and corrective actions. Reports should be understandable to elected officials and the public, not limited to technical metrics such as token use or model latency.
Contracts must prevent the vendor from making public-law claims on the city’s behalf. The city should state that the vendor supplies decision support and cannot independently approve, condition, deny, inspect, or enforce a permit. The contract should preserve audit rights, require incident notice within a defined period such as 24 to 72 hours for serious events, and set deletion and export rules for city data. It should also prevent vendor retention of application files for unrelated model training unless the city has separately determined that use is lawful and disclosed.
A useful escalation clause should distinguish defects from misconduct. A critical security breach, unauthorized external communication, or materially false city decision may trigger immediate suspension, while a minor interface problem enters a managed correction process. Renewal should be denied when corrective work is incomplete, monitoring lapses, or performance deteriorates. The city should not have to finish an annual procurement process before disabling a system causing continuing harm.
Public accountability also requires records. For each material AI-assisted decision, the city should preserve the relevant input, cited authority, generated recommendation, human disposition, and final statutory basis. However, not every system needs to retain a full trace indefinitely. The records schedule should match the legal value and cost of each record type, with a practical approach of retaining core decision records for at least the applicable appeal period and system logs for the period justified by risk, security, and audit needs. State public-records and retention laws must control where they require a different period.
The governance process itself should be reviewable. A senior legal, technology, and public-interest panel can review high-risk permits, but routine oversight should not require a new hearing for every model update. A published register showing the system, purpose, owner, risk tier, approval date, expiration date, and summary of controls reduces secrecy. If a city cannot explain this information plainly, the system may be too complex for the current organization to govern safely.
Common Mistakes and Limits of the “Human in the Loop” Solution
The most common mistake is naming a human as the safeguard without giving that person time, information, or authority. If staff must approve 500 flagged cases per day with no independent verification, the human role is ceremonial. Controls should be based on review depth, not on a signature. A reviewer should see the AI’s recommendation, the source text or plan provisions, the uncertainty or missing information, and a practical way to reject or correct the result.
Another mistake is using aggregate accuracy as the sole measure. A system with 95% accuracy may still create severe failures in denials, affordable-housing applications, flood-zone decisions, or accessibility issues. Cities should measure error costs and subgroup outcomes, though sensitive demographic analysis requires privacy safeguards and may be limited where data is sparse or legally restricted. Where sample sizes are inadequate, the city should avoid declaring fairness and instead use more cautious thresholds, additional review, and further collection.
Pilots are also mishandled when the goal is simply to prove that the product works rather than to learn whether the city should continue using it. A 30-day pilot may test speed but not appeals, rare cases, or organizational resilience. It should have preapproved success, failure, and stop conditions—for example, 90% completeness for document routing, fewer than 1% of wrong routing decisions escaping review, and correction within two business days. If the tool saves time but creates systematically harder appeals, that is not an unqualified success.
Finally, cities sometimes ask whether AI is “fair,” “accurate,” or “safe” as if one label can authorize deployment. No such label is reliable across purposes, populations, and periods. Governance must ask narrower questions: accurate at what task, safe under what operating conditions, fair compared with which decision standard, and accountable to whom. This is less dramatic than claiming that software can eliminate political judgment, but it is more useful because it identifies the evidence and authority that public decision-making requires.
Costs, Timelines, and When Cities Should Act
There is no universal market price for a city AI permit. A lower-risk document-classification pilot may cost roughly $25,000 to $100,000, while an integrated permit-review or case-management system can range from approximately $100,000 to several million dollars depending on integrations, data preparation, security review, and licensing. Annual subscription and usage charges can range from tens of thousands to more than $1 million for a large enterprise deployment. These are planning ranges rather than quotations, and cities should obtain competitive proposals with total-cost terms that include storage, model use, support, audits, and exit.
The governance work may add $75,000 to $250,000 for a well-scoped municipal pilot, while legal drafting, independent testing, records redesign, and staff training could increase that amount. Smaller jurisdictions can reduce expense by joining a regional consortium, using existing procurement vehicles, or beginning with a read-only tool. They should not reduce cost by omitting logs, appeal information, or accountability merely because the vendor offers a low initial price. Public infrastructure has long maintenance and replacement costs, and an exit plan is part of responsible procurement.
Timing should depend on the capability. A city should act before deployment, not after an agent can already submit applications, access broad datasets, or communicate decisions. As of 26 September 2026, the immediate priority is not hypothetical superintelligence; it is the already growing use of AI by local governments and the continuing expansion of agentic tools. A city can begin with a 90-day inventory of systems and a 180-day authorization pilot, then issue formal permits for the highest-risk existing tools. Waiting for a universal federal framework may delay controls without resolving local authority or workflow risks.
The strongest trigger for urgent action is a system that can take a consequential action with limited human review, particularly if it handles housing, environmental review, enforcement, public benefits, or due-process rights. A useful deadline rule is to inventory consequential systems within 90 days, require a temporary control review within 30 days of discovery, and prevent material expansion until authorization is complete. Cities should move quickly but proportionately: high-impact autonomy requires stronger review, while read-only search can proceed through a lighter permit.
The result should not be a ban on AI. Municipal staff may need help locating ordinances, comparing plan sheets, detecting duplicate submissions, summarizing long records, and communicating routine status. The goal is to permit useful automation while denying unauthorized discretion. A defensible AI governance regime therefore combines risk tiers, written authorization, measurable thresholds, public records, vendor accountability, appeal routes, and the power to pause the system. It recognizes that speed can improve public service, but speed without valid authorization is not democratic efficiency.
A Practical Governance Sequence for Municipal Adoption
First, the city should create an inventory covering every acquired, purchased, or internally built tool that touches permit data. The inventory should identify owners, vendors, users, data, integrations, and whether the system advises or acts. Existing systems should be prioritized by consequence, not novelty. A system that can issue a denial deserves earlier review than an internal tool that only extracts a date from a document.
Second, the city should adopt a short policy defining categories, minimum evidence, decision rights, and suspension triggers. Legal staff should map the system to zoning authority, due process, public-records requirements, civil-rights duties, environmental law, privacy rules, and procurement controls. Technical staff should set testing methods, but legal and policy officials should determine which functions may be delegated. The final policy should be approved through a process visible enough that the public understands who granted authority and under what limits.
Third, departments should submit permit applications using a common form and evidence package. Reviewers should score the proposed system against purpose limitation, data quality, security, human oversight, accuracy, disparate impact, appeal design, vendor dependency, and reversibility. The reviewing panel should issue an approval with conditions, require changes, impose a temporary moratorium, or deny authorization. Approving a system in an unrestricted way should be the exception rather than the default.
Fourth, the city should run a monitored pilot with a defined cohort and period. A 90-day pilot may use historical cases or a limited class of live applications, but the authorization should state which actions remain prohibited. The city should compare results with a documented human baseline, investigate failed cases, and provide a safe route for affected applicants. At the end, the owner should recommend renewal, modification, or termination based on evidence rather than enthusiasm.
Finally, the city should publish a short register and maintain a suspension channel accessible to staff and the public. The register can include the system name, purpose, risk tier, owner, approval and expiration dates, and contact for correction. The city should conduct an annual governance review and a post-incident review after any serious error. This sequence recognizes that no city will predict every technical failure, but it can ensure that failures are detected, corrected, and paid for by the institution that granted permission.