Enterprise AI Procurement: A Due Diligence Checklist for Buyers
A practical due-diligence framework for buying AI systems, covering outcomes, data, evaluation, security, governance, contracts and exit planning.
By Leila Haddad, Women in AI Editorial Fellow ยท 13 September 2026
Enterprise AI procurement is difficult because the thing being bought can change after it is tested.
A supplier may update the model, alter a safety policy, switch a subprocesser or introduce a new data-retention practice. Performance can vary by user, language and context. A compelling demonstration may say very little about reliability inside your workflow.
The procurement process therefore needs to evaluate both the current product and the supplier's system for managing change.
Begin with the outcome
Do not start with a vendor category. Start with the operational problem, the people affected and the evidence required to justify adoption.
Define:
the decision or task being supported; the current process and baseline; expected benefit; acceptable error and failure modes; users and affected people; required human oversight; prohibited uses; integration boundaries; conditions under which the project will stop.
"Deploy a generative AI assistant" is not a procurement objective. "Reduce time spent drafting first responses to routine customer queries while maintaining resolution quality and preventing disclosure of account data" is.
The UK Government's guidelines for AI procurement emphasise a clear problem definition, market engagement, data assessment, benefits and risks. These disciplines apply well beyond public procurement.
Test the use case, not the demo
Ask suppliers to work with representative scenarios under controlled conditions. Use your own evaluation set where lawful and practical.
The evaluation should cover:
task quality against a baseline; failure rate and severity; performance across relevant groups and languages; latency and availability; cost at realistic volume; resistance to misuse; human-review workload; accessibility; explainability appropriate to the decision; behaviour when evidence is missing.
Agree success criteria before the test. Otherwise, both sides can reinterpret mixed results as success.
A pilot is an experiment with a decision at the end. It should not become a permanent exception to production standards.
Examine data across the lifecycle
Ask what data enters the system, where it goes and what happens next.
Questions include:
Which customer, employee or operational data will be processed? Is data used to train or improve any model? How long are inputs, outputs and logs retained? In which jurisdictions is data processed? Which subprocessors receive it? Can retention or training use be disabled contractually and technically? How are deletion and access requests handled? What data supports retrieval or fine-tuning? How is provenance documented? How does the system prevent one customer's data appearing to another?
"Your data is secure" is not an answer. Request the architecture, policy and contract language that make the claim testable.
Understand the model supply chain
Many AI vendors rely on foundation-model providers, cloud platforms, data services and open-source components. That is normal, but it changes the risk.
Create a dependency map. Identify:
model providers and versions; hosting and inference locations; open-source models and licences; retrieval, moderation and monitoring services; human annotation or review providers; critical libraries and infrastructure; which party is responsible when a dependency fails.
Ask how the supplier assesses updates and communicates material changes. A model substitution should not arrive as a surprise in production.
Review security as a system property
The NCSC's secure AI development guidance divides security across design, development, deployment, and operation and maintenance. Procurement should test all four.
Ask for evidence of:
threat modelling; secure development practices; access and identity controls; tenant isolation; encryption and key management; vulnerability reporting; penetration and adversarial testing; prompt injection and data exfiltration controls; logging and incident response; business continuity and disaster recovery; software and model supply-chain management.
For agents, scrutinise permissions. What tools can the system call? Can it send messages, alter records, execute code or spend money? How are actions approved, limited and audited?
A model should never receive broader authority simply because implementing fine-grained controls is inconvenient.
Evaluate governance and accountability
NIST's AI Risk Management Framework is designed to help organisations incorporate trustworthiness into AI design, development, use and evaluation. Use its govern, map, measure and manage functions to structure supplier questions.
Request:
named ownership for safety and compliance; risk classification and assessment; documented limitations; model or system cards; evaluation methods and results; change-management procedures; monitoring and incident metrics; escalation routes; external assurance where relevant; evidence that affected users informed design.
Do not confuse the presence of a policy with the effectiveness of a control. Ask how the supplier knows the process works.
Put change into the contract
AI contracts should address a changing service.
Key clauses may cover:
approved purpose and prohibited uses; data use, retention, location and deletion; model and material supplier changes; performance and service levels; audit and information rights; security incidents and notification; regulatory cooperation; intellectual property and output claims; indemnities and liability; accessibility and non-discrimination; human oversight requirements; subcontractors; termination assistance; export of data, prompts, configurations and logs.
The European Commission has published updated model contractual clauses for public buyers of AI systems. They are not a substitute for legal advice, but they show how AI-specific obligations can be expressed contractually.
Avoid accepting a contract in which the supplier can materially change the system while the buyer remains bound to the original risk decision.
Calculate total cost, including control
The licence price is only part of the cost.
Include:
integration and data preparation; evaluation and red teaming; human review; monitoring and incident response; security and legal review; model usage and compute; change management and training; rework caused by errors; switching and exit; internal product ownership.
An apparently inexpensive model may be costly if every output requires extensive review. A more expensive system may still create value if it reduces control effort and performs reliably. Compare total operating economics against the current process.
Design the exit before entry
Vendor lock-in is particularly strong when prompts, evaluations, workflow logic and user habits accumulate around one provider.
Before signing, ask:
Can data and configuration be exported in usable formats? Who owns fine-tuning artefacts and evaluation sets? Can another model be substituted? How long will transition support last? What is deleted after termination? Can the service be reduced safely if the supplier fails? Is there a manual or alternative process for critical work?
A tested exit path improves negotiating power and operational resilience.
The buyer's decision record
At approval, create a concise record with:
use case and accountable owner; supplier and critical dependencies; evaluation results and limitations; risk assessment; required controls; contract exceptions; total cost and expected value; pilot or deployment boundaries; monitoring and review date; exit and stop conditions.
This record should be understandable to leaders outside procurement and the AI team.
A compact due-diligence checklist
Before purchase, confirm that:
the problem and baseline are clear; success criteria were set before testing; representative users and cases were evaluated; data flows and retention are understood; model dependencies and change processes are documented; security evidence covers the full lifecycle; governance has named owners; the contract allocates AI-specific responsibilities; total operating cost is credible; exit, rollback and incident procedures are workable.
Enterprise AI procurement is not a search for a risk-free supplier. It is a decision about whether evidence, controls and commercial terms make a particular system acceptable for a particular use.
Continue with our enterprise AI hub, AI impact assessment guide and agentic AI governance guide.