The Difference Between an Enterprise AI CoE and an AI Platform Team

Job postings blur them. Steering committees conflate them. Engineers get told to "ask the CoE" for a broken gateway alias and "ask platform" for eval template guidance — and both teams shrug. An enterprise AI CoE and an AI platform team are complementary, not interchangeable. One sets standards and grows capability; one ships and operates shared infrastructure. Role confusion duplicates effort, creates gaps, and gives domains two teams to route around instead of one fast path.

The difference, plainly#

Platform builds and runs the rails. CoE teaches people to ride them — and curates which patterns belong on them.

Charter comparison#

Neither team should own end-user workflows. That stays with domain product + engineering.

What platform owns#

Concrete platform responsibilities:

• Model gateway — aliases, routing, spend tags, rate limits
• Logging and redaction — prompt/response retention, PII handling
• Tool registry / MCP integration — allowlist, threat review hooks
• Eval harness infrastructure — runners, result storage, CI integration
• Deployment templates — how domain services connect to gateway and observability
• SLOs on shared services — error budget policy for internal customers

Platform says no to unsafe configs. It also publishes SLAs for provisioning and documents the blessed path.

What CoE owns#

CoE responsibilities that platform should not absorb:

• Reference architectures per job class — kept in sync with what platform actually supports
• Golden-set examples — starter evals domains copy and extend
• Training and office hours — eval design, tool governance, incident retros
• Portfolio reporting — pilots vs prod, kill recommendations
• Cross-BU learning — postmortem library, community of practice

CoE does not merge gateway PRs at 3 a.m. Platform does.

Handshake interfaces#

Healthy orgs define explicit interfaces:

from dataclasses import dataclass
from typing import Literal

Role = Literal["coe", "platform", "domain"]

@dataclass
class WorkItem:
    title: str
    primary_owner: Role
    consult: list[Role]

ROUTING_TABLE = [
    WorkItem("Add new model alias in prod gateway", "platform", ["coe"]),
    WorkItem("Publish eval template for RAG job class", "coe", ["platform"]),
    WorkItem("Domain workflow on-call incident", "domain", ["platform", "coe"]),
    WorkItem("Gateway outage", "platform", ["coe"]),
    WorkItem("Tier-2 autonomy policy update", "coe", ["platform", "domain"]),
    WorkItem("CI gate for minimum logging fields", "platform", ["coe"]),
    WorkItem("New tool MCP server approval", "platform", ["coe"]),
]

def resolve_owner(title: str) -> WorkItem | None:
    for item in ROUTING_TABLE:
        if item.title == title:
            return item
    return None

Publish this routing table internally. Ambiguity is how shadow IT wins.

Sequencing requests domains should follow#

1. Design workflow — domain + CoE office hours optional
2. Provision rails — platform ticket: gateway namespace, logging, CI template
3. Implement + eval — domain, using CoE starter sets
4. Risk review — tiered by job class; CoE does not replace risk
5. Prod deploy — domain on-call; platform pager only for shared services

Domains that skip step 2 and paste API keys into a Lambda recreate the split teams were meant to prevent.

Metrics each team publishes monthly#

Confusion fades when dashboards show separate scorecards:

If CoE reports high template adoption but platform sees traffic bypassing the gateway, someone is measuring the wrong thing — fix the metric, not the org chart again.

Escalation when routing fails#

Default to platform for shared-service uptime or gateway policy. Default to CoE for pattern gaps. Hold joint office hours weekly. Escalate to steering only when SLAs are missed twice — not for every disputed PR. Publish escalation next to the routing table.

Org chart patterns that work#

Three common patterns — pick one explicitly:

Dual track fails when CoE and platform do not meet weekly. Platform-led fails when enablement becomes afterthought ticket backlog. Federated fails early when domains lack AI depth — start centralized enablement, federate later.

Summary#

An enterprise AI CoE enables: standards, patterns, training, portfolio hygiene. An AI platform team delivers and operates: gateway, logging, eval infrastructure, deploy paths. CoE shapes behavior; platform shapes traffic. Define routing, avoid overlap on gateway ownership and standards enforcement, and keep domain workflows owned by domains. Clarity between the two teams is what makes the sanctioned path faster than shadow IT.