AI Centre of Excellence: A Practical Playbook

Last updated: 2026-08-14

You have been asked to establish an AI Centre of Excellence, or an AI Transformation Office, or a function with a similar name and unclear boundaries. The founding decision is not the org chart. It is which of three jobs the function does, because a unit attempting all three does none of them.

AI Centre of Excellence: A Practical Playbook

The decision this page helps you make

You have been asked to establish an AI Centre of Excellence, or an AI Transformation Office, or a function with a similar name and unclear boundaries. The founding decision is not the org chart. It is which of three jobs the function does, because a unit attempting all three does none of them.

The three jobs are building systems, enabling other teams to build, and governing what gets built. They require different people, different funding, and different measures of success. Choose one primary and one secondary. Refuse the third in writing.

Rules of thumb

1. Choose the operating mode on day one and write it into the charter. Build means the CoE delivers systems itself. Enable means the CoE provides platform, patterns, and coaching while business units deliver. Govern means the CoE sets standards and assesses compliance. Build and govern in the same unit creates a conflict that will surface at the worst moment. Enable and govern coexist reasonably. Build and enable coexist for about eighteen months before delivery pressure crowds out enablement.

2. Staff it with people senior enough to say no. A CoE of talented juniors becomes an order-taking shop within two quarters. The function needs at least two people whose seniority allows them to tell a director that a proposal is not viable and survive the conversation. This matters more than the technical depth of the bench.

3. Write the sunset clause at the founding. State the conditions under which the CoE dissolves into the line: capability distributed, standards internalised, delivery running without central intervention. A centre with no defined end state optimises for its own continuation, and everyone in the organisation can tell.

4. Decide funding model early. Central funding produces high demand, weak prioritisation, and a queue. Chargeback produces disciplined demand and excludes the units that most need help. A hybrid works: fund discovery, standards, and platform centrally, charge for delivery capacity. Whatever you choose, publish it, because ambiguity about who pays suppresses requests more than any price would.

5. Publish an intake process with a stated response time. One form, one queue, one published turnaround. Teams route around functions that respond unpredictably. The response time matters more than the answer, because a fast no allows a team to move on and a slow yes has already cost them a quarter.

6. Say no in a way that leaves the requester better off. Every rejection includes the reason, the condition under which the answer changes, and one alternative. A CoE known for useful refusals gets consulted early. A CoE known for blocking gets consulted after commitments are made, which is when you can no longer help.

7. Build the platform before the portfolio. Shared evaluation harness, shared logging, shared access patterns, shared prompt and model registry, shared deployment path. Every project that arrives before the platform exists rebuilds these badly and becomes a maintenance liability the CoE inherits.

8. Embed rather than centralise. Place CoE staff inside delivery teams for defined periods with a defined capability transfer objective. Capability moves through working alongside people, not through documents. Set the exit date at the start of the placement or the embed becomes permanent staffing.

9. Own a small number of systems yourself. A CoE that has never operated a production system in its own name loses credibility fast and gives advice that does not survive contact with operations. Two or three is sufficient. More than that and you have quietly become a delivery team.

10. Report outcomes owned by the business, not activity owned by you. Publish the change in the business metric with the business owner named alongside it. Workshops delivered, models built, and people trained measure your effort rather than the organisation's result. The first framing survives a budget review. The second does not.

11. Run a quarterly kill review. Review every active engagement and stop those that have not moved. Publish what you stopped and why. This is the single fastest way to establish that the function has judgement, and it recovers capacity you would otherwise never see again.

12. Assume you are the third attempt. Most organisations have tried something similar before, under a different name, with a different sponsor. Find out what happened and why it stopped. The reasons are usually structural and still present, and addressing them explicitly in your charter is more valuable than any capability you build.

The artefact: operating mode selector

Answer these and the mode usually chooses itself.

The artefact: CoE charter template

Keep it to two pages. Longer charters are not read and therefore not binding.

1. Purpose. One paragraph. The organisational outcome, not the function's activities.

2. Operating mode. Primary and secondary. State the mode you are explicitly not adopting and who holds that responsibility instead.

3. Scope. In scope by domain and system type. Out of scope, stated plainly.

4. Decision rights. What the CoE may decide alone. What it recommends. What it may block, and the appeal route.

5. Services and response times. Each service, its intake route, and its published turnaround.

6. Funding. Central, chargeback, or hybrid. Rate card if applicable.

7. Staffing. Roles, seniority, and embedded placement policy including maximum duration.

8. Measures. Three to five outcome measures with named business owners. Reporting cadence and audience.

9. Governance. Who the CoE reports to, meeting cadence, and escalation path.

10. Sunset conditions. The observable conditions under which the function dissolves, and the review date at which those conditions are assessed.

The artefact: intake form

Ten fields. If a requester cannot complete these, the request is not ready and the conversation should start there.

1. What decision or process does this change?
2. Who owns that decision today, by name?
3. What does the current process cost, in time, money, or error rate?
4. What does good look like, expressed as a number?
5. What data exists, who owns it, and have you seen it?
6. Who accepts the output and acts on it?
7. What happens when the system is wrong?
8. Is the effect reversible?
9. Who has funded implementation, as distinct from the pilot?
10. What is the deadline and what drives it?

Failure signals

• The CoE reports activity metrics and cannot name a business owner for any outcome.
• Requests arrive after budget is committed and vendors are selected.
• Every business unit has hired its own capability and stopped calling.
• The charter has never been used to refuse anything.
• Embedded staff have been in place for over a year with no capability transfer measured.
• The function has grown headcount and the portfolio of live systems has not grown.
• Nobody can state the conditions under which the CoE would close.

What this does not cover

This page addresses the design and operation of a central AI function. It does not cover the specific technical architecture of the shared platform, vendor selection for tooling, or the human resources mechanics of establishing new posts and grades in your organisation. The last of these frequently determines the timeline more than any design choice here, and is worth scoping before you announce a start date.

Download this playbook as Markdown · All playbooks