AI due diligence: five red flags to check before the investment committee meets

Most AI due diligence reviews the architecture diagram. The diagram is the founders' description of the product, not the product. The findings that move a valuation sit one layer down, in the bills, the test sets, the data agreements and the code paths that run when a customer actually uses the thing.

This AI due diligence checklist covers the five red flags we check first, the question that brings each one into the open, and what good evidence looks like. None of them needs a week of testing to raise. All of them should be settled before the committee votes.

1. The "proprietary model" is a prompt and a vendor

Many AI products are a well-designed workflow around someone else's model. That can be a fine business. It is a different business from one that owns a model, and it should be priced differently.

Ask: "Which parts of the system did you train yourselves, on what data, and what does it do better than the base model it started from?"

Good evidence: a clear map of which steps call an external model and which call the company's own, training records for anything described as proprietary, and an evaluation showing the company's model beats the off-the-shelf alternative on the tasks customers pay for. If nobody can produce that comparison, the moat is the workflow and the data, not the model. Value it that way.

2. Accuracy claims with no test set behind them

"97% accurate" is a sentence in a deck until someone shows the test it came from. The questions that matter are: accurate on what inputs, measured how, and is it still true for the latest release?

Ask: "Can we see the held-out test set, the results by input type, and the scores for your last three releases?"

Good evidence: a test set the model never trained on, results broken down by the kinds of input customers send (clean documents behave very differently from phone photos), and a release history showing accuracy is measured every time the product changes. The warning sign is a single headline number with no breakdown and no history. It usually means accuracy is checked occasionally, by hand, on easy cases.

3. Gross margin quoted at today's volume

AI products carry a variable cost that traditional software doesn't: every request pays for compute, often to a third party. At small volume that cost hides inside a healthy margin. At the volumes in the growth plan it can grow faster than revenue: inputs get longer, customers use features more heavily, retries pile up under load, and cheaper pricing tiers stop being available.

Ask: "What is your cost per unit of work today, and what does your model say it will be at two, five and ten times current volume?"

Good evidence: a cost model built from real invoices rather than list prices, with the assumptions written down, and a load test showing where the system starts to slow down or fail. If the company has never modelled cost at the volumes in its own plan, the plan's gross margin is an assumption, and your valuation inherits it. We walk through how to model AI inference costs and gross margin at scale in a separate note.

4. One provider carries the product

When most of the inference bill goes to a single model provider, that provider's pricing, rate limits and terms of service set the company's margin and its reliability. Switching is rarely as simple as changing an API key: prompts, output parsing and quality checks are often tuned to one model's behaviour.

Ask: "What share of your inference spend goes to your largest provider, and how long would it take to move that work to another one?"

Good evidence: a model layer that separates the product from any single provider, a second provider that has actually been tested on the core tasks, and a realistic switching estimate measured in weeks, not a hopeful "we could switch tomorrow". Heavy concentration is fixable, and often cheaply, but it belongs in the price until it is fixed.

5. Training data the company can't clearly use

Where the training and fine-tuning data came from decides whether the company's main asset is actually its own. Customer data used under terms that don't allow training, scraped content with no recorded licence, or data from a partner whose agreement has lapsed can all turn a moat into a liability.

Ask: "For each source of training data, what is it, how much of the total does it make up, and which agreement lets you use it?"

Good evidence: an inventory of data sources with the share of the training set each one makes up, the clause in each agreement that permits the use, and, for anything uncertain, an estimate of what removing it would cost in accuracy. The legal conclusion belongs to counsel. The engineering facts underneath it (what is in the data, and what happens to the model without the questionable part) are what counsel needs to reach one.

Turning the checklist into an investment decision

Each of these findings lands in one of three places: it supports the valuation, it discounts it, or it becomes work to fund after closing, ideally as part of a 100-day value creation plan. The mistake is leaving it unclassified, so it surfaces as a surprise in the first board meeting instead of a line in the investment memo.

Our sample AI asset rating report shows what that classification looks like on a fictional company: every finding tested, sized and sorted into support, discount or fix.