Listen to this article
Jump to a section
In this article
Executive Summary
When all AI skill sits in one team, work slows down and everyone depends on that team. It does not scale. To make AI change last, move from “AI as a service” run by a central team to “AI as a capability” spread across the business units closest to the work.
Core conclusions
- The central team should own strategy, rules and the overall design. Delivery from start to finish should sit with the business units, because they know how the work is done.
- Scaling needs four things working together: tools good enough for real work, clear guardrails, business units that own their use cases, and skills built into daily work.
- Once these line up, teams ship faster, more people use the tools, and ROI can be traced. The central team stops being a bottleneck and can focus on design and on linking work across domains.
The argument, in ten slides
Save it, share it, or send it to whoever’s still routing every AI request through one team.
Public and private organisations are both spending more on artificial intelligence, and spending it faster. Many are held back by the way they are set up. AI skill sits in one central team, often led by a Chief AI Officer. Everyone else mostly just uses tools that team has built for them.
This model does not scale.
A central team cannot deliver AI change on its own. Central leaders are needed to set strategy, set the rules and keep the design coherent. The value comes from work done across the business. The people closest to operations, assets and services are best placed to spot waste, design fixes and improve them quickly.
The fundamental shift required is from “AI as a service” to “AI as an organisational capability”.
In the “AI as a service” model, business units send in requests and a central team builds and deploys the tools. This slows things down, limits testing and makes everyone depend on one team. It also caps how many use cases can be worked on at once.
In contrast, an “AI capability” model lets staff build things themselves. This doesn’t mean every employee becomes a data scientist. It means they can put together, adapt and run AI in their own area, using set tools inside controlled environments.
Where AI gets built when it moves from service to capability
AI as a capability: units own their use cases and KPIs and build on governed platforms. The centre sets standards and guardrails and runs shared infrastructure.
Schematic. The three units are the post's examples of people closest to the work.
Tooling
Staff need platforms good enough for real work, which hide the hard parts but keep control in place. This usually means low-code or no-code tools for building AI, copilots built into company systems, model libraries they can reuse, and secure ways to reach data. The aim is to make it easier to try things without weakening the technology.
Governance
Spreading AI out without control adds risk. So the guardrails must be clear. They include rules for classifying data, steps for testing models, audit requirements and cybersecurity controls. The ISO 42001 AIMS Readiness Checklist is a useful starting list for exactly these guardrails. The central AI or digital team should set the standards instead of holding up delivery.
Operating model
Business units must own their AI use cases. This is the same ownership question that triggers quiet resistance when handled poorly, so getting it right matters for the politics as much as for the structure. Each function should be responsible for finding openings, setting the results it expects and tracking them against its operating KPIs. Central teams give support, shared infrastructure and oversight, but they do not deliver the work from start to finish.
Capability development
Traditional training programmes are not enough. People must learn as part of their daily work. This can mean building use cases with guidance, internal groups where people share what works, and short rounds where teams build, test and improve tools on real operating data.
When these parts line up, the organisation moves from one-off pilots to steady returns. Several results you can measure usually follow:
- Teams ship faster because they can improve their tools without waiting for the centre to rank their request.
- More people use the tools because the people who know the work built them.
- Return on investment can be traced, because each use case links directly to lower costs, better service or lower risk.
- Central teams are free to focus on higher-value work, such as improving the design, advanced modelling and linking work across domains.
This model also scales in complex settings such as smart cities, infrastructure systems and government services. There, each area is different and needs its own know-how, so delivering everything from the centre is inefficient by nature.
So the leader’s job is to set up the conditions for new ideas to spread widely, within rules, rather than to “serve finished AI solutions”. That means investing in shared platforms, setting clear standards, lining up incentives and holding each business unit to account.
AI transformation becomes sustainable only when creation is democratised, structured, and aligned to measurable outcomes.
Free tool
ISO 42001 AIMS Readiness Checklist
Before you hand any of the four capability elements to a business unit, score your organisation against the guardrails a distributed model needs.
Cite or quote this article
Was this useful?
