Portfolio AI Doesn’t Scale Until the Second Company Does
A use case at one portfolio company is not a portfolio capability.
It may be a good pilot. It may even produce real value. But until the result survives a second company—with different data, systems, process habits and local leadership—you have not proved replication. You have proved that one team, under one set of conditions, made something work.
That distinction is where private equity AI strategies are breaking.
FTI Consulting's 2026 Private Equity AI Radar surveyed 200 fund and operating leaders. Roughly 36% reported production deployment in specific use cases, but only 7% had reached enterprise-scale production. At the same time, 95% said AI initiatives met or exceeded their original business-case criteria. The report shows a market with plenty of local wins and very little repeatable scale.
Here’s what works: stop circulating use-case lists. Build a Portfolio Replication Contract that states exactly what must be true before an AI workflow can move from one PortCo to another.
The model is rented. The vendor deck is disposable. The replication contract is the owned operating asset.
Why good pilots fail during portfolio transfer
Most portfolio AI programs start with a sensible ambition: prove a workflow in one company, package the playbook, then roll it across the portfolio. The failure is not usually a lack of enthusiasm. It is an assumption hidden inside the word “package.”
Teams package the visible layer: prompts, automation steps, screenshots, dashboards and a benefits slide. They do not package the operating conditions that made the result possible.
The first PortCo may have clean CRM ownership, a disciplined sales process, a product catalogue with stable identifiers and a revenue leader who personally clears exceptions. The second may have duplicate accounts, regional process variants, undocumented spreadsheet overrides and no owner for failed outputs. The same workflow is technically installed, but the economic unit is different.
After 15+ acquisitions, I’ve learned that integration playbooks only compound when you separate the repeatable core from company-specific reality. Copy everything and you import hidden assumptions. Customise everything and you destroy the portfolio advantage.
AI raises the stakes because a workflow can appear functional while quietly producing rework, weak decisions or customer risk. A demo shows capability once. Replication requires accepted work under local operating conditions.
The Portfolio Replication Contract
A Portfolio Replication Contract is a go/no-go specification between the fund, the proven PortCo and the receiving PortCo. It is not a procurement document. It is the evidence package that decides whether to copy, adapt or reject a transfer.
Use eleven fields.
1. Value-driver hypothesis
Name the financial line the workflow is supposed to move: qualified pipeline, price realisation, renewal risk, support cost, implementation capacity, working capital or another measurable driver.
“Deploy an AI sales agent” is not a hypothesis. “Increase accepted meetings from dormant accounts without raising sales-development cost per opportunity” is.
FTI found revenue growth was the most common orientation for PortCo AI initiatives at 41%, ahead of purely cost-focused programs. That makes attribution more important, not less. Revenue outcomes have longer causal chains and more confounders than a straightforward labour-saving task.
2. Accepted unit of value
Define the smallest completed outcome the business will pay for: an accepted lead, a resolved ticket, a reviewed contract, a reconciled invoice, a validated diligence answer.
Measure that unit after human review and downstream use. Model output is inventory. Accepted output is value.
3. Minimum data contract
List the sources, required fields, identifiers, freshness windows, permitted joins and null rules. Name the canonical system for each field and who corrects exceptions.
If the original workflow depends on a clean account ID shared across CRM, billing and support, say so. Do not let the receiving PortCo discover that dependency in week six.
4. Workflow boundary
State where the automation starts, where it stops and which decisions remain human. Include the exception path, escalation owner, prohibited actions and fallback mode.
The transferable asset is rarely an autonomous process. It is a controlled boundary around a recurring decision.
5. Local variance map
Document the differences that could change the outcome: geography, product mix, customer segment, language, regulation, contract model, sales motion, service level and system architecture.
Classify each variance as irrelevant, configurable or structural. Configurable differences belong in deployment parameters. Structural differences may invalidate the transfer.
6. Accountable operator
Name one local business owner and one technical owner. The business owner accepts or rejects the output. The technical owner maintains data, orchestration and observability.
A portfolio team can provide the kit and the pressure. It cannot remotely own every operational exception.
7. Deployment kit
Package the reusable components: workflow definition, data schema, connectors, prompts, evaluation set, access policy, monitoring, runbook, baseline template and handover material.
This is where Build-Operate-Transfer earns its name. Build the first implementation with the receiving team, operate it until evidence is stable, then transfer ownership with the system—not a folder of slides.
8. Guardrails and assurance
Define model tiers, data restrictions, approval thresholds, audit records, quality tests, rollback conditions and incident ownership. A workflow touching customer communications needs different controls from internal document classification.
The contract should make unsafe replication impossible by default, not merely discouraged in a policy document.
9. Baseline and economics
Record the current cycle time, acceptance rate, error rate, human effort and fully loaded cost per accepted unit. Then capture the same metrics after deployment, including retries, review, repair, observability and vendor spend.
Do not claim savings from gross minutes generated. Count net capacity released after quality control.
10. Transferability score
Score the receiving PortCo from zero to two across five dimensions:
- Data: missing, repairable or ready
- Process: unstable, variable or standard
- Ownership: absent, shared or accountable
- Controls: undefined, partial or enforceable
- Economics: unknown, marginal or compelling
A score of eight to ten is a copy candidate. Five to seven requires adaptation. Zero to four is a reject or redesign decision. The score is not universal truth; it is a forced conversation about conditions before money is committed.
11. Stop condition
Write the failure gate before launch. Examples: acceptance below 85%, review effort above eight minutes per unit, no measurable movement in the chosen value driver, or exception cost that removes the margin case.
A stop condition protects the portfolio from keeping a politically attractive workflow alive after the evidence has turned.
Copy, adapt or reject
The replication decision should produce one of three outcomes.
Copy when the accepted unit, data contract, workflow boundary, ownership and economics are materially equivalent. Reuse the deployment kit and change only configuration.
Adapt when the value driver is the same but one or two operating conditions differ. Modify the local connector, evaluation set, language, approval threshold or exception path. Track adaptation work separately so the fund learns which components are truly reusable.
Reject when structural differences break the value hypothesis. A workflow built for high-volume transactional sales may not transfer to a low-volume enterprise motion. Rejection is not failure. It prevents portfolio standardisation from becoming expensive theatre.
This is the hidden leverage: rejected transfers improve the system. They reveal where the portfolio has distinct archetypes. Over time, the fund can maintain two or three proven variants instead of pretending one template fits every company.
Build the portfolio learning loop
The second deployment should not only consume a playbook. It should improve it. Maintain a versioned replication register for every attempted transfer: source PortCo, receiving archetype, readiness score, adaptations, time to accepted value, unit economics and final gate.
That register gives the operating team a portfolio-level learning curve. After three or four transfers, patterns become visible. A connector that was treated as local may belong in the standard kit. A supposedly universal evaluation set may need sector variants. A recurring ownership gap may justify shared enablement rather than another technology purchase.
This is also how the fund avoids false standardisation. Reuse should increase with evidence, not with executive pressure. Every successful transfer raises confidence in the reusable core. Every failed transfer should narrow the claim, improve the readiness screen or retire the workflow. The objective is not maximum rollout. It is faster allocation of capital toward transfers that can reproduce accepted value.
A 30-day proof path
Do not begin with ten PortCos. Use 30 days to prove whether the second implementation reproduces the result.
Days 1–5: select the proof pair
Choose one workflow already producing accepted value and one receiving PortCo with the closest business archetype. Freeze the original baseline and complete the eleven contract fields. Interview the original operator to surface hidden manual work, not just the designed process.
Days 6–10: score readiness
Run the five-dimension transferability score with both operating teams. Inspect real records, exception queues and access controls. Do not accept “we have Salesforce” as proof that the same fields, ownership or lifecycle definitions exist.
The gate: copy, adapt or reject before build work starts.
Days 11–20: deploy the smallest complete path
Implement one accepted unit end to end. Include retrieval, model calls, business rules, human review, observability, fallback and ownership. Use a fixed evaluation set from the receiving company. Keep the original and receiving results separate.
The goal is not feature parity. It is to test whether the repeatable core survives local reality.
Days 21–27: run controlled production
Process enough real volume to expose normal exceptions. Measure acceptance, review time, repair, cost per accepted unit and movement in the chosen value driver. Compare medians and the ugly tail; averages hide the cases that consume operators.
Log every adaptation. If local changes become a rewrite, the workflow is not yet a portfolio product.
Days 28–30: make the scale decision
Use one of four gates:
- Scale the kit when the result reproduces and adaptations are configuration-level.
- Create an archetype variant when the value holds but a recurring structural difference needs a distinct package.
- Redesign the core when hidden dependencies from the first PortCo block transfer.
- Stop when economics or quality fail the pre-agreed threshold.
The board output is one page: baseline, result, transferability score, adaptations, economics, decision and accountable owner. No innovation theatre. No pilot graveyard.
What the fund should own
Vendors can provide models, orchestration and implementation capacity. The fund should own the evidence layer: the value definitions, readiness criteria, evaluation sets, transfer history, economics and decision record.
That asset compounds across holding periods. It improves which workflows you select, which PortCos you pair, where operating teams need support and what evidence belongs in the exit story.
It also changes diligence. Instead of asking whether a target “uses AI,” you can ask whether it has the data contracts, accountable operators and accepted-unit evidence required to receive a proven portfolio workflow. That is a much stronger indicator of value-creation readiness.
The €240M ARR lesson is the same: systems scale when definitions and handoffs remain stable while local teams can operate them. The €1.5B exit did not come from collecting more tools. It came from building repeatable operating machinery that could survive growth, integration and scrutiny.
Private equity does not need another catalogue of AI possibilities. It needs a transfer system that can tell the difference between a local win and a portfolio capability.
30 days to proof. The second company is the test.
Book a 30-minute strategy call
