Field notesStrategy & leadership
What an AI center of excellence should own, and what it shouldn’t.
A small central team should own shared foundations, standards, evaluation practice and vendor contracts. Workflows and their results belong to business owners. A center of excellence that approves every idea turns into a queue.
veridive6 min read
A center of excellence should make AI work easier to do well across the company, not route every idea through a committee. That means a small central team owns what every workflow needs and none should rebuild: shared foundations, standards, evaluation practice and vendor contracts. The workflows themselves, and their results, belong to the business owners who run them.
Get the split wrong one way and each department buys its own tools and repeats the same security review. Get it wrong the other way and the center approves every idea, and turns into a queue.
What problem is a center of excellence meant to solve?
Without one, the same work happens many times over. Each department signs its own contract with a model provider, runs its own security review of the same service, and invents its own way of judging quality, or skips it. Nobody can list which AI systems are in production, which decisions they touch or who owns them.
A center of excellence solves duplication and blind spots: one set of contracts, shared components, consistent standards and a single register. It is also where hard-won lessons collect: which provider terms passed review, which evaluation habits caught real problems, which review screens people actually liked. It should not take over choosing and running workflows, because that knowledge lives in the business.
What should stay central?
The rule: if more than one workflow needs it, or it commits the company to a supplier, it is central. If it defines what good means for one workflow, it belongs to that workflow’s owner. If it touches identity, networks or hosting, it belongs to IT and security.
| Responsibility | Central team | Workflow owners | IT and security |
|---|---|---|---|
| Choosing workflows to change | Advises, keeps the list | Decide | Consulted |
| Baseline, acceptance criteria, results | Sets the standard | Own | – |
| Reference answers for evaluation | Trains, reviews | Write | – |
| Model access and provider contracts | Owns | Consulted | Reviews security terms |
| Shared retrieval, logging, monitoring | Builds, maintains | Use | Hosts, secures |
| Identity, access and networks | Consulted | – | Owns |
| Security and data-protection review | Coordinates | Supply facts | Owns, with the DPO |
| Register of systems in production | Keeps it | Keep their entries current | Consulted |
| Running or stopping a workflow | Supports | Decide | Supports |
The default, when something doesn’t fit the rule: it stays with the business owner, and the central team helps.
What should stay with business owners?
Everything that depends on knowing the work: which workflows to change, what a good answer looks like, where a person approves, how the review screen fits the team’s day, and whether the result is worth keeping. The owner writes the reference answers, signs off the acceptance criteria, runs the system after launch and decides when to stop it. The workflow’s budget sits with them too, so the decision to spend and the benefit land in the same place.
It mirrors how our own projects run: the domain owner, the person whose work changes, is essential, and the builders never decide what correct means.
How big should the central team be?
Small, and sized by the number of workflows in flight rather than by ambition. Describe it by responsibilities, not by a target number of people; in a smaller company one person may hold two of them.
- Lead: owns the portfolio view, the contracts and the standards, and stops the center from trying to do everything itself.
- Applied AI engineers: build the shared components and work alongside workflow teams, building with them rather than for them.
- Evaluation owner: keeps evaluation practice honest, from templates to reviews of acceptance criteria to checks that automated grading agrees with people.
- Enablement: training by role and a network of champions, the work AI enablement covers.
Picture an illustrative case: a central team of four supporting five business-owned workflows, namely supplier confirmations in procurement, returns decisions in customer service, month-end commentary in finance, contract checks in legal and policy questions in HR. Each owner holds the baseline, the reference answers, the review design and the results. The center holds the provider contract, one retrieval component shared by legal and HR, logging and monitoring, the evaluation templates and the register. Nobody in the center owns a workflow. Resist staffing the center for the roadmap you hope for: add a person when workflow teams are waiting on something shared, not before.
How do you stop it becoming a bottleneck?
Watch for three anti-patterns:
- The innovation lab that ships demos. Signs: impressive prototypes, nothing in production, no owners outside the lab. Fix: every project starts with a business owner and a baseline, and the lab is judged by workflows in production.
- The approval committee. Signs: every idea waits for a monthly meeting, and teams quietly buy tools of their own. Fix: publish standards and a self-service path. Low-risk uses, such as an approved assistant for internal drafting, need no approval; consequential uses get a review with a time limit.
- The platform before the workflow. Signs: months of platform work with no user, and requirements that are guesses. Fix: build foundations for the first workflows that need them, and generalize when the second needs the same thing.
A center of excellence that approves every idea turns into a queue.
Two signals show whether it works: the time from an idea to its first evaluation on real examples, which should be weeks rather than quarters, and the number of workflows in production with named owners.
How does the model change as you scale?
It moves outward in stages:
- First workflows: the central team is hands-on and builds with the first owners.
- Several workflows: hub and spoke. The hub keeps foundations and standards; the spokes, champions or engineers placed in business units, build and run.
- Many workflows, or several companies: federated. Business units have their own AI leads, and the hub narrows to contracts, standards, the register and shared components.
One thing stays constant: workflows and results stay with their owners. In a group of companies the same logic applies one level up, as AI in a group of companies explains, and the register is what a board should ask to see.
Find the unclaimed rows
Fill in the responsibilities table for your own company, with names, and look for the rows that two groups claim or nobody does. Those rows are the real gaps in your operating model. Choosing the first workflows for the center to support is where AI strategy and discovery begins.
Sources
- Artificial Intelligence Risk Management Framework (AI RMF 1.0), NIST AI 100-1 National Institute of Standards and Technology (NIST) nvlpubs.nist.gov/nistpubs/ai/NIST.AI.100-1.pdf
- ISO/IEC 42001:2023 Information technology — Artificial intelligence — Management system International Organization for Standardization (ISO) www.iso.org/standard/42001
Ask an assistant about this note