What changes in diligence when the target is an AI company?

What changes when the target is an AI company is that three questions ordinary technical diligence never asks become the questions the deal turns on: is the AI claim true, can a model-written codebase be maintained, and does the margin survive the model-provider invoices. The rest of the review, the architecture, the team, the security posture, the technical debt, is the same work as technical due diligence on any software company.

This page is the map. Each of the three changes gets a section here and a method page elsewhere in the AI startup due diligence guide.

Why is the AI claim now a legal question?

The AI claim became a legal question because regulators started enforcing it, and that changes what an investor is expected to have checked. Reveneau's diligence checklist puts the claim test ahead of the code review for exactly this reason: a claim that fails a live test changes the price of the deal more than anything an engineer finds in the repository.

The enforcement record is short and specific. On 18 March 2024 the SEC announced settled charges against two investment advisers, Delphia and Global Predictions, for making false and misleading statements about their use of artificial intelligence; Delphia paid $225,000 and Global Predictions $175,000, and the SEC's chair called the conduct "AI washing" [1]. On 25 September 2024 the FTC announced Operation AI Comply, five actions in one day against companies whose AI claims it said were deceptive, among them DoNotPay, which settled for $193,000 over its "AI lawyer" claims [2]. On 11 April 2025 the SEC filed charges against the former chief executive of Nate, Inc., a shopping app that had raised over $42 million on the claim that it used AI to complete purchases; the SEC alleged the company relied in large part on contract employees entering orders by hand [3].

Each case has the same shape. A statement about what the AI does, made to customers or investors, that a test would have contradicted. That is why the method on how to verify an AI claim with a test is built around a live input the team has never seen: it is the cheapest way to find out whether the claim survives contact with reality before the price is set.

There is a second consequence. When an investor's portfolio company is charged with AI washing, the investor's process is the next thing examined. A diligence file that shows a claim table with a test result against every line is a different document from one that shows a deck and a demo recording.

What does a model-written codebase change about the engineering read?

A model-written codebase changes which signals carry information. The engineering read still asks whether the code is well built and whether the team can keep building it; what changes is that the cheap signals a reviewer used to rely on are now cheap to fake, and the expensive signals are the only ones left.

Stack Overflow's 2025 survey of 33,662 developers found 84 percent using or planning to use AI tools in their work, and found that 66 percent named solutions that are "almost right" as their biggest frustration with those tools [4]. That phrase describes the maintenance profile of a generated codebase. It runs. It passes the path the developer tried. The errors sit in the branches nobody read.

So the questions change. Commit history no longer tells you how many people understand the code, because one person driving a coding agent can produce the commit volume of a team. Style consistency no longer tells you about discipline, because the model is consistent by default. Test count no longer tells you about coverage of the specification, because a model will write tests that pass against the code it just wrote.

What still carries information is the eval suite, the checks written from the specification that a change must pass before it ships, together with the last failing run and what was done about it. Eval-driven development explains what a suite is; the eval suite as a diligence artefact explains how to read one in a deal. The other things that carry information are the scanner output, because Veracode's July 2025 test of over 100 models found 45 percent of generated samples failed security checks [5], and the provenance record, because a codebase that cannot say which tool wrote which file cannot answer the licence question either. Diligence on an AI-written codebase covers what to ask for.

Why is the margin a different shape?

The margin is a different shape because inference is a cost of goods that arrives as a monthly bill from a supplier, scales with usage rather than with headcount, and can be repriced by the supplier without notice. Software gross margin used to be a hosting bill that fell as a share of revenue as the company grew. An AI product's cost of goods can grow faster than its revenue if customers use the product more than the pricing assumed.

The benchmarks show how wide the spread is. Bessemer's State of AI 2025, published on 13 August 2025, describes two kinds of fast-growing AI company: "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 on a slower curve at 60 percent [6]. ICONIQ's July 2026 survey of over 300 software executives reports an average gross margin of 45 percent for 2025 and projections of 53 percent for 2026 and 59 percent for 2027 [7]. The projections are hopes and the 2025 figure is a survey average.

The target's number comes from three documents: the model-provider invoices, the usage logs that explain them, and the revenue by customer for the same months. Rebuilding inference gross margin from invoices is the worked method. The reason it has to be per customer is that a blended figure hides the contracts where usage costs more than the customer pays, and those are the contracts that decide whether the plan works.

The supplier side has its own risk. Menlo Ventures' December 2025 survey of enterprise buyers put Anthropic at 40 percent of enterprise LLM API spend, OpenAI at 27 percent and Google at 21 percent [8], which says the buyers of AI are already spreading their exposure. A startup built on one model and one price list is more concentrated than its own customers. Model dependency risk covers what a swap, a retirement or a price change does to the plan.

What stays the same?

Everything else stays the same, and it is most of the work. The architecture review, the team assessment, the security posture, the technical debt inventory, the data room, the report structure: the pages of the technical due diligence guide cover all of it, and none of it is optional because the target says "AI" in the deck.

Two things are worth naming because AI targets tempt reviewers to skip them. The first is the cloud bill outside inference: an AI product still runs on compute, storage and networking, and cloud cost due diligence applies unchanged. The second is the gap between reported metrics and engineering reality, which SaaS metrics versus engineering reality covers; on an AI target, the version of that gap is a usage metric that counts model calls the customer never asked for.

What the change does to the engagement plan

The three changes add work on top of the general review. The table below shows where.

Review area	Ordinary software target	AI target adds
Product claim	Feature walkthrough in the demo	A claim table, a live test on a held-out input, a trace read
Code quality	Repository read, commit history, test coverage	Eval suite review, failing runs, scanner output, provenance record
Licences	Open-source scan	Generator tool terms, reproduced-code check, copyright status of generated files
Security	Scanner and pen-test review	Same scan, plus the model-specific risks in the OWASP list for LLM applications
Cost of goods	Hosting bill as a share of revenue	Per-customer margin rebuilt from model-provider invoices and usage logs
Vendor risk	Cloud provider concentration	Model provider concentration, retirement schedule, price-list exposure
Moat	Product, distribution, switching cost	Data curve: quality against data volume, and cost of equivalent data

Each addition is a day or two of senior engineering time given access to the artefacts. The failure mode is planning the engagement as an ordinary review and discovering in the last week that nobody asked for the invoices.

How to start

Start with the claim table. Read the deck, the website and the data room and write down every sentence that says what the AI does. Each line gets a test and, later, a result: confirmed, contradicted or untested. The claim table is what the investment committee should see, because the count of untested claims is itself a finding.

Then ask for the artefacts before the management meeting: the eval suite and its last ten runs, the model-provider invoices for twelve months with the usage logs, the list of models and versions in production, the code-generation tools in use and their terms, and the most recent security scan. A company that has these sends them in a day. A company that does not have them has told you something. Questions for the management meeting is the list to take into the room once the artefacts have been read.

If the target is at pre-seed, most of this is out of proportion to the cheque, and the question is narrower: what does "we use AI" mean at all? What "we use AI" should mean at pre-seed answers that one, and AI startup diligence red flags by stage says which of the checks on this page matters most at which stage.