Due diligence

What AI due diligence should actually cover

Most AI diligence stops at 'do they have AI'. Here is the checklist that separates a real capability from a vendor API and a good deck.

7 min read

Every deal now arrives with an AI narrative attached. Sometimes it is the reason for the multiple. More often it is a paragraph in the CIM that nobody on the deal team is equipped to test, and it quietly survives all the way to close.

The problem is not that diligence teams ignore AI. It is that the questions being asked — do you use AI? which models? how many customers use the feature? — are answerable by any company that has wired an API call into a product. They do not distinguish between a durable capability and a thin layer that a competitor could replicate in a fortnight.

Here is what a review has to establish instead.

1. What is actually in production

Start with an inventory that separates three categories, because management decks almost never do:

  • In production: running against live customer or operational data, with monitoring, and with a named owner.
  • In pilot: working, but on a subset, usually without the operational scaffolding.
  • In development or demo: works when someone drives it.

Ask for the deployment history and the monitoring dashboards rather than the roadmap. A feature that has been in production for eighteen months has a very different risk profile to one that shipped six weeks before the process started.

2. Where the intelligence actually lives

The critical distinction is whether the target owns anything that a competitor could not buy on the same terms.

A model fine-tuned on proprietary operational data that took years to accumulate is an asset. A prompt template calling a commercial API is a product decision — a reasonable one, often the right one, but not a moat, and it should not be underwritten as one.

Questions that separate them:

  • What would it cost a well-funded competitor to reach parity, in months and dollars?
  • If the primary model vendor doubled its prices, what happens to gross margin?
  • If that vendor deprecated the model tomorrow, how long to migrate, and who does it?

3. The data rights position

This is where deals get genuinely damaged, usually after close.

Establish what data trained or fine-tuned the models, and whether the contracts covering that data permit the use. Customer agreements written before 2023 frequently do not contemplate model training at all, and silence is not permission in every jurisdiction.

Check specifically for:

  • Customer contracts that prohibit secondary use of data
  • Training data acquired from sources with restrictive licensing
  • Open-source models under licences that limit commercial deployment
  • Data residency commitments that the current architecture does not honour

4. The real cost to run it

AI costs behave differently from the software costs a diligence model usually handles. Inference cost scales with usage rather than with seats, which means a successful year can compress gross margin instead of expanding it.

Build the cost picture from billing detail, not from a management estimate:

  • Inference and API spend for the last twelve months, monthly
  • That spend expressed per active user, per transaction, and as a share of revenue
  • GPU or reserved capacity commitments, with their expiry dates
  • The fully loaded cost of the ML and data engineering team

Then run the plan case through it. A model that costs eleven cents per transaction at current volume is fine. At the volume in the growth plan it may be the single largest line in cost of revenue.

5. Key-person concentration

AI capability concentrates in very few people far more often than conventional software does. It is common to find one or two individuals who understand the training pipeline, the evaluation harness and the deployment path — and no documentation that would let anyone else pick it up.

Establish who they are, what their retention looks like post-close, and what happens to the roadmap if they leave in month three. Then price that.

6. Governance, or the absence of it

You are not looking for a policy document. You are looking for evidence that someone can answer four questions:

  • How do we know the model is still performing? (Evaluation, run on a schedule.)
  • What happens when it is wrong? (Human review, escalation, remediation.)
  • Can we turn it off? (Rollback path, tested.)
  • Who decided it was acceptable to deploy? (A named person, with a record.)

An operation that cannot answer these has not necessarily done anything wrong. But it has a remediation cost, and it belongs in the model.

What the output should look like

A useful AI diligence report is short and specific. For each finding: what we found, what evidence supports it, what it costs, and what has to happen about it. Red, amber, green, with the ambers explained — because in practice the ambers are where the negotiation happens.

What it should never be is a survey of the AI landscape with the target’s name inserted. The deal team can read the market commentary themselves. What they cannot do without access and time is establish whether this particular company’s AI story survives contact with its own billing data.