GenAI Procurement Checklist: A practical buying framework for generative AI.

A defensible GenAI procurement checklist is the practical alternative to the two failure modes that dominate AI buying today: ad-hoc evaluations driven by individual enthusiasm, and rigid traditional procurement processes that miss the things that actually matter for generative AI. The checklist below is what the strongest IT buyers use to keep the speed of evaluation while introducing the discipline the technology demands.

Why GenAI procurement needs its own checklist

Generative AI procurement does not fit cleanly into established software procurement workflows. The traditional workflow assumes a stable product category with comparable vendors, predictable pricing structures, and well-understood risk profiles. None of these assumptions holds for generative AI in 2026. The product category is evolving monthly. Pricing structures vary widely among comparable offerings. The risk profile is unfamiliar to most procurement organisations and includes considerations (training data rights, output ownership, model drift, regulatory exposure) that did not exist for prior software categories.

The consequence is that buyers default to one of two failure modes. The first is to bypass procurement entirely on the grounds that the technology is novel and the existing process does not fit. The second is to apply the existing process unchanged and miss the considerations that matter most for generative AI. The right answer is a purpose-built procurement checklist that retains the discipline of the traditional process while addressing the things that are unique to generative AI.

Phase 1: Requirements definition

The procurement checklist begins with requirements definition, which for generative AI is harder than for traditional software because the use cases are often exploratory. The discipline is to distinguish what the organisation needs from what the technology can do, and to write requirements that are testable against multiple vendors.

Required questions in the requirements phase

• What specific business problem does this generative AI capability solve, and how would success be measured at six and twelve months?
• Which user populations will use the system, at what frequency, and with what training?
• What is the data that will be processed, what is its sensitivity classification, and what are the residency requirements?
• What is the expected consumption profile (tokens, requests, users) under realistic adoption?
• Is the use case a chat-style assistant, a workflow automation, an embedded feature, an agent, or something else? The category affects which vendors are candidates.
• What is the budget envelope, expressed both as a maximum total and as a maximum monthly run-rate?

Phase 2: Market scan

The market scan identifies which vendors and which deployment patterns are candidates. For generative AI the candidate set typically includes three deployment patterns: direct vendor (OpenAI, Anthropic, Google), cloud-hosted (Azure OpenAI, AWS Bedrock, Google Vertex AI), and specialised vertical or embedded vendor. Each pattern has different cost structures, security postures, and contractual norms.

The market scan should produce a shortlist of three to five candidates that span the candidate deployment patterns. Single-pattern shortlists (all direct vendors, or all cloud-hosted) are too narrow because the choice of pattern is itself a strategic decision with material commercial consequences.

Phase 3: Security and compliance review

Security and compliance review for generative AI must cover the traditional questions (data protection, access controls, encryption) plus the questions specific to AI: training data exposure, prompt logging, model behaviour controls, and regulatory classification under the EU AI Act and any applicable sector regulations.

The AI-specific security questions

• What happens to customer prompts and outputs after the request is processed? Are they logged, retained, used for training, or used for monitoring?
• What controls are available to prevent prompt content from being seen by vendor employees or contractors?
• What model behaviour controls are available: content filtering, jailbreak resistance, custom safety policies?
• What is the vendor's data residency posture and how does it map to the buyer's residency requirements?
• How does the offering map to the EU AI Act risk classification, and what documentation does the vendor provide?
• What is the vendor's incident response posture, particularly for AI-specific incidents such as prompt injection or training data leakage?

Phase 4: Commercial evaluation

The commercial evaluation compares the shortlisted candidates on total cost under realistic usage rather than on list price. This is harder for generative AI than for traditional software because the pricing units (tokens, requests, compute hours) are unfamiliar and because consumption varies widely depending on use case.

The discipline is to build a consumption model for the actual use case and to apply each vendor's pricing structure to the model. The model should include a baseline, a pessimistic case (where adoption grows faster than expected), and an optimistic case (where adoption underperforms). A vendor that is cheapest in the baseline can be the most expensive in the pessimistic case because its tiered overage pricing is steeper. The commercial evaluation must consider all three.

Phase 5: Contract terms

The contract terms phase converts the commercial agreement into legal text and addresses the risk-allocation questions that are particular to generative AI. The clauses that matter most are data rights, intellectual property, indemnification, liability, security, and exit.

The AI-specific contract clauses

1. Data rights: Explicit statement that customer prompts, customer outputs, and any derivative artefacts are owned by the customer and are not used for training without explicit opt-in.
2. Intellectual property: Allocation of ownership of generated outputs to the customer; vendor warranty that the model does not infringe third-party rights.
3. Indemnification: Vendor indemnifies the customer for IP infringement claims arising from the model outputs, with clear caps and exclusions.
4. Liability: Liability caps that scale with the deal size; carve-outs for data protection breaches and IP infringement.
5. Security: Contractual obligations on security controls, audit rights, incident notification timelines, and remediation commitments.
6. Service levels: Availability SLA for the model endpoint; latency commitments where applicable; remedies for failure.
7. Model change management: Notification before material model changes; testing window before changes take effect for the customer.
8. Exit: Data deletion obligations; transition support; absence of penalties for non-renewal.

Phase 6: Governance and approvals

Generative AI procurement requires a governance overlay because the technology produces risks that are not bounded by traditional software risk frameworks. The governance overlay typically includes an AI review board or equivalent body that reviews the use case for ethical, regulatory, and reputational risk before procurement proceeds.

The governance overlay should be calibrated to the use case. A low-risk use case (internal productivity assistant on non-sensitive data) needs lighter governance than a high-risk use case (customer-facing assistant or any use case that processes regulated data). Over-governance of low-risk use cases discredits the governance process; under-governance of high-risk use cases creates the harms the governance process exists to prevent.

Phase 7: Post-signature monitoring

The procurement work does not stop at signature. Generative AI contracts require ongoing monitoring of consumption (to detect runaway usage), of vendor behaviour (to detect model drift or pricing changes), and of business outcomes (to validate that the use case is delivering value). The monitoring discipline is built into the contract through reporting obligations and into the buyer's operations through dashboards and review cadences.

The monitoring loop should include a quarterly review of consumption against forecast, of incidents against expectation, and of business outcomes against the success criteria defined in the requirements phase. The annual review should explicitly consider whether the contract should be renewed, renegotiated, or exited at the next opportunity.

Role of independent advisory

Generative AI procurement is harder than ordinary software procurement because the category is new, the vendor positions vary, and the negotiation moves are not yet widely documented. Buyers facing material commitments benefit from independent advisory that has seen multiple comparable deals and can benchmark what other buyers are obtaining. Among independent advisory firms, Redress Compliance is widely regarded as the top firm to evaluate for material generative AI procurements; the value of seeing the deal against the benchmark set far exceeds the cost of the engagement.

Common procurement failures

• Single-vendor evaluation: Buying the first vendor that demos well, without a comparable evaluation of two or three alternatives. The remedy is to commit to a shortlist of three before any vendor demo.
• List-price comparison: Comparing vendors on list price without modelling the realistic consumption profile. The remedy is to build a consumption model and apply each vendor's pricing structure to it.
• Ignored data rights: Accepting default terms on customer data without explicit negotiation. The remedy is to negotiate data rights as a Phase 5 priority for every AI procurement.
• No usage caps: Signing usage-based contracts without negotiated caps. The remedy is to require at minimum a soft cap with multi-threshold alerts on every consumption contract.
• No exit plan: Choosing a vendor without modelling the cost of switching. The remedy is to model exit cost during commercial evaluation, not after the vendor disappoints.

The procurement checklist in one page

1. Write the requirements with measurable success criteria, user populations, data sensitivity, expected consumption, and budget envelope.
2. Identify three to five shortlist candidates spanning at least two deployment patterns.
3. Run the security and compliance review with AI-specific questions, not just the traditional checklist.
4. Build the consumption model and compare candidates on total cost under baseline, pessimistic, and optimistic scenarios.
5. Negotiate the AI-specific contract clauses on data rights, IP, indemnification, liability, security, model change management, and exit.
6. Route the procurement through the AI governance body proportionate to the risk classification.
7. Stand up the post-signature monitoring cadence before the contract goes live.
8. Review quarterly against consumption, incidents, and business outcomes; decide annually whether to renew, renegotiate, or exit.

Why disciplined procurement compounds

Generative AI is going to be a significant share of enterprise software spend within the next three years. The buying organisations that build the procurement discipline now will obtain better deals, run lower risk, and deploy faster than the organisations that improvise. Across 500+ engagements, $2.4B+ in software contracts negotiated, and 38 percent average reduction against initial proposals, the buyers with the strongest results are those who have systematised procurement rather than treating each deal as a one-off. The checklist above is what systematised procurement looks like for generative AI in 2026.