The centre’s dashboard looked energetic. Pilots launched, methods published, models demonstrated and people trained all rose each quarter. Production outcomes did not. Domains waited for approval, central experts lacked workflow context, and the platform team discovered that the centre had started building another evaluation service.

The unit had become four things at once: a showcase factory, approval tollbooth, talent island and platform duplicate. Each role could generate activity and preserve headcount. None answered the institutional question: which enterprise-wide constraint can this centre remove that existing domain, platform or independent functions cannot remove efficiently?

An AI Centre of Excellence is an organisational instrument, not evidence of maturity. Its economic purpose is to pool scarce expertise, create reusable assets, set a small number of binding invariants, broker evidence and transfer capability. The centre should make domains more capable of owning outcomes safely, not compete with them for ownership.

The strongest rival is often correct. Mature domains, persistent platform products and independent risk may already cover every legitimate job. In that enterprise, a separate centre adds coordination, context loss and another boundary to negotiate. The burden of proof therefore sits with each proposed central service.

Original synthesisThe five-rung CoE mandate ladder

The CoE mandate ladder is this article’s synthesis. Each rung is a legitimate central job only when a named enterprise constraint, beneficiary and service receipt justify it. The ladder does not imply that every enterprise needs all five or that one permanent team must perform them.

Setting invariants is not universal approval. The centre may steward a minimum evaluation schema, provider-evidence requirement or escalation route because inconsistent behaviour would hide aggregate risk. Domain owners still interpret outcome evidence and decide business use. The invariant is as narrow as the enterprise property it protects.

Building shared capability requires actual reuse. A reference architecture, evaluation harness or vendor pack should reduce duplicated effort and improve comparable evidence across beneficiaries. Optional assets must earn consumption through service and fit. Mandatory assets are governed honestly as invariants or platform products rather than advertised as optional best practice.

Frontier acceleration is temporary by design. Scarce experts embed with a domain to resolve a novel architecture, evaluation or operating question. The intervention has a decision, evidence objective, recipient owner and end date. Success means the domain can continue or can make a well-supported stop decision without retaining permanent central delivery.

Independent assurance cannot own the product it challenges. The centre may host scarce testing expertise if separation and mandate are credible, although a mature independent risk function may be the better home. First-line owners retain design, outcome, remediation and value accountability.

Transfer and exit is not administrative cleanup. It is a primary job. Once repeatable capability stabilises, operations should move to a persistent platform or accountable domain, be federated through contracts, or retire. The centre keeps only the expertise or challenge that still removes a genuine constraint.

NIST’s AI RMF Core and Playbook connect lifecycle governance, context, measurement and management while leaving implementation adaptable to organisational context.[1][2] The mandate ladder is one institutional synthesis, not a claim that NIST prescribes a centre.

Institutional testBalance reuse and scarce expertise against queue and context cost

A proposed service belongs at the centre when enterprise benefit exceeds centralisation cost. Benefits include reusable assets, pooled specialist expertise, comparable assurance and coordination of a systemic change. Costs include waiting, translation, loss of domain context, duplicated ownership, incentive conflict and weakened accountability.

The beneficiary must be real, not hypothetical. Count distinct domains with a comparable need, the adaptations each requires and the effort they would otherwise duplicate. A shared label can conceal different outcome semantics. If every consumer needs a separate implementation and little knowledge transfers, the apparent reuse case is weak.

Knowledge placement matters. Specialised knowledge can be integrated through shared rules, sequencing, teams and common language.[9] Decisions should also sit where relevant specific knowledge can be used without excessive transfer cost.[10] A centre can broker experts and codify patterns, but it should not absorb a domain decision merely because the expert is central.

The talent-island failure separates model expertise from workflow, data meaning, customer consequence and adoption conditions. A central team optimises evaluation metrics while domain operators repair evidence and exceptions around it. Embedding experts temporarily can integrate the knowledge without transferring product ownership.

The approval-tollbooth failure treats all requests as a central service. Low- and high-consequence use cases wait for the same forum, producing sponsor escalations and shadow AI. Narrow enterprise constraints and differentiated service routes are stronger than universal review. The centre should publish completeness rules, service times and escalation.

Queue cost includes more than delay. It changes which work enters the process, encourages informal releases and consumes domain attention in repeated translation. Service distribution, abandonment, bypass and rework sit beside reuse and assurance evidence. A busy centre can be destroying more value than it creates.

The showcase factory has no production outcome owner. A polished pilot may reduce uncertainty, but its receipt is the decision it enables, not the demonstration count. If no domain accepts the outcome, operating path and capture duty, the centre should close the option rather than accumulate orphaned prototypes.

Modularity can support reusable capability through stable interfaces.[7] Architectural knowledge also sits in relationships between components, so transfer needs more than code or a template.[8] The service must codify the interface, assumptions, evidence and adaptation rights that recipients require.

Service disciplineEvery central job needs a service contract and an exit test

The contract starts with the enterprise constraint and beneficiary. It explains why domains cannot solve the problem efficiently alone and defines the unit of service. “AI expertise” is not a unit. A completed vendor evidence pack, evaluation run, architecture intervention or independent challenge opinion can be requested, timed and reviewed.

Binding and optional status must be explicit. A binding invariant names the minimum behaviour, authority and exception route. An optional service states the consumer choice and evidence it must earn. A centre should not enforce optional templates through informal approval power or describe mandatory controls as friendly guidance.

The record names local knowledge required and accountability retained by the domain. A central evaluation service may supply methods, infrastructure and comparable evidence. The domain still defines decision consequence, representative cases, threshold interpretation and outcome response. The centre cannot validate away missing product ownership.

Service time includes completeness, normal response, high-consequence escalation and capacity limit. When demand exceeds capacity, the centre narrows scope, adds a governed route or transfers delivery. It does not hide ageing behind a first-in queue or accept unlimited demand while promising expert attention.

Success receipts measure constraint removal. Reuse shows which beneficiaries consumed and adapted the asset. Service evidence shows wait, rework and outcome. Capability evidence shows what recipients can now operate without the centre. Assurance evidence shows independence and decision impact. Activity counts remain diagnostic.

The transfer condition is written at service creation. It can be stable interfaces, repeatable demand, recipient capability, proven operations or expiry of novelty. The accountable recipient and migration obligations are named early. Otherwise transfer becomes a negotiation against the centre’s headcount after the work is already entrenched.

The sunset date forces a decision: renew because the constraint remains, productise into a platform, federate through domains, retain independent assurance, or retire. Renewal states evidence and the next exit condition. Silence cannot extend a service indefinitely.

Ownership boundariesKeep domain outcomes, platform products and independent challenge distinct

The domain product owner holds workflow, customer, threshold, release and value decisions. The platform team owns persistent shared products, service levels, cost, reliability and portability. The CoE owns only its contracted invariant, reusable asset, expert intervention or assurance service. Independent risk retains its mandate to challenge and constrain.

The platform-duplicate failure occurs when the centre rebuilds routing, observability, evaluation operations or provider integration already assigned to a product team. Duplication fragments service and evidence. A novel prototype may begin in the centre, but stable operations, roadmap and consumer rights belong with the platform recipient.

A centre may convene evidence across domains without becoming a committee owner. It can identify shared provider exposure, recurring failure or evaluation gaps and route those signals to accountable roles. It cannot accept business consequence merely because it sees the portfolio.

Government adoption evidence points to central coordination and capability gaps, but also to uneven implementation and limited impact measurement.[3] Applicable regulatory and management-system duties also need accountable lifecycle implementation.[4][5] None requires a unit called a CoE.

Revised US model-risk guidance emphasises proportionate governance and validation for models within its scope.[6] Independent review can be a legitimate central service when scarcity and separation justify it. The contract states scope and preserves remediation with the first line.

Capability migrationRun a relay from discovery to productisation and retirement

Capability transfer begins during discovery. The centre records the novel mechanism, assumptions, beneficiary needs and evidence that would make the work repeatable. Codification turns expert judgement into interfaces, tests, guidance and escalation without pretending that every context is identical.

Productisation adds service ownership, reliability, cost, security, versioning, observability and consumer rights. A platform team is the natural recipient when reuse and persistent operations dominate. A domain is the recipient when the asset remains tightly coupled to one outcome. Federation fits when common evidence can coexist with local implementation.

Cross-boundary learning requires deliberate transfer, shared practice and recipient participation.[11] Communities of practice can steward knowledge without owning every execution.[12] The centre may retain a knowledge network after delivery leaves, provided membership does not restore approval power.

Systemic innovation can justify central coordination where component changes are interdependent.[13] Once interfaces stabilise and autonomous adaptation becomes safe, the coordination form should change. The centre’s historic involvement is not a reason to preserve it.

The relay receipt records recipient capability, operating acceptance, migrated consumers, service performance, unresolved exceptions and the central access withdrawn. Retirement closes credentials, queues, budgets and duplicate artefacts. A service has not transferred while the old centre remains the hidden fallback.

Measure constraint removal and capability transfer

A central performance review starts with the service portfolio, not the organisation’s aggregate activity. For each service, ask whether the named constraint still exists, who benefited, which decision or operating state changed, what the service cost and which capability the recipient now holds. The answer can support renewal, redesign, migration or closure.

Constraint-removal evidence is specific. A vendor pack reduces repeated diligence and improves consistent contractual evidence. An evaluation method allows comparable release receipts while preserving local thresholds. A frontier intervention resolves a novel architecture uncertainty. Independent testing changes a release, remediation or stop decision. If a service cannot name such a receipt, demand may be ceremonial.

Reuse needs a denominator and adaptation record. Downloads, attendees and template copies do not establish value. The centre records eligible beneficiaries, actual consumers, repeated use, local extensions, rejected uses and effort avoided. Rejection can be useful evidence when a shared asset does not fit. It should guide boundary repair rather than pressure domains to inflate adoption.

Capability transfer is demonstrated through recipient action. Staff can operate the service, diagnose failure, change a bounded configuration, support consumers and recover without calling the former central team. Documentation and training help, but paired operation, incident rehearsal and live decision evidence provide stronger proof. Access withdrawal tests whether hidden dependence remains.

Queue evidence protects against tollbooth behaviour. Report completeness, wait distribution, rework, high-consequence ageing, sponsor escalation, abandonment and suspected bypass. Segment standard work from frontier and assurance services. A fast showcase response cannot offset a slow release opinion, and a busy queue is not evidence that central review is the right design.

Context-loss evidence comes from defects and translation. How often does a central recommendation require domain correction? Which missing workflow, data or customer assumption caused it? How many interactions were needed before the expert could decide? Recurrent translation can justify temporary embedding, a stronger evidence interface or returning the service to the domain.

Accountability drift is tested by asking who explains the outcome when a service fails. If domain leaders point to the centre, or the centre begins setting product thresholds to protect its method, the boundary has moved. The contract restores domain consequence ownership and limits the centre to its asset, intervention or challenge object.

Headcount and budget create understandable incentives to retain work. The sunset review should therefore include the recipient and an owner outside the service. They compare constraint evidence, service economics, recipient capability and independence needs. Renewal cannot be approved solely by the team whose mandate continues. Transfer success should be valued in performance and workforce plans.

People affected by transfer need a visible path. Central experts may join a platform product team, return to domains, retain a frontier practice or support independent assurance. Workforce design should reward codification and recipient capability rather than treating handover as loss of status. Otherwise the institution asks people to eliminate the work on which their role depends.

A portfolio view reveals systemic patterns. Several temporary interventions may point to a missing platform. Repeated local exceptions may show that an invariant is too broad. Persistent assurance demand may justify a durable independent capability. Multiple services with mature recipients may justify closing the centre itself. The unit’s form follows the remaining constraints.

The no-CoE audit maps the five legitimate jobs to current owners and evidence. Enterprise invariants have stewards and exception routes. Platform products have service, cost and consumer rights. Domains can own outcomes and absorb specialist practice. Independent functions can challenge proportionately. Knowledge crosses boundaries through communities and records. When each mapping is credible, creating a centre would make the operating model worse.

Mandate review should also inspect what the centre has made easier to stop. Shared evidence can reveal that a provider, architecture or use pattern is unsuitable across several domains. Frontier expertise can close an option before delivery spend grows. Independent assurance can narrow release. A transfer discipline can retire two overlapping services. These negative decisions are valuable constraint work even when they reduce the centre’s visible project count.

Executives should resist replacing outcome accountability with sponsorship. A senior sponsor can secure funding and remove an enterprise obstacle, but the recipient still owns service, customer and economic consequence. The centre’s leader owns the contracted portfolio and its exits. Platform, domain and assurance leaders acknowledge their accepted responsibilities. This chain prevents enthusiastic central support from becoming indefinite shared accountability after the original experts move on.

The portfolio review records disagreements as evidence. A domain may reject a common asset because adaptation costs exceed reuse; a platform may refuse transfer because interfaces remain unstable; assurance may require separation that the proposed team cannot provide. Resolving those claims openly is stronger than forcing consensus. The resulting decision can narrow, extend, move or close the service with the responsible owner and next review condition visible.

Worked transferAn evaluation harness leaves the centre after proving reuse

Three domains need repeatable evaluation evidence for different human–AI workflows. Each has built scripts, data adapters and reporting conventions. Results cannot be compared, provider changes trigger repeated work, and the platform does not yet own an evaluation product. The enterprise constraint is duplicated infrastructure and incompatible evidence, not a shortage of central product owners.

The centre contracts one service: a versioned evaluation harness and vendor evidence pack. Domain owners supply decision consequence, representative cases, acceptance interpretation and outcome response. The CoE supplies reusable execution, provenance, reporting interfaces and scarce evaluation expertise. Independent risk defines and challenges the evidence needed for relevant consequence classes.

The service unit is a completed evaluation run and evidence receipt for one version, cohort and configuration. The contract publishes entry requirements, normal and elevated service times, adaptation points and escalation. It records local data and workflow knowledge needed. The centre cannot approve the product merely because the harness executes successfully.

Reuse evidence arrives when each domain runs the common core, retains its local cases and consumes the receipt in a release decision. Differences become explicit extensions rather than forks. Provider due diligence is updated once and linked to each consuming decision. Queue and rework are monitored to ensure central execution is not becoming a tollbooth.

Transfer begins when interfaces and demand stabilise. The platform team accepts service ownership, reliability, cost, access, versioning and consumer support. Domain adapters remain domain-owned under contracts. The centre supplies documentation, paired operations and incident rehearsal, then withdraws production access after the recipient meets the acceptance conditions.

Independent assurance remains separate. Risk or a suitably independent expert service challenges evaluation design and selected evidence but does not operate the harness or own remediation. The CoE may retain a small frontier method capability for novel cases with new time-boxed contracts. Routine runs, support and roadmap no longer sit in the centre.

Success receipts show three-domain reuse, accepted platform operation, stable service, comparable evidence, migrated consumers and closed duplicate pipelines. The centre does not claim the products’ outcome value. Finance and domain owners hold those receipts. The central service succeeds by disappearing from routine delivery.

The no-CoE counter-case is equally legitimate. Suppose platform products already provide evaluation and observability, domains hold strong outcome and workflow capability, and independent risk can access specialist review. Enterprise invariants and evidence exchange already operate. A new centre would duplicate owners and create another queue. Mandate triage should reject it.

NIST’s online informative references include mappings that can support traceability and execution patterns.[14] Such references may inform a reusable asset, but the centre still has to prove enterprise demand, operating fit and transfer. A catalogue entry does not justify an institution.

Interactive instrumentCoE Mandate Triage

The triage returns one mandate, accountable owner, service contract and exit test. It does not calculate CoE maturity. A service can remain binding, transfer to a platform, embed temporarily in a domain, stay independent, or never enter the centre.

ConclusionA good centre removes the need for its routine delivery

The centre earns its place by removing enterprise constraints, not by owning every model or gathering the most experts. Narrow invariants protect shared truth. Reusable assets reduce duplication. Time-boxed expertise advances novel decisions. Independent assurance preserves challenge. Transfer turns central learning into distributed capability.

Every service carries its own institutional proof: beneficiary, unit, status, service time, reuse, retained domain accountability, success receipt, transfer condition and sunset. This record exposes a showcase, queue, talent island or platform duplicate before activity becomes a protected mandate.

Constraint economics can change. A novel cross-domain problem may justify a centre today and a platform product tomorrow. Mature domains may absorb expert practice. Independent challenge may remain. A service that no longer removes a constraint should retire even when it is busy.

The no-CoE result is not failure. It can show that domains, platform teams and independent functions already operate the legitimate jobs with clearer accountability and lower coordination cost. The centre is a means, not a badge.

The decisive performance measure is transferred capability. Domains own outcomes more safely, platforms run reusable services, evidence moves across boundaries and central dependencies close. A centre that succeeds in this way may become smaller. That is institutional progress, not a reason to invent more central work.

Evidence spineReferences

1. National Institute of Standards and Technology (2023), ‘AI Risk Management Framework: Core’. NIST AIRC Core.
2. National Institute of Standards and Technology (2023), ‘AI RMF Playbook’. NIST AIRC Playbook.
3. OECD (2026), ‘Adopting and governing AI in government’, Digital Government Outlook. OECD.
4. European Union (2024), ‘Regulation (EU) 2024/1689 laying down harmonised rules on artificial intelligence’, Articles 4, 9, 14, 17 and 26. EUR-Lex.
5. International Organization for Standardization and International Electrotechnical Commission (2023), ‘ISO/IEC 42001:2023, Information technology, Artificial intelligence, Management system’. ISO standard record.
6. Board of Governors of the Federal Reserve System, Office of the Comptroller of the Currency and Federal Deposit Insurance Corporation (2026), ‘Revised Guidance on Model Risk Management’, SR 26-2. Federal Reserve letter.
7. Baldwin, C. Y. and Clark, K. B. (2000), Design Rules, Volume 1: The Power of Modularity, MIT Press. MIT Press.
8. Henderson, R. M. and Clark, K. B. (1990), ‘Architectural Innovation’, Administrative Science Quarterly, 35(1), 9–30. doi:10.2307/2393549.
9. Grant, R. M. (1996), ‘Toward a Knowledge-Based Theory of the Firm’, Strategic Management Journal, 17, 109–122. doi:10.1002/smj.4250171110.
10. Jensen, M. C. and Meckling, W. H. (1995), ‘Specific and General Knowledge, and Organizational Structure’, Journal of Applied Corporate Finance, 8(2), 4–18. doi:10.1111/j.1745-6622.1995.tb00283.x.
11. Edmondson, A. C. and Nembhard, I. M. (2009), ‘Product Development and Learning in Project Teams: The Challenges Are the Benefits’, Journal of Product Innovation Management, 26(2), 123–138. doi:10.1111/j.1540-5885.2009.00341.x.
12. Wenger, E. (1998), Communities of Practice: Learning, Meaning, and Identity, Cambridge University Press. doi:10.1017/CBO9780511803932.
13. Chesbrough, H. W. and Teece, D. J. (1996), ‘When Is Virtual Virtuous? Organizing for Innovation’, Harvard Business Review. HBR.
14. National Institute of Standards and Technology, ‘GATE Operational Control Model to AI RMF 1.0’, National Online Informative References. NIST CSRC.