The AI due diligence question bank: what to put to the founder
Thirty questions for the technical founder, grouped by what each one is really testing, and the follow-up that catches a rehearsed answer.
Most diligence questions have a rehearsed answer, because founders have been asked them before. The useful ones are the follow-ups, which are harder to prepare for and reveal whether the first answer was knowledge or recitation. The thirty below are grouped by what they test, which is the data position, the model dependency, evaluation discipline, the team and what the founder already knows is wrong. Ask six of them properly rather than thirty quickly.
A founder raising a round has answered the obvious questions forty times. You will get a fluent answer to anything on a standard list, and fluency tells you about preparation rather than about the company.
What works is the second question. The thirty below are grouped by what each is testing, each with the follow-up that separates knowledge from recitation.
Ask six properly rather than thirty quickly. Depth catches more than coverage.
The data position
1. Where did the training or fine-tuning data come from? → Follow-up: Who checked the licence, and when?
2. What do your model provider's terms permit you to do with inputs and outputs? → Follow-up: When did you last read them?
3. Does customer data leave the customer's environment? → Follow-up: Which of your contracts says it does not?
4. What happens to a customer's data when they leave?
5. Is any of your data proprietary rather than merely private? → Follow-up: What generates it, and how has the volume grown over two quarters?
6. What would a competitor have to do to assemble equivalent data?
The model dependency
7. What is your gross margin at current inference cost? → Follow-up: At twice that cost?
8. What breaks if your provider deprecates the model you use?
9. Could you switch providers, and has anyone tried? → Follow-up: How long did it take, or how long would it take?
10. How much of the product's behaviour is prompt rather than code?
11. When did you last have to change things because a provider shipped a new model?
12. What proportion of your cost of revenue is inference?
Evaluation discipline
13. How do you know the output is good? → Follow-up: Show me the number and its history.
14. What is in your evaluation set, and who wrote it?
15. What happens when the system is wrong? → Follow-up: Who finds out, and how long does it take?
16. What is your worst failure in production so far?
17. Has quality been measured against anything other than your own judgement?
18. What would make you roll back a release?
The team and the code
19. Who wrote most of this, by commit history rather than by title?
20. Are those people still here, and on the cap table?
21. What would you rebuild if you started again? → Follow-up: What stops you?
22. What is the oldest part of the system nobody wants to touch?
23. How long would a new engineer take to ship something meaningful?
24. What is on the roadmap that you already know will require a rewrite?
What they already know is wrong
The most productive group, because it invites candour rather than defence.
25. What would a sceptical engineer say after a week in this codebase?
26. What keeps you awake that is not fundraising?
27. Which customer is closest to leaving, and why?
28. What did your last technical hire tell you was wrong?
29. If this fails in two years, what is the most likely reason?
30. What question should I be asking that I have not?
Reading the answers
Specific and fast means lived experience. General and fluent means prepared. Defensive is worth noting and is not necessarily bad, because founders get asked these questions by people with no technical standing and learn to armour up.
The strongest signal on this list is question 21. Founders answer it honestly more often than anything else, because it reads as a chance to show judgement rather than as an audit, and the answer tells you what they actually think of their own system.
The second strongest is 30. A founder who has a real answer has been thinking about their own risks.
One limit worth stating
Thirty questions is a bank to draw from, not a script. Worked through in order it becomes an interrogation, the founder moves into performance mode, and every answer afterwards is worse. Pick the six that matter for this company, ask them conversationally, and follow whatever comes back rather than returning to the list. The list is there so you notice which six to pick.
What these questions are checking
The underlying framework is in the technical due diligence checklist for an AI startup, the defensibility questions are separated out in how to tell whether an AI startup's moat is real, and what it costs to have somebody else do the whole read is in what technical due diligence on an AI startup costs.
Our first memo for a fund is free, one per fund, inside 48 hours, and it includes the questions worth putting to this particular founder. Book the call.
If you are evaluating a company and want a technical read before the next partner meeting, that is the conversation to have.
Request the memoWritten by
Radwan Altaf
Radwan runs AISynq. Before that he delivered software inside enterprise programmes at DHL, AT&T, DirecTV and Accenture, which is where the habit of measuring a result against its baseline came from. More about the firm.
Read next
- What technical due diligence on an AI startup costsWhat firms charge for a technical read on an AI company, what moves the number, and the three things a cheap memo leaves out.
- How to tell whether an AI startup's moat is realFour kinds of defensibility an AI company can claim, which ones survive a competitor with the same model, and the test that separates them in one question.
- Technical due diligence checklist for an AI startupThe twelve questions worth asking before you back an AI company, what a good answer sounds like, and the two that most founders cannot answer at all.
Work with us
Looking at a company right now and want a technical read before the partner meeting?
Request the free memoGet the next one
New writing in Technical due diligence as it goes up, roughly twice a month. One article per email and nothing else in it.