AI Procurement Checklist (2026): The Complete Buyer's Framework

An AI procurement checklist works only if it is structured, not a list of tips: classify the use case first, then assess the vendor across data handling, deployment model, output ownership, update control, auditability, security, commercial terms and exit rights. The single biggest mistake buying committees make is starting with the vendor demo instead of the classification step, because the classification decides which checklist items are mandatory and which are optional. This guide gives the full framework, the standards worth citing, and a downloadable questionnaire you can hand to a vendor on a call or attach to an RFP.

A fill in the blank version of this checklist, grouped by section for a vendor call or an RFP, is available to download as a PDF at https://mickai.co.uk/downloads/ai-procurement-checklist-2026.pdf.

Why is AI procurement different from ordinary software procurement?

Buying an AI system is not the same exercise as buying a CRM, a ticketing tool or a payroll platform, because the product itself keeps changing after you sign. A conventional SaaS contract locks in a feature set that moves slowly and predictably. An AI system's behaviour can shift with a model update the vendor pushes without warning, the training data behind it carries its own provenance and licensing questions, the ownership of what the system generates is often contractually undefined, and the system may fall into a regulated category that a spreadsheet tool never would. None of those four issues (behaviour drift, data provenance, output ownership, regulatory classification) has a settled equivalent in traditional procurement practice, which is why a generic vendor-risk template misses most of what actually matters.

This is also why an AI procurement checklist has to be structured differently from a standard vendor questionnaire. It cannot simply add "AI" as a tickbox to an existing security review. It needs its own sequence, starting with classification, because a chatbot pilot for internal document search and a credit-scoring model carry entirely different obligations even if they come from the same vendor.

What should you classify before you assess a single vendor?

Before scoring any vendor, classify what the AI system actually does and where it sits. Two questions decide the shape of the rest of the checklist.

• What function does it perform? Decisioning (it decides or materially influences an outcome), generation (it produces content, code or communications), retrieval (it finds and summarises information), or automation (it executes a workflow step). Each carries a different risk profile: decisioning systems need the heaviest audit and human-oversight scrutiny.
• Does it touch a regulated category? Credit and lending, employment and recruitment, health and clinical support, biometric identification, education access, essential public or private services, or anything law-enforcement-adjacent. These categories are treated as high-risk under most modern AI regulation, which means the audit, human-oversight and documentation items in this checklist stop being optional.

Classification is not paperwork for its own sake. It determines whether the vendor needs to prove independent auditability and human oversight (mandatory for a regulated use case) or whether a lighter-touch review is proportionate (a low-stakes internal drafting tool). Do this step first, in writing, before the vendor conversation starts.

Where does the data go?

This is the single most-asked question in AI vendor risk assessments, and it has five parts, not one.

• Storage location. Which country or region is the data stored and processed in, and does that matter for your regulatory regime.
• Training use. Is your data used to train or fine-tune a shared or foundation model that other customers benefit from, or is it kept isolated to your own instance.
• Sub-processor disclosure. Who are the vendor's own subcontractors and model providers (the fourth parties), and will the vendor keep that list current and notify you of changes.
• Cross-border transfer. If data leaves your jurisdiction, what legal mechanism covers the transfer (an adequacy decision or standard contractual clauses under UK GDPR, for example).
• Retention and deletion. What is kept after a session or contract ends, for how long, and can you force deletion on demand.

Get the answers in writing and attached to the contract, not in a sales call. A verbal assurance about data handling is not enforceable; a data processing agreement is.

Can it operate offline?

Vendors fall into three real categories, and the difference matters more than it first appears: fully air-gapped or on-premise, meaning the system runs without any external network dependency; cloud-only with offline caching, meaning it can survive a short outage but still depends on the vendor's infrastructure for anything beyond basic continuity; and constant-connectivity cloud, meaning the business function stops the moment the internet connection or the vendor's service does.

Not every buyer needs an air-gapped system. A marketing content assistant with no access to sensitive data may be perfectly well served by a constant-connectivity cloud tool. But a continuity-sensitive, regulated, or highly confidential workload should know exactly which category its vendor falls into before signing, because this is one of the hardest terms to renegotiate after deployment. Ask the vendor directly to state, in writing, which of the three categories their product falls into. A vague answer is itself the answer.

Who owns the outputs?

Output ownership is set by contract, not by default law, in most jurisdictions. This means silence in the contract is not neutral: it usually favours the vendor. Confirm four things before signing.

• The contract states plainly that the buyer owns the outputs, or defines exactly what licence the vendor retains.
• The vendor does not claim a licence back over your generated content or derived work product for their own purposes (further training, marketing use, resale).
• There is an indemnity covering third-party intellectual property claims that arise from the system's outputs, since generative systems can reproduce material adjacent to their training data.
• If the vendor fine-tunes a model on your own data, the fine-tuned weights or adapters belong to you, or the contract at minimum states clearly who they belong to.

Also ask whether outputs are distinguishable from training data. A system that cannot show where a generated answer came from carries a contamination and leakage risk that is difficult to detect after the fact.

How are updates controlled?

An AI system's behaviour can change without a single line of your own integration code changing, because the vendor updated the underlying model. This is the update-control question, and it has four parts.

• Version pinning. Can you stay on a fixed model version rather than being auto-upgraded, and for how long is that version supported.
• Advance notice. What is the notice period before a behaviour-changing update reaches production, and is there a published changelog.
• Staging. Can you test an update in a sandbox before it reaches your live environment, and who is responsible for that testing.
• Deprecation. What is the notice period when a model version is retired, and what happens to workflows built against it.

A vendor that cannot answer these questions is telling you that your production behaviour can change on their schedule, not yours. For any decisioning or regulated use case, that is not an acceptable answer.

Can decisions be independently audited?

Auditability is the difference between trusting a vendor's word after an incident and being able to check the record yourself. Four things need to be true.

• The system logs the input, the output, and the specific model version used, for every decision, not just for flagged or disputed ones.
• Those logs are retained for a defined period long enough to support a regulatory look-back or an internal investigation, and the retention period is stated in the contract, not left implicit.
• A human reviewer can reconstruct why a specific output occurred from the logged record, without needing the vendor to explain it after the fact.
• The vendor supports third-party or regulator audit access to that record, rather than treating the log as an internal-only artefact.

For any use case that materially affects an individual (credit, employment, benefits, health), there also needs to be a human-oversight mechanism: a defined point where a person can review, question or override the system's output before it takes effect. Confirm log retention and audit-access terms in the contract before deployment, not after an incident forces the question.

What security controls should the vendor prove?

Security due diligence for an AI vendor covers the same ground as any serious software vendor, plus a few AI-specific items.

What commercial terms should you check?

Commercial due diligence for AI has a few traps that do not exist in traditional software pricing.

• Pricing transparency. What exactly counts as a billable "interaction," "seat" or "call," and how is usage measured and reported to you.
• Auto-renewal. Does the contract auto-renew, and what is the notice period to opt out.
• Price-change notice. How much advance notice is given before a price change takes effect.
• Usage caps and overage. What happens when you exceed an agreed usage threshold, and is overage billed automatically or does it require approval.
• Total cost of ownership. The licence fee is rarely the whole cost. Integration, retraining, support tiers and internal change management all add to the real figure, and a vendor comparison that ignores them is not comparing like for like.

What happens if you need to leave?

Exit terms are the part of a contract buyers check least and regret most. Confirm, before signing, not after a termination notice:

• What is exportable at termination: raw and processed data, decision and audit logs, any fine-tuned model weights or adapters trained on your own data, configuration, and prompt libraries.
• The export format, and whether it is a genuinely portable, industry-standard format rather than a proprietary one.
• The transition assistance period: a defined window of continued access and support after termination, rather than an immediate cutoff.
• Whether there is a sunset or wind-down clause, and whether the contract avoids indefinite auto-renewal that makes exit harder with each passing term.

A vendor that cannot answer these questions in writing before you sign is unlikely to make them easy after you have given notice.

Which standards and certifications are actually worth asking for?

Certifications are a useful screening signal, but they are not all equally meaningful, and none of them substitutes for reading the vendor's actual data, audit and exit terms.

A certification is a governance-process attestation. It shows the vendor runs a managed system that an accredited body has audited. It is not a guarantee of any specific technical control, and it does not replace reading the contract.

Build, buy, rent or own: which model fits?

Once the use case is classified and the vendor checklist is answered, the underlying question is which acquisition model fits your risk tolerance and regulatory exposure. There are four honest categories, and no single one is universally right.

None of these is a verdict. Many legitimate buyers correctly choose a cloud-rented AI service because their use case is genuinely low-stakes and speed matters more than data residency. The point of classifying the use case first (see above) is precisely so this choice is made deliberately, against a documented risk tolerance, rather than by default because the demo was impressive.

Use the downloadable checklist as a working document

Reading this guide once is not the same as having a repeatable process. The companion checklist mirrors every section above as a short-answer and yes/no questionnaire: print it, walk a vendor through it on a call, or attach it to an RFP response. A committee that can point to a completed, dated checklist has a defensible record; one that relied on a sales conversation does not.

How the auditability and exit questions in this checklist map onto owned infrastructure is set out at /sovereign-ai, and the film at /film shows the interface in operation.

Frequently asked questions

What should an AI procurement checklist cover?

Data handling (where data goes, retention, whether it trains shared models), deployment model (cloud, hybrid, on-premise, offline capability), output ownership, update and version control, independent auditability, security certifications, commercial terms, and exit and portability rights. A complete checklist maps each of these to the specific use case being procured, because a chatbot pilot and a credit-decisioning system carry very different risk.

Does my AI vendor need to be ISO 42001 certified?

Not legally, in most jurisdictions, but certification is increasingly requested in enterprise and public-sector tenders as third-party evidence of a functioning AI governance system. It is a useful screening signal, not a substitute for reviewing the vendor's actual data, audit and exit terms.

Is the EU AI Act high-risk deadline still 2 August 2026?

No. The Digital Omnibus deferred stand-alone Annex III high-risk obligations to 2 December 2027, and high-risk AI embedded in regulated products to 2 August 2028. Article 50 transparency obligations largely remain on the original schedule. The proof requirements themselves survive the deferral intact, so a procurement checklist built to this standard now stays correct.

Should an enterprise AI system be able to operate offline?

It depends on the use case. Continuity-sensitive, regulated or highly confidential workloads benefit from an on-premise or air-gapped option, while lower-stakes pilots may not need it. The point for a buyer is to know which category a vendor's system falls into before signing, because connectivity dependency is difficult to renegotiate after deployment.

What data should a vendor be required to hand back if we terminate the contract?

At minimum: raw and processed data, decision and audit logs, any fine-tuned model weights or adapters trained on the buyer's own data, and configuration and prompt libraries, in an industry-standard exportable format, with a defined transition-assistance period rather than an immediate cutoff.

Who owns the output of a generative AI system?

This is set by contract, not by default law in most jurisdictions, so the procurement checklist should confirm the vendor does not claim a licence back over generated work product, and that there is an indemnity covering third-party intellectual property claims arising from outputs.

Can AI-driven decisions be independently audited?

Only if the vendor logs the input, output and model version used for each decision, retains those logs for a defined period, and supports third-party or regulator access to them. A buyer should confirm log retention and audit-access terms in the contract before deployment, not after an incident.

Why does the use case need to be classified before the vendor is assessed?

Classification determines which checklist items are mandatory. A regulated, decisioning use case (credit, employment, health, biometric identification) requires the fuller set of audit, human-oversight and documentation obligations under most modern AI regulation. A low-stakes generation or retrieval tool does not carry the same weight. Skipping classification means either over-engineering a low-risk purchase or, more dangerously, under-scrutinising a high-risk one.

A note on owned and auditable platforms

For buyers whose classification work places them in the high-scrutiny category, owned infrastructure that can run offline and produces an independently auditable decision trail is one credible answer among several on the market, alongside the cloud, on-premise and self-hosted options set out above. Mickai is one such platform: owned and offline-capable rather than a constant-connectivity dependency, with a per-decision audit trail designed to be checked rather than taken on trust. The underlying architecture is protected by 104 filed UK patent applications covering 2,340 claims, cited here only as a matter of record, not as the basis for the comparison above.