ComparisonArtificial Intelligence
Choosing an AI operating model: centralized, hub-and-spoke or federated
An AI operating model settles who chooses which AI work gets done, who builds it, who owns the risk and who pays. The three common shapes, centralized, hub-and-spoke and federated, trade speed against control in different ways. This comparison sets them side by side, lists the shared services every model needs whatever its shape, and gives the signals that show when to move from one to another.
On this page
- Four questions an AI operating model answers
- Centralized, hub-and-spoke and federated models side by side
- Signals that point to each operating model
- What sits in the hub and what sits in the spokes
- Shared services every AI operating model needs
- Funding mechanics for AI platforms and teams
- A hypothetical manufacturer moves from centralized to hub-and-spoke
- Failure modes to watch whatever the model
- Questions and answers
- Sources
Four questions an AI operating model answers
Strip away the organization charts and an operating model answers four questions: who decides which AI use cases are funded, who builds and runs them, who owns the risk when something goes wrong, and who pays for the platform and the people. Most arguments about structure are really arguments about one of these four.
The answers differ because starting points differ. Where data, engineering talent and risk expertise sit today, and how alike the AI needs of different business units are, matter more than any reference design. The comparison here is vendor-neutral; a platform-specific team, such as a Salesforce Agentforce center of excellence, sits inside whichever model you choose.
Centralized, hub-and-spoke and federated models side by side
| Dimension | Centralized | Hub-and-spoke | Federated |
|---|---|---|---|
| Decision rights | A central AI team ranks and approves use cases | The center sets standards and holds the portfolio view; units propose and own use cases | Each business unit decides within group-wide policies |
| Who builds | The central team builds for everyone | The center builds shared components; embedded teams build use cases | Unit teams build and run their own systems |
| Funding | Central budget | Central platform budget plus unit-funded use cases | Unit budgets, sometimes with a platform levy |
| Speed | Quick at first, then queues form | Balanced once the center's services are usable | Quick where units are mature, uneven elsewhere |
| Risk control | Consistent and close to the builders | Common controls set centrally, applied locally | Varies by unit unless built into shared tooling |
| Reuse | High, because one team sees everything | High for platform and evaluation, moderate for use cases | Low unless deliberately coordinated |
| Talent | Concentrated, easier to hire and develop | Specialists in the center, product-minded builders in units | Spread thin, with harder career paths |
The highlighted column is the most common fit for organizations with several active business units. It is not a universal answer.
Signals that point to each operating model
- If
AI work is new, data is held centrally and only a handful of use cases are live.
ThenStart centralized, with a business owner named for every use case.
Scarce skills and first standards are easier to build in one place.
- If
Several business units run live use cases and the central queue keeps growing.
ThenMove to hub-and-spoke: keep platform, evaluation and risk review in the center and embed builders in the units.
The constraint has become capacity and business context, not standards.
- If
Units already run mature data and engineering teams with their own budgets.
ThenFederate delivery, but enforce shared controls through common tooling and a group-level AI inventory.
Mature units move faster alone, and controls hold only when they are built into the tools.
- If
Units are duplicating vendor contracts, models and evaluation work.
ThenPull those shared services back into a hub, even if delivery stays federated.
Duplicated spend points to a missing shared layer rather than a failure of federation.
What sits in the hub and what sits in the spokes
- AI center of excellence
Standards, model access, evaluation harness, risk review and the portfolio view.
- Operations team
Embedded builders working on forecasting, scheduling or quality use cases.
- Customer team
Embedded builders working on service, sales or marketing use cases.
- Finance team
Embedded builders working on reconciliation, reporting or audit support.
- Risk and compliance
A partner function that sets AI risk policy with the center and reviews high-risk uses.
- Platform engineering
Runs the infrastructure the center's shared services depend on.
Funding mechanics for AI platforms and teams
| Mechanism | How it works | Works well when | Watch for |
|---|---|---|---|
| Central budget | The center is funded directly and serves units free of charge | Demand is still young and needs encouraging | Unlimited demand and no signal of what is valued |
| Chargeback | Units pay for what they consume, such as build time or inference | Usage is measurable and units control their budgets | Units avoiding shared services to save money |
| Unit-funded with a platform levy | Units fund their own use cases and pay a fixed share for shared services | Several units are active under hub-and-spoke or federation | The levy treated as a tax unless services are visibly useful |
| Seed funding with handover | Central money funds pilots; units take on costs at production | Promising pilots need a path into unit budgets | Pilots that never find a business owner |
A hypothetical manufacturer moves from centralized to hub-and-spoke
Failure modes to watch whatever the model
The center turns into a gatekeeper
Early signalUnits describe the center as a queue or an approval step rather than a source of help.
MitigationJudge the center on time to production and reuse, and publish its service catalog.
Spokes drift from shared standards
Early signalEmbedded teams skip shared evaluation or register systems late.
MitigationBuild controls into shared tooling so the easiest path is also the compliant one.
Nobody owns risk across units
Early signalEach unit assumes the center owns risk, and the center assumes the unit does.
MitigationWrite the split of risk ownership into the charter and record it against every inventory entry.
Questions and answers
What does an AI center of excellence actually do?
It sets standards, runs shared services such as model access and the evaluation harness, keeps the AI inventory, reviews higher-risk uses and helps business teams deliver. In a hub-and-spoke model it builds reusable components rather than every use case. A center that only writes policy and approves projects tends to become a bottleneck that teams route around.
Where should the AI team report: the CIO, CTO, CDO or a business leader?
The reporting line matters less than the decision rights. A center reporting to technology leadership needs a clear mandate from the business to prioritize; one reporting to a business leader needs strong links to platform and security teams. Choose the line that gives the center authority over shared standards while leaving use-case ownership with the business.
How does the operating model relate to an AI management system?
A management system under ISO/IEC 42001 requires defined roles, responsibilities and authorities for AI, and the operating model is where those are decided. Settling who approves deployments, who owns risk and who runs incident response makes the ISO 42001 implementation far simpler, because the management system then documents decisions already made.
Can ColdAI help design an AI operating model?
Yes. ColdAI's AI strategy and roadmap work covers investment priorities, organizational readiness and technology selection1, and the operating model is part of organizational readiness. Broader redesign of how the whole business is organized sits with the transformation capability, and people and role changes with people and organizational performance.