The AI operating model. Centralised or federated.

What an AI operating model is.

An AI operating model is the way a company organises the people, decisions, funding and platforms that let it build and run AI at scale. It answers four questions that pilots never have to: who decides which use cases get built, who owns the shared platform and data, who is accountable when a model is in production, and how a capability built in one corner of the company reaches the rest of it.

This is the layer that separates a company with a dozen impressive demos from one where AI is genuinely part of how work gets done. As we set out in the AI-augmented enterprise, the hard part is almost never the model. It is the organisation around the model, and the operating model is the shape of that organisation. Get it wrong and you either strangle AI in a central bottleneck or scatter it into a hundred incompatible experiments that never compound.

The three shapes, and what each one costs.

Three patterns cover most of what large enterprises actually run. Each buys you something and charges you for it.

Centralised: one team owns AI.

A single central team owns the platform, the models, the standards and the delivery. Everything AI flows through it. This buys depth and control. The talent sits together and gets better faster, the standards are consistent, governance is straightforward because one team holds the pen, and there is no duplicated spend. It is the fastest way to build real capability from a standing start.

The cost is throughput and distance from the business. The central team becomes a queue, and the business units wait. Because the builders sit far from the operational reality, they can ship technically sound systems that miss the domain in ways only the front line would have caught. Centralised is excellent early, and it becomes the bottleneck precisely when demand takes off.

Federated: every unit runs its own.

Each business unit builds and runs its own AI, close to its own problems. This buys speed and ownership. The people building the system understand the domain, the work reflects real priorities, and no one waits on a central queue. Units feel accountable because the capability is theirs.

The cost is duplication and drift. Three units solve the same problem three times, on three stacks, with three data pipelines. Governance fragments, because each unit sets its own bar, and the company loses the ability to see, or defend, what AI is doing across the whole. Under the EU AI Act, that lack of a consistent view is a genuine exposure, not a tidy-desk preference.

Hub-and-spoke: central platform, local delivery.

A central hub owns the platform, the shared data, the standards and the governance. The spokes, embedded in the business units, own delivery and the use cases. This is where most large enterprises settle, because it keeps the expensive, reusable things central and pushes the domain-specific work out to where the knowledge lives.

Centralise the platform and the guardrails. Federate the use cases and the delivery. Almost every durable AI operating model is a version of that sentence.

The hub gives you one platform instead of ten, one set of guardrails, and a place where scarce senior talent compounds. The spokes give you speed and domain fit. The tension to manage is real: the hub must serve the spokes rather than police them, or the model quietly collapses back into a central bottleneck wearing a new name.

How to choose the model you need now.

Choose based on your maturity, not on an org-chart preference. The mistake we see across Paris, Dubai, Singapore and Bali is a company copying the operating model of a firm three years ahead of it, and inheriting a structure its capability cannot yet fill.

A short diagnostic:

• Maturity. Little in production and thin AI talent points to centralised, to build the muscle in one place before spreading it.
• Demand. Many units with real, distinct use cases and pressure on the central queue points to hub-and-spoke, or to federating delivery.
• Regulatory exposure. High-stakes, regulated decisions raise the value of central governance and a single, auditable view, which argues against pure federation.
• Talent. Scarce senior AI talent argues for a strong hub where it compounds, rather than being thinned across every unit.

Most companies should read this as a sequence rather than a single answer. The model that is right today is usually not the one that is right in two years.

The operating model evolves as you mature.

Treat the operating model as a path, not a fixed choice. The pattern that works is to start centralised, build a real platform and a delivery track record in one place, then shift toward hub-and-spoke as the platform hardens and the standards are strong enough to hold under federated delivery. You centralise to learn, then push delivery outward once the centre can support it without losing control.

Two things make that evolution safe. First, a platform and guardrails solid enough that a business unit building on them cannot easily go wrong, which connects directly to the technical foundations in AI agent architecture. Second, a funding and value model that holds whatever the shape, because an operating model with no business case discipline simply scales spending faster. The structure decides how fast you move. The value discipline decides whether moving fast is worth it.

Where we come in.

We help leadership choose the operating model that matches where the company actually is, then build the parts that make it work: the central platform and guardrails, the delivery model in the business units, the funding and the decision rights. We are as willing to tell a company to stay centralised for another year as to help it federate, because the failure mode is almost always adopting a structure the capability cannot yet fill.

The Consulting team in our Paris, Dubai, Singapore and Bali offices is reachable from the brief form below. We answer within one working day, with the partner who will sit on the file.