Before Buying an AI System, Companies Must Demand Evidence and an Exit File

An Impressive Demo Does Not Mean a High-Quality Asset

An AI product can be impressive in a controlled demo and still be a bad acquisition. The interface may conceal manual labor, benchmarks may not match production, the model may depend on a vendor that can change terms at any time, and the acquirer may not own the code or data needed to operate it after closing. Buyers who only verify demos and nominal accuracy are not doing technical due diligence—they are watching a product pitch.

The core question in an acquisition is not "does this AI work?" but: under what inputs, dependencies, controls, costs, rights, and operating conditions can the system produce acceptable results—and can the buyer maintain or replace those conditions after the deal?

This article is based on an AI system due diligence framework that integrates scoping, data flows, performance evidence, critical dependencies, operational governance, deal terms, and cross-functional interviews into an "Evidence and Exit File." It serves multiple decision scenarios: buy, buy with conditions, price adjustment, remedial holdback, pilot, license, or walk away.

Write the Investment Thesis as Falsifiable Propositions

Every evidence request should serve to test a value thesis. Typical theses include: the system reduces manual cost per case; it improves conversion or retention; proprietary data creates durable differentiation; the technology can scale to new markets; it can support higher volume at acceptable gross margin; the team has a repeatable improvement loop; and the buyer can integrate the capability faster than building it.

The key is to rewrite each thesis as a falsifiable proposition. "The platform automates customer service" must become "within a defined ticket scope, the system resolves an agreed share of accepted outcomes without human intervention while meeting response-time, quality, safety, and cost thresholds."

Next, actively look for disconfirming evidence: hidden human intervention, excluded hard cases, delayed escalations, excessive refunds, reviewer time, expensive inference, customer churn, and vendor subsidies can all produce attractive aggregate metrics while destroying the investment thesis. A seller willing to admit where the product fails is often more operationally mature than one claiming it can do everything.

The Twelve Components of the Evidence and Exit File

The file should be versioned, access-controlled, and precisely tied to deal scope. It contains twelve parts: system boundaries and architecture; asset, ownership, and license register; data provenance and permitted-use register; performance claims and reproduction pack; security and abuse case assessment; operational metrics and incident history; unit economics and capacity model; vendor and open-source dependency graph; customer commitments and regulated-use map; organization, key-person, and process dependency map; integration and transition plan; and exit, replacement, and failure-containment plan.

Do not accept screenshots in place of safely shareable exports or raw evidence. Dashboard images omit metric definitions, filters, exclusions, and time zones. Ask for data dictionaries, calculation logic, sample sizes, and cohort boundaries, and reconcile them against financial or operational records. Sensitive evidence should sit in a controlled data room with least privilege, logging, watermarking, retention management, and clean-team arrangements where necessary.

Reconstruct One Real Data Flow End to End

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

At each boundary, ask: what data enters, and who provides it? What license or contractual basis covers this use? Where is data stored and processed? Which subprocessor or model provider receives it? Is data used to train, fine-tune, evaluate, or improve any system? Which identifiers link it to individuals or customers? What transformations and redactions occur? Which logs or caches create additional copies? How are correction, access, retention, or deletion enforced? What does the system output, and what actions can it trigger?

Verify documented flows with telemetry and configuration. Architecture diagrams are often idealized; network routes, cloud resources, warehouse tables, API logs, feature flags, and support workflows reveal what actually runs. Maintain a "shadow path" register for spreadsheets, manual exports, private notebooks, message attachments, ad hoc buckets, and review tools—shadow paths often carry the highest-risk data and the weakest controls.

Shadow Paths refer to data processing and flow channels that business users build for themselves outside formal IT governance and monitoring—for example, exporting customer data into personal spreadsheets, sending sensitive files through messaging attachments, temporarily writing production data to personal notebooks or unmanaged buckets, or calling external APIs directly while bypassing approval workflows. These paths are dangerous because the data they carry is often as sensitive as, or more sensitive than, that in formal systems, yet is entirely unconstrained by access control, audit logging, encryption, and retention policies. In AI systems, shadow paths also commonly appear as unregistered prompt templates, ad hoc retrieval indexes, manual labeling copies, and feature-flag bypasses. During due diligence, the seller (or target company) should be required to proactively inventory and register all shadow paths, assess each one's data classification, access scope, copy retention duration, and deletion feasibility, and incorporate them into the data flow diagram and risk register—rather than assuming the official architecture diagram is the full picture of how the system actually runs.

Data Rights Are an Operational Dependency, Not a Legal Annex

Data value cannot be separated from data rights. Demand dataset-level provenance evidence rather than broad assurances like "public," "anonymized," or "customer-owned." The register should cover source, collection date, purpose, consent or contractual basis, licenses, geographic restrictions, sensitive attributes, retention period, deletion capability, derivative rights, model training rights, redistribution restrictions, and evidence of vendor authorization.

For customer data, compare contract language against actual use. Does the product use one customer's data to improve outputs for other customers? Are opt-out choices honored across pipelines and backups? Can customers export or delete their data? What happens to embeddings, fine-tuning samples, feedback labels, and cached prompts after deletion?

For scraped or public data, identify the exact source, acquisition method, terms, robots behavior, copyright analysis, personal data exposure, and refresh process. "Available online" is not a complete rights opinion. Synthetic data likewise requires records of the generator, prompts or process, source dependencies, quality checks, and whether synthetic outputs reproduce sensitive or copyrighted material.

Reproduce Performance Claims on Locked Cohorts

Require the seller to list every material performance claim with its 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 types of cohorts:

• Reference cohort: the seller's declared evaluation set;
• Production replay cohort: historical representative inputs with authorized processing and known outcomes;
• Challenge cohort: edge cases, rare categories, distribution shifts, abuse scenarios, missing information, and high-impact decisions.

Prevent train-test leakage: hash datasets, check for duplicates, and review whether evaluation samples appear in training data, prompt templates, demos, or retrieval indexes. Where possible, keep the buyer's challenge set confidential until execution. Recompute metrics from raw predictions and confirm thresholds, aggregation, class balance, abstentions, failures, timeouts, and human overrides. If the seller reports 92% accuracy after excluding 30% uncertain cases, both numbers belong in the claim.

For generative systems, use structured rubrics and multiple evaluators where reasonable, and record disagreements. LLM-as-judge can help at scale, but it introduces another model dependency and should be calibrated against qualified human judgment.

Measure Business Outcome Acceptance, Not Model Output

Model accuracy does not equal business success. An extraction system can identify fields correctly while the workflow fails to reconcile; a customer service agent can write fluent answers while customers reopen tickets repeatedly; a lead-scoring model can rank prospects while sales considers them unqualified.

Build an outcome ledger and define eligibility and acceptance criteria before looking at results:

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

Report discarded, timed-out, and ambiguous cases. A model that can safely abstain may be valuable; a metric that quietly drops abstentions is misleading. Trace samples from model output to the ledger, CRM, payments, support, or customer actions and confirm that claimed savings appear in scheduling, headcount plans, vendor spend, throughput, or service capacity—not just theoretical time studies.

Break Down Unit Economics and Hidden Labor

AI gross margin is highly sensitive to workload mix and architecture. Separate fixed from variable costs: contribution per accepted case equals revenue per case minus model inference, retrieval and tool calls, cloud compute and storage, data or license royalties, human review and exception handling, support and refund costs, and variable security compliance costs.

Model costs by cohort: short versus long documents, common versus rare languages, simple versus complex tools, new versus existing customers, and normal versus peak traffic. Average costs can mask a loss-making long tail. Reconcile usage against vendor invoices and cloud bills, check discounts, credits, free tiers, founder arrangements, and minimum commitments, strip out temporary subsidies, and stress-test against vendor price increases, token growth, added review, and declining cache hit rates.

Hidden labor is not necessarily a defect—human review can be a legitimate safety control or service layer. The real risk is undisclosed, unmeasured, or unscalable labor. Map every human touchpoint: data labeling, prompt tuning, exception handling, content moderation, quality review, customer onboarding, manual tool execution, and incident response. Record time, skills, location, vendor, cost, permissions, turnover, and quality control. Interview operations staff separately and have them walk through a recent difficult case rather than the ideal process.

Supply Chain Dependencies and the AI Bill of Materials

Create a dependency graph covering foundation models, embeddings, rerankers, safety services, vector databases, data providers, cloud regions, identity providers, observability, and specialist contractors. For each critical dependency, record: contracting entity and term, transfer or change-of-control restrictions, pricing and commitments, service limits and support tier, data use and retention terms, geographic or customer restrictions, termination and suspension rights, export capability, replacement candidates, tested failover status, and migration time and cost.

The AI security development guidelines published by the UK National Cyber Security Centre (NCSC) with international partners including CISA emphasize supply chain security, verification of third-party components, documentation of models/data/prompts, asset tracking, and failover readiness for mission-critical systems. These are guidelines, not a security certification, but they support treating models, prompts, datasets, libraries, APIs, and logs as governed supply chain assets. Do not accept "multi-model" as evidence of portability; require a witnessed failover test comparing output quality, latency, tool compatibility, safety behavior, and cost after switching.

The AI bill of materials should extend the traditional software bill of materials to models, adapters, datasets, prompts, evaluations, tools, and providers. Compare the inventory against runtime observations and code repositories; orphaned assets and unregistered calls expose governance gaps. Cryptographic hashes help confirm artifact identity but cannot establish legal ownership or model quality.

AI Bill of Materials (AI BOM) is the extension of the traditional Software Bill of Materials (SBOM) into the AI era. While SBOM mainly registers software components, library versions, and licenses, an AI BOM must also cover foundation models (with versions and hashes), fine-tuning adapters, training and evaluation datasets (with provenance and licenses), prompt templates, retrieval indexes, tools and plugins, evaluation benchmarks, and the providers and hosting locations for each element. Its purpose is to let buyers trace the identity, provenance, rights status, and runtime call relationships of every artifact that affects outputs, thereby identifying orphaned assets, unregistered calls, and governance blind spots. It must be emphasized that cryptographic hashes only prove an artifact's integrity at a given moment; they cannot establish legal ownership, training data compliance, or model quality. The AI BOM is a governance and traceability tool that must be cross-checked against the contractual rights register, data provenance register, and runtime observations to genuinely support deal decisions and post-closing operations.

Security, Reliability, and Deal Controls

Security review should cover conventional application security and AI-specific paths: prompt injection, tool misuse, excessive agency, data exfiltration, training or retrieval poisoning, model theft, wallet denial of service, unsafe file handling, insecure deserialization, key leakage, and cross-tenant exposure. CISA's AI roadmap calls for secure procurement, development, and operations, strengthened vulnerability management, testing and red teaming, and integrating AI into security-by-design work. A roadmap is not a product assessment, but it is grounds to request implemented controls and evidence.

Test boundaries with authorized exercises: can untrusted content alter system instructions? Can a user make an agent invoke tools beyond its permissions? Can retrieved content expose another tenant's data? Are destructive actions separately approved? Can an attacker create unbounded inference costs? Review incident and vulnerability history, including near misses, and ask how the team detects, contains, communicates, remediates, and learns. A target with documented incidents and effective corrections may be lower risk than one claiming no problems but lacking monitoring.

The Stanford 2026 AI Index report shows that AI incidents persist among surveyed organizations while self-assessed incident response capability has declined. These survey findings cannot predict a specific target's risk, and self-reporting has limits, but they refute the idea that adoption maturity automatically brings incident maturity. Test the target's own response capability with tabletop exercises: a vendor outage at peak traffic, a corrupted retrieval index, leaked tool credentials, a major customer reporting harmful output, a model update causing a critical regression—observe decisions, evidence, contact ownership, and recovery, not just the written plan.

Translate findings into deal controls: closing conditions, price adjustments, escrow or holdbacks tied to acceptance, representations and warranties reviewed by counsel, remediation covenants with evidence deadlines, transition services agreements, key-person retention or knowledge transfer plans, vendor consents or contract replacement, limited pilots or staged acquisitions, prohibited uses until controls pass, and termination or exit rights where appropriate. Every control needs a measurable test. "Improve documentation" should become "deliver a complete AI bill of materials reconciled against runtime calls and code repositories, with no unresolved critical ownership or licensing issues."

Prompt Injection and Excessive Agency are two security risks specific to generative AI systems. Prompt injection refers to attackers hiding malicious instructions in user input, retrieved documents, web pages, or tool return results to induce the model to deviate from its instructions, leak system prompts, or perform unintended actions; indirect prompt injection is especially dangerous because malicious content may come from external data automatically fetched by the system rather than direct user input. Excessive agency refers to an AI agent being granted permissions, tools, or autonomous decision scope beyond what the task requires, so that if manipulated or erroneous, it may perform destructive operations, access cross-tenant data, or generate unbounded inference costs. Due diligence should require the target to demonstrate implemented controls for these two paths: isolation and marking of untrusted content, least privilege and separate approval for tool calls, human confirmation of destructive actions, tenant isolation of retrieval results, rate and budget caps on inference costs, and corresponding red team testing and incident records—rather than judging security levels solely from questionnaire answers.

The Exit File and Common Failure Modes

An exit plan is not pessimism; it confirms whether value truly resides inside the acquired assets or is rented from dependencies. The file should explain how to: export customer, configuration, evaluation, and operational data in documented formats; rotate credentials and transfer approved accounts; replace each critical vendor; maintain operations 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 version; separate the product if the buyer divests later; and shut down safely without leaving customer data or actions behind. Witness at least one export, restore, model failover, credential rotation, and deletion process, timing it and recording manual steps and missing permissions.

Common failure modes include: demo substituting for verification, dashboard acceptance, data room flooding, average economics, hidden human services, contractual optimism, paper portability, questionnaire security, key-person blind spots, and post-closing remediation fantasies. Each corresponds to a specific verification action—reproduce on production and challenge cohorts, recompute metrics, require a claim-to-evidence register, segment costs by workload, observe operations and count labor per accepted outcome, verify transfer clauses, execute switching tests, inspect configuration and incidents, map decisions and access to specific people, and price, condition, pilot, or stop before the deal.

AI due diligence is not about finding a single accuracy score but reconstructing the conditions that create value: assets, rights, data, model behavior, human operations, security, vendors, economics, customer commitments, and recovery capability. The Evidence and Exit File makes these conditions inspectable, showing which claims are reproducible, which costs will scale, which dependencies can transfer, which failures are contained, and whether the buyer can operate when the provider, founder, dataset, or model changes. The strongest outcome is not always approving the deal—a conditional deal, license, pilot, repricing, or rejection may preserve more value than buying a persuasive demo.

One-line Summary

AI due diligence should reconstruct the conditions under which value holds, using an Evidence and Exit File to verify claims, dependencies, costs, and replaceability.

Paragraph Summary

The article argues that an impressive AI demo does not mean a high-quality asset. The core question in an acquisition is under what inputs, dependencies, rights, costs, and operating conditions the system can produce acceptable results, and whether the buyer can maintain or replace those conditions after closing. To that end, the investment thesis should be rewritten as falsifiable propositions, and an "Evidence and Exit File" should be built with twelve parts covering system boundaries, data rights, performance reproduction, unit economics, supply chain dependencies, security governance, and exit planning. Performance must be reproduced on three locked cohorts—reference, production replay, and challenge—and business outcome acceptance rates reflect value better than model accuracy; unit economics must break down hidden labor and long-tail costs; and deal controls should link every material gap to a measurable test, an owner, and a deal consequence.