The thesis in one line: an AI center of excellence is not a maturity box to tick, it is an answer to a specific problem of scale. Build it before you have that problem and the team that came to unblock you becomes the counter everyone has to queue at.
The sequence repeats so often you can call it in advance. Someone on the board comes back from an event, or from a conversation with the audit committee, and says it is time to get this AI thing organised. A group gets formed: someone from tech, someone from data, someone from legal, someone from the business. It gets called a center of excellence. Its mission, written on the first slide, is to accelerate adoption.
Four months later, the same group has a request form, a queue of twenty cases and a fortnightly meeting that fits three. And the business people, the ones who were in a hurry, have stopped asking for permission.
What an AI center of excellence in a company actually is (and what problem it really solves)
An AI center of excellence in a company is a central team that concentrates judgment, tooling and standards so the rest of the organisation does not have to invent them every time. That is the useful definition, and it is worth noticing what it does not say: it does not say "that approves", it says "so nobody has to invent it".
The real problem it solves is duplication. When five departments are building five similar things, each with its own vendor, its own data criteria and its own way of measuring, there is an obvious cost —you pay five times— and one you cannot see: nobody learns from the other four. A center makes sense once that waste already exists and you can point at it.
What it does not solve is a shortage of cases. If your company has two AI initiatives and one of them is stalled, the problem is not coordination: there simply is not enough work in flight for there to be anything to coordinate. Building a governance structure on top of two cases is putting a control tower on an airfield with two flights a day.
Two different centers of excellence with the same name
Almost the whole argument clears up once you separate two models that share a name and do the opposite. One enables. The other approves.
| A CoE that enables | A CoE that approves | |
|---|---|---|
| What it delivers | Templates, access, people on loan, examples that work | A decision on your case |
| When it steps in | When you ask, and afterwards to review | Before you are allowed to start |
| What happens as demand grows | It ships more templates; marginal cost falls | The queue lengthens; marginal cost rises |
| How it measures success | How many teams got something into production | How many requests it reviewed |
| What people in a hurry do | Grab the template and go | Find a way around it |
The last row is the one that matters, and the one nobody puts on the slide. A bottleneck does not reduce demand: it diverts it. The work does not disappear because there is a queue; it comes out somewhere else, with no judgment, no record and nobody watching.
The queue does not remove the work: it pushes it outside
This is not a consulting hunch, it is measured behaviour. A report from the security vendor UpGuard, covered by Cybersecurity Dive, found that more than 80% of surveyed workers use unapproved AI tools at work —including nearly 90% of security professionals—, that half use them regularly, and that fewer than 20% stick to company-approved tools only. The sample is 1,500 security leaders and employees across the US, UK, Canada, Australia, New Zealand, Singapore and India, so read it as a signal about human behaviour, not as a number for your market. Source: Shadow AI is widespread — and executives use it the most, Cybersecurity Dive, 12 November 2025.
One detail in that report should change a few plans: they found a positive correlation between understanding AI security requirements and regularly using unapproved tools. The more someone knows about the risk, the more confident they are judging it themselves —and the more they route around the policy. Training on its own does not close that gap.
Translated to your company: every week a case sits in the committee queue is a week someone is solving that same problem on a personal account, uploading a document that should not leave the building and standing up a process that will leave no trace. The committee has not avoided the risk. It has made it invisible.
Three signs yours is slowing you down instead of speeding you up
- The headline metric is activity, not outcome. If what goes up to the board is cases reviewed, sessions run or policies published —rather than how many processes are running in production and what hours they gave back—, the center is measuring its own motion.
- The shortcut exists and everyone knows it. When the answer to "how do I get this done fast?" is "ask Marta, she builds it without going through the committee", the evaluation is done. People have voted with their feet.
- The queue grows faster than the capacity. If more requests come in than go out and the plan is "more meetings", the model is broken: the problem is not review speed, it is that reviewing everything does not scale.
None of the three gets fixed with more governance. All three get fixed by taking the center out of the path and putting it alongside.
What to build instead if you have 50 to 500 people
In that range —where most of the companies that write to us sit— you do not need a center of excellence. You need three far more boring things.
- A named owner per process, not per technology. Whoever owns the invoicing process owns the AI that touches invoicing. No committee understands their process better than they do, and the day something goes wrong, they are the one who gets asked.
- A shared, boring inventory. A list, visible to everyone, of what is being automated, who runs it, on what data and in what state. This is not governance: it is stopping five teams from discovering in December that they built the same thing. Half the value of a CoE is this list, and this list does not need a CoE.
- Prior approval only for what touches money, people or regulated data. Everything else —a summary, a draft, an internal classification— gets done and reviewed afterwards. The decision here is not binary, it is a matter of degree: how much autonomy you release and over which case is laid out in the autonomy levels of an agent.
The controls you do need —traceability, scoped permissions, what gets logged for each decision— do not depend on a committee existing: they are mechanics, and you build them once per system. How you build them is in governance and control for AI automation. The difference from a CoE that approves is that the control lives in the system, not in a meeting.
And there does come a point where centralising is right: when eight or ten processes are live, three teams are asking for the same thing and someone has to decide what gets reused. At that point the center is not invented from scratch: it is named on top of what is already working, with the people who already built it. That is the difference between a structure that describes reality and one that precedes it.
This is not the "consultancy or in-house team" argument
Worth separating, because the two get mixed up constantly. Consultancy, in-house team or freelance is a decision about who does the work, and we cover it separately in AI consultancy, in-house team or freelance. Center of excellence or embedded owners is a decision about how what you chose gets organised internally: you can have a CoE full of externals and embedded teams full of your own people, or the other way round.
They get confused because both come up in the same meeting and both sound like an org chart. But the first is decided by your capacity and your budget; the second, by your scale and the urgency of your processes. Answering one well does not spare you from answering the other.
What I would do on Monday
Before deciding the structure, one question with numbers: how many processes do you have in production with AI today, and how many are stalled waiting on a decision? If the second number is bigger than the first, you do not have a governance problem: you have a delivery problem, and another layer of governance will make it worse.
It is, underneath, the same pattern behind why AI automation projects fail: the structure around the work gets built before the work exists. The technology is the easy part; getting it used is the hard one, and there a committee that approves plays against you. That is why the first thing we move is not the org chart, it is AI adoption across the teams: fit with the real workflow, a named owner per process and demonstrated cases before anyone writes a policy.
An AI center of excellence is a good idea when it arrives late. Built early, the only thing it centralises is the waiting.