Building an Enterprise AI Operating Model

Enterprise AI programs often start with seats: a thousand chat licenses, a hackathon, a slide about transformation. Twelve months later the same enterprise has dozens of shadow GPT wrappers, no shared evals, and a security team chasing API keys in Slack. Bolting AI onto the org chart fails for the same reason bolting a model onto a deterministic app fails: the control plane never changed.

Start from work, not from models#

Pick a small set of job classes tied to measurable workflows: ticket draft + retrieval, contract clause extract, invoice field capture, internal search with citations. For each, define:

• Owner (product + engineering + risk)
• Success metric (time saved, error rate, deflection — pick one primary)
• Data sources and tool permissions
• Kill criteria if quality or risk misses the bar

If you cannot name the workflow and the metric, you are funding theater.

An operating model that fits how enterprises actually ship#

You need three roles, even if people wear multiple hats:

1. Platform — gateway, logging, eval harness, approved models, MCP/tool registry
2. Domain builders — workflow owners who ship on the platform
3. Risk partners — security, legal, compliance with review SLAs measured in days, not quarters

A Centre of Excellence that only writes standards nobody can consume will be ignored. A CoE that runs the gateway and the golden-set service becomes a bottleneck worth having.

Shared platform before hundred custom stacks#

Every team reinventing auth for LLM calls is how you get breaches. Mandate early:

• Model access through a gateway with aliases and spend tags
• Logging/redaction standards
• A shared eval pattern (even if golden sets stay domain-owned)
• A process to add tools (threat model + allowlist)

Local experimentation can happen in sandboxes with synthetic data. Production paths use the platform.

Adoption stages that do not skip controls#

People and change#

Training should teach when not to trust the output and how to escalate — not only how to write prompts. Measure adoption as workflows in production with owners, not seat counts. Seat counts flatter executives and hide shadow IT.

Procurement belongs after job classes and constraints exist. Buying the "best" model before you know the job recreates last decade's shelfware problem with tokens.

Funding and incentives#

If every business unit is scored on "number of AI pilots," you will get pilots. Score them on production workflows with eval pass rates and cost envelopes instead. Tie platform funding to shared services that remove duplicated spend. Punish (gently) production traffic that bypasses the gateway — with blocking, not only with emails.

Data readiness without boiling the ocean#

You do not need a perfect lakehouse to start. You need authorized access to the systems the workflow needs, retention rules, and a path to redact logs. Deliver the minimum data contract per job class; expand the platform data products as patterns repeat.

Executive reporting that is not fiction#

Report: workflows in production, quality vs baseline, incidents, cost per successful task, and privilege expansions approved. Do not report: total prompts typed, models ranked on public leaderboards, or hackathon trophy counts.

Vendor selection after job classes#

Model bake-offs before you know the job are expensive theater. Freeze job classes and constraints first, run candidates on golden sets you own, score outcome and cost together, then pilot one alias with canary traffic. Prefer model aliases over brand loyalty — swapping vendors becomes a config change with eval gates, not a rewrite of every service. Two approved providers through one gateway beats forty shadow accounts.

Summary#

Enterprises adopt AI safely by changing the control plane: workflow-shaped job classes, a shared platform for models and tools, eval and security gates with real SLAs, and scale only on those rails. Licenses and demos are inputs. Operable workflows with owners and metrics are the output. Everything else is bolting on.