← All writing

AI due diligence · Technical DD · For investors

AI due diligence: how to assess an AI company before you invest

Two different things get called AI due diligence, and the one that moves valuations is the one almost nobody sells. This is the checklist for it.

Search for "AI due diligence" and most of what comes back is about using AI to do due diligence: tools that read the data room faster, summarise contracts, draft the red-flag memo. Useful, and not what this article is about. This is about due diligence of an AI company - the work of finding out whether the AI in the pitch deck actually exists, whether it is defensible, and what it will cost the buyer to own it.

That second kind is where deals move. The tech file is now routinely one of the most heavily priced workstreams in a transaction, and for software and AI targets it is often the first. Yet the market for doing it properly is thin, because most advisers pivoted to selling the tooling instead. When I run this work through my technology and AI due diligence practice, the brief from the deal team is usually one sentence: is it real, and what does it break if it is not?

I have sat on the other side of this table. I took agentic AI into production at a regulated derivatives trading venue, where the systems I signed off carried real orders with real money behind them, and before that I was principal architect on the platform behind $330M of assets under management. The checklist below is the one I wish every deal team used, in the order I would run it.

1. Find out where the defensibility actually lives

Every AI product decomposes into three layers: the model, the prompt and orchestration layer, and the product around them. The first question of AI diligence is which layer the target actually owns, because the valuation usually assumes ownership of a layer the target is merely renting.

The question a venture investor should keep asking, borrowed from the wrapper debate: could this be rebuilt on off-the-shelf foundation models? If yes, what you are pricing is everything except the AI. I go deeper on how to answer that question by reading the system rather than the pitch in the companion piece, Is the AI real, or a wrapper?

2. Take the system off the demo path

A demo is a rehearsed path through a system. Diligence is about every other path. Arvind Narayanan's "AI snake oil" work made the academic version of this argument years ago: impressive performance on curated inputs tells you very little about behaviour on the inputs the real world will supply.

Practically, that means sitting with the product and doing what the demo never does: paste in the malformed document, the ambiguous instruction, the adversarial input, the query in the wrong language. Watch three things - what the system gets wrong, whether it knows it got it wrong, and what it does about it. A system that fails loudly and hands off to a human is production engineering. A system that fails confidently is a liability the buyer inherits at close.

Ask for the evaluation harness. A team that ships LLM systems seriously will have one: versioned test sets, regression scores over time, a record of what each model or prompt change did to quality. If evaluation happens by someone eyeballing outputs before release, write that down, because it means quality is a function of who was in the room.

3. Trace the training data and the model licences

If the target claims to have trained or fine-tuned anything, provenance is the red-flag topic of the moment in AI M&A, and for good reason: it is the one defect that cannot be fixed post-close with engineering effort.

None of this needs a lawyer to start. It needs someone technical asking for the data lineage and reading the licence files in the repo, then handing the specifics to the lawyers with the right questions attached.

4. Do the unit economics of inference

Classic software has near-zero marginal cost. LLM products do not. Every action the product takes burns tokens, and the margin story depends on numbers most pitch decks omit.

Get to a cost per unit of value: per document processed, per conversation, per resolved ticket. Then stress it. What happens to gross margin if usage grows the way the plan says it will? What happens if the model provider reprices, or if the product is quietly subsidised by a discounted tier that expires? And in the other direction: has the team done any engineering to bring inference cost down - caching, model routing, smaller models for cheap steps - or does every request go to the most expensive frontier model because nobody has looked?

A target that knows these numbers cold is telling you something about the team. A target that has never computed them is too.

5. Place the product under the EU AI Act before someone else does

Since 2 August 2026 the EU AI Act's obligations for high-risk systems are enforceable, with penalties scaling up to EUR 35 million or 7% of global turnover at the top of the range. For fintech targets this is not a peripheral question: credit scoring, insurance risk pricing and similar automated decisioning sit in Annex III, which is the high-risk list.

Diligence needs to establish three things: which risk category the product genuinely falls into, whether the target's own classification is defensible, and what the gap is between current engineering practice and the obligations that category carries - logging, human oversight, technical documentation, post-market monitoring. A UK-only company serving EU users is in scope whether it likes it or not. The cost of closing that gap belongs in the model, priced, not in a footnote.

6. Ask whether the audit trail can carry the claims

This is the item I weight most heavily for any product with agentic behaviour, because I have watched it decide whether systems ship. If the product takes consequential actions - moves money, files documents, makes decisions about people - can the target reconstruct, after the fact, what the system did and why?

Ask to see the trace for a real production incident: the reasoning steps, the tool calls with their exact inputs, what came back, who approved what. If the answer is a dashboard of green uptime graphs, the target is monitoring the system, not observing it, and the claims made to customers and regulators are resting on nothing. I wrote up what a real agent trace looks like, field by field, in Your AI agent works in the demo. Can you explain what it did last night?, and the buyer-side version of the test in How to audit AI agents. The short version: audit trails cannot be meaningfully retrofitted, so their absence is a cost, not a to-do.

7. Meet the people who actually built it

Org charts flatter. In most AI companies the capability concentrates in a very small number of people, and diligence should find out who they are, whether they are staying, and what walks out of the building if they do not. An hour of technical conversation with the person who built the orchestration layer tells you more than the architecture deck: whether the design decisions were reasoned or cargo-culted, whether the failure modes are understood, whether the roadmap is theirs or the founder's wish list.

While you are there, ask what they would fix first with the new money. Engineers answer that question honestly almost every time, and the answer is a free look at the real state of the codebase.

Running this inside a deal window

All of the above fits in one to two weeks alongside the rest of the workstreams, provided the person doing it can read the codebase rather than interview about it. The output that deal teams actually use is not a fifty-page appendix; it is a position - what is real, what is priced wrong, which findings are a price chip, which are a condition, and which, rarely, are a reason to walk - with every finding quantified where it can be and the assumptions stated where it cannot.

That is the standard this checklist is built to feed. If a diligence report cannot tell the partner what to do on Monday, it was research, not diligence.

Sources

This is the first of three pieces on assessing AI systems from the buyer's side, alongside Is the AI real, or a wrapper? and How to audit AI agents. I run technology and AI due diligence for investors and acquirers through Trustflux Ltd - evidence-backed findings, explicit assumptions, delivered inside a deal window.

Written with Claude Code. The checklist is the artefact; the article is the receipt.