AI Technical Diligence Checklist

• □List the three to five technical statements the investment case depends on, in the company’s own words.
• □For each, note whether it is a capability claim, a performance figure, a cost or margin claim, or a defensibility claim.
• □Agree which claims a document review can settle and which would need an experiment.

• □Evaluation reports behind every headline figure: dataset, baseline, sample size, date, and who ran it.
• □Examples of failures and how often they occur, not only successful demonstrations.
• □Which results come from production use and which from controlled tests or pilots.
• □Customer usage data showing that the AI feature is used and retained, where the claim depends on it.
• □How much human review or correction sits behind the product today.

• □Sources of training, fine-tuning, and retrieval data, with the rights or licences for each.
• □Customer data terms: what the company may use for training or improvement, and what it may not.
• □Personal data processed, where it is processed, and under which agreements.
• □How data quality and labelling are checked, and by whom.
• □Any data the product depends on that a third party could withdraw.

• □The evaluation suite the team runs before each release, and recent results.
• □How the team detects regressions when a model, prompt, or vendor changes.
• □Whether test data is kept separate from training and tuning data.
• □How quality is monitored once a feature is live.

• □Every model and AI service the product depends on, with contract terms and pricing exposure.
• □What happens to cost and quality if the main model provider changes price, terms, or behaviour.
• □Whether the product could move to another provider, and what that would take.
• □Gross-margin sensitivity to inference costs at current and projected volumes.

• □What the product’s AI components can read, write, or execute in customer environments.
• □How high-impact actions are approved, logged, and stopped.
• □How prompt injection, data leakage, and misuse have been tested.
• □Incident history and how incidents were handled.

• □Who built the core system, and whether they are still with the company.
• □How much of the technical advantage is in code, data, workflow, or relationships.
• □Patent position, distinguishing granted patents from pending applications and provisional filings. A provisional filing is not a granted patent.
• □Open-source dependencies and their licences.
• □Key-person risk and documentation.

• □Which of your headline figures has someone outside the company reproduced?
• □Show us a case where the system was wrong. How did you find out, and what changed?
• □If your main model provider doubled prices tomorrow, what would happen to margin?
• □What does a customer have to do manually today that the deck implies is automated?
• □Which part of the product would a well-funded competitor find hardest to copy, and why?
• □What would make you stop or change the current AI approach?

Settle these before any reviewer sees confidential material.

• □Has the reviewer built, advised, invested in, or competed with the company or its close competitors?
• □Does the reviewer have an existing or expected commercial relationship with any party to the deal?
• □Would the reviewer be offered implementation or advisory work if the investment proceeds?
• □Record each disclosure, and decide whether to proceed, narrow the scope, or use a different reviewer. A different brand or domain does not make a conflicted reviewer independent.