Technical Due Diligence Checklist for AI MVPs Before Funding

Technical due diligence on an AI MVP covers the same layers as any custom software development review, including code, infrastructure, security, dependencies, and team risk. It should also test AI-specific evidence: evaluation design, prompt and model configuration, privacy-aware traces, failure behavior, task-level economics, and rights to training or retrieval data. A demo and a few hand-picked outputs cannot establish performance across the intended workload. A versioned evaluation process, backed by representative cases and reproducible records, gives a reviewer evidence they can inspect.

This is an engineering checklist, not legal, investment, or assurance advice. Evidence requests vary by buyer, investor, sector, and transaction. We re-checked the regulatory and standards references on 2 September 2026.

Want an independent technical DD pass before your raise?

Book Free Consultation

Why evidence, not a demo

Benchmark results are workload-specific, but they show why a demo is insufficient. A preregistered Stanford study of more than 200 open-ended legal queries reported incorrect information in more than 17% of answers from Lexis+ AI and Ask Practical Law AI, and more than 34% from Westlaw AI-Assisted Research at the time tested. Those figures do not transfer to another domain or current product version. They do show that a purpose-built interface alone is not evidence of reliability. Reviewers need measurements on the product's own intended and foreseeable use, with uncertainty, failure examples, and limits documented. See the Stanford study summary and paper.

AI-specific checks to add

These checks extend the normal software review. Each item states what to inspect and a warning sign.

An evaluation set. A versioned sample of intended, edge, unanswerable, adversarial, and relevant subgroup cases, with reference labels or rubrics and a sampling rationale. Unit tests remain useful for deterministic properties; judged outputs also need calibrated scoring. Red flag: only curated examples and no coverage or uncertainty analysis.
Regression evaluation. Run the relevant suite on material prompt, retrieval, model, policy, or tool changes before release, then monitor production signals. The cadence and blocking rules should reflect consequence severity. Red flag: behavior changes ship without comparison to the approved baseline.
Privacy-aware observability. Record the minimum metadata needed to investigate quality, security, latency, and cost. Raw prompts and responses may contain personal, confidential, or privileged data, so justify, redact, restrict, and expire them. Red flag: either no traceability or unrestricted indefinite content logging.
Prompt, model, and configuration records. Version prompts, retrieval settings, policies, tools, and model identifiers. A provider may change behavior even when an identifier is stable, so retain evaluation results and release metadata rather than promising exact output reproduction. Red flag: no record of what configuration served an incident.
Failure handling. Define timeouts, bounded retries, degraded behavior, human escalation, and recovery objectives. A second provider is one option, not a universal requirement, and it brings its own cost and consistency risks. Red flag: an external dependency can fail without a tested user-visible path.
Task-level economics. Measure input, output, cache, tool, media, retry, and human-review costs per successful task, including the actual distribution of calls. Red flag: margin forecasts use a single ideal call or assume provider prices stay fixed.
Rights and lawful use of data. Keep provenance, licence or other legal basis, contractual restrictions, consent where relied upon, deletion duties, and permitted training or retrieval uses per source. Red flag: an unexplained scraped corpus or data whose origin cannot be traced.
Measured failure modes and controls. Report task-specific error categories, severity, and confidence intervals, then connect each material risk to retrieval, validation, refusal, escalation, or another tested control. Red flag: "RAG fixes hallucinations" or a single aggregate score without failure analysis.
Model choice and concentration risk. Document why the chosen model and hosting route meet quality, privacy, availability, jurisdiction, and cost requirements. Test portability where it matters instead of assuming an abstraction layer makes providers interchangeable. Red flag: no exit plan for a material provider or model change.

Evidence-room artifacts to prepare

The exact request list varies, but these artifacts let a reviewer test claims without relying on a founder's memory. Their presence does not guarantee financing or valuation.

Artifact	Why diligence cares	Red flag if missing
Architecture diagram (dated, names external dependencies)	Supports review of trust boundaries, scaling assumptions, concentration, and key-person risk	Material dependencies or ownership are unclear
Data-flow map and processing inventory	Shows what data each party receives, why, where, and for how long	Personal or confidential data flows cannot be explained
Evaluation reports (versioned harness, dataset, configuration, results)	Lets reviewers examine coverage, uncertainty, failures, and regression decisions	Only selected examples or an unexplained aggregate score
Model, prompt, retrieval, policy, and tool registry	Links a release or incident to its serving configuration	Production behavior cannot be attributed to a configuration
Runbook, service objectives, and incident response	Shows ownership, detection, escalation, recovery, and communication	Failure paths and accountable owners are untested
Current SBOM, licence review, and vulnerability process	Supports dependency, licence, and known-vulnerability review	Dependencies and remediation ownership are unknown
IP and data-rights chain	Shows employee, founder, contractor, open-source, model, and dataset rights under the applicable contracts and law	A core asset has no documented owner or permitted use
Risk-based security evidence	Could include threat modelling, secure-development records, test reports, and relevant independent assurance	Claims are not matched to the system's threats and controls

Data, privacy, and provenance

For EU deployments, map GDPR obligations to the actual processing and party roles. That can include records of processing where Article 30 requires them, a lawful basis, an Article 35 DPIA before processing likely to result in high risk to people's rights and freedoms, and Article 28 terms where a processor relationship exists. A model provider may be a controller, processor, or sub-processor depending on the facts and contracting chain. EDPB Opinion 28/2024 says anonymity of an AI model must be assessed case by case and is not presumed. Under the amended EU AI Act, Article 50 contains several role- and system-specific transparency duties, most applicable from 2 August 2026. Annex III high-risk rules apply from 2 December 2027, while Annex I product-embedded high-risk rules apply from 2 August 2028. Record the classification, role, duty, and date that actually apply.

Questions a reviewer can test

A reviewer may test whether the product depends on one model or provider, whether claimed differentiation is evidenced, whether gross-margin calculations include all inference and review costs, whether retention assumptions are measured, and whether evaluation results reflect production use. Transaction documents, retention arrangements, representations, and indemnities are deal-specific, so do not treat a generic checklist as a prediction of terms. The security and ownership issues in AI-assisted code are covered in our Lovable, Bolt, and Replit due diligence post; evaluation design is covered in when LLM evals are worth building.

"A demo shows one path. A governed evaluation process shows which workload you measured, how often it fails, and whether a release changed the result. That is evidence a reviewer can inspect."

Frequently Asked Questions

What is technical due diligence for an AI startup?

A scoped review of the code, infrastructure, security, dependencies, data flows, AI behavior, operating evidence, and team risks behind a product. AI-specific work can include evaluation design, serving-configuration records, task-level economics, failure controls, privacy, and data and model rights. It does not certify that the company will scale or is legally clean.

What might a reviewer check in an AI MVP?

The request depends on the transaction and sector. Common testable areas include provider concentration, evidence for claimed differentiation and quality, complete inference economics, privacy and security controls, measured retention, incident readiness, and rights to code, models, and data.

What evaluation evidence should I prepare?

A versioned, representative dataset and rubric; sampling rationale; results tied to the serving configuration; uncertainty and subgroup analysis; material failure examples; approval thresholds; regression history; and production-monitoring links. Human review can be part of the method, but undocumented spot checks are not reproducible evidence.

How is AI due diligence different from normal software due diligence?

It retains normal code, infrastructure, security, dependency, and team review. It also examines variable model behavior, evaluation coverage, prompt and serving configuration, task-level costs, external-model concentration, failure handling, privacy-aware traces, and rights and restrictions for training and retrieval data.

Do I need an SBOM for due diligence?

It is useful when software dependencies are material. Keep a current SBOM in a standard machine-readable format, validate it against the build, and pair it with licence and vulnerability processes. When the relevant Cyber Resilience Act provisions apply from 11 December 2027, products in scope must include an SBOM in technical documentation, in a commonly used machine-readable format covering at least top-level dependencies. The rule does not cover every AI MVP or transaction.

What is an IP and data-rights chain?

Evidence showing who owns or may use the code, datasets, models, media, and other assets under applicable law and contracts. EU software rules distinguish employee-created programs from other authorship situations, and contractor terms vary. Verify assignments or licences, open-source obligations, model terms, and dataset permissions with counsel rather than assuming an invoice settles ownership.

How does GDPR affect AI due diligence in the EU?

Map Article 30 records where required, lawful bases and Article 9 conditions where relevant, Article 35 DPIAs for processing likely to create high risk, data-subject rights, transfers, retention, security, and Article 28 processor terms. A model provider's role depends on the facts and contracts. EDPB Opinion 28/2024 requires case-by-case assessment before treating an AI model as anonymous.

Does the EU AI Act apply to my MVP yet?

It depends on the system and role. Prohibited-practice provisions apply, GPAI-provider obligations may apply, and Article 50 has several specific transparency duties, most applicable from 2 August 2026. Annex III high-risk rules apply from 2 December 2027 and Annex I product-embedded high-risk rules from 2 August 2028 under the amended Act.

Is Austrian technical due diligence different?

The technical method is similar, but applicable Austrian corporate, employment, IP, funding, tax, and regulatory facts still need local review. If public funding is involved, provide the relevant grant agreement, eligible-cost records, reporting, change-of-control, and repayment terms instead of assuming a standard covenant.

How do I show my AI product is more than a model wrapper?

Do not rely on the label. Show measured user outcomes, workflow and integration depth, permissioned or proprietary assets where they exist, operational know-how, retention evidence, tested portability, and unit economics under realistic usage and provider-price scenarios.

Final thoughts

Technical due diligence on an AI MVP is broader than a generic code review. The AI-specific layer should connect evaluation evidence, serving configurations, task-level economics, failure controls, privacy, and data and model rights to the claims being made.

Prepare the evidence before a review: govern the eval set, record releases, test failure paths, calculate costs from real traces, document rights, and keep the artifacts current. This does not make diligence a formality, but it makes claims testable and gaps visible while there is still time to address them.

Primary sources used in this diligence guide

This checklist draws on public AI-risk, secure-development, privacy, product-security, and EU-law references.