AI Shared Services for a Holding Company, Without Mixing Subsidiaries

A holding company can share AI services across its subsidiaries by centralizing the platform, model access, engineering standards and review practice, while each subsidiary keeps its own agent memory, records, channels and permissions. The shared layer supplies capability, the entity layer holds the boundaries, and a named owner decides what may cross between them. The rest of this article shows how to draw that line and where it tends to break.

Key takeaways

• Share the platform and the know-how for running agents, not the working data each subsidiary holds.
• Give every subsidiary its own memory store, record set and permission scope, with no inheritance from the parent by default.
• Write down what may cross entity boundaries, who approves it, when it expires and how it is logged.
• Start with one low-risk shared service, such as evaluation templates, before touching customer or employee records.
• Review entity access on a fixed schedule and test that one subsidiary's agent cannot reach another's records.

Why holding companies share AI services at all

Subsidiaries in a group often start the same work separately. Each one selects a model, writes its own prompts, builds its own logging and negotiates its own access to tools. The result is uneven quality, repeated mistakes and several vendor relationships that nobody at group level can see. A shared service removes that repetition: one team maintains the evaluation method, the security baseline and the operational runbook, and every subsidiary uses them.

The reason to share is not to pool everything. Sharing knowledge about how to run agents is useful, while sharing the agents' working memory is usually a liability. A subsidiary's customer history, supplier terms and staff notes belong to that entity, may fall under different contracts and may need to be deleted on a different schedule. A holding company can move quickly on the first without accidentally making the second common.

What to share and what to keep separate

Make the split explicit before any build starts. Write it as two short lists and ask each subsidiary's leader to confirm it in writing.

• Share: model provider agreements and procurement terms, evaluation templates for generic tasks, logging and trace formats, tool design standards, the security baseline and the incident runbook.
• Keep separate: agent memory, customer and employee records, mailboxes and chat workspaces, tool credentials issued to each entity, approval authority, data location and retention rules, and the test cases that reflect that entity's real work.

Some items sit in between. Prompt libraries can be shared as templates while staying private where they contain pricing logic or client handling. Evaluation results can roll up to group level as pass or fail counts, while the underlying transcripts stay inside the entity. Decide these cases one at a time and record each decision, because the boundary sheet is only useful if someone can check it later. Shared model contracts also raise lock-in questions, which are covered in how to avoid AI vendor lock-in with business agents.

Designing the boundary: memory, records and permissions

Separation has to be enforced by the system, not requested in a prompt. An agent told to ignore another subsidiary's data can still be steered into using it by a poorly phrased request or by a retrieved document. Put the boundary in the infrastructure: each entity gets its own memory store or a namespace that retrieval cannot cross, its own tool credentials, and authorization checks that run on every action rather than once at login. The layers involved are described in the seven layers of company AI infrastructure.

Retrieval needs particular attention. When an agent answers from company documents, the retrieval layer decides which passages the model can see. Filter by entity identifier at query time, before ranking, so that a document from another subsidiary never reaches the model context. Keep a log of which sources were retrieved for each answer, since that log is the evidence you will need when someone asks why an answer contained a particular fact.

Credentials follow the same rule. Use entity-scoped accounts and narrow scopes for each tool, so the agent serving one unit cannot call the finance system of another even when both run on the same platform. Standard authorization guidance favors checking permissions at the point of each action and denying by default. Apply that to every shared component, including the parent team's own tools.

A step-by-step plan for the first shared service

Start with one service that is useful, low in personal data and easy to measure. Evaluation is often the best choice, because every subsidiary needs it and it can be built without moving customer records. Work through these steps in order.

• First, name one owner at group level for the shared service and one accountable lead in each subsidiary.
• Second, write the boundary sheet: what is shared, what stays in each entity, and which data classes are excluded from the shared service entirely.
• Third, build the shared runner so that every result carries an entity tag, allowing scores to be compared without exposing transcripts.
• Fourth, have each subsidiary write its own test cases from real past work, reviewed by its lead, and store them in its own space.
• Fifth, define one success criterion per subsidiary and one at group level, both observable in logs rather than in anyone's impression.
• Sixth, run the first cycle, review everything that crossed a boundary, and correct any leak before adding a second function to the shared layer.

Illustrative scenario: one evaluation service for three subsidiaries

Illustrative scenario: a holding company has a logistics unit, a retail unit and a professional services unit, each running a customer-facing agent. The parent team builds a shared evaluation runner that reads test cases from each unit's own store and writes results tagged with the unit name. During the first review, the logistics lead notices that the default dashboard shows raw transcripts to every lead. The parent team restricts the dashboard to the owning lead, shows only pass rates at group level and records who opens each transcript. No retail customer record was ever in the shared store, so the fix was a configuration change rather than a data cleanup. The scenario is invented to show the decision points.

Who decides what crosses the boundary

Governance is where shared services usually drift. A small group committee, meeting on a fixed cadence, can own the boundary sheet and approve exceptions. Each exception should state the data involved, the reason, the expiry date and the person who will remove it. The NIST AI Risk Management Framework is a useful reference for this kind of structured discussion, because it asks organizations to govern, map, measure and manage risk in their own context rather than adopt a generic checklist.

Changes to shared components should follow the same written request and approval path as changes to a single agent. That way a fix made for one subsidiary is visible to the others before it spreads. For the permission side of this work, the steps are set out in how to run a permission review for your AI agents.

Where shared services break, and how Be Human handles it

Four failure points recur. A shared dashboard exposes more than intended, a credential is reused across entities, a retrieval index is built once for the whole group without entity filters, and no one owns the boundary sheet after the first month. Each is cheaper to prevent at design time than to correct after a subsidiary has come to rely on the wrong behavior.

Be Human designs and operates this kind of layer as a managed service. A first engagement defines one useful role, the memory and tools it needs, the approval boundaries and an observable success criterion, so the entity split is written down before anything is connected. Managed operations then cover monitoring, recurring evaluations, integration maintenance, permission review and incident response, with controlled improvements made through a documented change path. The work is delivered remotely in English and Portuguese.

If you are unsure which shared function should come first in your group, the free Be Human AI diagnostic can help you find the first task worth handing to an agent.

Frequently asked questions

Can a holding company run one AI agent for all its subsidiaries? Usually it is better to run one shared platform with a separate agent for each subsidiary. A single agent with shared memory makes it hard to show which entity's data an answer used and complicates deletion when a contract ends. Shared components such as evaluation methods, logging standards and security reviews can still serve every entity.

Which AI services are safest to centralize first? Evaluation templates, logging formats, security baselines and incident runbooks are usually the safest starting points because they do not require moving customer or employee records. Model access can also be centralized if the contract terms have been reviewed for data use and retention. Anything that touches an entity's records should wait until the boundary sheet and permission checks have been tested.

How do we prove that one subsidiary cannot see another's data? Test it directly. Create requests from one entity's agent that target the other entity's records, and confirm that each attempt is denied or returns nothing, with the denial recorded in the logs. Repeat the test after every change and during scheduled permission reviews, because a passing result from last quarter says little about a change made this week.

Does centralizing AI services reduce costs? It can, but the more reliable gain is usually consistency and fewer duplicated builds. The actual effect depends on what each subsidiary was already spending and on how shared costs are allocated. Decide budget ownership before launch so that the shared service does not become a cost that nobody is willing to defend.

Be Human editorial guidance. Examples are illustrative unless explicitly attributed. Sources provide background; implementation choices depend on your workflow.