AI Center of Excellence vs AI Factory: Which Model Scales

September 4, 2026

Ask whether you need an AI center of excellence or an AI factory and you are comparing two categories of thing. A center of excellence is an organizational unit. An AI factory is a delivery system. Enterprises ask anyway, because they used the CoE as a stand-in for the delivery system and hit the ceiling that follows. The arrangement that scales is the one where the center owns standards and delivery has a product layer of its own. Redrawing the org chart moves the bottleneck into a different box. Eurostat reports that 19.95% of EU enterprises used AI technologies in 2025, and 55.03% of large enterprises did, so who delivers the next use case is a working problem for half of Europe’s large companies.

What an AI Center of Excellence Is, and What It Cannot Do Alone

An AI center of excellence is an internal team of experts that concentrates scarce skills, sets standards and prevents fragmented, ungoverned AI adoption across the business. That is the definition in Microsoft’s Cloud Adoption Framework, which is equally careful about scope: the CoE advises business and technical teams. It does not become the delivery organization for everyone else, and its capacity does not grow with the queue of use cases behind it.

A center of excellence is an organizational unit; an AI factory is a delivery system. This article does not define the AI factory operating model or its building blocks, and it does not score your maturity. It compares the organizational shapes enterprises actually use, names the point at which each one stops working, and states the delivery condition you have to meet before you change shape.

One line in that guidance runs against the market consensus. AI capability is normally built on teams that already exist, so an organization running a Cloud Center of Excellence adds AI skills there, and a standalone unit is warranted only when current teams cannot absorb the work. Most guides on this topic open by telling you to found a new body; in the source they paraphrase, that is the last option.

Four Shapes Enterprises Actually Use

Four arrangements cover nearly every enterprise. Each buys something and charges for it, and the charge is what most comparisons leave out.

Shape	What you buy	What you pay for it	Condition for it to work
Centralized delivery team	Consistency and one visible standard	One queue in front of one team	Demand stays under the team’s capacity
CoE with selected delivery	Scarce expertise where it is scarcest	Advisory load grows faster than the team	Few enough parallel initiatives to advise on
Hub and spoke platform model	Standards plus delivery close to the business	A platform someone has to keep running	The hub ships shared services, not intentions
Fully federated	Maximum speed inside each unit	Duplicated work and drifting standards	Governance already sits inside the tooling

Centralization is the usual first move and holds while the initiative count is small. The CoE variant narrows the mandate to standards plus a few flagship deliveries, which protects the specialists and does nothing about the queue behind them. Both last as long as demand stays under capacity, and demand here rises faster than headcount approvals.

Hub and spoke is where most enterprises say they are going. It separates from federation only if the hub delivers what the business units would otherwise build themselves: environments, templates, shared services. Full federation buys speed and pays in duplicated work and standards that quietly diverge, which is survivable where controls already sit inside the tooling.

Choosing a shape is not a trade between consistency and speed. It is a decision about where the queue sits, and all four of them have a queue.

Where the CoE Model Breaks: Four Inflection Points

The moment to change the operating model shows up as symptoms, not as a score. Three of the four below are named in the Microsoft framework; the fourth comes from delivery work and costs the most.

Approvals take longer than the work they gate, so teams that could have finished sit waiting for a slot.
Expertise runs out before demand does, and access to the specialists gets rationed by seniority or by who asks loudest.
Priorities become a negotiation, with product teams and the center settling sequence instead of delivering value.
Teams route around the process. Building the solution takes less time than getting permission for it, so people stop asking.

The last symptom is the serious one: governance stops existing in practice while continuing to exist on paper. Standards then cover only the projects that came through the front door, and the gap usually surfaces as an incident. A center being bypassed has already lost the control it was created to hold.

None of this is a failure of the team. A small group of specialists produces excellent pilots, because a pilot is what that structure is built to produce: high skill, one system at a time, little operational surface. The limit appears in the step after it, and hiring into the center does not move it.

What an AI Factory Adds That an Org Chart Cannot

An AI factory is not a fifth shape. It is the layer that lets the next use case start from something instead of from zero: shared standards, shared platform services, a delivery practice that repeats, and controls written into how work is done rather than applied afterwards. The operating model has named building blocks, and the pillar article walks through each of them.

Without that layer, a reorganization relocates the same people. The central team that was the bottleneck becomes a hub with the same headcount and the same backlog, now with a coordination meeting attached. Ownership of the use case pipeline is a useful test: the center runs it in a centralized model, the platform team and business units share it in hub and spoke, and a federated model often has no single list at all. Shape decides who holds the pipeline; the layer underneath decides whether it moves.

The Handover Condition: You Cannot Go Advisory Before the Platform Exists

The Microsoft framework states the condition without hedging: a CoE can move from gatekeeper to advisor once AI governance is embedded in platform operations, with delivery handed to platform teams and the center setting guardrails instead of approving requests. The condition sits in the word embedded. Four things are true before that handover, not after it.

Standards exist in executable form: templates, preconfigured environments, defaults that apply unless somebody overrides them. A document teams are asked to read is a request, not a standard.
A named team maintains that layer as a product, with an owner and a budget, rather than in the gaps between project deadlines.
Compliance checks happen inside the way teams work, not at a committee sitting between a team and its release date.
One place shows what is in production and who is accountable for it, by name rather than by department.

Here is the control question. If you moved your CoE into an advisory role tomorrow, what would enforce the standards on Monday? If the honest answer is that people will remember, the condition is not met and the change will produce drift with a nicer diagram. Microsoft’s guidance on governing AI makes the same point from the other side: governance is an operating function, not a review stage.

Accountability outlives whichever shape you pick. The NIST AI Risk Management Framework, voluntary and non-regulatory, puts its GOVERN function around the culture, roles and responsibilities that carry risk management through an organization. Named people hold responsibilities. A shape on a slide holds nothing.

The Roles a CoE Rarely Has

The staffing list for an AI center of excellence is consistent across sources: an executive sponsor, a dedicated lead, senior data scientists, machine learning engineers, governance and AI security specialists, AI operations professionals. That roster sets standards and runs pilots well. It is thin on the roles that keep production systems alive on a Tuesday afternoon, and no reorganization creates those roles by itself.

The evidence on what production demands is better than the anecdotes usually offered. Shankar, Garcia, Hellerstein and Parameswaran interviewed 18 machine learning engineers working on production systems for their 2022 study Operationalizing Machine Learning: An Interview Study, and reported three variables that decide whether a deployment succeeds: velocity, validation and versioning. All three are daily practices attached to a running system, not quarterly reviews. Kreuzberger, Kühl and Hirschl define MLOps through the principles, components and roles needed to operate machine learning products, and the roles are the part CoE staffing plans skip.

The public sector version is instructive. The GSA IT Modernization Centers of Excellence runs artificial intelligence as an advisory unit serving many agencies, not as the team that ships each agency’s systems. The useful staffing question is which roles hold production, and whether anyone in the organization holds them today.

Choosing Your Model: Five Questions That Decide the Shape

Five questions settle the shape faster than a workshop, because each has a factual answer people inside the organization already know.

How many AI initiatives have to run in parallel over the next twelve months?
Is there any shared layer that more than one team already uses?
Who is accountable for what runs in production today, by name rather than by team?
What happens to a standard if the center stops enforcing it next week?
Are teams bypassing the process, and if so, how long has that been going on?

None of the four shapes is wrong. The error is staying in one whose inflection points have been visible for several quarters, and the second error is changing shape while the delivery layer is still a plan. Standards can be set internally by people who know the business. The delivery layer is usually faster to stand up with a partner who builds one every quarter.

That is our work. Our enterprise AI factory service covers the platform services and delivery practice that let a center step back from approvals, and our generative AI delivery teams build the use cases running on it. If this argument is live in your organization, talk to our AI delivery team and we will walk the five questions with your leads.

Frequently Asked Questions

What is an AI center of excellence?

An AI center of excellence is an internal team of experts that concentrates AI skills, sets standards and stops fragmented, ungoverned adoption across the business. It usually owns strategy, capability building, pilots and reporting. It is not a delivery organization for the whole enterprise, and it fails as one once parallel initiatives pass what the team can advise on.

Do you still need an AI center of excellence once you run an AI factory operating model?

Yes, in a different role. Standards, scarce expertise and policy stay with the center, while delivery moves to the platform team and the product teams using the shared layer. The center goes from approving work to defining the guardrails work runs inside, a smaller mandate and a more durable one.

When should an AI CoE move from control to an advisory role?

When AI governance is embedded in platform operations and not a moment earlier. The observable triggers are approval queues, rationed expertise, priority disputes and teams bypassing the process. The condition for acting on them is a shared layer that enforces standards without anyone approving each request.

Centralized, federated or hub and spoke: which AI operating model scales best?

Hub and spoke is the only one that gives consistency and closeness to the business at once, and only when the hub delivers working shared services. Without them it is federation with an extra meeting. Centralized models scale until the queue forms; federated models scale speed and pay in duplicated work.