Build Portfolio AI Capability Without a Large Central Team

A private equity firm can build AI capability across its portfolio with a small shared specialist team if each company owns the workflow, its operating decisions, and its ongoing support. Give the shared team a narrow service mandate and a realistic capacity budget. Use it to solve repeated technical problems and coach local delivery, then bring in outside specialists for defined gaps.

Give the shared team a service mandate

Start by writing the work that a portfolio company can request. A small team might assess a workflow, review an integration design, supply an evaluation method, and help a local team put its first release into operation. Each service needs an entry requirement, an output, and a point where responsibility passes to the company.

The mandate should describe actual capacity. If the team can help with a release during agreed hours, say so. If it can't provide continuous incident response, the company needs another support arrangement before launch. Avoid an open promise to build every automation that management teams propose.

AI expertise can sit within an existing portfolio operations function. EQT describes Motherbrain as its dedicated AI and data team, including work with portfolio companies and external partners on implementation. That is an example of shared expertise in a PE firm; it doesn't establish the right headcount or budget for a smaller fund.

For a small portfolio, begin with the problem that repeats often enough to justify a shared service. Several companies may need help connecting approved AI tools to business records. Others may already have strong engineering teams and need occasional review. Make those differences visible before you create a permanent delivery department.

Separate shared expertise from the decision to buy a common AI platform. Companies can use the same review method while running different software. They can share a specialist's time without sharing production credentials or a customer database.

Write down who funds each service and who approves work that exceeds its agreed scope. Management teams need to see the cost they incur, including subscriptions and support after the specialist leaves. The operating team needs to see its own time commitment rather than treating internal assistance as free.

Name the people who own delivery

A lean model needs several responsibilities, even when a person holds more than a single role. The portfolio sponsor owns priorities and the shared capacity budget. A technical lead owns reusable engineering practices and reviews material technical decisions. A delivery engineer builds or adapts the workflow with the company.

Each participating company supplies a process owner who knows the work and can accept the result. Its systems owner approves access and integration changes. A finance representative checks the baseline and any claimed financial benefit. Staff who use the workflow need time to test exceptions and explain where the design fails.

The table below proposes an operating arrangement. It isn't a prescribed staffing ratio or a description of a Waypoint engagement. Assign these responsibilities to named people and confirm their availability before delivery starts.

A forward deployed engineer can connect the technical work with the company's operating context. They can investigate real cases, adapt integrations, and help staff test the result. Give them a clear route for product and process decisions; they shouldn't acquire payment authority or override a company's approval rules through a delivery assignment.

Specialists can cover more than a single company, but their availability needs a calendar. A technical lead who reviews designs on Fridays can't also provide instant approval for every midweek deployment. Arrange backup for critical decisions and document how the team escalates an urgent issue.

Microsoft's guidance on AI centres of excellence distinguishes setting standards, building agents, and monitoring production. It also highlights central queues and local readiness as operating-model concerns. A PE portfolio adds separate company management and access boundaries, so adapt that framework to each company's authority.

Select work that the companies can support

Ask a company to bring a concrete workflow with evidence of its current cost or delay. The request needs a sponsor, a process owner, representative cases, and a systems contact. Record what staff do when the normal path fails. A request for an AI strategy presentation doesn't provide enough detail to reserve engineering capacity.

Choose a first project that fits the company's ability to operate it. A draft assistant with a named reviewer may suit a team with limited technical support. A workflow that writes to the ERP needs a stronger release process and a person who can respond when an integration fails.

Compare opportunities against their business effect and readiness. The most attractive idea can still wait if the company can't obtain source data or make approval decisions. Label the blocker and its owner so the shared team doesn't spend its delivery allocation chasing access.

In its May 2026 discussion of AI, Blackstone separates companies where AI is central from those with meaningful upside and those where it is less material. That framing supports different levels of attention. It doesn't imply that each company needs the same project or a dedicated AI hire.

Look for a second company with a related problem, but don't force it into the first company's design. A distributor's quote preparation and a service company's proposal preparation may share document extraction. Their commercial terms, approval paths, and source systems can still require different local implementations.

A small-business discussion about using AI without a specialist hire captures a practical concern: who does the continuing work around the tool? Treat that question as reader context, rather than evidence of adoption or returns. Your project brief needs a real answer for the participating company.

Budget specialist capacity before promising starts

Count the team's available working days after leave and existing commitments. Reserve time for deployed-system support, technical review, and improvements to shared components. The rest is the delivery budget. Projects that consume it need an explicit start and an expected review point.

Consider an illustrative month with two specialists who each have 20 available working days. Together they have 40 specialist-days. If the plan reserves 12 days for support and maintenance and eight for discovery and review, it leaves 20 days for delivery. Those assumptions describe a planning example, not a benchmark for an effective AI team.

Two projects estimated at ten specialist-days each consume that month's delivery budget. A third project needs a later slot, a smaller scope, or additional capacity. Local staff time is separate: the shared team can't replace the company owner's work on source data, acceptance, and operational decisions.

Check scarce skills separately from the total. A team may have enough overall time but too little integration-engineering capacity for two ERP projects. Record the dependency on that specialist and avoid promising concurrent starts that require them to work in both companies at once.

Use discovery to narrow uncertainty before you reserve a delivery slot. Write the assumptions behind the estimate and identify the earliest test that can invalidate them. An inaccessible legacy system or an unreliable data export can change the scope substantially.

Set a limit on work in progress that matches support obligations. A company awaiting its data export can return to a readiness queue, releasing the build slot. Keep the reason visible and agree how it re-enters the queue. Don't let unfinished projects accumulate under an optimistic completion percentage.

Publish the queue and its decision owner. Portfolio executives need to know which requests have capacity, which need local preparation, and which require outside help. Track waiting time alongside delivery time; a small team that finishes builds quickly can still leave companies waiting months to start.

Reuse tested patterns with clear limits

A reusable pattern is a maintained way to solve a repeated problem. It can include extraction code, a review interface, an evaluation harness, and deployment instructions. State the inputs it accepts, the actions it permits, and the conditions where it fails.

For example, a document-intake pattern can extract fields and send uncertain cases to a reviewer. Each company still defines its required fields, accepted document types, and downstream decisions. Supplier invoices and customer claims can share an extraction method while needing very different review rules.

Give shared components a maintainer and a version. Record which companies use each release. A change to extraction behaviour needs evaluation against the receiving company's cases before rollout. Share synthetic examples or approved, sanitised test material; keep confidential records within the company's permitted environment.

Package the operating instructions with the code. Include setup, permissions, logging, and a rollback procedure. A local engineer needs to understand what they can change without breaking compatibility. If the shared team alone can interpret the package, the portfolio has transferred its dependency to a central bottleneck.

Measure reuse through the second implementation. Record adaptation hours, defects, and support effort. If the second company needs a near-total rewrite, describe the original work as a company-specific solution and extract only the components that repeated.

Keep vendor purchasing guidance separate from technical reuse. An approved supplier list can reduce repeated assessment, but each company still checks the terms and configuration for its use. A shared commercial agreement doesn't authorise the transfer of company data into another company's account.

Plan for a company leaving the portfolio. It needs access to the code and instructions it requires to operate, subject to agreed rights, and a path to replace shared services. Test the handover while the current owners can still explain it. Include that work in the shared team's capacity plan.

Make local ownership practical

A process owner needs authority and protected time. They decide which output meets the business need, organise representative testing, and approve the operating change. Naming a busy functional manager without adjusting their workload creates an approval queue.

Work alongside the staff who handle exceptions. Let them test difficult cases before launch and explain what information they need to reject a result. Translate those findings into the interface and the runbook. Training should cover the actual workflow, including when to stop using it.

Before release, name the person who watches failures and the team that responds. Define the hours of coverage and where users raise problems. The company should know how to pause the workflow and return to its agreed manual process if the system fails.

Keep release approval separate from benefit measurement. The process owner can accept a workflow that works correctly, while finance checks whether the business has realised a cost reduction. Released staff capacity may support growth or clear a backlog without reducing payroll. Record that outcome accurately.

Use a handover rehearsal. Ask the receiving team to handle an exception, find the active configuration, and explain the recovery path without relying on the visiting specialist. Record assistance and close the gaps before expanding volume.

The shared team can support a component while a local service owner takes responsibility for the full workflow. Write that boundary into the support agreement. If an ERP outage blocks processing, the company needs a route to its ERP support team rather than sending every failure to the AI specialist.

Our guide to ownership after AI launch covers these continuing responsibilities in more detail. Across a portfolio, repeat the ownership questions for each company; a common template doesn't prove that the named people have accepted the work.

Buy outside help for a specific gap

Bring in outside help when the work needs a scarce skill, has a defined delivery peak, or requires independent review. An ERP integration specialist can handle a system the shared team rarely encounters. A deployment engineer can help a company establish its first production path while a local team learns to operate it.

Write a bounded brief with deliverables and acceptance tests. State the systems involved, the person who approves access, and the handover expected at the end. Ask the supplier to distinguish implementation work from support and to show the costs that continue after the engagement.

Require delivery into company-controlled systems with appropriate access. Agree how the company receives source code, configuration, and operating instructions. If the supplier retains a service dependency, document its support terms and the path to replace it. A short project can leave a long operating obligation.

A forward deployed engineer fits work that needs both engineering and direct investigation of company workflows. A consultant can help clarify process changes and decision rights. A software engineer fits a defined build with established requirements. Choose against the gap, and check the person's actual skills rather than relying on the title.

If the same external task returns every month, reassess the staffing model. A recurring need can justify a local hire or a continuing specialist arrangement. Include coordination and supervision in the comparison; a supplier's day rate alone doesn't describe the cost of delivering and maintaining the workflow.

Don't outsource acceptance. The company owns the business decision to use the result, and the shared team owns any shared component it adopts. Preserve the test evidence and agree who fixes defects discovered after handover.

Review outcomes and change the model

Use a regular portfolio review to decide what deserves capacity next. For each live workflow, examine the accepted business outcome, quality failures, and full operating cost. For the shared team, examine queued demand, time spent supporting previous releases, and the effort required to adapt patterns.

A portfolio-wide AI scorecard can hold comparable evidence without forcing identical goals. Pair it with the capacity view. A successful pilot may need more support than expected, leaving less time for the next company's build.

Start with a bounded discovery and delivery cycle. Choose the first company, establish its baseline, and deliver the smallest workflow that tests the intended outcome. Once the receiving team can operate it, test reuse in a second company and review what changed. Keep dates conditional on actual readiness and capacity.

Expand central staffing when recurring specialist demand and shared maintenance justify it. Move more delivery into a company when it has the team and authority to own the work. Stop sharing a component when differences cost more to maintain than separate implementations.

This model fits a PE operating team with limited specialist capacity and companies willing to assign real local owners. It also fits a corporate group with comparable operating units. If participating companies need continuing hands-on support for every change, budget that service explicitly before promising wider coverage.