AI Startup Due Diligence: An Evidence-First Checklist

AI startup due diligence helps investors, customers, and partners test whether a company’s product, technology, data practices, and business claims stand up to scrutiny. An evidence-first process starts with documents and reproducible demonstrations, not a polished pitch; prepare a secure review space, a written question list, and permission to examine relevant records.

What You’ll Need

• A defined purpose and scope: investment, procurement, partnership, or another decision.
• A secure data room or document-sharing method, with access limited to reviewers who need it.
• A checklist, evidence log, and named people responsible for technical, commercial, legal, and security review.
• Company materials, including product documentation, contracts, financial information, and relevant policies. Request sensitive records in a privacy-conscious form.
• Access to a live product demonstration and, where feasible, a test environment using non-sensitive data.

Step-by-Step

1. Define the decision and claims to test. Write down what you need to decide, the intended use of the product, and the claims that matter. For example: does it perform a stated task at an acceptable level, can the company serve the expected workload, and does its revenue model account for inference costs? Separate essential requirements from desirable features. Set a deadline and identify who can approve, challenge, or stop the review.
2. Build an evidence register. For each claim, record the exact wording, evidence requested, source, date, owner, and status: verified, partly verified, unverified, or contradicted. Note whether evidence is company-produced or independently corroborated. Ask for underlying material rather than relying on a slide or verbal assurance. Record gaps explicitly; absence of evidence is not proof that a claim is false, but it should not be treated as confirmation.
3. Check the product in a realistic demonstration. Ask the team to show the product from input to output, including configuration, human review, and failure cases. Use representative tasks, including ambiguous or difficult examples, and agree on evaluation criteria beforehand. Observe latency, error handling, and whether outputs can be traced or corrected. If a demo cannot be repeated independently, record that limitation and request a sandbox or a supervised trial with suitable safeguards.
4. Inspect model and system claims. Establish what the product actually uses: a company-trained model, a fine-tuned model, a third-party model, retrieval, rules, or a combination. Request architecture and model documentation appropriate to the review, including versioning, dependencies, evaluation methods, and known limitations. Ask how changes are tested and rolled back. Do not assume that owning an interface or prompt means the company owns the underlying model or can control a provider’s changes.
5. Validate performance with task-specific evidence. Request evaluation results, test-set composition, baselines, sample sizes, and definitions of success. Check whether tests reflect the intended users, languages, inputs, and operating conditions. Look for leakage between training and evaluation data, cherry-picked examples, and metrics that hide serious errors. Where possible, reproduce a small agreed test using a holdout set. Treat benchmark scores as context, not proof of performance in your setting.
6. Trace data rights and handling. Map where training, customer, and operational data come from; who may use them; where they are stored; and how long they are retained. Review relevant licenses, consent or other documented permissions, customer terms, subprocessors, deletion practices, and whether customer inputs may be used to improve models. Check how sensitive data is minimized and protected. If the company cannot establish rights or explain data flows, pause use of the affected data until the gap is resolved.
7. Review security, privacy, and misuse controls. Request a description of access controls, encryption practices, incident response, vulnerability handling, backups, and independent assessments if available. Ask how the system handles prompt injection, data exposure, abuse, and unsafe outputs in the intended context. Confirm whether human review is needed and how incidents are escalated. Distinguish documented controls from controls that have been tested, and agree on a safe test scope rather than probing live systems without authorization.
8. Test business and operating assumptions. Examine customer references with permission, signed contracts or other support for revenue claims, renewal and usage patterns, and the difference between pilots and recurring deployments. Ask for unit economics by workload: model and infrastructure costs, support, human review, and other material expenses. Check capacity, provider dependence, service continuity, and what happens if usage or model prices change. Compare forecasts with actuals and state assumptions rather than treating projections as established results.
9. Check team, ownership, and obligations. Confirm who is responsible for core technology, security, and operations, and whether key knowledge is concentrated in one person. Review ownership of code and other relevant intellectual property, contractor arrangements, material third-party terms, and obligations to customers or providers. Have qualified counsel review legal questions; a diligence checklist is not a substitute for legal advice. Avoid collecting personal information that is not necessary for the decision.
10. Make a documented decision with conditions. Summarize verified strengths, unresolved risks, contradictory evidence, and assumptions. Rate each issue by likelihood, impact, and whether it can be mitigated before proceeding. Assign an owner and deadline to every open item. Decide to proceed, proceed with explicit conditions, defer, or decline. Preserve the evidence log and revisit material conditions before deployment or at agreed review points.

Common Mistakes

• Accepting pitch-deck metrics without definitions, data, or a way to reproduce them.
• Confusing a convincing demo with reliable production performance.
• Evaluating generic benchmark scores instead of the tasks and failure costs relevant to the intended use.
• Overlooking third-party model, cloud, or data-provider dependencies and their contractual limits.
• Treating a pilot, letter of intent, or free trial as equivalent to durable paid demand.
• Recording concerns without assigning an owner, deadline, or decision consequence.

Tips

• Ask the same core questions of founders and technical staff, then reconcile differences.
• Use a small, pre-agreed test set and keep the prompts, settings, model version, and results for reproducibility.
• Separate observed facts, company representations, reviewer assumptions, and open questions in your notes.
• Request redacted or aggregated evidence when detailed records would expose customer or employee information.
• Scale review effort to the decision: a low-risk trial needs less scrutiny than handling sensitive data or relying on the system for a critical workflow.

Troubleshooting

The company will not share sensitive records: Ask for redacted documents, summaries backed by source records, or a supervised review. Record what remains unverifiable and whether it blocks the decision.

Results differ between tests: Check model version, system prompts, settings, retrieval sources, and test inputs. Repeat a controlled evaluation and report variation, not just the best run.

Performance claims cannot be reproduced: Ask for the protocol and data boundaries, then run a small independent test. If access is unavailable, classify the claim as unverified and avoid relying on it as a decision-critical fact.

Reviewers disagree about severity: Describe the specific scenario, affected users, likelihood, impact, and mitigation. Escalate unresolved high-impact issues to the decision owner rather than averaging conflicting opinions.

The review is running out of time: Prioritize risks that could change the decision, such as data rights, security exposure, core performance, and economics. Defer lower-impact questions with named owners and deadlines; do not silently mark them complete.

Frequently Asked Questions

How long does AI startup due diligence take?
It depends on the decision, system access, and risk. A focused review can be short; deeper checks may take longer when evidence is missing or the product handles sensitive data.

What evidence is most important?
Evidence tied to the intended use: reproducible task performance, clear data rights and flows, security controls, customer commitments, and credible operating-cost assumptions.

Should reviewers inspect source code?
Not always. Architecture documents, a controlled demonstration, and independent testing may answer the key questions. Code review can help when ownership, security, or technical claims cannot otherwise be assessed.

Can a startup use third-party models and still have a defensible product?
Yes. Assess what the startup contributes and verify provider terms, portability, service dependencies, data handling, and the effect of provider changes.

What if the company has no independent audit?
That is not automatic proof of a problem. Use other available evidence, test controls proportionately, and record the limits of assurance before deciding.

When should a review stop the deal or deployment?
When a material risk cannot be understood or mitigated, such as unclear rights to essential data, unaddressed serious security exposure, or performance that fails a critical requirement.

Related

• SpaceX vs Other Private Space Companies: How They Compare
• League of Legends Virtual Bands: Members, Music & Lore
• Identifying Ancient Roman Sculpture: Key Traits