Quick Navigation
- Before we start — the organisational mistake behind many AI failures
- Why organisation design matters
- The major operating model patterns
- Platform, product, and governance roles
- Decision rights and ownership
- Capability pathways and centres of gravity
- How capability scales across the business
- Common failure patterns
- What good coordination actually looks like
- The operating model in one diagram
- Cheat sheet
Before we start — the organisational mistake behind many AI failures
An organisation can have strong technical talent, serious executive interest, and a healthy AI budget and still make very little progress.
Why? Because nobody agreed how AI work should actually happen.
Who approves tools? Who owns the platform? Who helps functions redesign workflows? Who decides what gets scaled? Who handles risk review? Who trains teams? Who measures value? If those questions are unresolved, the organisation will look busy while capability fragments underneath it.
This is why AI operating model work matters. It is not bureaucracy wrapped around innovation. It is the structure that determines whether innovation compounds or dissolves into isolated activity.
Why organisation design matters
Many AI programmes stall for a reason that has nothing to do with the model.
No one is sure who owns the platform. Product teams run their own experiments without standards. Governance shows up late. Procurement buys tools in silos. Data teams, engineering teams, and business teams all touch the same workflow with different incentives and no shared operating model.
Technology confusion is often organisation confusion wearing a technical mask.
The major operating model patterns
Most organisations end up using one of three patterns:
| Pattern | Strength | Risk |
|---|---|---|
| Centralised | Strong standards and efficiency | Can become a bottleneck |
| Federated | Business units move faster | Standards may fragment |
| Hub and spoke | Balance of shared platform and local adoption | Requires active coordination |
There is no universally correct model. The right one depends on scale, maturity, regulation, and the organisation's existing ways of working. But there is a universally wrong model: accidental decentralisation with no shared rules.
Try it yourself — Which pattern are you already in?
Many organisations debate operating models as if they are choosing one from scratch. In reality, they are usually already living inside one, whether intentionally or not.
| Question | Centralised | Federated | Hub-and-spoke |
|---|---|---|---|
| Who approves major tools today? | |||
| Who builds reusable capability? | |||
| Who owns local adoption? | |||
| Who defines guardrails? |
Map the answers honestly. You may discover that your official model and your actual model are different.
Platform, product, and governance roles
AI work becomes manageable when responsibilities are explicit.
- Platform teams provide reusable tools, guardrails, and integration patterns.
- Product or workflow teams apply AI to specific user or business problems.
- Governance functions define policy, risk rules, oversight, and review requirements.
- Leadership sets direction, priorities, and investment boundaries.
The important move is to separate shared capability from local application without letting them drift apart.
Decision rights and ownership
Teams get into trouble when they share tasks but not decisions.
An AI operating model should clarify:
- who can approve tools
- who can launch pilots
- who owns platform standards
- who signs off high-risk use cases
- who is accountable for value realisation
Without decision rights, coordination turns into meetings without progress.
Capability pathways and centres of gravity
AI capability rarely grows evenly across an organisation.
It usually forms around a few centres of gravity:
- a digital or data team that understands the technology
- a function with strong incentives to improve workflows
- a small leadership group pushing strategic adoption
- a risk or policy team trying to keep pace with expansion
The job of the operating model is not to pretend those centres of gravity do not exist. It is to connect them so one group's learning becomes another group's starting point.
This is where pathways matter. People need to know how an idea moves from curiosity to pilot, from pilot to governed product, and from local win to shared organisational capability. If that path is invisible, AI remains a collection of talented exceptions.
How capability scales across the business
AI maturity grows in layers.
At first, a small group of motivated people experiments. Then teams want shared access, shared patterns, and help with adoption. Later, the organisation needs portfolio management, governance forums, platform reuse, training pathways, and capability champions inside functions.
Scaling is not mostly about headcount. It is about making the right support reusable.
The most valuable scaling assets are often surprisingly unglamorous:
- standard review and approval patterns
- reusable prompt or workflow templates
- shared vendor evaluation criteria
- approved architecture patterns
- training pathways for different role groups
- examples of successful use cases that teams can adapt
In other words, scaling is not the spread of tools. It is the spread of repeatable good judgment.
Common failure patterns
Watch for these:
- platform team becomes a service desk with no strategic leverage
- business teams bypass standards because central support is too slow
- governance acts only as a blocker, not as a design partner
- nobody owns change management or capability building
- local wins never turn into organisational capability
The operating model exists to prevent those failures from becoming normal.
What good coordination actually looks like
Coordination is one of those words every strategy document uses and very few organisations operationalise.
In a strong AI operating model, coordination means:
- local teams can move, but not invent guardrails from scratch
- central teams enable, but do not become bottlenecks for ordinary work
- governance participates early enough to shape design rather than reject it late
- leaders can see the portfolio, not just isolated activity
- shared platforms and patterns reduce duplicate effort over time
Good coordination should feel like reduced friction. If your model creates more meetings than momentum, it is over-rotating into ceremony.
The operating model in one diagram
flowchart TD
A["Leadership & Strategy"] --> B["Governance & Standards"]
A --> C["Platform Capability"]
C --> D["Product / Workflow Teams"]
B --> D
D --> E["Adoption & Value"]
AI scales when the organisation can repeat good decisions, not when it accumulates more tools.
Cheat sheet
| Question | Good default |
|---|---|
| What operating model works best most often? | Hub-and-spoke or federated with strong shared standards |
| What must be centralised? | Guardrails, platform patterns, policy, critical standards |
| What can be decentralised? | Local use case design and adoption within guardrails |
| What breaks most often? | Unclear ownership and accidental fragmentation |