AI Operating Model vs Centre of Excellence: When to Change

Most enterprises start their AI work the same way. A small central team is formed, it is given a budget and a mandate, and it becomes the place every business unit sends its ideas. For the first handful of use cases that structure works well: scarce skills sit together, standards get written once, and the board has one name to ask about progress. The trouble starts later, when the queue of requests outgrows the team, the systems it shipped need owners who understand the business, and the people closest to the work begin building around it.

The evidence that structure matters is now hard to ignore. Reporting by Fortune on the MIT NANDA State of AI in Business 2025 study, published on 18 August 2025, found that about 5% of AI pilot programmes achieve rapid revenue acceleration while the vast majority stall with little to no measurable P&L impact. The same reporting lists, among the factors behind the successes, giving line managers rather than only central AI labs the job of driving adoption. That factor is about who does the work, which is an operating model question rather than a technology one.

This guide is about one decision inside the operating model: which structure to run, a centralised centre of excellence, a hub-and-spoke model or a fully embedded one, and the signals that tell you it is time to move between them. It deliberately cedes the rest. What an AI operating model is and who owns it sits in our enterprise AI consulting guide. The role-by-role grid lives in the delivery team RACI guide, build versus buy in the in-house versus vendor comparison, committee membership and cadence in the steering committee charter, and named framework ownership under SM&CR in the AI risk management framework guide.

This guide is shipped by the team behind DATS, the five-stage AI consulting system from DILR.AI that runs from Discover and Diagnose to Scale and Run. Or see AI operating model design, which covers governance, RACI and lifecycle and is audit-ready by design.

What is an AI centre of excellence, and what is it for?

An AI centre of excellence is a central team that holds an organisation's scarce AI skills, sets its standards and delivers its first use cases on behalf of the business. Its purpose is concentration: one place to hire specialists, choose platforms, write policy and prove value early. A centre of excellence is a starting structure for an AI operating model, and it works best while use cases are few, similar and closely watched.

The concentration is the point, and it is also the limit. A central team can see across every request, which is how it avoids three business units buying three overlapping tools. It can enforce one review process, which is what a regulator or an audit committee wants to see. And it gives the board a single owner for AI spend, which matters when the board approval paper asks who answers for a system once it is live.

What a centre of excellence does not hold is domain knowledge at scale. The claims handler, the credit analyst and the plant engineer can often see where a model will go wrong in their own work before a central data scientist can. In the early phase that gap is bridged by goodwill and secondments. Once AI is spread across many functions, goodwill stops being a mechanism, and in our view the structure has to change by design rather than by accident. The DATS consulting system puts operating model design at its third stage, after diagnosis and placement.

What are the three structures an AI operating model can take?

An AI operating model usually takes one of three structures. A centralised centre of excellence builds and runs everything. A hub-and-spoke model keeps standards, platforms and risk at the centre while domain teams deliver. An embedded model places AI skills inside each business unit with only a thin central layer. Each structure moves the same decisions, about priority, delivery, ownership and risk, to a different place.

The table below sets out where each decision sits. It is our own framing, drawn from delivery work rather than from any regulator's text, and real organisations often run a blend: a bank might keep model risk fully central while letting marketing analytics sit in the business.

In our view the structures are a sequence as much as a menu. The central layer has to codify its standards before it can hand delivery out, which makes hub-and-spoke the natural step between the two ends. Skipping that step risks embedded teams with no shared inventory of what they built.

When does a centralised AI centre of excellence stop working?

A centralised AI centre of excellence stops working when demand from the business outgrows what one team can build, own and review. The signals are visible before the results suffer: a lengthening request queue, live systems with no business owner, teams building tools around the centre, reviews that slow every release, and domain errors reaching production. Each one points to the same cause, a structure that has become the constraint.

None of these signals needs a survey to spot. They show up in the centre's own records, such as its request backlog, its system list and its release log. The five below are our own checklist rather than a published standard.

The queue grows faster than delivery. When the backlog of requests lengthens quarter on quarter and the central team spends more time triaging than building, business teams have a reason to stop asking, and that is the condition in which shadow projects tend to start.

Live systems have no business owner. A centre of excellence that ships a model and then keeps running it ends up doing operations work it was not set up for. The people best placed to judge whether the output is still right are in the business, not in the centre, and a model with no named business owner has nobody whose job is to notice when it stops being right. Our pilot purgatory analysis makes the same point about operating ownership in voice programmes.

Teams build around the centre. When a function buys its own AI tool on a card, or switches on a feature in a platform it already licenses, the centre has lost sight of part of the estate. The fix is not to ban the purchase; it is to bring the system into a shared register, which our guide to the AI tool inventory covers in detail.

Review becomes the bottleneck. If every change, however small, waits for the same central review, release cadence falls to the speed of the slowest reviewer. Proportionate review, where low-risk changes follow a lighter path, needs local judgement that a central team cannot supply for every function.

Domain errors reach production. When a model passes every technical test and still fails in the business, the knowledge needed to catch the failure sat outside the team that built it. That is the clearest sign that delivery needs to move closer to the work.

What changes when you move to a hub-and-spoke or embedded model?

Moving an AI operating model to hub-and-spoke or embedded changes who delivers and who owns, not who sets the rules. The centre keeps standards, the system inventory, platform choices and risk policy. Delivery, prioritisation within a domain and ownership of each live system move to named business teams. The shift works when the centre's role is rewritten as a product for the spokes, not left as a gatekeeper.

The public sector has written down what the centre needs to hold, and the list is useful well beyond government. The AI Playbook for the UK Government, published by DSIT and the Government Digital Service on 10 February 2025 for government and public sector organisations, sets ten principles for AI use and lists the support structures a public body should establish: an AI strategy and adoption plan, AI principles, an AI governance board, a communication strategy, a sourcing and partnership strategy, and AI training. It also suggests a change management team, a use cases register, monitoring, review and change processes, and fallback processes.

Read as an operating model, our mapping of that list is straightforward, though the Playbook itself does not make it. Strategy, principles, the governance board, sourcing and the register belong to the hub. Monitoring, review and fallback are run in the spokes against central standards. The Playbook's guidance for individual teams points the same way: clear roles, including who has the authority to change and modify a model's code, defined escalation pathways, and reporting into programme boards.

The Playbook is also candid about timing. In its section on creating the AI support structure it says, "These structures do not need to be fully mature before your first project." For a private sector reader that is a useful corrective. A centre of excellence does not have to finish designing the perfect hub before it lets a single spoke deliver; it needs enough of the hub in place, an inventory, a standard and an escalation route, to make the first handover safe. The same guidance recommends identifying the support structures you need for your level of maturity, or reusing ones already in place for other technologies.

Who holds accountability for AI once delivery leaves the centre?

Accountability for AI usually ends up split across several parties once delivery leaves a centre of excellence, and the evidence from UK financial services shows how far the split already runs. Executive leadership is the most common accountable party, but developers, data science teams and business users share the load. An AI operating model has to make that split explicit, or ownership dissolves into the gaps between teams.

The best published UK data on this comes from regulated firms. The Bank of England and FCA survey on artificial intelligence in UK financial services, published on 21 November 2024, found that 72% of firms using or planning to use AI allocate accountability for AI use cases and their outputs to executive leadership, followed by developers and data science teams at 64% and business area users at 57%. The same survey reports that accountability is often split, with most firms reporting three or more accountable persons or bodies.

The survey does not ask about structure, but our reading is that those three figures look like a hub-and-spoke split whether or not firms call it one: executive leadership at the top, data science teams delivering, and business users close to the work. The risk is not that accountability is shared; it is that nobody wrote down which party answers for which decision. A RACI is the tool for that, and the delivery team RACI guide sets one out.

Governance controls are layered in the same way. Among firms currently using AI, 84% reported having an accountable person or persons with responsibility for the AI framework, 82% used an AI framework or set of principles and 79% used data governance. Over half reported nine or more AI-specific governance components, chosen from a list of 16 approaches. That density is a hub asset: a spoke team cannot be expected to rebuild nine controls for itself, so the centre has to package them as something a domain team can adopt without negotiation.

The survey also flags the cost of distance from the technology. 46% of firms using or planning to use AI reported only partial understanding of the AI technologies they use, against 34% reporting complete understanding, largely because of third-party models. A third of all AI use cases are now third-party implementations, up from 17% in the 2022 survey. When much of the estate is bought rather than built, the hub's job shifts from building models to understanding suppliers, which is a different skill from the one most centres of excellence were hired for.

How do you move from a centre of excellence to an embedded model without losing control?

The safest move from a centre of excellence to an embedded AI operating model is staged: inventory every live system first, name a business owner for each, move delivery out one domain at a time, and keep standards and risk central throughout. Each stage has a check to meet before the next begins. Moving delivery before the inventory and owners exist risks losing sight of what the organisation runs.

The sequence below is our own method. It is not a regulatory requirement, and the pace depends on how many systems are live and how regulated the domains are.

Inventory every system. The pass test is simple: every AI system in production, built or bought, appears in one register with its purpose, its data and its supplier. The register is the hub's first product, and without it the spokes cannot be held to anything.

Name business owners. The check: each live system has a named owner in the business who answers for whether the output is still right. The central team stays on as technical support during the handover, but the owner is the person the incident report goes to. The National Audit Office made the same point about government itself: its March 2024 report on the use of AI in government found risks to value for money if government did not establish which department had overall ownership and accountability for delivering its AI adoption strategy.

Move delivery out one domain at a time. We suggest starting with the domain that has the most demand and the strongest local lead, and seconding a central specialist into the first spoke so the standards travel in person. The check: the first spoke ships a change through the central standards without the centre doing the work. Our AI execution office is embedded delivery, with production placements the client owns.

Keep standards central and run the hub as a product. The centre publishes its standards, templates, platform and review routes as things spoke teams use, with a proportionate path for low-risk changes. The check: spoke teams use the published route rather than asking the centre case by case, and the hub's measure becomes how quickly a spoke can ship safely, not how many systems the centre built itself.

The same ownership question applies to each of our enterprise AI solutions, six named use cases from post-call follow-up automation to enterprise knowledge retrieval.

What is the best AI operating model structure for a UK enterprise in 2026?

The best AI operating model structure for a UK enterprise in 2026 depends on how many use cases are live, how regulated they are and how much domain knowledge each needs. In our view a centralised centre of excellence suits an organisation with a few use cases, hub-and-spoke suits most firms past that stage, and a fully embedded model suits organisations whose business units already run their own technology teams well.

Three criteria decide it. First, volume: once demand from the business consistently exceeds what the central team can deliver and own, the centre should start handing delivery out. Second, regulatory exposure: the more a domain sits under rules such as the FCA's Consumer Duty or a prudential model risk regime, the more of its review should stay in the hub. Third, local capability: a business unit without its own engineering and data skills is not ready to be a spoke, however much demand it has.

Buyers in the UK typically compare large consultancies such as Accenture, Deloitte, PwC and KPMG with specialists such as Faculty, and the choice is about scale and fit. Where the redesign is one strand of a multi-country transformation with many affected roles, a large firm with change management capacity across jurisdictions can be the better choice, and we would say so. Where the task is to design governance, RACI and lifecycle for systems already in production, a team of senior practitioners who ship code, not decks, is the closer fit, which is how DATS approaches the work.

One concession runs the other way too. For an organisation with two or three AI use cases and no live production systems, a centralised centre of excellence is the right answer, and redesigning the operating model would be premature. The Discover and Diagnose stage of the method produces a ranked roadmap of where AI belongs and where it does not, which is the input to any decision about structure.

Frequently asked questions

Does an embedded model mean disbanding the centre of excellence?

An embedded AI operating model does not mean disbanding the centre of excellence; it means changing its job. The centre stops delivering most use cases and becomes the hub that owns standards, the system inventory, platform choices and risk policy. Some of its specialists can move into the business as the first embedded leads, carrying the centre's standards into each domain in person rather than through documents alone.

Closing the centre outright leaves nobody to keep the register and the standards, so a hub of some size still has to exist. The question is how small the hub can be while still doing that well, which the operating model design work settles case by case.

Is a centre of excellence the same as an AI governance board?

A centre of excellence and an AI governance board are different things in an AI operating model. The centre of excellence is a delivery and capability team that builds, advises and sets technical standards. The governance board is a group of senior leaders and experts that sets principles and reviews and authorises uses of AI. The board oversees; the centre delivers, and keeping the two separate stops the builders approving their own work.

The UK Government's Playbook describes the board in those terms and treats an ethics committee as optional, depending on the size and risk of the programme. The board's membership and meeting rhythm are covered in the steering committee charter, and the university AI governance guide shows how committee structures work in a sector with very different regulators.

How long does it take to redesign an AI operating model?

Redesigning an AI operating model takes weeks to design and longer to embed. Within DATS, the Operating Model engagement runs over six to ten weeks and covers governance, RACI and lifecycle, audit-ready by design. Moving delivery into the business then happens domain by domain, at a pace set by how many live systems need a new owner and how regulated each domain is.

The design work is the fast part. The slower part is the handover itself, which is why we suggest running the first spoke as a supported placement rather than a cold transfer. Readers who want the wider context can browse our other AI strategy articles.

Want to see this in production? Explore the DATS consulting system, review our six named AI solutions, see how the embedded execution office runs, or read about Dilr.ai and the practitioners behind it.

Written by the Dilr.ai engineering team, practitioners who ship enterprise AI in production. Follow us on LinkedIn for shipping notes, or subscribe via the RSS feed.