The AI due diligence checklist we actually use

Most AI due diligence checklists you can download are written to be exhaustive. Ours is written to change deals. After running technical and AI diligence for VC and PE funds, we keep returning to six areas where findings actually move the price, the terms, or the decision itself: production reality, error handling, evaluation practice, unit economics, data rights, and team concentration.

What follows is the working version of that checklist, with the questions we ask and the evidence we expect behind each answer. Answers without evidence are marketing. If you want the definitional groundwork first, start with what AI due diligence covers and when you need one.

How to use this AI due diligence checklist

Weight it by the thesis. If AI is one feature among twenty, diligence it like a feature. If the valuation assumes the AI is the product, every area below carries part of the price and deserves hours, not minutes.

Second, treat each answer as a lead, not a verdict. A finding only matters once it translates into money, time, or risk. We keep a separate note on the red flags that actually matter precisely because most findings do not.

One deliberate omission: defensibility. Whether the product has a moat is a strategic question with its own method, covered in evaluating an AI moat. This checklist establishes whether what you are buying exists and holds together.

Production reality

The gap between the demo and production is the single most common finding in AI deals. The demo always works. The questions:

• What share of real traffic goes through the AI components today, and how is that measured
• Show a live trace of one production request, end to end
• Which features in the sales deck are not in production yet, and since when have they been "coming next quarter"
• How many users touch the AI features weekly, and what does retention on those features look like

We have seen products where the agent from the deck handled a small corner of real usage while a rules engine and a support team quietly did the rest. That is not fraud, and it can be a sensible way to ship. But it changes what you are buying, and it should change what you pay.

Error handling and evaluation practice

Ask what happens when the model is wrong, slow, or unavailable. Strong teams answer in specifics: fallbacks, timeouts, degradation paths, review queues, and a name for who gets paged.

• What does the user experience when the model returns a bad answer
• Where do low-confidence outputs go, and who looks at them
• What is the incident history for the AI features, and where is it written down
• What happens during a model provider outage

A team that cannot name its last AI incident either does not monitor or does not ship. Neither is good news for the deal.

Error handling has a twin: evaluation, the habit that separates AI systems from AI demos. Ask to see the eval set, never to be told about it.

• How do you know quality did not drop after the last prompt or model change
• Show the eval set: how many cases, where they came from, when it last grew
• What are the current scores, and what caused the last regression

"We test it by hand" from a company charging enterprise prices is a finding. So is an eval set of forty examples written in one afternoon a year ago and never touched since.

Unit economics

The margin question deserves a full note of its own, the margin question every AI deal should start with, but the checklist version fits in three lines:

• What does one typical request fully cost, including retries, context, and orchestration overhead
• What is gross margin today, and modeled at ten times the volume
• What happens to that margin if model prices halve, or double

Teams that know their numbers answer in minutes, from a dashboard. Teams that do not will offer to get back to you, and the answer that comes back a week later deserves extra scrutiny.

Data rights

This is where diligence findings turn into legal exposure. The questions are unglamorous and worth every minute:

• Where did training and fine-tuning data come from, and what do the underlying contracts actually permit
• Can a customer demand deletion, and does deletion reach backups, embeddings, and fine-tuned models
• What legal basis covers the personal data sitting in prompts and logs
• Do enterprise contracts promise data isolation the architecture does not deliver

The last one is worth reading contracts for. A promise of "your data never trains our models" is easy to write and, in some architectures we have reviewed, hard to honor.

Team concentration

Finally, map who can actually operate the system. Not the org chart: the real map.

• Who can retrain or rebuild the pipeline from scratch
• Who wrote the prompts and evals, and who else has changed them since
• Who debugs production at 2am, and what happens if that person leaves

In AI products, knowledge concentrates harder than in classic software, because so much of the system lives in judgment about data and prompts rather than in documented code. If the answer to all three questions is the same name, the retention package is part of the price.

Running this checklist takes 3 to 4 days in a focused read and produces findings you can take into negotiation the same week. When the target is AI-heavy or the check is large, we run it as part of a full technical and AI audit, with a scorecard and a risk register ranked by severity, so the investment committee reads conclusions rather than notes.