This article presents the components of a defensible AI procurement policy, examines the leverage that buyer-side coordination creates for shaping vendor practice, and explains how industry-standard procurement language increasingly drives the floor of acceptable vendor terms.
Why AI Procurement Cannot Inherit the Standard Procurement Policy
Most procurement policies were written for predictable Information Technology (IT) acquisitions: defined scope, fixed-price terms, deterministic deliverables, and well-understood vendor populations. AI procurement violates these assumptions in five ways.
First, scope is volatile. The capabilities being acquired evolve faster than procurement cycles. A model evaluated in March is not the model deployed in June.
Second, vendor population is concentrated. A small number of foundation-model providers and inference platforms dominate the supply, limiting the buyer’s ability to play vendors against each other on standard terms.
Third, the artefact is opaque. Procurement evaluation cannot easily verify what is being bought. The Stanford Foundation Model Transparency Index at https://crfm.stanford.edu/fmti/ documents the magnitude of this opacity even for major providers.
Fourth, risks are emergent. Some risks (copyright contamination, jailbreak susceptibility, downstream regulatory categorisation) appear only at deployment. Procurement criteria must anticipate them.
Fifth, regulatory categorisation is buyer-dependent. Under the European Union (EU) AI Act, accessible at https://artificialintelligenceact.eu/, the same vendor product may be a high-risk system or a limited-risk system depending on the buyer’s intended use. Procurement criteria must reflect the buyer’s deployment context, not just the vendor’s product description.
The Components of an AI Procurement Policy
A defensible AI procurement policy assembles seven components.
1. Scope Definitions and Triggers
What counts as AI procurement? Any system that uses AI features? Only systems where AI materially shapes outputs? Only systems that meet a defined risk threshold? The policy must define the triggers crisply enough that procurement, engineering, and business teams agree on which acquisitions are in scope.
2. Tiering and Risk Classification
Procurement cannot apply the same controls to every AI acquisition. Tiering — typically minimal, standard, enhanced, and critical — calibrates control depth to risk. Article 15 of this module addresses tiered programs in full; the procurement policy is the place where tiering rules are codified.
3. Required Diligence Artefacts
For each tier, what evidence must the vendor supply before contracting? Article 3 of this module defines the eight diligence domains. The procurement policy specifies how those domains map to evidence requirements at each tier.
4. Contractual Floor Terms
For each tier, what contract clauses are non-negotiable? Article 4 of this module identifies twelve clause families; the procurement policy declares which clauses are required and which are negotiable, and which negotiations require senior approval.
5. Approved-Supplier Lists and Exception Process
Does the organization maintain a positive list of approved AI suppliers, a negative list of restricted suppliers, or both? How are exceptions requested, approved, and time-limited? Approved-supplier lists materially reduce per-acquisition cost but require the maintenance discipline that many organizations underestimate.
6. Evaluation Criteria and Scoring
How are AI vendors evaluated against each other? The criteria must combine the conventional procurement dimensions (price, terms, financial soundness) with the AI-specific dimensions defined in Article 3 (governance, data handling, model behaviour, evaluation evidence) and a clear weighting that reflects the use case’s risk tier.
7. Standards References
Which standards does the policy adopt as floor expectations? The International Organization for Standardization / International Electrotechnical Commission (ISO/IEC) 42001:2023 standard at https://www.iso.org/standard/81230.html, the U.S. National Institute of Standards and Technology (NIST) AI Risk Management Framework (AI RMF) at https://www.nist.gov/itl/ai-risk-management-framework, the U.S. National Institute of Standards and Technology (NIST) Special Publication (SP) 800-161 Revision 1 at https://csrc.nist.gov/pubs/sp/800/161/r1/final, the U.S. Cybersecurity and Infrastructure Security Agency (CISA) Software Bill of Materials programme at https://www.cisa.gov/sbom, the Supply-chain Levels for Software Artifacts (SLSA) framework at https://slsa.dev/, the Software Package Data Exchange (SPDX) standard at https://spdx.dev/, and the Cloud Security Alliance reference materials at https://cloudsecurityalliance.org/ are the dominant anchors. Adopting them in policy reduces per-vendor negotiation cost dramatically.
Buyer Power and Coordination
Individual buyers have limited leverage with concentrated AI providers. Coordinated buyers — through industry consortia, standards bodies, sectoral procurement frameworks, or government purchasing collaboratives — have substantially more.
Three mechanisms have emerged.
The first is shared standard contract clauses. The European Commission has published model AI procurement clauses for public-sector buyers; the U.S. General Services Administration has issued similar guidance. Sectoral consortia in financial services, healthcare, and defence have produced their own. Adopting these reduces per-deal negotiation and signals to vendors that the standard is general, not idiosyncratic.
The second is shared evaluation infrastructure. Independent assessors, audit-as-a-service offerings, and standards-body certifications (ISO/IEC 42001 conformance) reduce the need for every buyer to evaluate every vendor independently. Vendors that obtain widely recognised certifications can serve many buyers under simplified diligence.
The third is collective monitoring and incident sharing. Industry Information Sharing and Analysis Centers extend to AI; participating buyers detect vendor-side incidents collectively and apply collective contractual pressure where vendor responses are inadequate.
What the EU AI Act Adds
The EU AI Act effectively standardises the floor for many vendor obligations across the EU market through Article 25 (deployer obligations), Articles 26 to 27 (operational duties), Articles 53 to 55 (General-Purpose AI provider obligations), and the high-risk technical-documentation requirements of Annex IV. Buyers operating in or selling into the EU benefit from this regulatory floor: vendors that cannot meet it cannot serve the market, which raises the floor of acceptable terms globally because few vendors maintain materially different offerings by region.
The Stanford Foundation Model Transparency Index at https://crfm.stanford.edu/fmti/ provides comparable disclosure data that buyers can use as an objective reference in procurement evaluation.
Maturity Indicators
| Maturity | What AI procurement policy looks like |
|---|---|
| Foundational (1) | AI acquisitions use the generic IT procurement policy; AI-specific risks are not surfaced; exceptions are routine. |
| Developing (2) | An AI procurement annex exists but is inconsistently applied; tiering and required-evidence rules are loosely defined. |
| Defined (3) | All seven components are documented and operative; tiered controls are enforced at procurement gates; standards references are adopted in policy. |
| Advanced (4) | Approved-supplier lists are maintained and refreshed; consortium participation is active; exception rates are measured and reported. |
| Transformational (5) | The organization contributes to industry procurement frameworks and influences regulatory and consortium standards. |
Practical Application
A government agency procuring a generative-AI policy-drafting assistant should begin not with a vendor short-list but with the procurement policy itself. The agency’s procurement function classifies the acquisition as enhanced tier under EU AI Act high-risk criteria (the system informs decisions affecting individual rights), draws the required-evidence and floor-terms templates for that tier, references ISO/IEC 42001 and NIST AI RMF as the standards floor, references CISA AI-BOM, SLSA, and SPDX as the technical-attestation floor, and only then issues the request for proposal. Vendors that cannot meet the floor self-deselect; vendors that can compete on the dimensions that actually matter. The procurement decision is documented, defensible, and reusable — the same policy applies to the next AI acquisition without negotiation from scratch.
The next article (Article 14) addresses what happens when, despite all of this, something goes wrong: vendor incident response and the notification chains that turn upstream failures into managed downstream events.