AI Center of Excellence Setup
Design and launch an internal AI function with a working operating model, not an org chart and a mission statement.
Most AI centres of excellence fail the same way. A team is named, a charter is written, and within two quarters it has become either a bottleneck everyone routes around or an internal research group producing prototypes nobody adopts. The difference between those outcomes and a functioning one is almost entirely operating model rather than talent.
Pick a model before picking people
| Model | How it works | Best when |
|---|---|---|
| Centralised | The CoE builds and owns AI systems for the whole organisation. | Scarce specialist skills, high regulatory exposure, few but large use cases. |
| Federated | The CoE sets standards and enables delivery teams who build their own. | Strong engineering capability already distributed across product teams. |
| Hub and spoke | A small core team plus embedded practitioners inside business units. | Most mid to large organisations. Balances consistency against local knowledge. |
Choosing wrong is expensive. A centralised model in a company with capable product engineering creates a queue and resentment. A federated model in a company with no internal AI skills produces twelve incompatible approaches and no governance. We recommend based on your current engineering distribution and regulatory position, not on what worked elsewhere.
The parts that make it work
An intake process people will actually use
A defined route for requests, with a lightweight scoring step, a published service level for responses, and a visible queue. If submitting a request takes longer than trying something with a corporate ChatGPT licence, the CoE gets bypassed and loses visibility of what is being built. That shadow activity is where most governance failures originate.
Standards that are short enough to read
Evaluation requirements, deployment checklist, monitoring baseline, documentation minimum, and the approval gates tied to risk tier. Written as checklists rather than policy prose. A standards document nobody opens has the same effect as no standard at all.
A reusable asset library
Shared evaluation harnesses, prompt patterns, retrieval components, connectors and infrastructure templates. This is what makes the second project cheaper than the first, and it is the clearest evidence the CoE is producing value.
Governance proportional to risk
A model inventory, risk classification aligned to the EU AI Act and any sector rules, defined approval gates, and an audit trail. Low risk internal tooling should pass through in days. High risk systems should face real scrutiny. Applying the same weight to both guarantees the process is either too slow or too weak.
How the engagement runs
- Weeks 1 to 3: current state mapping. What is already being built, by whom, with what oversight. This usually surfaces more activity than leadership expected.
- Weeks 4 to 6: operating model design, funding and staffing plan, intake and governance process drafted with the teams who will use them.
- Weeks 7 to 9: standards, templates and asset library. Governance forum established and run once with us present.
- Weeks 10 to 12: launch support, first real intake processed end to end, and a review that adjusts the process based on what broke.
Run one real request through it before you announce
Processes designed in a workshop fail on first contact with an actual request. We insist on running one genuine intake through the full path, including approval, before launch. It always exposes something.
Output
Operating model, intake and governance process, standards, asset library, launch support. Delivered in editable formats. Full IP transfers to you on final payment.
FAQ
How large does the core team need to be?
Smaller than most proposals suggest. A hub and spoke CoE at a mid-sized organisation typically runs with three to six people in the core, covering technical lead, governance, and one or two engineers, plus embedded practitioners funded by the business units. Large central teams tend to accumulate work the business units should own.
Should the CoE sit under IT, data or the business?
Reporting into IT alone tends to produce technically sound systems that miss commercial value. Reporting into a single business unit produces a function that serves that unit. The most durable arrangement we see reports to an executive with cross-functional authority, with a governance forum that includes legal and risk.
We already have a CoE that is not working. Can you fix it rather than rebuild?
Usually yes, and it is normally cheaper. We start with a diagnostic on why it is being bypassed. The cause is almost always intake friction, unclear decision rights, or a standards burden that is disproportionate to the risk of the work.
How do you measure whether the CoE is working?
Time from request to decision, share of AI activity visible to governance rather than happening in the shadows, reuse rate of shared assets, and the proportion of initiatives that reach production. Headcount and number of prototypes are not measures of anything useful.
Often paired with
Fractional Chief AI Officer
Senior AI leadership on retainer, typically two to four days a month, for organisations not ready to hire a full time executive.
Read moreAI Training and Workforce Enablement
Role specific AI training built on your own tools and policies, with practical exercises rather than a lecture.
Read moreAI Adoption and Change Management
The organisational side of an AI rollout, from workflow redesign to communication and measured adoption.
Read moreIs this the right engagement?
Tell us what you are trying to decide. If a different service fits better, or if you do not need us at all, we will say so.