Told to "set up an AI Center of Excellence," one CIO did exactly what the playbooks advised. Within a year the CoE was fully staffed, with a governance charter, a shared toolkit, and a roadmap deck the board admired. It had also shipped almost nothing. The team could advise, but it could not decide, fund, or deploy; every use case still depended on a business unit with its own priorities and no obligation to act. The CoE had become what many become, a steering committee with a mandate but no authority. The lesson was uncomfortable and important. The problem was never the absence of a team. It was the absence of an operating model, the structure that decides who owns AI, who funds it, who builds it, who runs it, and how it moves from pilot to production, again and again. Capability had been organized. It had not been operationalized.
Executive Summary
The first two articles in this series established the gap between AI investment and value and mapped where value actually concentrates. This one addresses the machinery that captures it. A prioritized portfolio of high-value use cases still stalls without a system to deliver them repeatedly, and that system is the AI operating model. It is not a tool, and it is not a center-of-excellence box on an organization chart. It is the set of decision rights, capabilities, and ways of working that industrialize the path from idea to production. Its defining choice is structural, how central or distributed AI ownership should be, and the evidence is clear: enterprises that scale AI are far more likely to run a hub-and-spoke model, and they earn their way there through maturity rather than declaring it on day one.
Figure 1. The AI operating model: a delivery system built on a shared data and platform foundation.
Why the Operating Model Is the Missing Piece
Most enterprises do not have an AI problem. They have an AI-at-scale problem. They can run a pilot; what they cannot do is run the fortieth pilot as reliably as the first, graduate it into production, and repeat that across dozens of teams without reinventing the wheel each time. McKinsey's research is blunt that the barrier is a leadership and operating-model problem, not a technology one. The operating model is what converts a promising use case, the output of a good value map, into a producing one, and then does it again. Without it, every initiative is a bespoke project that consumes senior attention and rarely compounds. With it, delivery becomes a repeatable capability, and the marginal cost of the next use case falls instead of resetting to zero.
What an AI Operating Model Actually Is
An operating model is easiest to define by what it decides, not by the boxes on a chart. It answers five questions: who sets strategy and prioritizes, who funds, who builds, who operates in production, and who answers to the regulator. It rests on a shared data and platform foundation, so teams consume infrastructure rather than rebuild it, and it standardizes the ways of working that move an idea through evaluation, deployment, and monitoring. This is why the shorthand "stand up a Center of Excellence" is necessary but not sufficient. A CoE without funding authority, decision rights, or production ownership is a steering committee, and steering committees do not ship. The label matters far less than the components beneath it: prioritization, data and platform, delivery and operations, talent and roles, governance, and adoption. Weakness in any one caps the performance of the whole. The strongest operating models also make a single team accountable end to end for each production use case, so ownership does not evaporate at the handoff from build to run.
The Central Choice: Centralized, Federated, or Hub-and-Spoke
Every enterprise designing an operating model chooses among three archetypes, and each is right for a different stage.
A centralized model concentrates AI talent, tooling, and decision rights in one team that serves the enterprise. It buys consistency and governance, and it is the natural starting point as well as the safest choice for regulated, high-risk use cases. Its cost is the bottleneck: one team cannot know every domain or move at every unit's speed. A federated model pushes ownership into the business units, with the center setting standards and coordinating. It buys speed and domain proximity, and it fits highly diversified, mature enterprises, but its risk is duplication and governance erosion as units optimize for themselves. The hub-and-spoke model is not a compromise between the two but a deliberate design: a central hub owns standards, platform, and governance, while embedded spokes own use cases and delivery in their domains. It is where most successful scalers land. Dataiku found that enterprises which scale AI are roughly three times more likely to use hub-and-spoke than any other structure, and IBM found that AI leaders operating centralized or hub-and-spoke models achieve materially higher return than their decentralized peers.
Figure 2. Three operating-model archetypes, each suited to a different stage of maturity.
Sequencing: You Earn Your Way to Federation
The most common mistake is choosing the destination as the starting point. McKinsey's operating-model work describes a progression: most enterprises begin centralized, then progressively hand ownership to domain teams, moving to hub-and-spoke and eventually, at high maturity, to a federated structure. Federation is the destination, not the on-ramp, because an organization must first build a hub worth connecting to. The mechanism that makes the progression safe is the stage gate, explicit criteria backed by evidence from pilots that must be met before a use case, or the organization, advances. Enterprises that skip the gates tend to scale prematurely, building on foundations that cannot bear the weight, and then mistake the resulting failure for a failure of the technology. Maturity, not ambition, should set the pace.
Figure 3. Enterprises progress from centralized to federated as maturity grows.
The Regulated-Industry Lens
Regulation shapes the model independent of maturity. In banking, insurance, and healthcare, where AI decisions carry compliance exposure, McKinsey's analysis consistently finds that centralized governance produces better compliance outcomes and faster approval of regulated use cases, because traceability and auditability favour central oversight. The practical answer for these industries is a split: centralized control of risk, model governance, and data, with hub-and-spoke delivery for everything else. The hub holds the controls that must not vary; the spokes hold the speed. Getting that division right is often the difference between an AI program a regulator trusts and one that is quietly frozen.
Making It Real: Decision Rights and Stage Gates
An operating model becomes real the moment it is specific. Name the owners: who decides which use cases proceed, who holds the budget, who builds, who operates the system in production, and who is accountable for risk. Replace opinion-led progression with stage gates tied to measured pilot outcomes and treat governance as a product with users and a lifecycle, not a policy document written once and ignored, so that it enables delivery rather than obstructing it. None of this is glamorous, and all of it is what separates enterprises that ship from those that deliberate. The winners do not have better AI than their rivals; they have a better system for turning it into results.
Recommendations
Five priorities separate an operating model that scales from an org-chart exercise that does not:
- Match the model to your maturity, and sequence deliberately. Start centralized if you are early or regulated, plan the path to hub-and-spoke, and treat federation as a destination you earn.
- Assign decision rights explicitly. Name who decides which use cases proceed, who funds, who builds, who operates in production, and who owns risk. Ambiguity here is where delivery dies.
- Build the shared foundation first. Give the spokes a data and platform layer they consume rather than rebuild, so speed compounds instead of fragmenting.
- Progress on evidence, not enthusiasm. Install stage gates tied to measured pilot outcomes and hold the line on them even when a sponsor is impatient.
- Centralize risk, federate delivery. Keep model governance, data, and compliance central, especially in regulated industries, while pushing execution to the domains that own the outcome.
Business Impact
The return on getting the operating model right is both direct and compounding. Directly, shared infrastructure and consistent governance lift ROI, which is what IBM's finding of materially higher returns for centralized and hub-and-spoke structures reflects. Indirectly, an operating model narrows the gap between an enterprise's best team and its median team, because capability is shared rather than relearned, and it makes AI durable: higher-maturity organizations are more than twice as likely to sustain their AI initiatives for three years or more. The alternative is the steering-committee trap, a portfolio of pilots that never compounds into capability, and a leadership team that mistakes activity for progress.
Future Outlook and Conclusion
Agentic AI raises the stakes rather than lowering them. As systems begin to act autonomously, the questions the operating model answers, who owns, who governs, who is accountable in production, become more consequential, not less, because an ungoverned agent scales a mistake at machine speed. The enterprises that capture the next wave will be the ones building the operating model now, while the work is still deliberate. At Cubastion, this is the work we do with enterprise leaders: designing and standing up the operating model that turns AI capability into adoption at scale. Knowing where AI pays is one thing. Building the machine that reliably captures it is another, and it is where scale is won. The final question is what keeps that machine trustworthy as autonomy grows, the subject of the next article.