When Does an AI Centre of Excellence Become a Bottleneck?

An AI centre of excellence becomes a bottleneck when work repeatedly waits for central capacity or decisions that capable local teams could own within agreed controls. Diagnose the queue before changing the organisation chart. Separate shared standards, delivery work, and exceptional decisions, then test a bounded transfer of responsibility with the people who will run the workflow.

Find where requests actually wait

An AI centre of excellence, or CoE, is a shared function that develops expertise and helps the organisation govern and deliver AI work. Its remit may include platform operation, standards, advice, and implementation. Those activities consume different skills and need different decisions.

Trace recent requests from first submission to a usable decision or accepted release. Include open requests and those the team abandoned. Record when work waited for an owner, evidence, specialist review, engineering, or a scheduled meeting.

Separate elapsed time from active handling. A request that takes a short review but waits weeks for the next committee has a different constraint from a connector that needs substantial engineering. Count clarification loops and work returned for more information without resetting the original request date.

A discussion among engineering managers asks where delivery stalls after implementation speeds up, including product decisions, dependencies, and release coordination. It provides a question to investigate, rather than a benchmark for your organisation. Examine your request history to establish the actual constraint.

Ask local teams what they did while waiting. They may have continued a manual process, narrowed the request, or built an unsupported workaround. Record that behaviour and its operating consequences. A smaller official backlog can conceal work that people stopped submitting.

Use the method below as a proposed diagnostic, not a reported client result. The illustrative example follows an internal policy assistant whose local team needs content updates while the CoE also handles requests for new systems and actions.

Separate the work in the central queue

Classify requests by the decision or service they need. A question about an approved tool, a source-access request, and a new production integration should have identifiable routes. Combining them in a single project backlog makes it hard to see which capacity is scarce.

For the policy assistant, replacing an outdated approved document differs from connecting a new source collection. A further request to update customer records introduces a different action boundary. Establish the real change before assigning its review path.

Microsoft's CoE operating-model guidance separates setting rules, building agents, and monitoring production. It identifies growing demand as a constraint on central delivery and team readiness as a condition for distributing responsibility. Use those dimensions to inspect the work your centre currently owns.

Look for recurring advice that can become maintained guidance, repeated implementation steps that can become supported tooling, and decisions that require a business owner outside the CoE. Keep genuine specialist review visible rather than labelling every delay a central-team failure.

Check whether requests are ready for the queue they enter. A proposal without a source owner may need discovery before security review. Give it a clear next action and accountable person, while retaining the total time the organisation spends resolving the dependency.

For the broader choice between central, embedded, and federated delivery, use our AI team-structure comparison. The diagnostic here can improve a central arrangement as well as identify responsibilities ready to move.

Give each decision an accountable owner

Write the decision, its owner, the evidence they need, and the boundary of their authority. Name a delegate or escalation owner for absence. A list of consulted departments doesn't tell the delivery team who can resolve a disagreement.

Microsoft's decision-rights guidance calls for named people and separates business ownership, programme coordination, governance, platform operation, and delivery roles. Adapt those responsibilities to the size of your organisation. A small company can assign several roles to the same person while keeping each decision explicit.

The following is an illustrative allocation for the policy-assistant example. The responsible leadership must approve the actual delegation and any required specialist sign-off.

Keep delivery, business acceptance, and specialist approval distinct where the control requires it. A local engineering team can build a connector without gaining authority to approve all the data it accesses. State the required approval in the task and release evidence.

Give the CoE a clear route to challenge a proposed use outside the agreed controls. Give the business owner a clear route to challenge a priority or unresolved dependency. Assign the final trade-off to the executive or other authority who actually owns it.

Make the supported delivery path work

A supported delivery path is a documented and maintained way to reach an accepted operating workflow. It includes approved services, identity, evaluation, release checks, monitoring, and support. Local teams need a working route they can follow with the access and skills they actually have.

Observe a team using that route from a fresh request. Check whether it can provision the approved environment, run the example tests, understand a failure, and obtain a decision. Record every hidden permission or expert intervention needed to proceed.

DORA's platform-engineering guidance recommends starting with a common workflow, providing clear feedback, and allowing other teams to contribute through defined interfaces. Apply that approach to the internal service. A maintained template and contribution process can reduce repeated central handling where the same requirements recur.

For the policy assistant, provide an approved content-update procedure with source checks and an evaluation command or interface. Explain which changes stay within that procedure and which need a new assessment. Test deletion, superseded content, and permission changes alongside normal updates.

Keep the supported path narrow enough to maintain. A standard for an internal read-only assistant doesn't establish a supported route for customer-facing transactions. Publish what the route covers and how a team asks for a missing capability.

Offer advice at a defined point in the work, with a record of the decision. If every routine question still needs the same expert's private message, update the guidance or tooling and check whether another team can proceed independently.

Define exceptions and their escalation

Define an exception by the requirement that changes: a new source class, external audience, action authority, supplier, or departure from an approved control. Ask the requestor to state what the existing path can't handle and the evidence behind the proposed alternative.

Route the exception to the owner of that decision, with the necessary specialist input. Set a triage point, a communication route, and an escalation path for unresolved work. A response target needs staffing and a named delegate to function.

Keep the status informative. “Waiting for review” can mean missing evidence, a scheduled specialist assessment, or an unresolved management choice. Show the next action, owner, and dependency so requestors know what can move the work forward.

A missed target should trigger escalation to a named authority. Silence doesn't grant permission to use new data or release a new action. Preserve the current approved boundary while the relevant owner resolves the request.

Record the exception's scope, conditions, and review trigger. An approved trial with a bounded audience doesn't automatically become general permission. Our AI approval-process guide describes how to connect that decision to release and continuing operation.

Review recurring exceptions as a service-design signal. Several teams asking for the same unsupported connector may justify a common capability. Several requests for incompatible business rules may need separate local designs. Keep the evidence behind that choice.

Match demand to review and delivery capacity

Measure new demand and completed work by request type. Keep advisory questions, approval decisions, platform work, and delivery assignments separate. Their handling times and skill requirements differ, so a total ticket count can't establish the capacity needed.

Consider an illustrative approval queue receiving 12 complete requests a week and resolving eight. If those rates hold, with no other additions or closures, open work grows by four a week and by 16 across four weeks. This arithmetic describes the stated assumptions; it isn't a forecast or a staffing benchmark.

Include requests waiting for information and reopened work in the overall flow. Report their status separately without removing them from the operating view. Otherwise a team can appear to improve its queue by sending difficult requests back to requestors.

Inspect active handling time, oldest pending age, and elapsed time for completed decisions. State the population behind any percentile and show open work alongside it. A completed-only report can improve while the oldest unresolved requests stay untouched.

Limit concurrent delivery commitments and make priority conflicts visible. The centre may need dedicated capacity for shared services and incidents before accepting another implementation. Have the responsible sponsor decide which work waits, with the consequence recorded.

Choose the remedy from the cause. Repeated clarification may need a better intake brief; repetitive review may need a supported control; scarce specialist judgement may need more capacity. Moving the queue to business teams without those capabilities leaves the constraint unresolved.

Test local readiness before delegating

Delegate a defined responsibility to a named receiving team. Specify the workflow scope, permitted changes, evidence requirements, and support boundary. Confirm that the team has the access, time, and skills to exercise the responsibility after the central experts step back.

For the policy-assistant content update, have the local source owner and technical operator process an approved revision. They should verify its authority, run relevant answer checks, inspect permissions, and identify how to withdraw an incorrect document. Record where they still need central help.

Practise a failed case and an exception. Give the team a conflicting source version or a request for a new collection in the approved test environment. Check whether it stops at the correct boundary and reaches the right owner with the evidence required.

Fund continuing work. Evaluation updates, incident cover, and source maintenance need capacity after launch. A volunteer champion can help colleagues learn, but their availability doesn't establish an accountable production service.

Keep central oversight inspectable through a shared inventory, release evidence, and monitoring within approved access. Use targeted checks to verify that delegated teams follow the agreed process. Avoid a second routine approval that silently recreates the original queue.

For a PE portfolio, establish delegation within each company's authority and agreements. A fund-level enablement team can supply standards and expertise while local management owns its operating decisions. Common ownership doesn't assign every company's release authority to the same central committee.

Pilot the change and review the whole flow

Choose a recurring request class and a capable receiving team for a bounded trial. Recover the baseline queue and handling record, agree the delegation, and set the evidence for success. Include the central team and the local operating owner in that design.

Measure time to an accepted outcome alongside defects, rework, exceptions, and local effort. Check whether the central queue shrinks because the supported route works, because work moved elsewhere, or because requestors stopped asking. Inspect a sample of completed and unfinished work.

Review the shared team's workload too. A successful transfer may release time for specialist cases or reduce interruptions, while initially adding coaching and platform maintenance. Record those effects before promising a staffing or financial saving.

Keep a way to narrow or withdraw the delegation if evidence shows the team can't maintain the control or operating coverage. Name who makes that decision and who owns in-flight tasks. Repair the missing capability before expanding the same responsibility to another team.

Use the trial to update decision rights, guidance, and capacity allocation. Our workforce and organisation design scope covers the role and management changes, while AI governance addresses the operating controls. Expand the arrangement when the receiving team can demonstrate the responsibility it now owns.