Ask the seller to reproduce the AI result that matters most to the deal.
Same source record. Same product version. Fresh run. Keep the trace.
If the result cannot be reproduced, the buyer may be looking at a demonstration rather than an asset. If it can, the trace becomes a receipt: it shows which data, model, instructions, tools, people and vendors created the outcome. AI due diligence follows that receipt until the buyer knows what will transfer and what will disappear when the deal closes.
Name the asset before grading it
“Our AI” can refer to very different property. Separate the pieces.
| Asset candidate | Evidence that it exists |
|---|---|
| Proprietary data | Dataset inventory, provenance, rights, version and quality record |
| Evaluation system | Representative cases, acceptance rules, runner, results and failure history |
| Model or adaptation | Training method, weights or provider record, version and reproducible test |
| Retrieval layer | Corpus, access filter, indexing process, citations and freshness operation |
| Agent application | Instructions, tools, permissions, state, approvals, logs and fallback |
| Product workflow | User path, business rule, integration, outcome and support process |
| Operating know-how | Named people, runbooks, incident evidence and change practice |
A target may have several of these. It may also have only a product workflow built on a third-party model. That can still warrant the price. The mistake is pricing every layer as proprietary without evidence.
Write a transfer statement for each candidate: what the buyer receives, which right permits continued use, which outside dependency remains and which person knows how to operate it.
Replay one material outcome
Pick a case tied to revenue, retention, labor, risk or another deal assumption. Avoid the seller’s cleanest demo. Use an ordinary production case plus a case that previously failed.
Preserve the run as a sequence:
- Source input and permission context.
- Data preparation or retrieval.
- Model and instruction version.
- Tool calls and outside services.
- Human review or approval.
- Final product action.
- User or business outcome.
- Cost and latency record.
Now change one material condition. Remove a source, supply conflicting evidence, deny a tool, cross a usage limit or substitute the documented fallback model. The changed run tells the buyer more than a second happy example.
The trace should be exportable without the seller’s private observability account. If the buyer cannot retain the evidence, post-close learning starts at zero.
Prove the data can travel with the deal
Data volume is not a moat when the target cannot show where the data came from or how it may be used.
For every dataset used to train, tune, retrieve, evaluate or monitor the material outcome, record:
- source and collection method
- owner and applicable contract or permission
- allowed purposes and transfer conditions for counsel to assess
- personal, confidential or restricted fields
- transformations, labeling and quality decisions
- retention, deletion and correction path
- downstream copies and derived artifacts
- person accountable for the record
Keep technical findings separate from legal conclusions. The review can show that a training set contains customer support conversations and that its source agreement is missing from the data room. Counsel decides what rights transfer and what remedy the transaction needs.
The OECD Due Diligence Guidance for Responsible AI frames due diligence as an ongoing process for identifying and addressing impacts in AI development and use. It is not an M&A valuation standard. Its evidence habit is still useful: trace impacts and responsibilities through business relationships instead of treating the model as an isolated object.
Rebuild the quality claim from cases
An accuracy number without its cases, sampling method, version and acceptance rule is decoration.
Request the evaluation inventory. For each set, capture who assembled it, which product population it represents, when it was frozen, how labels were decided, which cases were excluded and what action a failure can cause.
Inspect results by consequence. A document classifier that confuses two harmless internal categories has a different failure than one that routes a payment, denies a request or sends customer communication. Aggregate scores can hide the second case inside thousands of easy examples.
Ask for four views:
| View | Diligence question |
|---|---|
| Current release | Does the shipped version meet its own acceptance rules? |
| Prior releases | Is quality stable, improving or drifting under the same cases? |
| Hard-case slices | Which users, inputs or actions carry concentrated failure? |
| Production review | Do observed failures resemble the evaluation set? |
Re-run a sample from the buyer’s environment where practical. Preserve raw outputs and final actions. A target should be able to explain a mismatch without quietly changing the test.
Price the workload, including failed work
AI unit economics are workload economics. The model price is only one input.
Reconstruct a month from metered records. Separate input and output usage, retrieval, repeated model calls, tool calls, retries, failed runs, human review, storage, observability and reserved infrastructure. Tie the total to completed business outcomes, not API requests.
Use at least three cohorts: ordinary usage, a heavy customer or workflow, and a failure-heavy slice. Model growth through the variables that actually scale, such as documents processed, conversations, agent steps, context length, concurrent users or reviewed exceptions.
Then run sensitivity cases:
- the provider changes price or removes the preferred model
- context or agent steps grow with customer complexity
- quality controls increase human review
- a major customer needs a separate region or deployment
- rate limits force additional capacity or queuing
Do not invent precision. Give ranges, assumptions and the point at which the gross-margin or capacity claim stops working.
Inspect authority outside the model
An agent can produce harmless text or change a customer record. The diligence scope should follow the action.
For each tool, API and data store, record the identity used, allowed actions, target objects, policy check, approval point, idempotency rule, timeout, retry, log and reversal path. Deny a forbidden action in a controlled environment and inspect the target system afterward.
NIST’s AI Risk Management Framework is a voluntary framework organized around govern, map, measure and manage functions. Use those functions to check whether risk work exists across the product lifecycle. Do not turn a framework reference into a claim that the target is compliant or safe.
Prompt refusals are not access control. The application should constrain credentials and actions even when the model output is wrong or hostile content reaches its context.
Test provider and model exit
The architecture slide may say “multi-model.” Look for a completed substitution test.
Record the current provider, model, version policy, contract, data handling terms, region, quota, safety settings, latency, cost unit and feature dependencies. Then list what a replacement would need to reproduce.
Run representative evaluation cases on the proposed fallback. Exercise tool calling, structured output, retrieval, safety behavior and context limits used by the product. Record code changes and quality differences.
A replacement that handles a chat prompt but breaks the product’s JSON contract is not a fallback. Neither is a model that passes easy cases while doubling human review.
The result can be a portability range rather than a pass. The buyer needs to know whether exit is an afternoon configuration change, a month of revalidation or a product redesign.
Find the human dependencies
Ask the operator who is not the principal model engineer to deploy a small change, run the evaluation suite, diagnose a bad production result and switch to the approved fallback.
Watch where the handoff stops. The missing detail may live in a notebook, a prompt-management account, a personal cloud project or someone’s memory of why an evaluation case was excluded.
Create a knowledge transfer record for each load-bearing role: responsibility, system access, recurring decisions, emergency action, substitute, documentation and transfer test. Retention plans should follow observed concentration, not job titles.
Connect AI evidence to ordinary product value
An impressive model capability can still be a weak acquisition asset when users do not depend on it, the workflow cannot integrate, or the buyer already owns an equivalent service.
Trace adoption beyond feature activation. Which users return? Which product action follows the output? What manual work remains? Which customer contract or renewal depends on the result? How does the AI path interact with the rest of the product?
Compare the target capability with the buyer’s existing systems and data rights. The decision may be preserve, integrate, replace or retire. “Strategic AI” is not a fifth disposition.
Issue an asset receipt
Give each claimed AI asset a one-page receipt:
| Receipt field | Required entry |
|---|---|
| Claimed asset | Data, evaluation, model, application, workflow or know-how |
| Observed evidence | Trace, dataset, test, contract, operating record and date |
| Buyer receives | Code, rights, accounts, artifacts, people and documentation |
| External dependency | Provider, license, data source, person or platform |
| Quality and cost boundary | Tested cases, workload and assumptions |
| Control boundary | Permissions, approval, monitoring, failure and recovery |
| Confidence | What was reproduced and what remained inaccessible |
| Transaction action | Condition, term input, first 100-day task, monitor or reject |
Keep ordinary software findings in the broader technical review. This receipt exists because AI introduces a separate question: is the value in a transferable asset, a repeatable operating system or a demo that depends on access the buyer will not inherit?
Our technical due diligence guide covers the wider product, engineering and transaction review. AI due diligence is the specialist layer underneath an AI claim. It follows the result until the buyer can reproduce it, operate it and explain what remains outside the deal.