AI vendor due diligence is the one step that separates a sound AI platform purchase from an expensive lesson. Buying an AI platform looks exactly like buying software, right up until the moment it goes wrong: the contract reads like a normal SaaS agreement, the demo is polished, and the pricing page has three tidy tiers. Then the model updates overnight, the outputs drift, and nobody in the room can explain why. AI vendor due diligence exists to catch that gap before the purchase order leaves your desk, not six months after it.

Traditional procurement checklists were built for deterministic systems that behave the same way on Tuesday as they did on Monday. AI vendor due diligence has to interrogate things a standard security questionnaire never touches: where the training data came from, who owns the fine-tuned weights, what happens when an underlying foundation model is deprecated, and how quickly you could walk away. If your team has not yet run an AI readiness assessment, do that first, then bring this list to the vendor call.

The stakes are asymmetric. A poor CRM choice wastes money and irritates a sales team. A poor AI platform choice can leak regulated data into somebody else’s training set, produce decisions you cannot explain to a regulator, and bind your core workflows to a model you do not control. That asymmetry is the entire argument for taking AI vendor due diligence seriously before signature rather than after.

What follows is a working checklist of 30 questions, grouped into five buying areas, plus a scoring method, a way to embed the process, and the mistakes that most often cost buyers money. Use it as a live document. Send it before the demo, score the written answers, and treat evasiveness as data.

Table of contents

Why AI Vendor Due Diligence Is Not Ordinary Software Procurement

ai vendor due diligence checklist b procurement framework

Most procurement frameworks assume the product you test is the product you get. With AI platforms that assumption quietly breaks, which is why AI vendor due diligence needs its own set of questions rather than an extra tab on an existing spreadsheet.

Probabilistic output breaks traditional acceptance testing

A conventional system either passes a test case or fails it. An AI platform gives you a distribution of answers, and a build that scores 94% on your acceptance set can score 88% next quarter after a routine model update. Your diligence has to establish what the vendor guarantees about output stability, not just uptime.

The vendor’s model is often somebody else’s model

Many AI products are a thoughtful interface wrapped around a third-party foundation model. That is a legitimate business, but it changes your risk profile: your data path, pricing floor, and deprecation calendar are all set by a company you never signed with. Good AI vendor due diligence traces the full stack to its origin.

Regulation is moving faster than procurement cycles

The EU AI Act, ISO/IEC 42001, and sector rules on automated decision-making are all landing inside typical three-year contract terms. A vendor that cannot describe its compliance roadmap today is asking you to carry that risk. Our guide to ISO 42001 implementation explains what a credible answer sounds like.

Questions 1-6: Company Viability and Commercial Stability

ai vendor due diligence checklist c company viability

The first block of AI vendor due diligence is unglamorous and non-negotiable. AI is a capital-hungry sector with a high failure rate, and the cheapest way to lose an implementation budget is to buy from a company that does not survive the contract term.

1. Who owns the company, and who funds it?

Ask for the cap table summary, the last funding round, and the lead investors. You are not being nosy; you are establishing who decides the product roadmap. A vendor majority-owned by a strategic investor in your own sector is a different proposition from one backed by generalist venture capital.

2. What is your current runway, and when do you next need to raise?

Vendors dislike this question, which is precisely why it belongs in AI vendor due diligence. You do not need exact figures. You need to know whether the renewal date sits before or after a funding cliff, because that is when pricing and support quality typically change.

3. How many production customers run this at our scale?

Reference logos on a website often represent pilots. Ask for the count of customers in production, the median deployment size, and how many are in your industry. Then ask to speak to one who churned. Vendors who take AI vendor due diligence seriously will make that introduction; the rest will offer a curated reference call instead.

4. What is your gross retention rate for the last two years?

Gross retention strips out upsell and tells you whether customers stay. Anything below 85% in enterprise software deserves an explanation. Pair this with the average tenure of the customer success team, because retention driven by heroic individual effort does not survive their departure.

5. Who are your key personnel, and what happens if they leave?

Small AI vendors are frequently one or two researchers deep on the thing that actually differentiates them. Ask which named individuals are critical to the model roadmap, whether they are under retention agreements, and what documentation exists so the work survives a resignation.

6. What is your acquisition posture?

If the vendor is acquired, your contract goes with it, and the acquirer’s priorities may not include your use case. Ask directly whether they are in an active process, and negotiate a change-of-control clause that gives you an exit if ownership changes materially.

Questions 7-12: Model Provenance, Benchmarks, and Evaluation

ai vendor due diligence checklist d model provenance

This is the block that separates real AI vendor due diligence from a rebadged software questionnaire. You are establishing what the model is, where it came from, and how you will know when it degrades.

7. Which base models power this product, and can you switch them?

Get the specific model names and versions, not the marketing category. Then ask how the product behaves if that model is deprecated with 90 days’ notice. A vendor with a genuine abstraction layer will describe a tested migration path; one without will change the subject.

8. What data was the model trained or fine-tuned on?

You need provenance for two reasons: legal exposure from scraped or licensed content, and performance relevance to your domain. Ask whether training data was licensed, synthetic, or public, and request written confirmation of indemnity for intellectual property claims arising from model output.

9. How do you measure accuracy, and on what benchmark?

Vendor benchmarks are chosen to flatter the product. During AI vendor due diligence, insist on the evaluation set definition, the sample size, and the date it was last refreshed. Public leaderboard scores tell you almost nothing about performance on your documents and your edge cases.

10. Can we run our own evaluation on our own data before signing?

The answer should be yes, in a sandbox, with your real data under an NDA. A vendor that only offers a curated demo environment is telling you their numbers do not survive contact with messy inputs. This is the single highest-value step in AI vendor due diligence, so budget two to four weeks and staff it properly.

11. How do you detect and communicate model drift?

Ask what monitoring exists, what thresholds trigger an alert, and whether customers are notified before or after a model change ships. The right answer includes a changelog, a versioning scheme you can pin to, and a defined window in which you can test a new version.

12. What is your approach to hallucination and error handling?

Every generative system produces confident errors. What matters is whether the platform surfaces uncertainty, cites sources, supports human review on high-stakes actions, and logs enough context for you to investigate a bad output weeks later.

Questions 13-18: Data Rights, Privacy, and Residency

ai vendor due diligence checklist e data security

Data terms are where AI contracts differ most sharply from ordinary SaaS, and where the weakest AI vendor due diligence is usually done. Read the data processing addendum yourself rather than accepting a summary.

13. Is our data used to train your models, by default or ever?

The only safe answer is a contractual no, with the setting off by default rather than opt-out. Check whether the commitment flows down to sub-processors, including the foundation model provider, because that is where the gap usually sits.

14. Where is our data stored and processed, in every region?

Ask for the full list of regions for storage, processing, inference, and logging. Inference frequently happens somewhere different from storage. If you operate under residency obligations, our overview of international data privacy compliance sets out what to require in writing.

15. Who are your sub-processors, and how are we notified of changes?

Request the current sub-processor list and the notice period for additions. Thirty days’ advance notice with a right to object is a reasonable ask. A vendor that reserves the right to change sub-processors silently has effectively removed your ability to manage the risk.

16. What is your data retention and deletion policy?

Establish how long prompts, outputs, embeddings, and logs are kept, and whether deletion is genuine or a soft flag. Ask specifically about vector stores and caches, which are routinely overlooked in deletion workflows, routinely missed by AI vendor due diligence, and routinely still holding your content months later.

17. Who owns the outputs, and any fine-tuned weights?

If you pay to fine-tune a model on your data, state in the contract that the resulting weights are yours or are exclusively licensed to you and destroyed on termination. Output ownership should be unambiguous, with the vendor claiming no licence beyond service delivery.

18. How do you handle a data subject access or deletion request?

Regulators expect a defined process with a clock on it. Ask how a request is executed technically, how long it takes end to end, and what evidence you receive. “We would work with you” is not a process and should not pass AI vendor due diligence.

Questions 19-24: Security, Access Control, and Incident Response

Security questions in AI vendor due diligence cover the usual ground plus a new attack surface: prompt injection, tool use, and agents that can act on your systems.

19. What independent certifications do you hold, and can we see the report?

SOC 2 Type II, ISO 27001, and increasingly ISO 42001 are the baseline. Ask for the full report under NDA, not the certificate, and read the exceptions section. A logo on a trust page tells you a certificate exists; the exceptions tell you how well it is run.

20. How is access to our data controlled internally?

Establish which vendor staff can read customer data, under what approval, and whether access is logged and reviewed. Ask whether support engineers can view prompt content during a ticket, because that is the route by which confidential material most often leaves your control.

21. How do you defend against prompt injection and jailbreaks?

This is AI-specific and frequently unanswered. Ask what input sanitisation, output filtering, and privilege separation exist, particularly where the platform can call tools or take actions. Ask whether they run adversarial red-teaming and how often.

22. What permissions does the system need in our environment?

Agentic features often request broad scopes on email, file storage, or CRM. Demand least-privilege scoping, per-action approval for anything destructive, and a full audit trail. The lessons from supply chain attacks on third-party integrations apply directly here.

23. What is your incident response and breach notification commitment?

Get the notification window in hours, written into the contract, along with what information you receive and who owns customer communication. Ask when they last ran a tabletop exercise and what it changed. Verbal reassurance here is the weakest possible outcome of AI vendor due diligence.

24. Do you carry cyber and technology errors and omissions cover?

Ask for the certificate, the limits, and whether AI-specific claims are excluded. Many policies were written before generative AI and contain exclusions that surprise both sides. Our breakdown of cyber insurance red flags covers what to check.

Questions 25-30: Pricing, Integration, and Exit Strategy

The final block of AI vendor due diligence is about the total cost of the decision, including the cost of reversing it. Token-based pricing makes AI budgets harder to forecast than any software category before it.

25. How exactly is this priced, and what drives cost up?

Map the billing unit precisely: seats, tokens, documents, API calls, or a blend. Then model a realistic heavy-usage month, not the vendor’s example. Ask what happens at the overage boundary and whether you get an alert before the bill arrives.

26. Can you cap our spend, and how are price rises governed?

Request a hard spend cap or a soft cap with automatic notification. Negotiate an uplift ceiling tied to an index for the contract term, and ask specifically what happens if the vendor’s own model costs rise. Without that clause the risk is entirely yours.

27. What does implementation actually involve on our side?

Get a written statement of the internal effort required: data preparation, integration work, change management, and ongoing prompt or workflow maintenance. This internal cost is routinely two to three times the licence fee and is the line most often missing from a business case.

28. How does this integrate with our existing stack?

Ask for the API documentation before signing, along with rate limits, webhook support, and the SDKs maintained in-house versus community-maintained. Confirm SSO, SCIM provisioning, and audit log export to your SIEM, because retrofitting those later is expensive.

29. What is the exit process, and what do we get back?

Define the export format for your data, prompts, configurations, and evaluation history, and the window in which it is available after termination. An export that arrives as a proprietary blob is not portability, and this is the single question buyers most regret skipping.

30. What service levels apply, and what is the remedy?

Uptime alone is insufficient for an AI platform. Push for latency targets, throughput commitments, and support response times by severity, each with a service credit attached. Then ask what percentage of customers claimed credits last year, which tells you whether the SLA is real.

How to Score Your AI Vendor Due Diligence Answers

Collecting 30 answers is only useful if you can compare vendors consistently. A simple scoring model turns a subjective debate into a decision your finance and risk teams can sign off.

Weight the categories to your actual risk

Score each answer 0 to 3: 0 for no answer, 1 for a verbal assurance, 2 for documented policy, 3 for contractual commitment with evidence. Then weight the five blocks. A regulated firm might weight data and security at 30% each; a startup optimising for speed might weight commercials higher.

Set hard fails before you see the answers

Decide in advance which answers end the conversation regardless of total score: training on your data without consent, no independent certification, no export path, or refusal to allow evaluation on your own data. Agreeing hard fails before the demo prevents a compelling salesperson from renegotiating your standards in the room.

AI Vendor Due Diligence Mistakes That Cost Buyers Money

Patterns repeat across failed AI purchases. These are the ones that show up most often in post-mortems, and each is avoidable with better AI vendor due diligence at the front of the process.

Evaluating the demo instead of the deployment

Demo environments use clean data, curated prompts, and a warmed-up model. Your environment has inconsistent documents, unusual formats, and users who type badly. Insist on a pilot with your own data, and judge the product on that.

Letting the pilot become the contract by default

Pilots have a way of quietly turning into production without anyone re-running the commercial and security review. Set a decision date at the start of the pilot, and complete the full AI vendor due diligence before usage grows past the point where switching is realistic.

Treating the AI as the whole risk

Most AI projects fail on process, not model quality: unclear ownership, no measurement of the baseline, and no plan for the humans whose work changes. Score the vendor’s implementation methodology as seriously as their benchmark numbers.

Building AI Vendor Due Diligence Into Your Procurement Process

A checklist used once is a document. A checklist wired into procurement is a control. Organisations that buy AI well have turned AI vendor due diligence into a repeatable stage with named owners, rather than a heroic effort by whoever championed the tool.

Assign one owner and a cross-functional panel

One person should own the completed scorecard, but the answers need three sets of eyes: security for the data and access questions, legal for rights and exit, and the business owner for evaluation results. Running those reviews in parallel rather than in sequence usually halves the elapsed time without weakening the outcome.

Tier your vendors so the process scales

Not every purchase deserves ten weeks. Define three tiers by data sensitivity and operational dependence, then attach a fixed subset of these questions to each tier. A tier-three tool gets six questions and a week; a tier-one platform gets all thirty plus a technical evaluation.

Keep the completed answers as evidence

Store the finished AI vendor due diligence pack alongside the contract, with dates and the named respondent. When a regulator, auditor, or insurer asks how you assessed the vendor, that file is your answer. It also gives the renewal team a baseline to compare against instead of starting cold.

Frequently Asked Questions About AI Vendor Due Diligence

How long should AI vendor due diligence take?

For a departmental tool, two to three weeks is realistic. For a platform touching regulated data or core operations, six to ten weeks including a technical evaluation. The security and data review is usually the long pole, so start it on day one rather than after commercial agreement.

Do we need all 30 questions for a small purchase?

No. For a low-risk tool under a modest spend, the data rights block and the exit questions cover most of the exposure. Scale the depth of AI vendor due diligence to the sensitivity of the data and the difficulty of reversing the decision.

What if the vendor refuses to answer some questions?

Distinguish between cannot and will not. A pre-revenue startup genuinely may not have SOC 2 yet, and that can be managed with compensating controls. A refusal to put data-use terms in writing is a different signal entirely and should usually end the process.

Should we run this checklist again at renewal?

Yes. Models, sub-processors, ownership, and pricing all change mid-contract. A shortened AI vendor due diligence review at renewal, focused on what changed since signature, catches the drift that accumulates quietly over a three-year term. Frameworks such as the NIST AI Risk Management Framework provide a useful structure for that periodic review.

Run this checklist properly once and it becomes reusable infrastructure. The vendors who answer well tend to be the ones still worth working with three years later, and thorough AI vendor due diligence is how you find them before the invoice rather than after.

More AI coverage: explore Progressive Robot's AI Models, Tools & Releases hub — hands-on reviews, setup guides and benchmarks in one place.