Before You Acquire an AI System, Demand an Evidence and Exit Dossier

An AI product can look impressive in a controlled demonstration and still be a poor acquisition. The interface may hide manual work, the benchmark may not match production, the model may depend on a supplier that can change terms, and the company may not own the data or code needed to operate after closing. A buyer who verifies only the demo and headline accuracy is not performing technical due diligence. They are reviewing a presentation.

The central acquisition question is not “Does the AI work?” It is: under what inputs, dependencies, controls, costs, rights, and operating conditions does the system produce an acceptable outcome—and can the buyer preserve or replace those conditions after the transaction?

This guide adapts the original AI system due-diligence framework, which emphasizes scope, data flows, performance evidence, critical dependencies, operating governance, conditions, and cross-functional interviews. Here we turn those ideas into an evidence and exit dossier: a package that supports a buy, conditional buy, price adjustment, remediation holdback, pilot, licensing decision, or refusal.

The method applies to acquisitions, strategic investments, major vendor commitments, and purchases of an AI-enabled product line. It is not legal, accounting, cybersecurity, or investment advice. Qualified specialists must assess the applicable transaction and jurisdiction.

The decision in one page

Do not approve an AI acquisition because a model appears accurate, proprietary, or fast. Approve only when the buyer can connect claimed value to reproducible evidence, map every material dependency, quantify the cost of operating at the required service level, establish rights to use and improve the system, and execute a credible transition or exit.

Decision	Evidence state	Typical condition
Proceed	Claims reproduced; rights and dependencies verified; operating plan funded	Standard closing and integration controls
Proceed conditionally	Value is plausible but bounded gaps remain	Holdback, covenant, remediation milestone, or limited scope
Pilot before commitment	Production behavior or integration remains uncertain	Time-boxed acceptance test with stop criteria
Reprice	Economics change after real inference, labor, data, or supplier costs	Revised valuation or commercial terms
License instead of buy	Value sits mainly in replaceable access, not transferable assets	Contract with service, portability, and exit protections
Stop	Material claim cannot be reproduced, rights are unclear, or dependency is unacceptable	No transaction until independently resolved

“Proceed conditionally” must name an owner, deadline, acceptance test, remedy, and consequence. A vague promise to “improve governance after closing” transfers uncertainty to the buyer without changing the price or control.

Define what is actually being acquired

The phrase “AI system” is too broad for diligence. Draw the product boundary before requesting documents. The asset may contain:

• proprietary application code;
• prompts, routing, guardrails, retrieval logic, and evaluation assets;
• fine-tuned or trained model weights;
• third-party foundation models accessed by API;
• open-source models and libraries;
• licensed training, reference, or enrichment data;
• customer-provided data and feedback;
• annotation processes and contractors;
• cloud, vector database, monitoring, and security services;
• human review or fulfillment hidden behind the interface;
• operating procedures, customer support, and exception handling;
• trademarks, domains, contracts, and distribution relationships.

For each component, mark whether it is owned, licensed, customer-controlled, open source, vendor-hosted, employee-created, contractor-created, or operationally undocumented. Then mark whether it is transferable, replaceable, exportable, and necessary for the revenue claim.

A company may “own the AI product” while relying on a non-transferable API account, data licensed for a narrower purpose, or key prompts stored in an employee’s private workspace. The product still functions before closing, but the buyer may not be acquiring the conditions that make it function.

Start with the investment thesis, then try to break it

Every evidence request should test a value thesis. Typical theses include:

• the system reduces labor per completed case;
• the system improves conversion or retention;
• proprietary data creates durable differentiation;
• the technology can expand into new markets;
• the product can operate at higher volume with acceptable margins;
• the team has a repeatable improvement loop;
• the buyer can integrate the capability faster than building it.

Rewrite each thesis as a falsifiable claim. “The platform automates support” becomes “for the defined ticket population, the system resolves an accepted outcome without human intervention in a stated proportion of cases, while meeting response time, quality, safety, and cost thresholds.”

Then identify disconfirming evidence. What would show that the claim is wrong? Hidden human work, excluded hard cases, delayed escalations, excessive refunds, high reviewer time, expensive inference, customer churn, weak security, or a vendor subsidy can all create a convincing top-line metric while destroying the thesis.

The diligence team should reward evidence that narrows claims. A seller that knows where the product fails may be more operationally mature than one that claims universal performance.

Assemble the evidence and exit dossier

The dossier should be versioned, access controlled, and linked to the exact transaction scope. It contains twelve sections:

1. system boundary and architecture;
2. asset, owner, and license register;
3. data provenance and permitted-use register;
4. performance claims and reproduction package;
5. security and abuse case assessment;
6. operating metrics and incident history;
7. unit economics and capacity model;
8. supplier and open-source dependency map;
9. customer commitments and regulated-use map;
10. organization, key-person, and process dependency map;
11. integration and transition plan;
12. exit, replacement, and failure-containment plan.

Do not accept screenshots where exports or raw evidence can be provided safely. A dashboard image omits definitions, filters, excluded cases, and time zones. Request data dictionaries, calculation logic, sample sizes, cohort boundaries, and reconciliation to financial or operational records.

Sensitive evidence belongs in a controlled data room with least-privilege access, logging, watermarking where appropriate, retention, and a clean-team arrangement when competition or privacy makes broad access inappropriate. Diligence is not permission to copy all customer data.

Map the end-to-end data flow

Reconstruct one real transaction from input to business outcome. Follow raw data through collection, validation, preprocessing, storage, model calls, retrieval, tools, human review, output delivery, feedback, monitoring, and deletion.

At every boundary, ask:

• What data enters and who supplied it?
• What permission or contractual basis covers this use?
• Where is it stored and processed?
• Which subprocessor or model provider receives it?
• Does the data train, fine-tune, evaluate, or improve any system?
• Which identifiers connect it to a person or customer?
• What transformations and redactions occur?
• Which logs or caches create additional copies?
• How is correction, access, retention, or deletion executed?
• What leaves the system and which action can it trigger?

Test the documented flow against telemetry and configuration. Architecture diagrams are often aspirational. Network routes, cloud resources, data warehouse tables, API logs, feature flags, and support procedures reveal the implemented system.

Create a “shadow path” register for spreadsheets, manual exports, private notebooks, messaging attachments, temporary buckets, and reviewer tools. Shadow paths frequently hold the highest-risk data and the weakest controls.

Verify data rights as an operating dependency

Data value cannot be separated from data rights. Ask for provenance at dataset level, not a generic assurance that data is “public,” “anonymized,” or “customer owned.”

The register should cover source, collection date, purpose, consent or contract basis where relevant, license, geographic restrictions, sensitive attributes, retention, deletion capability, derivative rights, model-training rights, redistribution limits, and evidence of supplier authority.

For customer data, compare contract language with actual use. Does the product use one customer’s data to improve outputs for others? Are opt-outs honored in pipelines and backups? Can a customer export or delete data? What happens to embeddings, fine-tuning examples, feedback labels, and cached prompts?

For scraped or public data, identify the exact sources, acquisition method, terms, robots behavior, copyright analysis, personal data exposure, and update process. “Available online” is not a complete rights opinion.

For synthetic data, document the generator, prompts or procedures, source dependencies, quality checks, and whether synthetic outputs reproduce sensitive or copyrighted material. Synthetic does not mean provenance-free.

Any dataset that cannot be used after closing should be removed from the performance reproduction test. This shows what the buyer can actually operate.

Reproduce performance claims on locked cohorts

Ask the seller to list every material performance claim with definition, dataset, denominator, exclusions, model version, code version, prompt version, evaluation method, date, and owner. Select claims tied to the investment thesis and reproduce them in a controlled environment.

Use three cohorts:

• reference cohort: the seller’s declared evaluation set;
• production replay cohort: representative historical inputs with authorized handling and known outcomes;
• challenge cohort: edge cases, rare classes, distribution shifts, abuse cases, missing information, and high-impact decisions.

Prevent train-test leakage. Hash datasets, inspect duplicates, and examine whether evaluation examples appear in training, prompt templates, demonstrations, or retrieval indexes. Keep the buyer’s challenge set confidential until execution when feasible.

Recalculate metrics from raw predictions. Confirm thresholds, aggregation, class balance, abstentions, failures, timeouts, and human overrides. If the seller reports 92% accuracy after excluding 30% of uncertain cases, both numbers belong in the claim.

For generative systems, use structured rubrics and multiple evaluators where justified. Record disagreement. LLM-as-judge methods can help at scale, but they introduce another model dependency and should be calibrated against qualified human decisions.

Measure outcome acceptance, not model output

Model accuracy may not equal business success. An extraction system can identify fields correctly while the workflow fails to reconcile them. A support agent can write fluent answers while customers reopen cases. A lead-scoring model can rank prospects while sales rejects them as ineligible.

Build an outcome ledger:

accepted_outcome_rate = accepted_business_outcomes / eligible_cases
straight_through_rate = accepted_outcomes_without_human_rework / eligible_cases
exception_rate = cases_routed_to_exception / eligible_cases
rework_minutes_per_case = total_human_rework_minutes / eligible_cases
critical_failure_rate = critical_failures / eligible_cases

Define eligibility and acceptance before viewing the result. Report dropped, timed-out, and ambiguous cases. A model that abstains safely can be valuable; a metric that quietly removes abstentions is misleading.

Trace a sample from model output to ledger, CRM, payment, support, or customer action. Confirm that claimed savings appear in schedules, headcount plans, vendor spend, throughput, or service capacity rather than in a theoretical time study alone.

Decompose the unit economics

AI gross margin is sensitive to workload mix and architecture. Separate fixed and variable costs:

contribution_per_accepted_case =
  revenue_per_case
  - model_inference
  - retrieval_and_tool_calls
  - cloud_compute_and_storage
  - data_or_license_royalties
  - human_review_and_exception_labor
  - support_and_refund_cost
  - variable_security_and_compliance_cost

Model costs by cohort: short versus long documents, common versus rare languages, simple versus complex tools, new versus established customers, and normal versus peak traffic. Average cost can hide a loss-making tail.

Reconcile usage to provider invoices and cloud bills. Check discounts, credits, free tiers, founder arrangements, and minimum commitments. Remove temporary subsidies. Stress-test provider price changes, token growth, higher review, and lower cache hit rates.

Capacity matters. Run load tests that reflect concurrency, tool dependencies, rate limits, queueing, retries, and downstream systems. A product that works at current volume may require a different architecture and capital profile at the buyer’s scale.

Treat human operations as part of the technology

Hidden human labor is not automatically a defect. Human review can be a sound safety control or a valuable service layer. The diligence risk is undisclosed, unmeasured, or non-scalable labor.

Map every human touch: data labeling, prompt tuning, exception handling, content moderation, quality review, customer onboarding, manual tool execution, and incident response. Record time, skill, location, vendor, cost, access, turnover, and quality controls.

Interview operators separately from executives. Ask them to walk through the last difficult case, not the ideal workflow. Observe queue age, workarounds, copy-paste steps, escalation, and undocumented judgments.

Calculate labor per accepted outcome and at peak demand. Determine whether the process depends on a few founders or domain experts. If expertise cannot be transferred, add a retention, documentation, and shadowing plan to the transaction condition.

Map model and supplier concentration

Create a dependency graph covering foundation models, embeddings, rerankers, safety services, vector databases, data suppliers, cloud regions, identity providers, observability, and specialized contractors.

For every critical dependency, record:

• contract entity and term;
• assignment or change-of-control restriction;
• price and commitment;
• service limit and support tier;
• data use and retention terms;
• geographic or customer restrictions;
• termination and suspension rights;
• export capability;
• replacement candidate;
• tested failover state;
• time and cost to migrate.

The UK National Cyber Security Centre’s secure AI development guidance, co-authored with international partners including CISA, emphasizes supply-chain security, verified third-party components, documentation of models, data and prompts, asset tracking, and readiness to fail over for mission-critical systems. This is guidance, not a certification that a target is secure. It does, however, support treating models, prompts, datasets, libraries, APIs, and logs as governed supply-chain assets.

Do not accept “multi-model” as evidence of portability. Ask for a witnessed failover test. Compare output quality, latency, tool compatibility, safety behavior, and cost after switching.

Build an AI bill of materials

Traditional software bills of materials identify packages and versions. An AI bill of materials should extend the inventory to models, adapters, datasets, prompts, evaluations, tools, and providers.

Asset	Required fields
Model	Provider, identifier, version, license, hash where available, use
Dataset	Owner, source, license, purpose, retention, lineage, sensitivity
Prompt	Owner, version, system role, secrets, approved use, test link
Retrieval index	Sources, build date, embedding model, deletion process
Tool	Permission scope, credential owner, action boundary, rollback
Evaluation	Dataset hash, rubric, judge, date, thresholds, results
Library	Package, version, source, license, vulnerabilities
Service	Contract, region, subprocessors, export, termination, failover

Compare the bill with runtime observations and repositories. Orphan assets and unregistered calls reveal incomplete governance. Cryptographic hashes can help establish artifact identity, but do not establish legal ownership or model quality.

Examine security through abuse cases

Review conventional application security plus AI-specific paths: prompt injection, tool misuse, excessive agency, data exfiltration, training or retrieval poisoning, model theft, denial of wallet, unsafe file handling, insecure serialization, secret leakage, and cross-tenant exposure.

CISA’s AI roadmap calls for secure acquisition, development, and operation, stronger vulnerability management, testing and red teaming, and integration of AI into secure-by-design work. A roadmap is not a product assessment. Use it as a reason to request implemented controls and evidence.

Test boundaries with authorized exercises. Can untrusted content change system instructions? Can a user cause the agent to call a tool outside their permission? Can retrieved content expose another tenant? Are tool calls validated and idempotent? Are destructive actions separately approved? Can attackers create unbounded inference cost?

Review incident and vulnerability history, including near misses. Ask how the team detects, contains, communicates, remediates, and learns. A target with documented incidents and effective corrections may be less risky than one claiming never to have had a problem without monitoring.

Inspect production reliability and change control

Request service-level objectives, availability history, latency percentiles, queue age, error budgets, incident reports, recovery tests, backup results, and dependency outages. Segment by customer and feature.

Then inspect change control. How are model, prompt, retrieval, policy, and tool changes proposed, tested, approved, deployed, observed, and rolled back? Can the team reproduce the exact configuration that produced a customer result? Are releases tied to evaluation evidence?

Stanford’s 2026 AI Index reports continued organizational AI incidents among surveyed organizations and a decline in self-rated incident-response strength among respondents. Those survey findings do not predict a specific target’s risk, and self-reporting has limitations. They do contradict the idea that adoption maturity automatically produces incident maturity. Verify the target’s own response capability.

Conduct a tabletop exercise: provider outage during peak traffic, corrupted retrieval index, leaked tool credential, harmful output reported by a major customer, or model update causing a critical regression. Observe decisions, evidence, contact ownership, and recovery—not merely the written plan.

Verify intellectual property and transferability

Trace key code, prompts, models, datasets, and inventions to employees, founders, contractors, partners, and acquisitions. Confirm assignment documents and open-source compliance with counsel.

Identify copyleft or source-available obligations, attribution, redistribution restrictions, model licenses, acceptable-use conditions, and commercial limitations. Review how code-generation tools were used and what verification process followed. Do not infer infringement from tool use, but do not assume tool output is clean by default.

Check patents and trade secrets only where relevant to the thesis. A secret is valuable only if the company identifies it, restricts access, and maintains confidentiality. A claim that “our prompts are proprietary” is weak when prompts are widely shared in tickets or customer-visible logs.

Test change-of-control and assignment clauses for APIs, data, cloud credits, research agreements, and customer contracts. A right held by the seller may not survive the transaction automatically.

Cross-check customer promises

Sample contracts, security questionnaires, data-processing terms, proposals, and marketing claims. Compare them with implementation.

Look for commitments about accuracy, human review, data location, model training, deletion, subprocessors, security certifications, uptime, explainability, and permitted uses. Identify side letters and custom configurations.

Reconcile revenue concentration with technical variation. A major customer may depend on a bespoke model, manual process, or legacy environment that does not share the standard product economics. Losing one operator or vendor can therefore affect both retention and margin.

Interview customer success and support teams. Recurring objections, workarounds, and refund reasons expose product boundaries that product dashboards may not show.

The diligence flow

flowchart TD
  A[Define transaction thesis] --> B[Draw system and asset boundary]
  B --> C[Build data dependency and rights registers]
  C --> D[Reproduce claims on locked cohorts]
  D --> E{Business outcome and economics hold?}
  E -- No --> X[Stop reprice or redesign thesis]
  E -- Yes --> F[Review security reliability and incidents]
  F --> G[Verify IP contracts and transferability]
  G --> H[Test scale integration failover and exit]
  H --> I{Material gap remains?}
  I -- Yes --> J[Condition holdback covenant or pilot]
  I -- No --> K[Approve with integration controls]
  J --> L{Acceptance test passed by deadline?}
  L -- No --> X
  L -- Yes --> K

The flow prevents performance from eclipsing ownership, security, economics, or exit. It also converts findings into decisions instead of producing a long risk list with no transaction consequence.

A minimal evidence-manifest validator

The following Node.js example checks whether a diligence manifest contains required sections and blocks unowned critical dependencies. It validates structure only; it cannot verify that documents are truthful.

const manifest = {
  thesisId: "T-01",
  evidenceDate: "2026-10-20",
  claims: [{ id: "C-1", reproduced: true, datasetHash: "sha256:demo" }],
  dependencies: [
    { name: "foundation-model-api", critical: true, owner: "vendor", transferable: true, failoverTested: false },
    { name: "evaluation-suite", critical: true, owner: "target", transferable: true, failoverTested: true }
  ],
  sections: ["architecture", "data-rights", "performance", "security", "economics", "ip", "exit"]
};

function validateDossier(d) {
  const required = ["architecture", "data-rights", "performance", "security", "economics", "ip", "exit"];
  const missing = required.filter(section => !d.sections?.includes(section));
  const unreproduced = (d.claims || []).filter(claim => !claim.reproduced || !claim.datasetHash);
  const criticalGaps = (d.dependencies || []).filter(dep =>
    dep.critical && (!dep.transferable || (dep.owner === "vendor" && !dep.failoverTested))
  );
  return {
    ready: missing.length === 0 && unreproduced.length === 0 && criticalGaps.length === 0,
    missing,
    unreproduced: unreproduced.map(item => item.id),
    criticalGaps: criticalGaps.map(item => item.name)
  };
}

console.log(JSON.stringify(validateDossier(manifest), null, 2));

The sample should fail because the critical vendor model has no tested failover. That failure is intentional: a contractual assurance of portability is not an operational test.

Convert findings into transaction controls

A finding without consequence is a note. Translate material gaps into one or more controls:

• condition precedent before closing;
• price adjustment;
• escrow or holdback tied to acceptance;
• representation and warranty reviewed by counsel;
• remediation covenant with evidence deadline;
• transition-service agreement;
• key-person retention or knowledge-transfer plan;
• supplier consent or contract replacement;
• limited pilot or phased acquisition;
• prohibited use until a control passes;
• termination or walk-away right where appropriate.

Each control needs a measurable test. “Improve documentation” becomes “deliver a complete AI bill of materials reconciled to runtime calls and repositories, with no unresolved critical owner or license.” “Reduce model risk” becomes “pass the challenge cohort with defined critical-failure limits and demonstrate rollback.”

Avoid conditions that reward document production without operational change. A new policy is not enough if the system still lacks logs, access control, review, or deletion.

Build the exit dossier before signing

An exit plan is not pessimism. It establishes whether value is inside the acquired assets or rented from dependencies.

The dossier should explain how to:

• export customer, configuration, evaluation, and operational data in documented formats;
• rotate credentials and transfer approved accounts;
• replace each critical vendor;
• operate during a provider suspension or pricing dispute;
• preserve customer access and contractual commitments;
• delete seller data no longer authorized after transition;
• retain required audit evidence;
• restore the last known-good release;
• separate the product if the buyer later divests it;
• shut down safely without orphaning customer data or actions.

Witness at least one export, restore, model failover, credential rotation, and deletion workflow. Time the process. Record manual steps and missing permissions.

If the system cannot leave its current founder accounts, vendor relationships, or undocumented operator knowledge, the buyer is acquiring continuity risk.

Contradictions the committee should hear

AI can accelerate diligence itself. McKinsey describes growing use of generative AI for target identification, document search, summarization, and diligence workflows. That can reduce manual discovery time and connect information across a deal. It can also create a recursion problem: an AI tool summarizes evidence about another AI system, and reviewers mistake speed for verification.

Use AI-assisted diligence to locate clauses, cluster issues, generate questions, and trace references. Preserve source citations, access controls, and human accountability. Never let a generated summary replace the underlying contract, configuration, or test result.

Another contradiction is that more evidence is not always better. A massive data-room dump can conceal missing ownership, unclear definitions, or contradictory versions. Prefer a traceable manifest that connects each claim to its authoritative artifact, test, owner, and decision.

Finally, proprietary technology is not automatically valuable, and third-party technology is not automatically weak. A maintainable system built on well-governed services may be stronger than a proprietary model with unclear data rights and no operating team. Diligence should test the thesis, not reward fashionable labels.

Failure modes that invalidate the review

Demo substitution

The team watches ideal inputs and calls the result validation. Reproduce claims on production and challenge cohorts.

Dashboard acceptance

Reviewers accept screenshots without definitions, raw data, or reconciliation. Recalculate material metrics.

Data-room flooding

Volume replaces lineage. Require a claim-to-evidence manifest and identify authoritative versions.

Average economics

Profitable easy cases hide an expensive tail. Segment cost and acceptance by workload.

Hidden human service

Manual quality work is excluded from product cost. Observe operations and include labor per accepted outcome.

Contract optimism

The buyer assumes vendor, data, and customer agreements will transfer. Verify clauses, consents, and replacement options.

Paper portability

An architecture is called model-agnostic without a failover test. Execute the switch and measure regression.

Security by questionnaire

Policies and yes/no answers replace technical evidence. Inspect configuration, incidents, tests, and recovery.

Key-person blindness

Critical knowledge lives with founders or contractors. Map decisions, access, and operating judgment to people.

Post-close remediation fantasy

The committee assumes every gap can be fixed later without cost or customer impact. Price, condition, pilot, or stop now.

Final checklist

• [ ] The investment thesis is written as falsifiable claims.
• [ ] The system boundary includes models, data, prompts, tools, humans, vendors, and operations.
• [ ] Every material asset has an owner, license, transfer state, and replacement path.
• [ ] Data provenance and permitted use are verified at dataset level.
• [ ] Performance claims are reproduced on reference, production, and challenge cohorts.
• [ ] Metrics include abstentions, exclusions, failures, and accepted business outcomes.
• [ ] Unit economics include inference, infrastructure, data, human review, exceptions, and support.
• [ ] Capacity and peak-load behavior are tested.
• [ ] The AI bill of materials is reconciled to runtime and repositories.
• [ ] Security testing covers tool use, prompt injection, data leakage, supply chain, and cost abuse.
• [ ] Incidents, near misses, rollback, and recovery evidence are reviewed.
• [ ] Customer promises match implementation and economics.
• [ ] Change-of-control, assignment, and key-person dependencies are addressed.
• [ ] Integration, export, failover, deletion, and shutdown have witnessed tests.
• [ ] Every material gap has an owner, test, deadline, remedy, and transaction consequence.
• [ ] AI assistance in diligence preserves source evidence and human accountability.

Conclusion

AI due diligence is not a hunt for a single accuracy score. It is a reconstruction of the conditions that create value: assets, rights, data, model behavior, human operations, security, suppliers, economics, customer promises, and recovery.

The evidence and exit dossier makes those conditions inspectable. It shows which claims reproduce, which costs scale, which dependencies transfer, which failures are controlled, and whether the buyer can operate when a provider, founder, dataset, or model changes.

The strongest outcome is not always approval. A conditional deal, license, pilot, repricing, or refusal can preserve more value than buying a persuasive demo. The discipline is to connect every claim to evidence and every material uncertainty to a decision before the transaction makes uncertainty expensive.

Sources

• CISA Roadmap for Artificial Intelligence
• NCSC Guidelines for Secure AI System Development
• Stanford AI Index Report 2026
• McKinsey: Gen AI in M&A, from theory to practice to high performance
• McKinsey: Strategy for a digital world and technology due diligence