# Navigating AI Procurement and Governance in the Public Sector Public-sector AI is no longer a pilot conversation. Cities, counties, and state agencies are moving from "what could AI do for us?" to "how do we buy, deploy, and govern it responsibly?" The gap between those two questions is where most projects stall — not because the technology is missing, but because procurement, policy, and accountability haven't caught up. This guide is a practical roadmap for municipal and agency leaders navigating AI procurement software decisions and building AI governance frameworks that staff can actually follow. ## Why AI in government is different Enterprise AI advice doesn't map cleanly onto government. A city IT director evaluating an AI vendor is balancing constraints that a private-sector CTO never touches: public records law, procurement statutes, elected oversight, resident trust, and staff who need to explain any decision back to the community. Four constraints shape every public-sector AI decision: 1. **Transparency by default.** If a resident asks how a decision was made, "the AI decided" is not an acceptable answer. Governance has to produce a human-readable trail. 2. **Procurement runs on statute, not intent.** RFPs, sole-source justifications, and cooperative purchasing agreements all pre-date modern AI. You have to make AI fit the existing process, not the reverse. 3. **Data is public trust.** Resident data, case files, permit histories, and internal communications are subject to retention, disclosure, and minimum-necessary-access rules that most SaaS AI vendors were not designed around. 4. **Careers ride on it.** A misfire in a private company is a bad quarter. A misfire in government becomes a council meeting, a news cycle, and sometimes a lawsuit. Any AI procurement or governance framework that ignores those four constraints will collapse the first time it's tested. ## A five-phase AI procurement roadmap Use these five phases as the backbone of any AI procurement decision. They align with how most municipalities already run technology purchases and give elected officials and department heads clear go/no-go checkpoints. ### Phase 1 — Problem framing (before you look at any vendor) Most failed AI purchases start with the vendor demo, not the problem. Before evaluating AI procurement software, get specific: - What workflow, decision, or bottleneck are you trying to change? - Who does it today, how often, and how long does it take? - What would "good" look like in twelve months — time saved, response time, backlog reduction, resident satisfaction? - Who has the authority to change the workflow if AI succeeds? If you cannot answer those four questions in one paragraph, you are not ready to buy. You are ready to run a discovery — internal or with a partner — and come back. ### Phase 2 — Data readiness AI vendors sell capability. What they cannot sell is your data being ready to use. Audit before you procure: - **Where does the data live?** ERP, records management, permit system, shared drives, email. - **Who owns it?** Not "IT" — the actual department that answers questions about it. - **What can leave your environment?** Some data can go to a third-party model. Some cannot. Some can only go to a model hosted in a specific region or FedRAMP-authorized environment. - **What's the quality?** AI amplifies whatever it's given. If the underlying records are inconsistent, the output will be too. This phase alone kills more bad procurements than any RFP scoring rubric. ### Phase 3 — Vendor and tool evaluation Now you're ready to look at AI procurement software and platform vendors. Evaluate on six axes, not just features: | Axis | What to ask | | --- | --- | | Security posture | SOC 2, FedRAMP, CJIS if applicable. Data residency. Encryption at rest and in transit. | | Data handling | Is your data used to train their models? Can you turn that off? Retention policy? | | Explainability | Can staff see why the model produced a given output? Is there an audit log? | | Human-in-the-loop | Does the workflow require human approval for consequential decisions? | | Integration | Does it fit your existing stack (Microsoft 365, Google Workspace, your ERP) or does it demand a rip-and-replace? | | Total cost | Licensing, implementation, training, and the internal staff time to operate it. | A vendor that cannot answer any one of these with a straight face is a vendor to walk away from — no matter how good the demo looked. ### Phase 4 — Contracting and procurement Modern AI does not fit the standard IT services contract template. Before signing, make sure the contract explicitly addresses: - **Data ownership and portability.** Your data is yours. You get it back in a usable format if you leave. - **Training rights.** The vendor may not train foundational models on your data without written consent. - **Model changes.** You are notified before the underlying model is swapped or upgraded in a way that changes output. - **Uptime and incident response.** Specific SLAs, specific breach-notification timelines. - **Termination.** A clean exit path — not a hostage situation with your workflow. If your existing IT contract template doesn't cover these, add an AI addendum before you sign. Every one of these items has been a real dispute in a real government contract in the last twenty-four months. ### Phase 5 — Rollout and operations Procurement doesn't end at signature. Build the rollout plan into the purchase decision: - **Pilot scope.** One department, one workflow, ninety days. - **Success metrics.** Defined before the pilot starts, not after. - **Training.** Every staff member who touches the tool. Not a recorded webinar — real, in-person or live-remote sessions with time to ask questions. - **Feedback loop.** A named person who collects issues and gets them fixed. - **Go/no-go review.** Written decision on whether to expand, adjust, or shelve. ## Responsible AI governance for public agencies Governance is where most agencies over-engineer or under-engineer. Over-engineered governance produces a 40-page policy no one reads. Under-engineered governance produces the news cycle you were trying to avoid. Effective public-sector AI governance has five components. Keep each one short enough that a department head can hold it in their head. ### 1. Acceptable use policy One page. What staff can use AI for, what they cannot, and what data can never be pasted into a public model. Written in plain English. Signed by every employee who has access to AI tools. ### 2. Risk tiering Not every AI use is equally risky. Tier them: - **Low risk** — drafting internal communications, summarizing public documents, brainstorming. - **Medium risk** — assisting with resident-facing communication, non-binding recommendations to staff. - **High risk** — any decision that affects a resident, employee, or vendor — permits, benefits, discipline, procurement scoring. High-risk uses require human-in-the-loop approval, an audit log, and a documented review process. Low-risk uses do not. ### 3. Data classification Map your data to what can be used with which model. A simple three-tier system works: - **Public** — anything already published or subject to routine disclosure. Any tool. - **Internal** — non-public but non-sensitive. Enterprise or contracted AI only, with data-handling terms in place. - **Sensitive or regulated** — CJIS, HIPAA, PII, personnel, litigation. On-premises or dedicated-tenant only, if at all. ### 4. Human oversight and accountability Every high-risk AI use has a named human owner. That person is accountable for the output — not the vendor, not the model, not "the algorithm." If a resident asks who made the decision, there is an answer. ### 5. Transparency to residents Publish, in plain language, where and how the agency uses AI. Update it when things change. Answer questions directly. Trust compounds; so does its opposite. ## Common pitfalls (and how to avoid them) - **"AI as a mandate."** A department is told to use AI without a specific problem to solve. Result: shelfware. Fix: always start from a workflow problem, not a technology directive. - **"Vendor-led governance."** The AI vendor writes the governance policy. Result: a policy that permits everything the vendor sells. Fix: governance is written by the agency, with the vendor as a technical input, not the author. - **"Pilot forever."** Nothing ever leaves pilot phase because no one wants to sign off. Fix: build the go/no-go decision date into the pilot from day one. - **"Compliance theater."** A long policy document, a signed attestation, and no operational change. Fix: measure adoption and outcomes, not policy word count. - **"One-time training."** Staff are trained at launch and never again. Fix: quarterly refreshers and a named person to answer day-to-day questions. ## What to do next If your agency is early on this path, three practical steps: 1. **Pick one workflow.** Not five. One. Where AI could plausibly save real time or improve real service. 2. **Assess your data and readiness.** Honestly. If the data isn't there, fix that first. 3. **Draft a one-page acceptable use policy.** Before any tool is purchased. It will save you months of confusion later. AI in government does not have to be risky, expensive, or slow. It has to be deliberate. The agencies getting real results are the ones who treated procurement and governance as part of the product decision, not paperwork to do afterward. If you'd like a second set of eyes on where AI actually fits in your agency — or a review of an AI procurement you're evaluating — a 30-minute strategy call is usually all it takes to get unstuck.

Navigating AI Procurement and Governance in the Public Sector

Want help applying this to your organization?