Scaling AI across a portfolio

Almost every fund can now point to a portfolio company where AI works. Far fewer can show that it worked faster and cheaper at the second company than at the first, and faster again at the tenth. That is the difference between a set of successful projects and a portfolio capability, and the numbers say most funds are still on the first side of it.

FTI's 2026 survey of 200 fund and operating leaders found 36 percent of portfolio companies using AI across multiple use cases, and only 7 percent at enterprise scale. Talent was the single largest constraint, cited by 35 percent. The funds that have scaled show what it takes. Hg reports more than 1,600 AI projects live across its portfolio, with roughly 260 million dollars of budgeted EBITDA impact, a fivefold increase since 2024, supported by a value creation team of more than a hundred AI specialists working inside portfolio companies.

Most funds will not build a team of that size. Almost all of them can build the discipline behind it. This piece is about that discipline: what a portfolio should share, what each company must keep, and how to make each deployment cheaper than the one before.

Why portfolio programs stall

The failure modes are consistent enough to list.

Every company starts from zero. Each portfolio company runs its own discovery, picks its own tools, builds its own integrations and learns the same lessons. The fund pays full price for every deployment and learns nothing it can reuse.

Licenses stand in for change. Distributing AI tools across the portfolio produces usage statistics and very little EBITDA. BCG's recent work on AI in private equity draws the line between deploying tools, reshaping how work is done, and inventing new products; most portfolios are still at the first.

The mid-market cannot hire for it. A company with 400 employees cannot recruit, retain and manage a team that understands both the model layer and its own P&L. Nor should it try to.

The people who carry it were not in the room. Operating partners and portfolio executives who did not help design a program rarely carry it into their companies with conviction. That is an incentives and ownership problem, not a technology one.

What a portfolio should share

The unit of reuse is the pattern, not the data. A great deal can be built once at the fund level and carried into every company.

Patterns for common workflows. The monthly close, accounts payable, collections, customer support, proposal drafting and quote generation look remarkably similar across companies in different industries. A proven design for each, with its failure modes documented, turns a three-month build into a three-week adaptation. We have written about one of these in detail in closing the books with agents.

Evaluations. For each pattern, a set of test cases and a measure of what good looks like, so that a new deployment can be proven before it goes live rather than after. This is the single most transferable asset in a portfolio program and the one most often skipped, as we argued in why evals matter.

Connectors to common systems. Most portfolio companies run on a handful of ERPs, CRMs and ticketing systems. Integration work done once, with permissions inherited from the source system, serves every company on the same stack.

Governance. A standard action boundary, approval policies, audit requirements and incident procedures, adopted by each company and adjusted where its regulation requires. Buyers and lenders increasingly ask for this, and it is far cheaper to adopt a template than to invent one twenty times.

Model purchasing. A portfolio buying capacity across several labs has pricing leverage no single company has, and the ability to route each workload to the model that does it best. That leverage disappears if every company is tied to one provider.

A bench of people. A small central team that has built each pattern before, and moves between companies, is worth more than twenty generalists hired separately.

What each company must keep

The opposite column is where portfolio programs get into trouble, often with good intentions. The temptation is obvious: pool data from across the portfolio and build something that learns from all of it. There are three reasons to resist it.

It is the company's value at exit. A buyer is buying that company's proprietary data, its customer relationships and the expertise its people have built up. If those are entangled in a sponsor-level platform, separating them at sale becomes a carve-out, with transition services, cost and a discount attached. Each company's codified expertise, its rules, its precedent and the evaluations built on its own cases, should live in a layer that company owns and can take with it. That principle, which we laid out in the sovereign frontier enterprise, matters more under private ownership than anywhere else, because the ownership is designed to change.

Pooling across competitors is an antitrust question. Funds frequently own more than one company in the same sector, and those companies compete. Sharing pricing, cost, customer or bidding data between competitors is exactly the kind of information exchange antitrust law targets. Federal antitrust agencies withdrew their long-standing safe harbors for information sharing between competitors in 2023, and regulators are now looking specifically at how common owners handle information across portfolio companies. A cross-portfolio model trained on competitors' pricing is not a clever use of scale. It is a liability.

Customer contracts usually forbid it. Many commercial agreements restrict the use of customer data to providing the contracted service. Using it to train or improve systems that serve other companies, including sister companies, can breach them.

The rule that follows is simple. Share the machinery; keep the substance. Patterns, evaluation designs, connectors, governance and purchasing move across the portfolio. Data, customers, pricing and expertise stay home.

Who runs it after the builders leave

The second reason portfolio programs stall is that they are built to be demonstrated rather than operated. A system that only its builders understand becomes a liability the week they move to the next company.

Build-operate-transfer is the model that works. The central team or partner builds the first version alongside the company's own people, operates it jointly until it is stable, and hands it over with three things in place: a named owner inside the company who is accountable for its results, a trained team that can adjust rules and handle exceptions without an engineer, and a record of quality, cost and volume that the owner reviews every month. Training cannot be an afterthought; it is part of the deliverable, which is why Fig Academy is built into our engagements rather than sold alongside them.

Making the fifth company cheaper than the first

Scale is measurable, and it should be measured.

Sequence by similarity. Take the pattern proven at one company to the companies whose systems and workflows most resemble it, not to whichever company asks first.

Track the cost to deploy. The key metric of a portfolio program is not the number of projects but the time and cost to take a proven pattern live at the next company. If it is not falling, the program is not scaling; it is repeating.

Keep a portfolio register. Every live workflow, its owner, its baseline, its measured impact, its run cost and the models it uses. The same register becomes the evidence base for each company's exit and for the fund's next raise, which we discuss in the private equity AI playbook.

Keep model choice open at the portfolio level. Twenty companies tied to a single lab for the length of a fund is a concentration risk no investment committee would accept for any other critical input. How to preserve that choice, and what to ask of partners, is the subject of choosing an AI partner for your portfolio.

Key takeaways

• The measure of a portfolio AI program is whether each deployment is faster and cheaper than the last, not how many projects are live.
• Share patterns, evaluations, connectors, governance, model purchasing and a bench of people. These are where scale comes from.
• Keep each company's data, customers, pricing and codified expertise its own. It is the company's exit value, pooling it across competitors creates antitrust exposure, and customer contracts often forbid it.
• Build to operate, not to demonstrate: a named owner, a trained team and a monthly record of quality and cost in every company.
• Model choice is a portfolio-level concentration decision. Keep it open.

A portfolio learns from what it builds, not from what its companies know. Share the first; protect the second.