Put the Automation Transfer Dossier in the Exit Data Room
A portfolio company can show a buyer an impressive list of AI wins and still create more diligence work than confidence.
The problem is rarely whether the automations run today. It is whether another operator can understand them, control them, price them, and keep them running after the people who built them have left the room.
That distinction matters now. FTI Consulting’s 2026 Private Equity AI Radar, based on 200 fund and operating leaders, found that 36% of portfolio companies use AI across use cases, but only 7% have deployed it at enterprise scale. Revenue acceleration was the leading priority at 41%, while deal selection, value-creation planning, and exit readiness were already part of the AI agenda.
AI deployment is moving from experiment to operating asset. Exit documentation has not caught up.
Here’s what works: put an Automation Transfer Dossier in the exit data room. It turns a collection of scripts, agents, model subscriptions, and undocumented prompts into operating evidence a buyer can test.
The dossier does not manufacture a valuation premium. It reduces ambiguity, key-person dependency, and the time buyers spend figuring out what they are actually acquiring.
A working automation is not yet a transferable asset
Most portfolio AI programmes are built under pressure. A commercial lead connects a call transcript to the CRM. A finance manager builds an invoice-matching workflow. A developer creates an internal support agent. A founder wires several tools together to produce the weekly report.
Each win can be real. The revenue may be measurable. The hours saved may be genuine. But the operating knowledge often lives in personal accounts, chat threads, browser bookmarks, and one person’s memory.
That creates six predictable diligence questions:
- What exactly does the automation do? Not the demo. The production workflow, its boundaries, and the business decision it affects.
- Which systems and data does it depend on? Including credentials, source tables, APIs, vector stores, model providers, and undocumented exports.
- Who is accountable when it fails? A named process owner, not “the AI team.”
- What does it cost per accepted outcome? Model spend alone is not unit economics.
- How is risk controlled? Review gates, access rights, exception handling, retention, and an audit trail.
- Can a new owner run or move it? Without the original builder and without breaching a licence or customer promise.
If the seller cannot answer those questions quickly, the buyer has to assume more risk. The automation may still be useful, but it looks like fragile know-how rather than a managed capability.
I have seen the same pattern across more than 15 acquisitions and operating environments that reached €240 million in ARR before a €1.5 billion exit. Buyers do not gain confidence from a polished architecture slide. They gain confidence when dependencies, economics, controls, and ownership survive contact with detailed questions.
The Automation Transfer Dossier
The dossier is a compact operating record for every material automation. Material means the workflow affects revenue, customer delivery, financial reporting, regulated data, a contractual commitment, or a process the buyer would struggle to replace.
Do not document every personal productivity shortcut. Start where failure, removal, or loss of ownership would change the investment case.
The framework has eight parts.
1. Purpose and operating boundary
State the job in one sentence: “Qualifies inbound requests and routes accepted opportunities to the correct sales queue” is useful. “AI sales assistant” is not.
Record the trigger, inputs, outputs, users, frequency, and the decision boundary. Show what the automation is allowed to do and where a human takes over. This prevents a buyer from mistaking a narrow workflow for a general capability.
2. Dependency map
List every system, data source, model, provider, integration, service account, and scheduled job required to run the workflow. Mark which dependencies are owned, contracted, open source, or tied to an individual account.
This is where hidden fragility surfaces. The sophisticated agent may depend on a CSV emailed every Monday, an API key owned by a former contractor, or a model feature that is not included in the enterprise agreement.
Twenty-plus years in hosting and infrastructure taught me a durable rule: the visible application is rarely the whole service. Transferability lives in the dependency chain.
3. Ownership and access
Name the business process owner, technical operator, data owner, and escalation contact. Record where credentials live, how access is granted, and which privileges the workflow holds.
“Built by Sarah” is biography. “Owned by Revenue Operations, operated by Platform Engineering, quarterly access review by Security” is an operating model.
4. Controls and evidence
Document the human review points, acceptance rules, access controls, logging, data retention, incident process, and rollback method. Attach evidence: sample logs, approval records, exception reports, or test results.
This aligns with the direction of the NIST AI Risk Management Framework, which is designed to bring trustworthiness into the design, use, and evaluation of AI systems. For a transaction, the practical question is simple: can the seller show that the control exists and is used?
A policy without an operating record is weak evidence.
5. Unit economics and realised value
Show the baseline, the current result, and the full operating cost. Include model and software spend, human review time, exception handling, maintenance, and failed runs.
Then tie the workflow to an accepted business outcome: qualified opportunities routed, invoices matched, tickets resolved within policy, reports delivered without correction, or churn risks actioned.
Avoid theoretical headcount savings unless cash actually left the cost base. A buyer can underwrite observed throughput, cycle time, margin, or conversion more confidently than a spreadsheet of “hours freed.”
6. Exception history
Keep a short record of material failures and near misses: what happened, how it was detected, business impact, recovery time, and what changed afterward.
This is not a confession file. It proves the company can operate the system when normal conditions break. A workflow with an honest exception history and a tested response is usually easier to assess than one presented as flawless.
7. IP, licensing, and data rights
Record who owns the prompts, code, templates, evaluation sets, and generated assets. Link the relevant provider contracts. State which customer or third-party data enters the workflow and whether that use is permitted.
Flag change-of-control terms, non-transferable subscriptions, open-source obligations, data-residency commitments, and dependencies on a founder’s personal account.
This section needs legal review where material. The dossier does not replace counsel; it gives counsel something concrete to inspect.
8. Portability and handover test
A transfer dossier is not complete until someone tests it.
Give a capable operator who did not build the workflow the runbook and controlled access. Ask them to run it, diagnose a planted failure, rotate a credential, and explain the fallback. For critical systems, also test whether the workflow can move to an approved alternative model or provider without rebuilding the entire process.
Record the result, gaps, owner, and remediation date. Portability does not mean changing providers every quarter. It means knowing which choices are reversible and what it would cost to reverse them.
What the buyer should see in the data room
The finished artifact should not be a 200-page AI policy. Use one index plus a concise record for each material workflow.
The index should show:
- workflow name and purpose;
- business owner and technical operator;
- criticality and data class;
- production status and monthly volume;
- accepted-outcome metric;
- annualised operating cost;
- control status;
- last portability test;
- open remediation items; and
- links to the runbook, contracts, logs, and evidence.
That index gives the deal team a portfolio view. The underlying records let specialists inspect the handful of workflows that matter most.
It also gives the seller an honest answer when a buyer asks, “Which of these capabilities survive a change in model, owner, or infrastructure?”
The exit-readiness chain
The Automation Transfer Dossier follows a simple chain: inventory the workflows, attach operating evidence, test portability, answer buyer diligence, and reduce uncertainty around the capability being transferred.
The sequence matters. Teams often jump straight to a data-room folder and collect screenshots. That creates documentation theatre. Evidence and testing must come first; the folder is only the delivery mechanism.
A 30-day proof path
Do not launch an enterprise-wide documentation programme. Pick one portfolio company and one material workflow. Thirty days to proof is enough to learn whether the framework reduces risk or merely creates paperwork.
Days 1–5: Select and baseline
Choose a workflow tied to revenue, customer delivery, finance, or a material data risk. Capture its purpose, owner, current volume, result metric, operating cost, and known failure modes.
Set a proof target. For example: a new operator can understand the workflow, run it, recover from one failure, and explain its economics using only the dossier and approved access.
Days 6–12: Map the real system
Interview the business owner and technical operator together. Trace the trigger through every system, data source, model call, review gate, and output. Verify the map against logs and credentials rather than accepting the remembered process.
Tag every dependency as owned, contracted, portable, replaceable with effort, or single-point fragile.
Days 13–18: Attach evidence
Add the last 30 to 90 days of volumes, accepted outcomes, costs, exceptions, review activity, and incidents. Link contracts, licences, data-processing terms, access records, and the current runbook.
Where evidence does not exist, say so. An explicit gap with an owner is more useful than a green status based on opinion.
Days 19–23: Run the handover test
Use an operator who did not build the automation. Time how long it takes them to understand the workflow, run it, find a controlled fault, follow the fallback, and identify the commercial impact of downtime.
Do not coach them through missing steps. Every intervention is a dossier defect.
Days 24–27: Close the critical gaps
Fix only what blocks safe transfer: personal credentials, missing access, unclear ownership, unrecorded licences, absent rollback steps, or economics nobody can reconcile.
Do not spend the month polishing diagrams while a production dependency remains tied to one person.
Days 28–30: Make the scale decision
Present the result to the operating partner, company leadership, and the deal-readiness owner. Compare the proof target with the handover result.
Scale the dossier across other material workflows if the test shortened explanation time, exposed fixable risk, and produced evidence the deal team can reuse.
Stop or redesign if the artifact becomes a static questionnaire nobody operates. The dossier should be generated from existing logs, contracts, runbooks, and ownership systems wherever possible. Manual narrative should be the exception.
Treat transferability as part of value creation
Bain’s Global Private Equity Report 2026 describes a market in which recovery has been narrow and the old assumptions of easy multiple expansion no longer hold. That puts more weight on operating performance and the quality of the asset presented at exit.
For AI-enabled capabilities, quality includes transferability.
The hidden door is to build the dossier during value creation, not during the final sprint to diligence. Add the workflow index to quarterly portfolio reviews. Require a handover test after material changes. Capture exception and unit-economics data while the system runs. By exit, the data room becomes an export from the operating system rather than an archaeological dig.
A buyer does not need every automation to be perfect. The buyer needs to see what exists, why it matters, how it is controlled, what it costs, where it fails, and whether the next operator can own it.
That is how AI stops looking like founder-dependent cleverness and starts looking like a transferable operating capability.
