How to Manage AI Across Business Units

Multi-business-unit companies get AI wrong in two opposite directions. Centralize too much and units route around the center, building on corporate cards and personal accounts. Devolve too much and the company ends up with five incompatible stacks, five sets of credentials, and no way to answer what is running. This guide gives the split that works and the mechanisms that make sharing actually happen.

What belongs where?

Element	Centralize	Devolve	Why
Model access and gateway	Yes	No	Scale, cost attribution, data enforcement
Agent identity and permissions	Yes	No	Security and auditability
Connectors to shared systems	Yes	No	Build once, reuse everywhere
Evaluation harness and tooling	Yes	No	Consistency and reuse
Observability and inventory	Yes	No	Visibility across the estate
Standards: evidence, security, data	Yes	No	Consistency and regulatory position
Risk framework and appetite	Yes	No	One risk position for the company
Use case selection	No	Yes	Units know their processes
Outcome ownership and baselines	No	Yes	Ownership follows accountability
Funding for agents	No	Yes	Money creates commitment
Supervision levels within appetite	No	Yes	Units live with the consequences
Unit-specific connectors	No	Yes	Only that unit needs them

The AI funding models for executives piece covers the platform-plus-product funding split that matches this structure.

How is the central team measured?

On enablement, not control. The metrics that keep a central team honest:

• Time to first agent for a business unit that has never built one.
• Platform adoption: what share of the estate runs on it.
• Reuse: how many agents use each connector.
• Review turnaround for the high-risk tier.
• Unit satisfaction, measured directly.

Measured on approvals performed or policies published, a central team becomes the bottleneck it was created to prevent. Measured on how fast units ship safely, it builds the paved road that makes governance automatic.

What are the two failure modes?

Bottleneck. Every deployment queues for central review, regardless of risk. Units wait months, then find workarounds, and the center loses visibility precisely because it insisted on control. The fix is risk tiering: the platform enforces controls for most agents, and review concentrates on the high-consequence few. The executive guide to AI agent governance covers the tiering.

Sprawl. Units build independently with their own providers, credentials, and standards. Nobody can produce an inventory, costs are unattributable, and the first incident reveals an agent nobody knew about. The fix is a paved road that is genuinely faster than the alternative, plus monitoring for unapproved services.

Both failures come from the same mistake: treating this as a control question rather than a service question.

How does sharing actually happen?

Not through goodwill or mandates. Through three mechanisms:

1. Reusable connectors. When the ERP connector exists, the next unit's agent starts weeks ahead. This is the strongest incentive to use the platform.
2. A visible inventory. Units can see what exists, who built it, and what it does. Most reuse starts with someone discovering that another division solved the problem.
3. Peer presentation. The unit that shipped presents at the quarterly forum, not the central team. Business units copy peers far more readily than they adopt central initiatives, and a divisional leader describing what worked is more persuasive than any platform roadmap.

How should governance work across units?

One framework, applied proportionately. A single inventory with owners and risk tiers, one risk appetite, one evidence standard, and one set of data rules, enforced by the platform. Units vary in how they apply supervision within appetite and in what they choose to build, not in whether controls apply. Where units operate in different jurisdictions, the framework accommodates regional rules rather than fragmenting. The data residency explained for executives piece covers the multinational case.

What about units at different maturity levels?

Expect and plan for it. A unit with a live agent and an operating rhythm needs a different relationship with the center than one that has never built anything. The center should offer graduated support: hands-on delivery for the first agent in a new unit, platform and standards only for mature units, and a clear path between. Treating all units identically slows the advanced ones and abandons the beginners.

What should executives ask?

• Can we produce one inventory across all business units today?
• What is the time to first agent for a unit that has not built one?
• Which connectors are reused, and by how many agents?
• Where are units routing around the center, and why?
• When did a unit last present what worked to its peers?

How can FISTA Solutions help?

FISTA Solutions builds the shared platform, connectors, and evaluation tooling that make devolved delivery safe, and delivers the first AI agent inside individual business units so they gain their own capability, through its AI enablement practice. Since 2017, FISTA has delivered 150+ projects for 50+ companies across 12+ countries.

To design the split between your center and your business units, talk to FISTA on WhatsApp, or read agentic AI and organizational design.