Org design for AI: why your Centre of Excellence becomes a bottleneck

Part 4 of five. "AI, leadership and the human structures of work" is a series on what AI actually changes about leading people, and why those changes are choices, not inevitabilities.

A large enterprise I heard about stood up an AI Centre of Excellence with the best of intentions: one central team to set standards, vet models, and keep everyone safe. Eighteen months later, the CoE had a six-week approval queue, three of the business units had quietly started using unsanctioned tools to get round it, and the security team, the very people the CoE existed to reassure, had less visibility into the company's real AI use than before it was created. The gate had not stopped the risky behaviour. It had driven it underground.

The last piece ended on a warning: you can only fix ownership and accountability so far one team at a time, because they also live in how the whole organisation is built. So this is the structural piece. When a company decides to get serious about AI, it almost always reaches for the same move, and that move is usually where adoption goes to die.

The move is the Centre of Excellence. Pull the AI expertise into one central team, give them the mandate for standards, safety, and best practice, and let the rest of the organisation come to them. It sounds responsible. It is how most enterprises have handled every new capability for thirty years. And with AI it reliably curdles into a bottleneck.

How the enabler becomes the ceiling

The failure is not incompetence. It is a structural trap. A central team that must review every model, approve every use case, and sign off every rollout becomes, by simple arithmetic, the ceiling on how fast the rest of the company can move. Ten teams want to build; one team has to approve; the queue forms.

And people do not wait in queues. They route around them. This is not hypothetical. A 2026 survey of 1,000 employees and 500 security leaders found 81% of employees using unapproved AI tools, and 45% of workers actively finding workarounds to reach applications their employer had blocked. That second number is the one that should worry you, because it is the queue-jumping made explicit: the official channel is half-empty and the unofficial one is packed. Your careful central control produces the exact thing it was built to prevent, ungoverned AI use, now invisible, because you made the governed path the slow one.

A gate does not stop the water. It decides where the water goes around.

The counter-argument, taken seriously

The obvious objection: but you need governance. AI carries real risk, data, compliance, reputation, and "enablement" sounds like a polite word for a free-for-all. Fair, and worth answering directly, because it hides a false choice.

Enablement is not the absence of governance. It is governance delivered as a road rather than a checkpoint. A checkpoint governs by inspecting each car; a well-built road governs by making the safe route the default, guardrails, a paved surface, a sensible limit built into the design, so that the easy thing and the safe thing are the same thing. The shadow-AI numbers are the proof that gating fails at its own stated goal: the CoE that inspects every use case ends up with less control, not more, because it drove usage into the dark. If your genuine priority is safety, the queue is the least safe design you could pick.

The pattern that actually scales

The organisations getting this right are inverting the central team's job. Instead of a team that approves, a team that enables. Two ideas from how high-performing engineering organisations are already built map onto this cleanly. The first is the enabling team: a small group whose success is measured by how quickly it can raise another team's capability and then leave, not by how many approvals it processes. Its job is to make the other teams good at AI, then get out of the way. The second is the platform team: it builds the paved road, the self-service tools, guardrails, and defaults that make the safe way to use AI the easy way. You do not govern by inspecting each decision. You govern by shaping the path so the default is already safe.

That is the shift in a line: govern the road, not each journey.

There is an older idea worth borrowing too, with a caveat. The Spotify model gave us the language of guilds and chapters, communities that cut across teams to spread a craft and stop knowledge pooling in silos. That cross-cutting community is a genuinely good home for AI practice: how we prompt, what we have found breaks, which failure modes to watch for. The caveat is honesty. The Spotify model was aspirational even at Spotify, and copied badly it becomes ceremony. Take the idea, spreading practice sideways across teams, not the diagram.

And there is a reason structure matters more here than almost anywhere. Conway's Law, the old observation that organisations ship systems which mirror their own communication structures, has never been more literal than with AI. Build a gatekeeping organisation and you get gatekept, brittle adoption. Build an enabling one and you get adoption that flows. The shape of the team becomes the shape of the capability.

What this asks of a leader

Resist the instinct that says control means a checkpoint. On a technology moving this fast, a checkpoint is a bottleneck wearing a lanyard. Design for enablement instead: a central team measured on how much capability it builds elsewhere, a platform that makes the safe path the easy one, and a community that spreads what works. Governance that enables velocity rather than gating it is not a slogan. It is a structural decision about whether your best people wait in a queue or get a paved road, and, on the evidence, about whether you have real control or only the paperwork of it.

But structure has a hard limit, and it is the one this series has been circling from the start. You can build the most elegant enabling organisation in the world and it will still fail if there is nobody left to enable, if the pipeline that produces capable people has quietly been switched off. That is the last piece, and it is the one I think we are getting most wrong.

The series: AI, leadership and the human structures of work 1. The psychological cost of AI is a leadership choice, not a technology outcome 2. Who's the authority now? Leading in the age of the jagged generalist 3. Managing a team of agents: leadership when roles become software 4. Org design for AI: why your Centre of Excellence becomes a bottleneck 5. Cutting juniors is a choice, not an AI inevitability

You are reading part 4. Links added as each publishes.

Written by Richard Atkins.

--- Sources: Team Topologies (Skelton & Pais) — https://teamtopologies.com/key-concepts · "AI Center of Excellence: Why Most Become Bottlenecks" — https://agility-at-scale.com/ai/people-change/ai-center-of-excellence/ · Shadow-AI prevalence (81% of employees using unapproved AI tools; 45% working around blocks; survey of 1,000 employees and 500 security leaders): UpGuard, "The State of Shadow AI" — https://www.upguard.com/resources/the-state-of-shadow-ai · The Spotify model — https://www.atlassian.com/agile/agile-at-scale/spotify · Conway's Law (Melvin Conway, 1968).