Every item framed twice — what the investor is testing for, and what a prepared founder puts in the data room. Written for both sides of the table.
“We use AI” stopped being a moat the moment foundation models turned into a utility you rent by the token. A widely cited MMC Ventures study, reported by MIT Technology Review, found that roughly 40% of European startups labelled “AI companies” had no material AI or machine learning in the product. So technical due diligence for AI startups now opens with a blunter question than “does the AI exist” — it asks whether the AI is real, owned, and defensible. This post frames every check twice: for the VC pricing the AI layer, and for the founder closing gaps before the data room opens.
What changed in 2026 — AI moved from annex to core of technical due diligence
AI-specific checks used to be a short annex after the code review and the infrastructure audit. In 2026 they sit at the centre. Deal teams now expect a documented chain of title for every training dataset, fine-tuning artifact, and model weight. SOC 2 progress and bias-audit status show up in seed-stage checklists, not just at Series B. Early-stage diligence guides from firms like Pebblous now treat regulatory readiness as a seed-stage line item.
Two forces pushed the change:
- Foundation models commoditised. When every team can call the same frontier model, differentiation moves to proprietary data, evaluation rigour, and how deeply the AI is wired into the workflow.
- AI deals close faster. Directional data from Causo Hub’s H1-2026 AI go-to-market report puts enterprise pilot-to-paid conversion near 47%, against roughly 25% for traditional SaaS. Faster revenue means the AI layer carries more of the valuation — and investors price it under time pressure, often re-pricing mid-diligence.
How to use this checklist (both sides of the table)
Each of the six items below has two halves. What the investor asks maps to what VCs actually check in technical due diligence. What the founder must be able to prove maps to how a founder prepares for that same review.
- Investors: use it to structure the data-room request and to score the responses.
- Founders: run it as a self-audit 60 to 90 days before you open the raise. If you are still scoping the build itself, our breakdown of what it costs to build an MVP in 2026 covers the spend side; this checklist covers what that build has to withstand later.
The portable summary table at the end is the version to copy into a data-room index or a diligence tracker.
The checklist
1. How central is AI to the product?
What the investor asks: Would the product still function and still sell if the AI layer were removed or swapped for a simple rules-based baseline? Does AI sit in the core inference loop that delivers the value, or is it a thin feature wrapper around a conventional application?
What the founder must prove:
- An architecture diagram showing exactly where models sit in the request path.
- The share of revenue and active usage tied to AI-driven features.
- An honest “what breaks without it” statement.
This is the item that catches AI-in-name-only — the same gap the MMC Ventures figure points to.
2. Which models, and self-hosted vs. API?
What the investor asks: A full inventory of models in production — foundation, fine-tuned, and self-hosted open-weight. Which calls leave the company’s infrastructure, and to which providers? What is the cost per inference, and how does it scale with usage?
What the founder must prove: a current model registry, an infrastructure-cost breakdown per model, and the reasoning behind each build, buy, or fine-tune decision.
| Model | Hosting | Purpose in product | Fallback |
|---|---|---|---|
| Frontier LLM | Third-party API | Primary reasoning / generation | Secondary provider, tested |
| Fine-tuned open-weight | Self-hosted | Domain-specific classification | Base model + prompt |
| Embedding model | Self-hosted | Retrieval / search | Hosted embedding API |
3. Model provenance and training-data rights (chain of title)
What the investor asks: Can the company produce a verified chain of title across every training dataset, fine-tuning artifact, and model weight? What are the licence terms for each source, the consent or scraping basis, and does any base model’s licence restrict commercial or downstream use? A company that cannot account for its training data carries unquantified legal liability — and Startups Magazine has documented investors walking away from deals over exactly that hidden risk.
What the founder must prove:
- A dataset inventory: source, licence, acquisition date, and rights holder for each entry.
- Contracts or licences for any purchased or partner-supplied data.
- Documentation that fine-tuning inputs were lawfully obtained.
- A base-model licence review covering non-commercial clauses and output-use restrictions.
Flag SOC 2 and bias-audit status here too. For the how-to-comply depth, see our guide to Cyber Resilience Act compliance — this checklist stays on what the investor asks, not how to close the gap.
4. Is the eval harness reproducible?
What the investor asks: Can the team re-run its quality benchmarks on a clean machine and get the same numbers? Is the evaluation set version-controlled, held out from training, and representative of real production traffic? Are regressions caught before deploy, or discovered by customers? And who owns the eval set — the company, or a contractor who has since left?
What the founder must prove:
- Eval code and datasets committed to the repository.
- A documented, single-command way to run the full suite.
- CI that runs evals on every model change.
- A changelog of benchmark scores over time.
- Clean separation between training and evaluation data.
A reproducible harness is the evidence that the accuracy claims in the deck are real. Its absence discounts every performance number in the room.
5. How locked-in is the company to one LLM vendor?
What the investor asks: If the primary LLM provider doubled its prices, changed its terms, deprecated the model, or suffered an outage, how long would a switch take and at what quality cost? Are prompts, tool schemas, and output parsing coupled to one vendor’s quirks? Is there an abstraction layer, or are API calls hard-coded throughout the codebase?
What the founder must prove:
- A provider-abstraction layer between the application and any single model API.
- At least one tested fallback model, with eval numbers measured on it.
- Portable prompts and clear versioning.
- A migration estimate in engineer-weeks.
Concentration on a single vendor is both a margin risk and a continuity risk. A diligence team will price it into the valuation.
6. Commit-history forensics — who actually built the core IP?
What the investor asks: Run the git history on the core repositories. Which named individuals authored the IP that matters, and are they still employees, equity-holders, and under a valid IP-assignment agreement? What share of the defensible code came from contractors, an outside agency, or an open-source lift? Are there large unexplained commits that could be copied code, or a critical module with a single author and no backup?
What the founder must prove:
- A contributor breakdown by commit volume on the core modules.
- Signed IP-assignment agreements for every past contributor — founders and contractors included.
- Provenance notes for any large code imports.
- A bus-factor assessment with a mitigation plan.
This is how a diligence team separates “the team built a moat” from “the team wired together some APIs.”
Why technical due diligence for AI startups gets re-priced mid-diligence
Because AI pilots convert to paid faster — directionally around 47% against 25% for traditional SaaS, per Causo Hub — revenue ramps sooner and the AI layer carries more of the valuation. That has two effects:
- The diligence window compresses. Investors are pricing a faster-moving asset with less time to inspect it.
- Each checklist item becomes a live pricing input. A missing training-data licence or a non-reproducible eval harness is not a footnote to clean up after close — it moves the number between term sheet and signing.
The practical takeaway for founders: a gap you do not fix before diligence becomes a discount, not a follow-up email.
The team lens — assess AI, domain, and commercial strength together
The final read is not ML headcount. It is whether the team combines three things:
- AI capability — they can build and maintain the models, not just call them.
- Domain understanding — they grasp the problem well enough to know what “good” looks like.
- Commercial instinct — they can sell the result and price it.
A strong research team with no domain depth ships demos that do not convert. Strong domain founders with a thin AI bench cannot hold the moat as models move. Diligence scores the intersection, not any single axis.
The portable checklist (summary table)
Use this AI due diligence checklist as the portable version — copy it into a data-room index or a diligence tracker. It condenses the six sections above plus the team lens into one row each.
| Checklist item | What the investor asks | What the founder proves |
|---|---|---|
| 1. AI centrality | Does it still work and sell without the AI layer? | Architecture diagram, AI-linked revenue share, “what breaks” statement |
| 2. Models & hosting | Full model inventory; which calls leave the building; cost per inference | Model registry, per-model cost breakdown, build/buy rationale |
| 3. Provenance & data rights | Verified chain of title for data, fine-tuning, and weights; licence terms | Dataset inventory, data contracts, base-model licence review |
| 4. Reproducible evals | Can benchmarks be re-run to the same numbers? Who owns the eval set? | Evals in repo, one-command run, CI, score changelog |
| 5. LLM vendor lock-in | Switching time and quality cost if the provider changes terms | Abstraction layer, tested fallback, migration estimate in engineer-weeks |
| 6. Commit-history forensics | Who authored the core IP; is assignment clean? | Contributor breakdown, signed IP assignments, bus-factor plan |
| 7. Team lens | AI, domain, and commercial strength assessed together | Evidence across all three, not just ML hires |
FAQ
What is technical due diligence for an AI startup?
It is the standard technical review of a company’s code, architecture, and team, plus AI-specific checks: whether the AI is material to the product, whether training data and model weights have a clean chain of title, whether evaluations are reproducible, and how dependent the company is on a single model vendor.
What do VCs check first in AI technical due diligence?
Two things. First, AI centrality — would the product still function and sell without the AI layer. Second, the training-data chain of title — whether every dataset, fine-tuning artifact, and model weight can be accounted for with licences and a consent basis. Both are fast ways to spot a mispriced deal.
How should a founder prepare for technical due diligence?
Run the six items above as a self-audit 60 to 90 days before opening the raise. Build the data room around them: architecture diagrams, a model registry, a dataset inventory with licences, evals in the repository, and signed IP-assignment agreements for every contributor.
Why do investors care about LLM vendor lock-in?
Because it is both a margin risk and a continuity risk. If the sole provider raises prices, changes terms, or deprecates a model, an unprepared company faces a costly migration and a possible quality drop. Diligence teams price that exposure into the valuation.
How is commit-history analysis used in due diligence?
The git history shows which named individuals authored the core IP, how much came from contractors or open source, and whether any critical module has a single author. It is the check that verifies IP-assignment agreements actually cover the people who wrote the defensible code.
Same checklist, both chairs
The checklist reads the same from either seat: investors price what founders can prove. Whichever side of the table you are on, work through these six items before the data room opens, not while it is live — during diligence, every unproven claim converts to a discount.
Muteki Group runs technical due diligence for AI startups from both sides — technical intelligence for investors assessing a target, and pre-raise readiness reviews for founders. See our CTO-as-a-Service and startup engineering practice to scope a review.
Image credits: Business professionals examining printed documents together in an office meeting photo by Vlada Karpovich on Pexels. Two colleagues reviewing information together on a laptop at a desk photo by Thirdman on Pexels.
