A Centre of Excellence is not a title on an org chart. It is a structural commitment: concentrate AI judgement, discipline, and shared services in a named team, then make the rest of the organisation use that team instead of improvising around it.
This decision aid gives senior leaders the shape of a working AI CoE: the mandate, structure, services, intake, governance handoffs, scorecard, and launch sequence required to make the CoE useful within the operating model.
Built from patterns I have seen across enterprise AI, product leadership, operator care, and transformation work. Illustrated through ArNa Nimbus, a fictional composite enterprise SaaS company.
The framework that follows is the executive shape of a working AI Centre of Excellence: how mandate, intake, services, governance handoffs, scorecard, and capability transfer connect into one operating organ that moves AI from scattered activity to repeatable capability.
Most CoEs do not fail because the people are weak. They fail because the structure is unclear. The pattern usually appears in one of three traps.
The first is the Centre of Expertise trap. The CoE becomes a group of smart advisors. It comments, reviews, and produces decks, but owns no movement in the portfolio.
The second is the Centre of Build trap. The CoE owns too much delivery. Every business unit sends work into the centre, the backlog grows, and the CoE becomes a bottleneck instead of an accelerator.
The third is the Centre of Governance trap. The CoE runs meetings, templates, and reviews, but lacks authority, delivery connection, or service value. The business learns to work around it.
A CoE should not start with hiring. It should start with decisions leadership is willing to stand behind.
First, mandate. For each capability, the CoE must either own, enable, or advise. If the posture is unclear, every disagreement becomes a one-off negotiation.
Second, structure. The team shape must follow the mandate. A CoE that owns portfolio governance needs different talent from a CoE that only advises on technical practice.
Third, services. The business must know what the CoE offers and how to request it. A CoE without a published service catalogue is a team people have heard of, not a team they know how to use.
Fourth, scorecard. The CoE must measure more than activity. Submissions, pilots, and training sessions matter, but the real question is whether business capability is increasing.
A CoE can be lean, mid-scale, or enterprise-scale. The right question is not how large the team should be. The right question is what role the organisation needs the CoE to play.
A lean CoE concentrates scarce judgement. It can own intake, evaluation standards, and the first few high-value use cases, but it must rely on business champions for reach.
A mid-scale CoE can operate through clearer pods: portfolio and governance, platform and evaluation, enablement and change. This is often the practical target for enterprises moving from scattered AI activity toward repeatable capability.
An enterprise-scale CoE behaves more like a product organisation. It has roadmap, backlog, platform responsibility, governance workflow, and business-aligned delivery capacity.
Across all shapes, one sequencing rule holds: appoint the portfolio lead early. A CoE that can build but cannot decide what to build will look busy while the portfolio stays weak.
A working CoE has visible machinery.
The first mechanism is intake. Business ideas need a front door. The CoE should turn demand into a shaped portfolio, not wait for the loudest sponsor or most attractive demo.
The second mechanism is service catalogue. The CoE must publish what it does: discovery, intake, governance review, model build support, evaluation, pilot management, production readiness, adoption enablement, and monitoring standards. The page does not need the full catalogue. The business does.
The third mechanism is governance handoff. The CoE does not own risk, legal, IT, or enterprise strategy. It connects them to the AI portfolio through named handoffs, agreed escalation routes, and a regular reporting rhythm.
The fourth mechanism is scorecard. The CoE should report activity, outcomes, and capability. Reporting only activity lets a busy CoE look productive while the organisation remains unchanged.
ArNa Nimbus is a fictional composite enterprise SaaS company, not a real client and not a Foundry product. It makes the CoE diagnostic visible.
The starting point is familiar: 4,500 employees, three product lines, two years into an AI strategy, and a CoE launched with a Head, three data scientists, and a broad remit to “accelerate AI”. After ninety days, the CoE has a vision deck, a draft risk taxonomy, and exploratory notebooks. No intake. No business commitment. No shipped use case.
The diagnosis is structural. ArNa Nimbus has created a Centre of Expertise trap. The team is intelligent and busy, but it has no mandate matrix, no portfolio front door, and no scorecard.
The restart sequence is narrow by design. First, ratify the mandate: the CoE owns portfolio governance, evaluation, and literacy; enables delivery, adoption, and change; and advises on risk appetite. Second, appoint the portfolio lead before hiring more data scientists. Third, publish intake and the draft service catalogue. Fourth, run one visible intake cycle and shape only the strongest use cases.
At Day 90, ArNa Nimbus has not yet created a scaled AI capability. It has created the machinery that can produce one. That is the right first result.
The first move is to write the mandate matrix before hiring anyone else. Pick the core capabilities the CoE will touch and decide whether the CoE owns, enables, or advises on each one. Even a draft will surface the disagreements that would otherwise become six months of drift.
The second move is to publish the service catalogue in draft. The first version will be imperfect. That is fine. Its purpose is to turn the CoE from a team people know exists into a team the business knows how to request.
The next move is not another CoE deck. It is naming what the CoE owns, publishing how the business uses it, and reporting whether capability is actually moving.
This page is the decision aid. It helps a senior leader recognise whether the CoE has a real operating mandate or is drifting into advisory, delivery bottleneck, or governance theatre.
The full PDF is the operating tool. It contains the deeper mandate logic, CoE shape options, intake approach, service catalogue, scorecard model, governance handoffs, ninety-day launch plan, and the full ArNa Nimbus fictional-composite restart sequence.
Use the report to turn the conversation from “do we have a CoE?” into “does the CoE have the mandate, machinery, and scorecard to move AI capability?”