AI startup due diligence: how investors check what is real

AI startup due diligence is the process of checking that an AI company's product does what the pitch says it does, that the code behind it can be maintained and transferred, and that the business still makes money after the model-provider invoices are paid.

That is the whole job. It is the same job as technical due diligence on any software company, plus three things that only exist when the target is an AI company. This guide is about those three things. It is written for the people who have to sign off on the deal: associates and principals at venture funds, deal teams at private equity firms, and angels writing cheques into AI rounds. Founders who are about to face one of those people will find it useful for the same reason.

What this guide is and who it is for

Ordinary technical diligence asks whether the software is well built and whether the team can keep building it. AI diligence has to ask three more questions, and each one needs a different method.

Does the AI do what the company says it does? This is the claim question. It is the one regulators have started enforcing, and it is the one where a demo tells you least, because the demo was chosen by the team.

Can the code be maintained and sold? This is the engineering question. It changes when most of the code was written by a model, because the usual signals (commit history, code style, who wrote what) mean something different, and because the checks that keep the code honest are evals rather than reviews.

Does the margin survive? This is the money question. Inference is a variable cost of goods that arrives as a monthly bill from OpenAI, Anthropic, Google or a cloud provider, and it moves with usage, model choice and the vendor's price list. Revenue can look like software while cost of goods looks like a utility.

Reveneau runs AI startup due diligence for investors, and the first artefact we ask a target for is its eval suite with one failing run attached, because a company that measures its own quality can show you the measurement and a company that asserts it cannot. Everything else on these pages follows from that habit: ask for the thing that can be checked, and treat everything that cannot be checked as a claim.

The short version

If you read nothing else, this is the method.

• Turn every AI claim into a test you can watch. A held-out input, processed live, with the trace visible. A demo is evidence of what the team chose to show.
• Ask for the eval suite, the pass gate, and a failing run. If there is no suite, quality is being asserted. If there is no failing run, the suite is not being used.
• Ask what the product is without the model. If the answer is "a prompt and a user interface", price the deal as a distribution business, because the model provider can ship the same thing.
• Rebuild gross margin from the model-provider invoices and the usage logs, per customer and per month. Do not accept a blended figure from the deck.
• Ask which model, which version, which price, and what happens on the day it is retired. Both major providers publish retirement schedules and both have retired models in the last twelve months.
• Ask for the code provenance: which tools generated code, which licence terms applied to their output, and whether the company can show what was human-written.
• Run the security scanners yourself. Veracode's July 2025 test of over 100 models found 45 percent of generated code samples failed security checks, so assume AI-written code carries that rate until scanned.
• For a data moat, ask for the curve: model quality against training-data volume. A flat curve is a data asset without a moat.

Why the target being an AI company changes the work

The reason to treat AI targets differently is that the claim itself has become the object of enforcement. In March 2024 the SEC settled with two investment advisers, Delphia and Global Predictions, over statements about their use of AI that the SEC found to be false; the penalties were $225,000 and $175,000, and the SEC's chair described the conduct as "AI washing" [1]. In September 2024 the FTC announced Operation AI Comply, five enforcement actions against companies whose AI claims it said were deceptive, including DoNotPay, which settled for $193,000 over its "AI lawyer" claims [2]. In April 2025 the SEC charged the former chief executive of Nate, Inc., a shopping app that had raised over $42 million on the claim that it completed purchases with AI, when according to the SEC's complaint it relied in large part on contract employees entering orders by hand [3].

Those cases are the stakes for an investor, in two ways. The first is direct: if the claim is false, the company's value is different from what the price assumes. The second is that the investor's own process is now visible. A fund that wrote a cheque on a demo and a deck, into a company later charged with AI washing, will be asked what it checked.

The other thing that changed is the code. A large share of new startup codebases are now written mostly by models. Stack Overflow's 2025 survey of 33,662 developers found 84 percent using or planning to use AI tools, and found that 66 percent named solutions that are "almost right" as their main frustration [4]. That is the maintenance profile an investor is buying: code that runs, passes the happy path, and hides its errors in the places nobody read. The page on diligence on an AI-written codebase is about how to find them.

How it works, step by step

An AI diligence engagement runs inside the general technical diligence timeline described in how to run technical due diligence. The AI-specific work adds these steps.

1. Write down every AI claim in the deck, the website and the data room. Each one becomes a line in a table with three columns: the claim, the test that would confirm it, and the evidence received. "Our AI reads the contract and extracts the obligations" is a claim. "Processes a contract we supply, live, and we compare the output to a lawyer's read" is the test.
2. Ask for the artefacts before the meeting. The eval suite and its last ten runs. The model-provider invoices for twelve months. The usage logs that go with them. The list of models and versions in production. The code-generation tools in use and their terms. A security scan from the last quarter, or permission to run one.
3. Run the claim test in a screen share. Supply the input yourself. Watch the trace. Ask to see the prompt, the retrieval, the tool calls and the model response separately. How to verify an AI claim with a test is the protocol.
4. Classify the product. Feature, wrapper or something in between. AI feature or AI wrapper gives a decision test that takes an hour.
5. Read the eval suite. What it covers, what it does not, what the pass gate is, and what happened the last time it failed. The eval suite as a diligence artefact walks through it.
6. Rebuild the margin. Invoices against revenue, per customer, per month, and per model. Rebuilding inference gross margin from invoices is the worked method.
7. Stress the model dependency. What breaks on a model retirement, a price rise, a rate limit, or a provider shipping the feature. Model dependency risk covers each.
8. Write the findings against the claim table. Every claim gets one of three results: confirmed by test, contradicted by test, or untested. Untested is a finding, and the investment committee should see how many there are.

What to check: the engineering read

The engineering read on an AI company has four parts, and this guide gives each one a page.

The codebase itself. Most of the general questions in assessing code quality still apply. What changes is what the signals mean. A repository where one account authored 90 percent of the commits used to indicate a single-developer risk; on an AI-written codebase it may indicate one person driving a coding agent, and the risk is different. Diligence on an AI-written codebase covers what to ask for and what a good answer looks like.

The evals. An eval suite is a set of checks, written from the specification, that the product must pass before a change ships. Eval-driven development explains what one is. For diligence, the suite matters because it is the only artefact that can show whether quality is measured. Anthropic's own guidance to developers is to "prioritize volume over quality" in test cases and to automate grading where possible [5]; a suite that follows that advice has hundreds of cases and a machine-readable pass rate, and both are checkable.

Provenance and licence. AI-generated code raises two questions the general open-source licence diligence does not: whether purely generated code is protectable at all, and whether the generator reproduced licensed code. The US Copyright Office concluded in January 2025 that copyright does not extend to purely AI-generated material and that prompts alone do not provide sufficient control for authorship [6]. Code provenance and licence exposure sets out what that means for a company whose codebase was mostly generated.

Security. Veracode tested over 100 models on coding tasks in four languages in July 2025 and found 45 percent of samples failed security tests; the Java rate was 72 percent, and cross-site scripting defences failed in 86 percent of relevant samples [7]. Those figures are the reason to scan the code rather than read it. Security of AI-written code in diligence lists what to run.

What to check: the money read

The money read has three pages, and the first is the one most deal teams skip.

Inference gross margin. Bessemer's State of AI 2025, published in August 2025, split the fastest-growing AI companies into two groups: "Supernovas" reaching $40 million of year-one revenue at a gross margin Bessemer gives as 25 percent and describes as often negative, and "Shooting Stars" growing more slowly at 60 percent [8]. ICONIQ's July 2026 survey of over 300 software executives reports an average gross margin of 45 percent for 2025, with respondents projecting 53 percent for 2026 and 59 percent for 2027 [9]. Those projections are what the companies hope will happen. The invoices are what has happened. The method on rebuilding inference gross margin uses only the invoices.

Model dependency. Enterprises are already spreading their spend: Menlo Ventures' December 2025 survey put Anthropic at 40 percent of enterprise LLM API spend, OpenAI at 27 percent and Google at 21 percent [10], and a16z's June 2025 survey of 100 CIOs found 37 percent running five or more models in production, up from 29 percent the year before [11]. A startup built on one model is more exposed than its customers are. Model dependency risk works through what a swap or a price change does to the plan.

Data moats. Casado and Lauten's 2019 analysis at a16z argued that "there generally isn't an inherent network effect that comes from merely having more data," that the value of the next unit of data falls while the cost of acquiring it rises, and that a "minimum viable corpus" is enough to start training against and gives no lasting defence [12]. Seven years later, with foundation models trained on most of the public internet, the argument is stronger. Data moat claims gives the tests.

Common mistakes

Treating the demo as the test. A demo is a claim with a user interface. The team chose the inputs, the model, the prompt and the moment. The fix is to supply the input yourself and to watch the trace, which is the whole of the protocol on the claim page.

Accepting blended gross margin. A single company-wide gross margin hides the customers whose usage costs more than they pay. Per-customer margin from the invoices and the usage logs is the only figure that tells you which contracts are subsidised.

Reading AI-written code the way you would read human code. The signals differ. Commit volume, style consistency and comment density are all cheap to produce with a model and tell you nothing. The eval suite, the scanner output and the failing runs are what carry information.

Asking "is there a moat?" instead of "what is the curve?" Every AI company says it has proprietary data. The question that produces a usable answer is how much better the product gets per unit of additional data, and what the same data would cost a competitor.

Forgetting the retirement schedule. Anthropic retired Claude Sonnet 4 and Claude Opus 4 on 15 June 2026 with notice given on 14 April 2026 [13]. A company that pinned a model version and never planned the migration has an unplanned engineering project in its next quarter.

Assuming the AI project will land. RAND's 2024 report, based on interviews with 65 experienced data scientists and engineers, opens with the observation that "by some estimates, more than 80 percent of AI projects fail" [14]. RAND is careful to label that as an estimate, and so should you be, but the direction is clear: the base rate for an AI initiative reaching production is low, and a target's pipeline of "AI features in development" should be discounted accordingly.

What it costs and how long it takes

There is no measured market price for AI-specific diligence. The general technical diligence market gives a range, and every figure below is a vendor's own statement about its own pricing, not a survey.

mev.com states that its technology due diligence services "typically range from $5,000 to $30,000" and gives 2 to 4 weeks as the usual duration [15]. papermark.com's price comparison table gives specialist technology firms at $35,000 to $95,000 per engagement and Big Four technology advisory at $50,000 to $150,000 [16]. Those two sources disagree by a factor of three at the low end, which tells you the market has no standard scope.

The AI-specific work in this guide adds to whichever scope you buy: a claim test, an eval review, a provenance check, a security scan, and a margin rebuild. Each is a day or two of a senior engineer's time given the right access. What technical due diligence costs has the general picture, and technical due diligence scope by stage covers how much of it a seed deal can carry. For AI targets specifically, AI startup diligence red flags by stage says which of these checks matters most at which cheque size.

The management meeting

Everything above produces questions. Questions for the management meeting of an AI startup is the full list, grouped by topic, with what a good answer sounds like after each one. It is deliberately ungated and printable. The question that matters most on it is the simplest: "Show me the last eval run that failed, and what you did about it." A team that can answer it has a quality process. A team that cannot has a hope.

Where this connects to the rest of our work

We build software with AI and hold it to an eval suite written from the specification, so the diligence we run on other people's AI code asks for the same artefacts we produce ourselves: the spec, the suite, the pass gate, the failing runs and the invoices. If the target cannot produce them, we can say what building them would take, which is usually the first line of the post-close plan.

If you want this run for you on a live deal, technical diligence for VC and private equity describes the engagement. If the target is a company you already own, AI adoption in portfolio companies is the page for the year after the cheque. And if you are the founder reading this before a raise, preparing an AI-written codebase for review is the other side of the same checklist.