Wiki · Concept · Last reviewed June 19, 2026

AI Procurement

AI procurement is the process by which an organization defines, buys, contracts for, tests, monitors, and exits an AI system or service under requirements that preserve public accountability, safety, data protection, competition, and operational control.

Category: Concept Published: June 19, 2026 Modified: June 19, 2026 Last reviewed: June 19, 2026 Tags: AI Procurement, Vendor Governance, Public Sector AI, AI Contracts, Risk Management

Definition

AI procurement is the governance of acquisition for AI systems, AI-enabled services, models, agents, datasets, evaluation tools, cloud services, and vendors. It is not only the act of buying software. It is the discipline of turning a proposed use case into enforceable requirements before a system enters an institution.

A procurement process decides what problem is being solved, what data will be used, what risks are acceptable, who may rely on the output, what evidence the vendor must provide, what rights the buyer retains, how performance will be measured, what logs and audit rights exist, and how the system can be suspended, modified, or replaced. It connects directly to AI Governance, AI System Inventory, AI Bill of Materials, AI Audits and Assurance, and AI Liability and Accountability.

The useful boundary is the deployed system, not the sales category. A procured AI capability may include a base model, a vendor-hosted endpoint, a user interface, retrieval indexes, prompts, fine-tunes, memory, analytics, subcontractors, cloud regions, human review workflows, and future model updates. Procurement should identify and contract around that boundary before the system handles real people, records, money, or public authority.

Snapshot

How It Works

A basic AI procurement cycle begins before vendor selection. The buyer should define the intended purpose, affected population, operational context, prohibited uses, data flows, privacy constraints, security requirements, evaluation criteria, human oversight, accessibility needs, and incident paths. The solicitation should ask for evidence rather than marketing: model and system documentation, data handling terms, known limitations, test results, cybersecurity posture, subcontractors, hosting location, pricing structure, support obligations, and change notification.

During selection, teams should involve acquisition, legal, security, privacy, data, civil-rights, program, accessibility, records-management, labor, and domain experts. During deployment, the buyer should pilot the system, test it on representative tasks, measure failure modes, record the version, and connect the system to monitoring and complaint channels. Contract terms should preserve data rights, interoperability, audit access, performance reporting, security remediation, portability, and termination rights.

For agentic systems, procurement must also ask what the system can do. Tool permissions, identity, spending authority, connectors, file access, browser use, human approval gates, sandboxing, trace logs, and rollback procedures are part of the purchased capability. A chatbot and an agent with production credentials should not pass through the same procurement review.

Current Context

In the United States federal government, OMB Memorandum M-25-22, issued April 3, 2025, gives government-wide guidance for acquiring AI. It applies to covered AI systems or services acquired by or on behalf of covered agencies, and it frames the acquisition problem around competition, performance and risk management, and cross-functional engagement. The memo instructs agencies to update internal acquisition procedures and include contract terms addressing matters such as privacy, testing, data rights, risk management, and interoperability where applicable.

Federal AI procurement also now has a more explicitly political content layer. OMB Memorandum M-26-04, issued December 11, 2025, implements federal "Unbiased AI Principles" for procured large language models, including truth-seeking and ideological neutrality as OMB-defined procurement principles. That memo is important source material for federal LLM purchasing, but it should be read as federal procurement policy, not as a general technical definition of bias, truth, or trustworthiness.

GSA's public Buy AI page, last updated May 11, 2026, lists federal AI procurement options through OneGov agreements and other vehicles. The page includes federal access paths for AI evaluation and enterprise AI tools and presents best practices: start from agency needs, scope and test solutions, manage and protect data, engage key officials, and monitor costs. GSA has also circulated draft government AI system terms and conditions, including a draft clause titled Basic Safeguarding of Artificial Intelligence Systems; because that material is marked draft, it should be cited as draft rather than final contract law.

GAO's 2026 report on federal AI acquisitions found that selected agencies were not yet systematically collecting lessons learned from AI acquisitions, even though such lessons could help agencies share contract terms, testing requirements, and data-rights practices. That finding points to an institutional weakness: procurement knowledge often stays inside single offices while AI vendors and platforms scale across many agencies.

European rules create another procurement pressure point. Under the EU AI Act, deployers of high-risk AI systems must use systems according to instructions, assign competent human oversight, monitor operation, keep logs when under their control, and report certain risks or incidents. Article 27 requires certain public bodies and private entities providing public services to perform a fundamental rights impact assessment before deploying specified high-risk AI systems. Buyers in or serving the EU therefore need procurement files that can support deployer duties, not just provider marketing claims.

OECD's catalogue of AI policy tools includes AI Procurement in a Box, a set of guidelines and checklists originally developed by the World Economic Forum and the UK Office for AI to support responsible public purchasing decisions. NIST's AI Risk Management Framework remains a general reference for mapping, measuring, managing, and governing AI risk across the lifecycle, while NIST SP 800-218A and joint cybersecurity guidance on deploying AI systems securely are useful for contract requirements around AI supply chains, secure deployment, and acquirer responsibilities.

Procurement File

A serious AI procurement should leave a procurement file that can survive staff turnover, vendor changes, and later investigation. The file should identify the use case, system owner, legal basis, affected population, risk classification, vendor, model or service, data categories, subcontractors, deployment environment, accessibility needs, human oversight role, and the conditions under which the system may not be used.

The technical evidence should include model and system documentation, an AI Bill of Materials or equivalent component inventory, data provenance records, security review, privacy review, evaluation plan, pilot results, known limitations, model-update policy, logging and retention rules, incident contact, vulnerability-disclosure channel, and decommissioning plan. For hosted services, the file should also record whether customer prompts, files, outputs, embeddings, traces, or feedback are used for training or product improvement.

The contract evidence should bind promises to remedies: service levels, data-use restrictions, deletion and export duties, audit rights, change notice, support obligations, breach notice, performance reporting, subcontractor flow-down, indemnity or liability allocation, suspension rights, transition assistance, and termination for unresolved safety, security, legal, or performance failures.

Governance and Safety

Procurement is where many AI risks either become governable or become embedded. A weak contract can leave an agency or company dependent on a black-box vendor, unable to inspect logs, unable to challenge model updates, unable to export data, unable to test subgroup performance, or unable to terminate without losing institutional memory.

Good procurement prevents "pilot drift," where a small experiment quietly becomes infrastructure. It also prevents "vendor laundering," where a buyer treats a contractor's proprietary system as outside public accountability even though the system affects workers, students, patients, customers, or residents. The buyer remains responsible for the decision to use the system.

Safety implications differ by use case. A document summarizer used on public text needs different controls from a benefits eligibility tool, clinical decision-support system, hiring screener, student-risk flag, coding agent, or workflow agent with email and payment access. Procurement should therefore tie obligations to the actual authority and data the system receives, not to a generic vendor category.

Competition is also a governance issue. Volume discounts, proprietary formats, bundled cloud credits, identity integration, data gravity, and model-specific workflow design can make exit expensive even when the contract permits exit on paper. Procurement should require usable exports, documentation, transition assistance, and retention limits before a dependency becomes operationally irreversible.

Defense Pattern

Source Discipline

Claims about AI procurement should distinguish statutes, binding contract clauses, executive guidance, agency web pages, draft clauses, vendor terms, marketing pages, third-party audits, and independent evaluations. A procurement page listing a tool or discount is evidence of an acquisition path, not evidence that the tool is safe, lawful, accurate, unbiased, or appropriate for a specific mission.

For current U.S. federal claims, prefer OMB memoranda, GSA acquisition materials, GAO reports, agency directives, SAM.gov notices, and final contract clauses over law-firm summaries or vendor blog posts. For EU claims, prefer the Official Journal text of Regulation (EU) 2024/1689 and official European Commission materials. For security claims, prefer NIST, CISA, NSA, NCSC, standards bodies, security advisories, and reproducible testing over product assurances.

Procurement evidence should be dated and versioned. A vendor's terms, model behavior, data-retention policy, subprocessors, prices, API, audit logs, and acceptable-use policy can change after award. Renewal reviews should compare the deployed system against the original procurement file rather than assuming the original approval still describes the system.

Spiralist Reading

AI procurement is the moment the institution chooses which machine it will let speak in its name.

The contract is not clerical. It decides what can be seen, challenged, logged, priced, appealed, or forgotten. A bad procurement turns public power into vendor opacity. A good one keeps the record attached to the system.

Open Questions

Sources

Return to Wiki