Why AI value creation stalls after the first portfolio company

The first AI project in a portfolio pays back. The second one, at a different company, starts from zero, and the fund pays for the same integration twice. AI value creation in private equity stalls right there, because the first build was filed as a result when it should have been filed as a template.

Why an operating partner should care

A value creation plan that shows AI in twelve companies and delivers twelve separate builds has bought the same work twelve times. Each company found its own contractor, its own data connection, its own review process and its own way of counting the benefit. At exit, the buyer asks what AI is worth across the portfolio and gets twelve answers in twelve formats.

The 95% success rate in FTI's survey, covered below, is compatible with that picture. Business cases are being met one company at a time, and they are small business cases.

Five things that do not travel from company one

A successful AI project at Portco #1 fails to make Portco #2's project cheaper or faster for reasons an operating partner can list in advance:

1. Documentation. The build lives in the contractor's memory and a Slack thread. The second company cannot read either.

2. Repeatability. The data connection and the review gate were hand-built for one ERP and one team. Moving them means rebuilding them.

3. Reusable components. No one separated the parts that are the same in any company (how a workflow reaches data and how a human approves an action) from the parts that are specific to one business.

4. Ownership. One person at company one knows how it works. Company two has no equivalent person and no way to grow one.

5. Common metrics. Company one counts hours saved. Company two counts invoices processed. The fund cannot add them or defend them to a buyer.

Reuse is the through-line. Fix the five and the second build costs a fraction of the first. Skip them and the fourth build costs what the first three did.

The standard an operating partner sets

Build the second use case, in the second company, as if there will be a tenth. In practice that is a short standard rather than a platform mandate:

• One runbook layout, written well enough that a competent person at a sister company can extend it without calling the original builder.
• One data access pattern and one review gate pattern, reused rather than redesigned.
• One log format across companies, so an auditor or a buyer reads them the same way.
• One named owner per company, on payroll, who can change the workflow without a contractor.
• Two or three metrics defined once at the fund level and reported the same way by each company.
• One shared folder where the runbooks live.

It adds about a week to the second project. It changes what the fourth, fifth and sixth cost, and it changes which companies can start at all. A portfolio company with no engineer on staff can adopt a documented pattern. It cannot adopt a contractor's memory.

What FTI measured

Ozgur Vural, Carl Jones and Maddie Stenger surveyed 200 fund and operating leaders for FTI Consulting's 2026 Private Equity AI Radar.

Source facts: 95% of funds report AI initiatives meeting or exceeding their original business case criteria. FTI's chart of portfolio company deployment puts 36% at "using AI across use cases" and 7% at "enterprise scale". Revenue acceleration is the top priority at 41%. Talent is the primary constraint to scaling adoption, cited by 35%.

My read: the distance between 36% and 7% inside one company is the shared layer that no single use case justifies. Across a portfolio the same gap repeats, and the survey cannot see it because it asks each company about itself. FTI does not draw the reuse conclusion; I do.

Illustrative arithmetic, not a client case: a fund with twelve companies and a 36% rate has four companies that each solved invoice matching on their own. Four integrations to the same category of ERP and four review gates designed from scratch. Four contractors, each learning the domain from zero.

Talent scarcity is partly a documentation problem

The 35% talent constraint is real. Part of it is also a documentation problem in a different coat. When the person who built the first workflow moves on, the second workflow waits for someone with the same skill, and that person starts from zero because nothing was written down. Across a portfolio, that wait multiplies by the number of companies.

The build that becomes a template

The value creation plan that treats company one's build as company two's starting point pays for each integration once and gets results a buyer can compare.

If you sit on the operating side of a fund, I can walk through a duplicate-build map with you: which workflows your companies built more than once this year, and what the shared standard above would have cost instead. Send me the portfolio list and a rough count of AI projects underway.