Technical due diligence checklist for an AI startup

A standard technical diligence checklist asks about test coverage, deployment, documentation and key person risk. Those questions are still worth asking, and they are not where an AI company's risk lives.

The risk lives in three places a software checklist does not look. What the company is allowed to do with its data. What happens when the model underneath it changes. And whether anybody can tell, with evidence, that the thing is getting better rather than merely getting different.

The data position#

1. Where did the training or fine-tuning data come from, and what permits its use? A good answer names the source and the licence. A bad answer describes the data and not its provenance, which usually means nobody has checked.

2. What do the vendor terms permit? If the product calls a commercial model, the provider's terms govern what can be done with inputs and outputs. Founders who have read them say so quickly. Founders who have not will reach for the phrase "standard terms".

3. What happens to customer data? Specifically whether it leaves the customer's tenancy, whether it reaches a model provider, and whether anything is retained. This is the question that kills enterprise deals eighteen months later, which is inside your holding period.

The model dependency#

4. What breaks if the model provider doubles the price? Ask for the number rather than the reassurance. A company that has run the arithmetic will tell you its gross margin at two or three times current inference cost.

5. What breaks if the model is deprecated? Providers retire models. A company with an abstraction layer and an evaluation suite can move. A company with prompts hard-coded against one model's behaviour cannot, and will spend a quarter finding out.

6. Is the thing a wrapper, and does that matter? Often it does not. A thin layer over a public API with real distribution and a real workflow is a business. The question is not whether there is proprietary modelling, it is what would happen if a competitor tried to copy it next week.

The evaluation discipline#

7. How do they know it is working? The strongest answer is an evaluation set with a number attached and a history of that number. The weakest is a demo and a claim. This question separates teams that are engineering from teams that are prompting.

8. What happens when it is wrong? Every AI product is wrong sometimes. Ask what the system does then, who finds out, and how long it takes. A team that has thought about it has a specific answer.

9. Has the output quality been measured against anything other than the team's own judgement? Harvard and BCG's field experiment on 758 consultants found that on tasks outside the model's competence, people using AI performed 19 percentage points worse than those using none, while believing they were doing better. Internal confidence is not evidence.

The ordinary questions, which still matter#

10. Who actually wrote this? Commit history over the life of the repository, not a headcount. On early teams one or two people usually wrote most of it, and you want to know whether they are still there and whether they are on the cap table.

11. What would the next six months of engineering cost? Not the roadmap. The cost of the work the roadmap implies, including the rebuilds nobody has scheduled.

12. What would they rebuild if they could start again? Founders answer this honestly more often than they answer any other question on the list, because it reads as a chance to show judgement rather than as an audit.

The two that go unanswered#

Questions 2 and 5. Vendor terms and model deprecation.

In most early-stage companies nobody owns either. That is not necessarily a reason to pass, because at eleven people nobody owns a lot of things. It is a reason to write them into the first hundred days, and to know before the committee meets that you are buying them rather than inheriting them solved.

Where this fits#

The questions above are what a memo should answer. How to actually get through a codebase quickly enough to answer them is a separate skill, written up in how to assess a startup codebase in two days. What that work costs when you buy it from somebody is in what technical due diligence on an AI startup costs.

Our first memo for a fund is free, one per fund. Three to six pages inside 48 hours, including the questions worth putting to the founder directly. Book the call and bring the company.