Federal AI Acquisition: A Practical Governance Checklist
A useful federal AI acquisition starts before a solicitation names a product. The acquisition team needs a precise mission outcome, representative evaluation evidence, data and exit rights, operational controls, and a plan for monitoring performance after award. This checklist turns those concerns into artifacts that program, acquisition, security, privacy, legal, data, and operations teams can review together.
1. Define the mission outcome and decision boundary
Describe the operational problem in terms of the decision or service that must improve. Establish the current baseline, the people affected, the systems involved, and the measurable result the acquisition should support. Keep the requirement outcome-based so vendors can propose different technical approaches without weakening accountability.
Document what the AI may recommend, generate, or automate; what requires human approval; and what must remain outside the system. This boundary should be specific enough to test during evaluation and to govern during operations.
- Named mission owner and operational owner
- Baseline measures and target outcomes
- Allowed actions, prohibited actions, and human-review points
- Representative users, environments, and accessibility needs
2. Turn evaluation into measurable acceptance criteria
Require vendors to demonstrate performance against representative tasks and data, not only a polished generic demo. Define quality, latency, reliability, security, and cost measures before selection, along with the minimum evidence needed to accept each release.
For generative systems, the evaluation plan should address inaccurate output, unsupported claims, sensitive-data exposure, harmful content, and changes in behavior after model or prompt updates. The test set, scoring method, reviewers, thresholds, and remediation path should be documented and repeatable.
- Scenario-based test set and scoring rubric
- Error taxonomy and escalation thresholds
- Cost and latency measured under expected load
- Re-evaluation triggers for model, data, or workflow changes
3. Protect data portability, interoperability, and exit options
OMB Memorandum M-25-22 directs agencies to pay attention to vendor sourcing, data portability, and long-term interoperability. Translate that direction into concrete contract deliverables: documented interfaces, export formats, configuration records, audit data, and a tested transition process.
Clarify ownership and permitted use of agency data, prompts, outputs, evaluation sets, fine-tuning artifacts, and operational logs. The exit plan should explain how the agency can retrieve its information, preserve records, transfer service, and discontinue vendor access.
- Documented APIs and machine-readable exports
- Data-use, retention, deletion, and model-training terms
- Configuration and evaluation artifacts delivered with the system
- Transition assistance and verifiable access revocation
4. Make governance part of day-to-day operations
NIST organizes AI risk work around Govern, Map, Measure, and Manage. An acquisition can use those functions to assign owners, map context and impact, measure performance and risk, and manage issues throughout the lifecycle. The exact controls should be tailored to the use case rather than copied as a generic checklist.
Create an operating record for the system: purpose, owners, users, data, dependencies, limitations, approvals, evaluation history, incidents, material changes, and retirement criteria. High-impact decisions need clear human accountability and an appeal or correction path appropriate to the service.
- Current system and use-case record
- Role-based access and approval matrix
- Monitoring, incident response, and change-control procedures
- Scheduled review and decommissioning criteria
5. Require secure-by-design delivery evidence
Security belongs in architecture, delivery, and operations. CISA’s Secure by Design guidance emphasizes reducing the security burden on customers and making protections such as multifactor authentication, logging, and single sign-on available by default. Acquisition teams can ask vendors to show how those principles appear in the proposed system.
Evidence may include a threat model, dependency and vulnerability practices, secrets management, identity boundaries, logging coverage, deployment safeguards, backup and recovery tests, incident procedures, and a software bill of materials when appropriate to the requirement.
- Threat model tied to the actual deployment
- Least-privilege identity and secrets controls
- Auditable releases, rollback paths, and recovery tests
- Security findings, remediation ownership, and reporting cadence
6. Package the requirement for cross-functional review
Before release, assemble a concise acquisition packet that the program, acquisition, security, privacy, legal, data, accessibility, records, and operations stakeholders can evaluate. Early cross-functional review reduces late surprises and makes vendor responses easier to compare.
A practical packet includes the mission outcome, workflow and data map, decision boundary, evaluation plan, security and privacy requirements, interoperability and exit provisions, service levels, reporting requirements, and post-award monitoring plan. Requirements still need to be tailored to the agency, acquisition strategy, applicable law, and risk profile.