AI Governance in Permitting: How to Keep Staff in Control of Every Decision

Housing pressure is rewriting a lot of local priorities right now, and permit volume is one of the first places it shows up. In departments already running close to capacity, the backlog compounds, and a slow queue rarely stays a building-department problem for long.

AI has moved out of conference panels and onto permit counters, and the question building officials ask has changed with it. Nobody is asking whether the technology works anymore. They want to know what to settle before it touches a single file: what the system is allowed to decide on its own, how easy it is for a reviewer to override it, and who has to answer for a decision an applicant appeals. That's a governance question, and unlike a lot of AI questions right now, it already has real answers.

Where AI sits in community development today

Cities now have real options across most of the community development lifecycle: intake and completeness screening, code compliance checks, applicant guidance, inspection scheduling, records search. But a reviewer who loses the first hour of every file to completeness checks has a different problem than one whose bottleneck is interpreting code, and the tool that helps one won't necessarily help the other.

Two departments we work with have staged their adoption rather than turning everything on at once:

• Seattle, Washington ran a structured program of AI plan review with 14 plan reviewers across two phases, starting with code compliance pre-screening and then intake pre-screening. Reviewers checked the system's output against their own determinations and fed back on the gaps.

• Calgary, Alberta is applying structured rule logic to one of Canada's most complex zoning frameworks, with consistency as the goal rather than speed.

Both departments followed the same pattern: start with a narrow slice of the work, check the system against reviewers who already know the right answer, adjust based on what's wrong, and only widen the scope once the evidence supports it. That's not caution for its own sake. It's what lets a department explain exactly how a result was reached when someone, an applicant, an auditor, a council member, eventually asks.

Governance is keeping pace, and it's showing up in an unglamorous place: procurement paperwork. Bellevue, Washington's AI Policy and Guidelines covers procurement, human review of outputs, attribution, data privacy, and the treatment of AI-assisted work as public records. Little Rock, Arkansas requires human oversight of all AI-generated work, routed through a committee that approves tools before deployment. And Stanwood, Washington issued an RFQ specifically for AI permit and plan review software, a peer department writing these expectations directly into a solicitation.

What "staying in control" actually means

Control is not a feeling of comfort about a vendor. It is five properties you can point at.

• Attribution. You can point to the person who made the determination. Not the system that was involved, the person who decided.

• Reversibility. City staff can change any output without friction, and changing it is routine rather than an escalation.

• Auditability. You can reconstruct how an output came about months later, when the applicant has appealed and the reviewer who handled it has left.

• Authority. The person whose job it is to make that call owns the decision. The system's output is an input to their judgment, not a substitute for it.

• Data protection. You can say where application data goes, who can access it, how long it is retained, and whether it leaves your control. Permit application contain site plans, financial information and personal details. Every AI-assisted record is still a public record subject to disclosure and retention rules, and Bellevue's policy treats this explicitly.

Six things worth deciding before you turn it on

1. What the system may and may not determine. Draw the line between screening and deciding. Confirming an application has every required document is screening. Deciding whether what's submitted actually meets code, the kind of call a licensed reviewer signs their name to, is deciding. That distinction needs to be a documented decision, spelled out in writing as policy, not something everyone's just expected to know. Undocumented, it depends on who's on staff that day, and staff changes.

2. How overrides get recorded. Capture who overrode the system, when, and why. The "why" is what actually matters. If reviewers keep overriding the same rule, say, a setback requirement the system keeps flagging wrong, that's not twenty isolated exceptions. That's the system misreading a local amendment, and it won't fix itself.

3. What explainability you expect. Here's a workable standard: a reviewer should be able to trace any output back to the exact page and code section that produced it.

4. Who reviews accuracy, and how often. Name one person and a set schedule. Codes get amended, the mix of applications shifts, and the AI's performance can quietly slip over time even if nothing about your process changed.

5. Where the data goes. Whether submitted plans and applications ever leave city hands, who outside your department can see them, how long they're kept, and how you'd actually produce them if someone filed a public records request.

6. Where AI is the wrong tool. Here's the honest answer: sometimes it is, and permit count alone won't tell you when. A department where most of the queue is simple residential work, a fence permit, a water heater swap, might find the setup costs outweigh the payoff. A department buried in complex commercial plan sets, even at a similar volume, usually finds the opposite, and both calculations shift again depending on how demanding your own city's code is. A department that doesn't already have a documented, consistent way of reviewing applications will struggle with any vendor regardless, because there's no standard for the AI to be consistent against yet. That has to come first. Deciding "not yet" is still a decision, and a reasonable one.

Who holds what

What to put in your RFP or RFQ

Every governance decision above turns into a specific question you can hand a vendor in writing. Here's what to actually ask. Stanwood's RFQ is a useful example of how specific this can get in practice.

• Ask for proof, not a description. Every output should point back to the exact page and code section it came from. Don't settle for a vendor telling you this is possible. Ask to see a real example, so you know a reviewer could actually explain the result to an applicant who pushes back.
• Get overrides in writing, and keep the record yourself. Every override needs a name, a timestamp, and a reason attached to it, and your department needs to be able to pull up that history any time, not just the vendor. If it only lives on their side, it doesn't do you much good.
• Ask what happens when a code changes. Codes get amended. Find out exactly how the system updates when that happens, and how long it takes, not just whether it happens at all. "We'll handle it" isn't an answer. A specific process is.
• Nail down exactly where your data goes. Where submitted plans and applications are stored, who outside your own staff can see them, how long everything is kept, and how you'd produce it all if someone filed a public records request. Permit files often include site plans, financial details, and personal information, so this one is worth pinning down.
• Make them show their math on any accuracy claim. If someone tells you their system is "95% accurate," ask what was measured, over what time period, and on what kind of permits. Without those three answers, the number doesn't actually mean anything.

Clariti's AI Plan Review Buyer's Guide goes further on comparing options once the answers come back.

Starting without a full program

You don't need a formal governance policy in place before your first project, and waiting for one is a good way to never start.

Two decisions do most of the work on day one. Write down what the system is allowed to decide on its own, and what it isn't. Then log every override with a reason, starting the first day you use it. Get those two right and the rest tends to follow.

Seattle's Department of Construction and Inspections (SDCI) partnered with Clariti on a two-phase pilot of AI-assisted permit pre-screening.  Staff started out skeptical: seven people had doubts for every one who didn't. Reviewers checked the system's answers against their own and flagged what it got wrong. After hands-on use, 71% came away with a more favorable view, and the people who used it most ended up the most convinced. 

Those numbers describe how reviewers felt about the tool, not how fast it worked. What changed their minds wasn't a sales pitch or a demo. It was using the tool themselves and checking its answers against what they already knew was right, which is exactly what happens naturally once you're logging overrides and keeping the system's scope narrow.

Governance usually gets treated like the thing slowing adoption down. In practice, it's closer to what makes adoption actually stick, because it gives the people doing the work something solid to stand on instead of just trusting that the tool is right.