Short answer
Technical due diligence on an AI startup covers eight areas: architecture and stack, model evaluation and reproducibility, data provenance and IP rights, defensibility, unit economics including true inference cost, security and agent permissions, production readiness, and team depth. The most common red flags are performance claims that cannot be reproduced, inference costs rising faster than revenue, unclear data rights, and AI agents with more permissions than their job requires.
Technical Due Diligence Checklist for AI Startups (2026)What technical due diligence on an AI startup actually involves
Technical due diligence on an AI startup is different from DD on a standard SaaS company. The questions are the same in structure: does the technology work, is it defensible, can it scale, what will it cost to maintain? But the answers require different evidence. A demo is not evidence. A benchmark on the company's own test set is not evidence. This checklist describes what a reviewer should ask for and what to look at when they get it.
It covers eight areas. Each includes what to request, what a good answer looks like, and the most common red flags.
1. Architecture and stack
Ask for a written architecture diagram, a list of third-party model and API dependencies, and the deployment topology. You are looking for whether the system is designed to be maintainable and observable, or whether it is a collection of scripts held together by a single engineer's knowledge.
A good answer includes a diagram that a new engineer could follow, named model versions with a pinning strategy, and a deployment pipeline that does not require manual steps for routine releases.
Red flags: undocumented prompts stored in someone's head, manual deployment steps for every release, a single engineer who is the only person who can run the system, and no staging or test environment.
2. Model evaluation and reproducibility
Ask for the evaluation dataset, the evaluation harness, and the most recent run results. Then run the evaluation yourself on a blind holdout set. This is the step most DD reviews skip, and it is the most important one for AI.
A good answer arrives with numbers, a versioned dataset, and a harness you can run. The company should be able to tell you the last time results changed significantly and why.
Red flags: performance claims with no linked evaluation, a demo environment that does not match production data, results that cannot be reproduced outside the demo, and no history of how metrics have changed over time. Data contamination between training and test sets is a common finding.
3. Data provenance and IP rights
Ask where training data, retrieval data, and fine-tuning examples came from, and request the licenses or data agreements for each source. For a retrieval-augmented system, ask how the system handles deletion requests and whether deletion reaches the vector store.
A good answer includes documented data sources, signed agreements for any third-party data, and a clear process for responding to deletion requests that covers embeddings and cached outputs, not just the source document store.
Red flags: training data scraped from the web without a documented legal basis, customer data used to improve the model without explicit consent, and no process for handling deletion that covers derived representations.
4. Defensibility
Ask what specifically makes this system hard to replicate. The answer should map to one of four credible categories: proprietary data the company controls, a workflow advantage built into integrations the customer already uses, a distribution advantage such as an existing customer base, or a regulated-domain advantage where the company has built compliance infrastructure that takes time to replicate.
A thin wrapper over a public model with no proprietary data or workflow lock-in is not defensible. That does not make it a bad business, but it changes the valuation basis. Test the company's claim against what a well-funded competitor with API access could build in 90 days.
5. Unit economics
Ask for a breakdown of cost to serve one user session: model API fees, cloud compute, storage, and any human review costs. Compare this to what the company charges per session or per user. The gross margin after inference costs is what matters, not the gross margin before.
A good answer comes back to the cent, with a clear breakdown. The company should know its inference cost per unit of output and have a view on how it changes at 10 times current volume.
Red flags: "we don't track inference cost separately," margins that assume cost optimisations that are not yet implemented, and unit economics that only work if a specific third-party model price holds. Some products have a human review step that is not visible in the model cost but is real and does not scale.
6. Security and agent permissions
Ask for the access control model, API key handling practices, and a list of what permissions AI agents hold in production. For generative AI systems, ask how the system handles prompt injection and what happens if a user extracts data the system was not supposed to share.
A good answer includes least-privilege agent permissions, API keys stored in a secrets manager rather than environment variables or code, and evidence that the team has tested for prompt injection against the specific tools the agent can call.
Red flags: AI agents with database write permissions they do not need, API keys in source code, no documented process for rotating credentials, and no testing for adversarial inputs against agent tool use.
Our technical due diligence service covers all eight areas with a written report and remediation estimates.
7. Production readiness and scalability
Ask for uptime history, incident records, and load test results. For a system that uses GPU compute, ask what happens when demand spikes beyond current capacity. Ask for the recovery time objective and whether it has been tested.
A good answer includes monitoring dashboards you can view, incident post-mortems, and a load test at a multiple of current peak traffic. The team should be able to describe what breaks first under load and what the mitigation is.
Red flags: no monitoring beyond basic uptime, no incident history (which may mean incidents are not being tracked), load tests that only cover the web layer and not the model inference layer, and no documented recovery process.
8. Team depth and technical debt
Ask for a code review of the core AI pipeline, a dependency audit, and an org chart with tenure. Run a git log analysis to identify concentration: if one engineer accounts for 70% of commits to the AI-critical paths, that is a risk. Ask who is on call when the model behaves unexpectedly at 2am.
A good answer includes a team where at least two engineers have deep familiarity with the production system, a dependency list with known CVEs documented, and a technical debt backlog with prioritised remediation items.
Red flags: ML engineers who left the company in the last six months, a roadmap with AI-critical features that are not yet funded, open-source dependencies with known high-severity vulnerabilities, and no documented on-call process for AI-specific failures.
What to do with the findings
Technical due diligence findings fall into three categories: blockers that require resolution before close, risks that should affect price or deal structure (escrow, founder warranties, milestone tranches), and observations that are worth noting but do not change the terms.
Most AI startups have findings in all three. The goal is not a clean report but a complete picture. A finding you discover after close is more expensive than one that affects the deal structure.
Our AI workflow automation case study shows the kind of system that holds up to production scrutiny. See also our AI readiness assessment service for pre-build diligence on the buyer side.
From our work
Related: Technical due diligence
Frequently asked questions
What is technical due diligence for an AI startup?
It is a structured review of an AI company's technology by an independent engineer or engineering firm. It covers whether the system works as claimed, whether the data and IP are clean, what it costs to run, how it handles security and scale, and whether the team can maintain and extend it. The output is a written report with findings categorised by severity and estimated remediation cost.
How long does technical due diligence take?
A focused review covering the eight areas above typically takes two to three weeks from access to written report. The timeline depends on how quickly the target company provides access to code, evaluation data, cloud accounts, and the team. A narrower scope, such as architecture and unit economics only, can be done in a week.
Who should run technical due diligence on an AI startup?
The reviewer should have hands-on experience building production AI systems, not just advising on AI strategy. The specific skills needed are model evaluation, infrastructure review, and security testing. A generalist software reviewer can cover architecture and code quality but will miss AI-specific risks like data contamination, evaluation methodology, and agent permission design.
What is the most common finding in AI startup due diligence?
Performance claims that cannot be reproduced outside the demo environment. This is the most common finding and the most significant. It usually reflects evaluation on a hand-picked or contaminated test set rather than deliberate fraud, but the effect on valuation is the same. The fix is straightforward: provide a versioned evaluation harness and a blind holdout set, and run it in the reviewer's environment.
Can an AI startup pass technical due diligence with known weaknesses?
Yes. The goal of technical DD is a complete picture, not a perfect one. A startup with documented debt, a clear remediation plan, and a team that understands the risks can often reach agreement on deal terms that reflect those risks. The deals that fall apart are usually those where weaknesses were hidden rather than ones where they were disclosed and priced.
