Should Every Portfolio Company Use the Same AI Platform?

A portfolio-wide AI agreement can reduce repeated supplier reviews and help companies buy on better terms. A common workflow needs more evidence: the companies must share enough of the underlying work, systems, and controls to make it worth maintaining. Decide what to share at each layer before committing the whole portfolio to a platform.

Define what a shared platform means

A PE team can share supplier assessment, contract terms, and training while each portfolio company keeps its own account. It can also operate a common model-access service with separate company environments. Or it can require every company to use the same application and workflow. Those choices have different costs and responsibilities.

A recent private equity discussion about AI guidance for portfolio companies asks whether operating teams should give central guidance or let each company choose tools. The question reflects a practical buying decision; the replies aren't verified evidence of portfolio returns. Begin by specifying which repeated problem the central team will solve.

Write down the proposed shared service, its users, and what stays with each company. A model gateway routes requests to approved providers and can enforce budgets. It doesn't, by itself, map ERP fields, resolve a customer's invoice dispute, or establish who can approve a payment.

AWS's hub-and-spoke architecture guide illustrates shared authentication, model access, and routing with tenant-specific resources across accounts. It demonstrates a possible infrastructure pattern, rather than a requirement to merge business applications. Use it as a reference if that pattern fits your existing cloud environment and support capability.

Compare workflows before choosing a common product

Map a few candidate workflows in each company. Record the task volume, present cost, source systems, exception types, and the person who accepts the result. Compare the inputs and decisions as well as the task name. Two finance teams that both process invoices may use different matching rules and approval limits.

Take an illustrative portfolio with a distributor and a field-service business. Both answer customer enquiries, but the distributor needs order lines, stock allocations, and shipment records. The service business needs technician availability and job history. They may reuse request logging and evaluation tooling while keeping retrieval and action logic separate.

Look for repeated components with stable boundaries. A connector framework may support several ERPs, but each connector needs company-specific mapping and permission tests. A document extraction component may repeat, while the validation rules determine whether the extracted fields mean the right thing locally.

For a buy-and-build group that already shares systems and operating rules, a common application may fit. For a portfolio spread across unrelated sectors, common supplier review or infrastructure may offer more repeatable work. Treat the level of standardisation as a conclusion from the workflow comparison.

Use an AI opportunity map to connect the choice to a documented value lever. A requirement to use a platform doesn't establish that a company has a valuable workload for it. Include a path for a company to defer adoption while it repairs the records or process the workflow needs.

Keep company data and permissions separate

Map the proposed data flow from each company's source system through retrieval, model calls, logs, and support tools. Identify every place that stores or exposes customer records, prompts, or responses. Define access by company and role, including the central team's administrators and suppliers.

AWS's tenant-isolation guidance explains that successful authentication doesn't establish isolation between tenants. Apply the company boundary when accessing resources. For an AI application, test retrieval, cached responses, job queues, exports, and logs as well as the visible interface.

Test a user from Company A requesting Company B's document, a reused job identifier, and a support account with excessive access. Test revocation after a staff member leaves. Derive the company context from trusted identity and routing controls; don't accept a company label supplied in a prompt as permission to retrieve records.

Microsoft's commercial Copilot privacy documentation, checked on 3 October 2026, says Copilot surfaces organisational content that the user has permission to view, including permissions through inter-tenant collaboration. It also directs administrators to check agents' terms and data access. Review existing sharing permissions before rollout and inspect every connector or agent that extends access.

Have each company's accountable team review data rights, retention, processing locations, and relevant contractual restrictions. Ownership of a portfolio company doesn't establish permission to put all its records into a shared knowledge base. Start portfolio reporting with approved aggregate measures; give any request for underlying records a defined access purpose and approval path.

If teams want to share prompts, evaluations, or workflow examples, remove sensitive company facts and check the rights to reuse the material. A corrected support answer can contain confidential pricing. Share the reusable method only after reviewing its contents.

Negotiate terms without forcing the wrong tool

Central procurement can prepare an approved supplier list, ask consistent security questions, and negotiate volume terms. Confirm whether the agreement covers separately owned companies, new acquisitions, and entities that later leave the portfolio. A headline discount needs an eligible customer and a workload that actually uses the service.

Ask how the supplier charges for seats, consumption, support, and implementation. Check minimum commitments, unused capacity, price changes, and contract renewal. Request an allocation method that lets each company see its own spend. The central team needs to explain who pays for shared capacity and exceptions.

Keep the application decision tied to the use case. A drafting assistant already included in a company's software estate may fit document preparation. A workflow that writes to an ERP needs validated integration and action controls. Compare the supported work before assigning licences or funding a bespoke build.

Create a short exception process for tools outside the approved list. Require a named owner, the reason the existing options don't fit, a data review, and a budget. Set a review date so an experiment doesn't become an unsupported permanent service. Measure exception frequency: repeated exceptions may show that the approved offering misses a recurring requirement.

Calculate the cost beyond the licence discount

Compare the current arrangement with a shared option over the same period and scope. Include migration, connectors, local data repair, training, central operations, and ongoing support. Include staff review and rework in the delivery cost. Keep claimed workflow benefits separate until the pilot measures them.

Consider an illustrative six-company portfolio, using annual figures in US dollars. Current licences cost $300,000. A shared agreement quotes $240,000, giving a $60,000 licence saving. The shared option also needs $35,000 in additional annual central operations, $70,000 in initial platform work, and $45,000 in initial local adapters.

Those assumptions give a first-year shared cost of $390,000, or $90,000 more than the current licence spend. With the setup complete, the stated recurring cost is $275,000, saving $25,000 a year. This comparison assumes other local costs stay unchanged and no further setup costs arise; add any changed maintenance, review, or support cost before using it in a decision.

The example isn't a vendor quote or a forecast. It shows why a licence discount can coexist with higher initial spend. A measured workflow benefit may justify the implementation, but the investment case must name the benefit and who will realise it. Our baseline guide explains how to make that comparison.

Allocate shared costs openly. Record the basis for a fixed service fee, usage charge, or central subsidy. Track accepted work and total delivery cost by company so a busy tenant doesn't hide the cost of idle commitments elsewhere. Use the inference-cost ledger method to trace attempts and review work through to completed outcomes.

Assign shared and local delivery owners

The central team needs an owner for the service contract, release process, access controls, and incidents. Each company needs a business owner who approves the workflow and a technical owner for its connectors and production operation. State who can pause the workflow or revoke access when a problem appears.

Agree the support boundary before launch. If a supplier's model is unavailable, the shared service team can investigate routing and provider status. If an order draft uses the wrong unit conversion, the company's process and integration owners need the source evidence. Users need a single route to report either problem without diagnosing the cause themselves.

Publish the shared service's scope and response arrangements. If the central team only has capacity for office-hours support, a company running round-the-clock dispatch needs its own coverage or a different service design. Don't assign a critical workflow to a support model that can't meet its operating hours.

For model or prompt changes, run common component tests and the affected companies' workflow evaluations. Keep versions and rollback paths explicit. A release that improves document drafting can still change invoice extraction, so company owners need evidence for their own acceptance criteria.

Test reuse with two different companies

Choose a first company with a documented opportunity and an available process owner. Choose a second company that tests the intended reuse while introducing a meaningful difference, such as another ERP or a distinct approval rule. Record which code and operating steps repeat, and which need a new implementation.

Start with a bounded workflow, such as preparing a draft for staff review. Capture the baseline, eligible volume, correction rate, review time, and full delivery cost. Test denied access, system outages, duplicates, and manual fallback before giving the workflow authority to change records.

Measure engineering hours for the second deployment against the first. Separate reusable component work from local mapping, training, and process repair. A common login screen doesn't establish that the second deployment was cheaper. Also record whether local support demand falls after staff learn the workflow.

Set expansion criteria before the pilot. Require acceptable output, tested access boundaries, a funded support owner, and a credible cost comparison. If the second company needs extensive custom work, narrow the shared service to the components that repeat. Keep the remaining delivery with its local owners.

Plan for acquisition, incidents, and exit

For a new acquisition, use an onboarding checklist covering contract eligibility, identity, source-system access, and workflow readiness. Don't connect production records merely to meet a portfolio adoption target. The company owner should accept the specific workflow before staff depend on it.

Test whether a company can export its configuration, relevant records, and evaluation history when it leaves. Confirm contract transfer or replacement terms, ownership of custom code, and responsibility for migration. Give the company a path to operate independently without exposing the remaining portfolio's data or credentials.

Prepare for a shared-service incident too. Define which workflows can continue manually, who communicates with users, and how each company can stop sending requests. Limit one company's excessive demand so it doesn't consume everyone else's capacity. Record dependency risks alongside expected cost savings.

Before a wider commitment, put a short decision record in front of the operating partners: the repeated need, chosen shared layer, local exceptions, approved data boundaries, full cost, and exit plan. For a varied portfolio, start with the smallest shared service the evidence supports. Expand to a common application where repeated deployments demonstrate matching workflow requirements and lower total delivery cost.