AI Due Diligence in M&A: How to Test What the Target Actually Built

AI due diligence is the workstream that tests whether a target's AI claims survive contact with its codebase, its contracts, and its P&L. It answers four questions a standard tech diligence pass does not: whether the AI is proprietary capability or a thin wrapper on someone else's model, whether the company has the legal rights to the data its models depend on, whether the unit economics of inference hold at scale, and what regulatory exposure the AI creates in the markets the buyer cares about. In 2026 this is no longer a specialty add-on. Nearly every software target claims AI in its deck, valuations carry an AI premium, and the premium is exactly what a buyer overpays when the claims are thinner than the diligence.

The wrapper question comes first

Start with the question that moves price the most: what did this company actually build? There is nothing wrong with a product built on OpenAI or Anthropic APIs. Most good AI products are. The problem is a valuation that prices API orchestration as if it were proprietary research. The way to tell the difference is in the repository and the architecture review, not the pitch deck. Look for what would survive if the underlying model vendor changed: evaluation harnesses, fine-tuned or distilled models the company owns, retrieval infrastructure over proprietary data, feedback loops that improve the product with usage, and prompt and routing layers under real version control. A target whose "AI moat" is a system prompt has a feature, and features get rebuilt by competitors in a quarter.

Ask the engineering team to walk through what happens when the primary model provider deprecates the version they depend on. Teams with real capability have a tested answer and a routing layer. Teams without one have downtime and a rewrite, and that risk belongs in the model, priced.

Data rights decide whether the asset is transferable

The most expensive findings in AI diligence are usually legal, not technical. Models are only as defensible as the rights to the data that trained them and the data they process at inference time. Three places to dig. Customer contracts: do they permit the target to train on customer data, and does that permission survive a change of control? A surprising number of enterprise MSAs say no, or say nothing, which in practice means no. Training data provenance: if models were trained on scraped or licensed third-party data, the licenses need to transfer, and indemnities need to be understood. Personal data: if personal information flowed into training sets, GDPR and the state privacy laws create deletion and consent questions that are hard to remediate after close, because you cannot easily delete a person from model weights.

Get the data flow diagram for every model in production and trace each input back to a contract that authorizes the use. Where the paper trail breaks, quantify the exposure and put it in the purchase agreement as a rep, an indemnity, or a price adjustment.

Inference economics are a gross margin question

AI products carry a cost of goods that traditional software does not: every user action that touches a model burns compute. Diligence should produce a real number for inference cost per customer per month, its trend, and its sensitivity to growth. The failure pattern is a target whose gross margin looks like 80 percent because model spend is buried in R&D or because a vendor's startup credits have not yet run out. Pull the cloud and model-provider invoices for the trailing twelve months, allocate them to the features that generate them, and rebuild gross margin with inference in COGS. If margin drops fifteen points under honest allocation, the revenue multiple should not survive unchanged.

The counterweight is real too: inference prices per token have fallen steadily, and a team with a routing layer that sends easy tasks to cheap models can improve margin every quarter. That capability is worth diligencing as an asset, because it separates operators from teams that will ride one expensive model into margin trouble.

Regulatory exposure and the compliance file

The regulatory perimeter around AI hardened while deal teams were watching interest rates. The EU AI Act's obligations are phasing in, with the general-purpose model provisions in force since August 2025 and the high-risk system obligations arriving on their own schedule. Colorado, Texas, Utah, and California all have AI statutes with different reach. If the target sells into hiring, lending, insurance, healthcare, or education, ask which of its systems meet a high-risk definition somewhere its customers operate, and what documentation exists: model inventories, impact assessments, evaluation records, human-oversight design. A target with governance artifacts is cheaper to integrate and cheaper to insure. A target without them hands the buyer a remediation program with a deadline attached, and that program has a cost you can estimate and deduct.

What the diligence actually reviews

A competent AI diligence pass typically covers the following, in roughly this order of price impact:

• Architecture and code review of the AI stack: what is owned, what is rented, and what breaks on vendor change
• Data rights tracing from every production model back to authorizing contracts, including change-of-control survival
• Rebuilt gross margin with inference costs allocated to COGS, with sensitivity to growth and model pricing
• Evaluation evidence: does the company measure model quality, and do the metrics support the product claims
• Team and key-person risk: who actually built the AI capability, and what walks out the door at close
• Regulatory mapping against the EU AI Act, US state statutes, and sector rules, with the remediation bill estimated
• Security review of the AI surface, including prompt injection paths and data leakage through model outputs

Each of these produces either comfort or a number, and the numbers belong in the model, the reps, or the integration plan. The red flags that matter in technology diligence generally apply here, with one addition specific to AI: demo-to-production distance. Ask how many of the AI features in the sales deck are in general availability, with usage data, versus in pilot with three design partners. The gap between those two lists is the gap between the story and the asset.

Evaluating the team and the evidence culture

AI capability concentrates in fewer heads than traditional software capability. In a 200-person target, the people who can actually retrain the model, rebuild the retrieval pipeline, or explain why the evaluation numbers moved often number three or four, and their equity treatment at close determines whether the buyer receives an asset or a repository nobody can operate. Diligence should name them, map what each one uniquely knows, and feed that map straight into retention planning. Then test the evidence culture around them: ask for the evaluation dashboard, the incident log for model regressions, and the last three decisions the team made because a metric moved. Teams with real capability answer from systems they already run. Teams performing capability answer with a slide built for the data room, and the difference is visible within an hour of technical sessions.

Timing matters too. This work belongs in confirmatory diligence at the latest, and the strongest buyers push the wrapper and data-rights questions into the LOI stage, because both are cheap to ask early and expensive to discover late. A data-rights defect found before exclusivity shapes price. The same defect found in week five of confirmatory diligence shapes nothing except the buyer's mood, because deal momentum by then has a constituency.

Using AI to run diligence, carefully

The second meaning of AI due diligence is using models to do the work: summarizing contract populations, extracting change-of-control clauses, flagging anomalies in the data room. Used well, this compresses weeks of associate reading into days and lets the humans spend their time on judgment calls. Two rules keep it defensible. Every material finding gets verified against the source document by a person whose name goes on the report, and no target data leaves the diligence environment for a model endpoint the engagement has not approved. A diligence provider should be able to tell you exactly which models touch your data room and under what terms. If they cannot, that is diligence data leaking into someone else's training set, and it is your deal doing the leaking.

Where this fits in the deal

AI diligence is not a standalone report for most deals. It runs as a module inside technology and commercial diligence, feeding the same model and the same negotiation. The software due diligence checklist still applies to an AI-heavy target: architecture, scalability, security, and team all still decide integration cost. The AI module adds the wrapper analysis, the data rights tracing, the inference economics, and the regulatory map. For buyers comparing providers who can do this credibly, we published a field guide to the best technical due diligence firms, with our own inclusion disclosed.

BD Emerson runs AI due diligence as part of our commercial, operational, and technology due diligence practice, for private equity funds, strategic acquirers, and lenders. Our teams have implemented the platforms these targets are built on, which is why our findings come with remediation costs attached rather than adjectives. If there is an AI story in your next deal, we can tell you what it is worth before you pay for it.