AI Center of Excellence for a Claude program

TL;DR

An AI Center of Excellence for Claude is worth standing up when four functions have no owner: enablement, governance, platform and measurement. Give it those four and a monthly report, and it pays for itself. Give it a mandate to approve every use case and it becomes the bottleneck everyone routes around.

What should an AI CoE own, and what makes it overhead?

A CoE should own the things that are expensive to duplicate and cheap to centralise: training material, policy, the platform configuration and the numbers. It should not own use case approval, because that puts a central team between the business and its own processes, and the business will go around it within a quarter.

The distinction is the difference between a CoE that lasts and one that gets dissolved in the next reorganisation. A central team that publishes the rules and the tooling is useful. A central team that gates every request becomes a queue.

Function	CoE owns	Business unit owns
Enablement	Curriculum, material, champion programme	Who gets trained and when
Governance	Policy, data classes, approval criteria	Applying the criteria to its own use cases
Platform	Residency, groups, spend limits, connectors	Requesting a connector or a model
Measurement	The report, the definitions, the baseline	Acting on its own numbers
Use case selection	Nothing	Everything
Review quality	The standard	Doing the reviews

Our position: a CoE with fewer than two full-time equivalents cannot do all four functions and should pick measurement and platform first, because those two are the ones nobody else will do. Enablement can be distributed to champions. Governance can be a part-time role for the DPO plus a documented policy.

Which numbers does the CoE report?

Report four numbers monthly: active users against assigned seats, spend concentration, the adoption level by department, and the open governance items with dates. The platform supplies the first three without custom tooling, which is the main argument for keeping the report simple.

Team and Enterprise analytics report a specific set of metrics, and knowing which ones exist saves a quarter of spreadsheet work:

• Summary: weekly active members, pull requests created in Code, sessions in Cowork.
• Who is using it: active members against assigned seats, by group and by member.
• How they use it: adoption level, product stickiness, skills, connectors.
• Results: pull requests created, designs created, file operations, conversations, MCP writes, estimated time saved.
• Spend: usage limits, spend concentration, total spend, spend by model.

The spend report exports one CSV row per person per model, with total_requests, total_prompt_tokens, total_completion_tokens, total_net_spend_usd and total_gross_spend_usd. It refreshes daily on a one-day delay, and custom date ranges reach back up to 90 days with the latest data from yesterday. For Enterprise, the Analytics API returns the same per-user usage and cost data programmatically, with a key carrying the read:analytics scope created by a Primary Owner.

Three constraints to design the report around before promising anything:

1. Role visibility. On Team plans only Owners and Primary Owners can see analytics. On Enterprise, Admins can see analytics but not Spend. If the CoE lead is an Admin, they cannot pull the spend figure, and that is a role design question rather than a tooling one.
2. Seat-based plans show no spend. On seat-based Enterprise plans, spend reports appear only once usage credits are turned on and cover overage spend only, because usage inside the seat allowance is not metered in dollars. A cost report built on this will show zero until a team goes over.
3. Cloud routes are invisible to these dashboards. Where Claude Code runs on Amazon Bedrock, Google Cloud or Microsoft Foundry, no metrics go back to Anthropic, so the analytics dashboards and the Claude Code Analytics API do not cover that usage at all. OpenTelemetry export is the route to per-user figures there.

The one number worth arguing about is spend concentration. In most deployments a small group of people generates most of the usage, and the CoE’s job is to find out whether they are the power users worth learning from or the ones who left Opus as the default model. Our Claude Code pricing guide covers the cost levers behind that question, with Claude Code averaging around 13 USD per developer per active day and 150 to 250 USD per developer per month across enterprise deployments. For the support load a CoE inherits, see our Claude Enterprise support guide.

How does the CoE enforce policy without becoming a queue?

Through groups and spend limits, set once and inherited from the identity provider. A CoE that enforces policy through tickets becomes the bottleneck. A CoE that enforces it through SCIM-synced groups with model access and spend limits attached scales without adding headcount.

The group documentation sets out the mechanics and the limits, and both matter for the design:

Mechanism	Detail
Group creation	Organization settings, or synced from your identity provider through SCIM
SCIM-synced groups	Cannot be renamed or deleted inside Claude
Per-user limit	A monthly limit applied to every member of the group
Shared budget	A pooled monthly budget, in beta, counting only from creation and resetting monthly
Precedence	An individual member’s limit takes precedence over any group limit
Multiple groups	A Multi-group spend limit setting chooses the higher or the lower group limit
Ceiling	Up to 1000 groups per organisation
Performance	Membership in more than 250 groups can slow performance
Who can manage	Groups need Identity and Access set to “Can manage”; spend limits need Billing set to “Can manage”

Two design decisions follow. Sync groups from the identity provider rather than creating them in Claude, because then joiners, movers and leavers are handled by a process that already exists and is already audited. And keep the group count low: 1000 is the ceiling, but a design that needs hundreds of groups is a design that has pushed policy decisions down to a level nobody can review.

The practical pattern we recommend:

1. One group per data class, not per department. The policy question is which data may enter a prompt, and departments share data classes.
2. One group per cost centre, carrying the spend limit. This is the group finance cares about.
3. One group for developers, carrying model access and the Claude Code policy.
4. One group for admins and the CoE itself, carrying the elevated roles.

Our AI governance framework for Claude covers the role and approval model those groups implement, and our AI compliance matrix maps the obligations behind the policy.

What does the CoE operating calendar look like?

Monthly for the numbers, quarterly for the policy, and event-driven for model changes. A CoE that meets monthly to discuss strategy produces minutes. A CoE that publishes a report monthly and verifies settings quarterly produces evidence.

Cadence	Activity	Output
Monthly	Pull the spend report and analytics, review spend concentration	One-page report per business unit
Monthly	Review blocked members and spend limit hits	Limit adjustments, or a conversation about usage
Quarterly	Verify residency settings per workspace and region	A signed check, not a document
Quarterly	Review the group design against the org chart	Group changes through the identity provider
Quarterly	Refresh enablement material	Updated curriculum version
Per model release	Regression test the use cases, update cost models	Migration decision with a date
Per AI Act milestone	Review classifications against the current obligations	Updated records of processing

The regulatory column is thinner than it looks but has firm dates. The European Commission’s regulatory framework page puts the AI literacy duty in force since 2 February 2025 and broad application of the Act since 2 August 2026, with the Omnibus, in force since 27 July 2026, moving the high-risk obligations to December 2027 for Annex III and August 2028 for Annex I. For a CoE, that means the literacy records are a standing monthly item and the high-risk work is a 2027 project with a published harmonised standard to work against since 19 October 2026.

Model releases are the event that most often catches a CoE out. Prices and token counts both move: Claude 4.7 and later models use a newer tokenizer that produces approximately 30 percent more tokens for the same text, so a cost model built on an earlier generation understates the current one by about a third. Rebuild rather than scale.

Run it yourself or outsource?

Staff the CoE internally and buy the parts that are specialist and finite. The functions that need institutional knowledge, which are governance judgement and enablement credibility, cannot be bought. The functions that need documentation currency, which are platform configuration and reporting pipelines, often should be.

CoE function	Staff internally	Good outsourcing candidate
Monthly report and definitions	Yes, after the pipeline exists	The pipeline build
Group and spend limit design	Yes	The first design, as a review
Residency verification automation	Review it	Build it
Curriculum and champion programme	Yes	The developer and admin modules
Policy and data classes	Yes, with legal	A template to start from
Model migration testing	Yes	The first regression harness

Our view: an external operator running your CoE permanently is a bad arrangement, because the CoE’s value comes from knowing which departments are serious and which are performing interest, and that knowledge does not transfer. An external operator building the measurement pipeline, the group design and the first regression harness in a quarter, then handing them over, is good value. Our managed AI services guide sets out the RACI for the operating work that sits underneath.

What to demand from an adoption or CoE engagement:

1. A report that uses the analytics the platform already produces, not a custom dashboard that needs maintaining.
2. The role visibility question answered: who holds the role that can actually see Spend.
3. Group design synced from your identity provider, not created by hand in Claude.
4. Residency verification as an automated check, with the command shown.
5. A handover date, with the material and pipelines in your repository and your tooling.
6. An explicit statement that use case approval stays with the business units.

A centre of excellence inherits an operation someone else started. The 90-day adoption plan describes what that handover should contain, and the recurring cost report it takes over is set out in our AI FinOps guide.

FAQ

What is an AI Center of Excellence?

An AI Center of Excellence is a small central team that owns the functions too expensive to duplicate across departments: enablement material, policy and data classes, platform configuration such as residency and spend limits, and the measurement baseline. It should not own use case approval, which belongs with the business units running the processes.

What should an AI CoE report monthly?

Four numbers: active members against assigned seats, spend concentration, adoption level by department, and open governance items with dates. The platform supplies the first three directly through Team and Enterprise analytics and the spend report, which refreshes daily with a one-day delay and reaches back 90 days.

Who can see spend data in Claude?

On Team plans, only Owners and Primary Owners can see analytics. On Enterprise, Owners, Primary Owners and Admins can see analytics, but Admins cannot view Spend. Group spend limits additionally require a role with Billing set to “Can manage”. Check this before naming a CoE lead who needs the spend figure.

How many groups should we create?

Few. The ceiling is 1000 groups per organisation, and membership in more than 250 groups can slow performance, but a workable design needs roughly one group per data class, one per cost centre, one for developers and one for admins. Sync them from your identity provider so joiner, mover and leaver handling is inherited.

CoE vs managed service: which do we need?

A CoE owns the decisions and the numbers; a managed service operates the platform. They are complements, not alternatives. The common mistake is hiring a managed service and assuming it will make the governance decisions, which it cannot, because accountability for data classes and model policy stays with the company.

Does a CoE satisfy the AI Act literacy duty?

Not by existing. The duty, in force since 2 February 2025, requires measures that give staff and others operating the system on your behalf a sufficient level of AI literacy for their role. A CoE is a good place to own the curriculum and the records, but the records are what satisfy the duty.

Sources

1. Anthropic Support: Usage analytics for Team and Enterprise plans (28 October 2026)
2. Anthropic Support: Groups and group spend limits (28 October 2026)
3. Anthropic Support: What is the Enterprise plan (28 October 2026)
4. Claude Code: Manage costs effectively (28 October 2026)
5. European Commission: Regulatory framework for AI (28 October 2026)
6. Anthropic: Model and feature pricing (28 October 2026)