How to Build an AI Center of Excellence That Ships

Most AI centres of excellence become review boards, and review boards get routed around. The ones that work own shared infrastructure that makes delivery teams faster. This playbook covers building that kind, drawing on FISTA Solutions' AI enablement work.

When is this worth doing?

When several teams are building AI systems independently and duplicating the same infrastructure, or when the organisation wants capability to spread beyond the one team that has it.

It is not worth doing when a single team is building a single system. A centre of excellence for one project is overhead with a name.

What does the sequence look like?

Step	Purpose
1. Define the mandate	Enablement and infrastructure, not approval
2. Staff with builders	People who have shipped
3. Build the shared platform	Gateway, evaluation, observability
4. Make the path faster	Adoption follows convenience
5. Spread capability	Patterns, pairing, documentation
6. Measure other teams' delivery	Not the centre's activity

Step 1 — Define a mandate that is not approval

Write down what the centre owns and, explicitly, what it does not. The useful mandate is shared infrastructure, enablement, and reusable patterns.

Approval authority is the mandate to avoid. A centre that must sign off on every AI project becomes the constraint on delivery, and teams respond by not describing what they build as AI.

Where governance genuinely requires review, keep it separate and light: a short risk assessment routed to the right people, not a board meeting. The centre can support that without being it.

Step 2 — Staff it with people who build

The credibility of the centre depends entirely on whether delivery teams think it can help them.

Engineers who have shipped AI systems can. Strategists and reviewers cannot, and teams work that out within a month. A centre of three builders is more useful than one of ten coordinators.

Rotate people through it from delivery teams. That keeps the centre connected to real problems and spreads its knowledge back out, which is the point.

Step 3 — Build the shared platform

The components genuinely worth building once: a model gateway with authentication, logging, and cost attribution; an evaluation harness; observability and tracing; prompt and version management; and a pattern library.

Those are the things every team otherwise builds badly and separately. Building them once, well, is the clearest value a centre delivers and the reason teams adopt it voluntarily.

Start with the gateway and observability. They give the organisation visibility it otherwise lacks and they make everything else possible. See what is an llm gateway.

Step 4 — Make the sanctioned path the fast path

Teams adopt shared infrastructure when it saves them time and route around it when it costs them time. That calculation is not affected by policy.

Measure time from a team deciding to build something to having it running on the platform. If that number is measured in weeks, teams will use a provider API directly and nobody will know.

Treat delivery teams as customers rather than as subjects of governance. The framing changes what gets built and how it is received.

Step 5 — Spread capability deliberately

Pair with delivery teams on their first AI system rather than building it for them. Publish patterns that solve recurring problems. Run enablement for the specific tasks teams are struggling with.

The goal is a centre that becomes less necessary over time, not one that accumulates dependency. Centres that build everything themselves create a queue and a single point of failure.

Write things down. A pattern documented once serves teams the centre never talks to, which is how capability actually scales.

Step 6 — Measure other teams' delivery

Track systems in production built on the shared platform, time from idea to production, adoption of shared components, and the proportion of AI work visible to the centre.

Reviews conducted, policies published, and sessions delivered measure the centre's activity. They are worth collecting internally and they are not what justifies the function.

If adoption is low, the platform is not good enough or the path is not fast enough. That is a product problem, and treating it as a compliance problem makes it worse.

How does this relate to governance?

They should be connected and not identical. The centre's platform produces the evidence governance needs — inventory, cost attribution, evaluation results, trajectory logs — as a by-product of teams using it.

That is the elegant version: governance gets visibility because the sanctioned path is the convenient one, rather than because teams file reports. A centre that instead enforces governance by review produces neither visibility nor speed. See what is an ai inventory.

When should it shrink?

When capability has spread and teams no longer need help to build well.

At that point the centre should become a platform team maintaining shared infrastructure, which is a smaller and more durable role. Centres that keep growing after capability has spread are usually protecting headcount rather than serving a need.

Saying this out loud at the start makes the centre more credible, not less.

Who needs to be involved?

Three to six builders initially, a leader with standing to negotiate with delivery teams, and rotating members from those teams.

The leader needs credibility with engineering rather than with executives. A centre that reports impressively upward and is ignored sideways achieves nothing.

How long does it take?

Three to six months to a platform teams use voluntarily. Centres still building their mandate after that have usually been positioned as governance rather than enablement.

What are the common failure modes?

Approval authority. Staffing with reviewers. Building the platform nobody asked for. A slow sanctioned path. Building systems for teams rather than with them. And measuring activity.

How do you know it worked?

Teams adopting the platform without being required to, time from idea to production falling, AI work visible to the centre rising, and the centre able to describe what other teams shipped.

What does it cost?

Mostly people's time rather than tooling. The expensive version is the one that stalls halfway and leaves the organisation with neither the old state nor the new one, which is why a narrow first pass beats a comprehensive plan nobody finishes.

Budget the work as an operated change rather than a project with an end date, because most of these need a maintenance tail. See AI total cost of ownership.

What should you do first?

Ask three delivery teams what they had to build themselves to ship their last AI feature. The overlap in their answers is your platform roadmap.

How FISTA Solutions helps

FISTA Solutions runs this work alongside client teams rather than around them: shared platforms built so the sanctioned path is the fastest one, capability spread by pairing with delivery teams rather than building for them, evidence produced as the work proceeds, and handover that leaves your people able to continue without us. Delivery runs through AI agents, AI enablement, and forward deployed engineers. The record is 150+ projects for 50+ companies across 12+ countries, with 47% average efficiency gains where measured.

To run this with support, message FISTA on WhatsApp, or read how to run an AI training program.