The phrase AI Center of Excellence has surfaced several times in recent discussions about AI leadership, operating models, and the roles organizations need as they move beyond experiments.
The interesting part for me is that I have already been doing much of this work. For close to four years, I have worked inside the Department of Government Enablement in Abu Dhabi. More recently, my work has focused on government-wide AI and data product portfolios. It has connected business priorities, data readiness, product ownership, delivery, governance, and adoption across government entities.
The wider ambition is significant. Abu Dhabi aims to become the world's first fully AI-native government across all digital services by 2027. DGE leads that transformation with Abu Dhabi Government entities.
When I compare that work with how AI Centers of Excellence are now being defined, the overlap is clear. An AI CoE is not mainly a team of technical experts. It is the operating model that turns AI ambition into repeatable delivery.
The hardest part of AI transformation is rarely access to a model. It is building the organizational system around it.
An AI CoE Is Not an AI Lab
The name can be misleading. It suggests a central team of AI specialists who receive problems from the rest of the organization and build solutions for them.
That model has limits. The central team soon becomes a queue. Business ownership weakens. Each project needs fresh integration, security, evaluation, and monitoring work. Pilots increase faster than production products.
A serious AI CoE has a wider role. It connects strategy with execution. It creates a common way to decide what gets built, who owns the outcome, which platforms and data are used, how risk is handled, how products enter production, and how value is measured.
The technical team is one part of this system. The full model brings together portfolio management, AI product management, platforms, data, architecture, engineering standards, security, responsible AI, reusable components, training, adoption, and value measurement.
This is much closer to the work I experienced in Abu Dhabi than the traditional image of an AI lab.
The Portfolio Matters More Than the List of Use Cases
AI experimentation is easy to start. A team gets access to a model and builds a chatbot. Another group starts a retrieval solution. A department buys an AI product. A third team tests agents.
The difficult questions come later. Which initiatives support a real priority? Is the required data ready? Who owns adoption? Are several teams building the same components? What moves from demonstration to production? Who stops weak work?
At government or enterprise scale, there will always be more ideas than delivery capacity. A CoE needs a portfolio process that compares opportunities on the same basis.
Strategic value matters. Expected economic or public value matters. Data readiness, technical feasibility, ownership, adoption effort, and risk matter as well.
This changes the leadership question from "What AI use cases do we have?" to "Where should we invest next?" It also gives leadership permission to stop work. Ending a weak pilot is not failure. It protects scarce people, time, and funding for stronger opportunities.
An AI CoE should therefore track production conversion, adoption, realized value, delivery speed, reuse, operating cost, reliability, and risk. Pilot count says little about transformation.
The Business Must Own the Outcome
Central AI teams often fall into a supplier model. The business asks for something. The AI team builds it. The business reviews it.
This creates an ownership gap. The AI team controls delivery, but it does not control the process being changed, the people expected to use the product, or the business result.
I prefer a federated model. The central CoE owns the common system. This includes portfolio governance, shared platforms, reference architecture, approved patterns, evaluation methods, specialist expertise, and reusable components.
The business or government entity owns the problem, product direction, adoption, and value. Joint product teams handle delivery.
This split matters in whole-of-government work. Central coordination supports consistency and reuse. Government entities still need active ownership because they understand their operations, users, regulations, and data in ways a central team never fully will.
From Use Cases to AI Products
Language shapes behavior. I prefer to talk about AI products instead of AI use cases.
A use case describes an opportunity. A product requires an owner, users, requirements, data, technology, success measures, acceptance, operations, and a lifecycle.
A demonstration needs little of that. A production product needs all of it.
This is why product management belongs at the center of an AI CoE. Someone must connect executive expectations with engineering reality. Someone must turn broad ambition into a portfolio, challenge weak business cases, expose dependencies, define success, and keep delivery tied to outcomes.
Technical fluency helps. My own work stays close to AI agents, agent harnesses, APIs, MCP, knowledge graphs, ontologies, data products, and platform architecture. That context makes it easier to see when an idea is realistic, when architecture is becoming too complex, and where shared capability beats another standalone solution.
Reuse Changes the Economics
One AI product might need model access, data connections, identity, logging, evaluation, monitoring, retrieval, APIs, agent tools, security controls, and cost tracking.
The next product often needs many of the same elements.
If every team builds them again, AI becomes slow and expensive. The CoE should identify repeated patterns and turn them into shared services.
A model gateway is one example. Common evaluation tooling is another. The same applies to approved models, data access patterns, agent tooling, security controls, monitoring, templates, and reference architectures.
The first product then carries part of the cost of building shared capability. Later products reuse it. The tenth product should be easier to launch than the first. If delivery does not improve over time, the organization is accumulating projects rather than capability.
Governance Must Sit Inside Delivery
Governance often appears too late. Teams experiment freely until security, privacy, architecture, or legal concerns appear close to production.
The opposite approach sends every idea through the same heavy approval route. That slows low-risk work without giving high-risk systems enough attention.
A better model starts with risk classification. An internal assistant that searches approved information needs a different route from an autonomous system that affects legal, financial, safety, or citizen outcomes.
Business criticality, data sensitivity, autonomy, affected users, model provider, human oversight, and the consequences of failure should determine the controls. Governance then becomes part of product design, not a final checkpoint.
Measure Value, Not AI Activity
AI programs produce many impressive-looking numbers. They count use cases, prompts, agents, models, trained employees, and saved hours.
Most of these measure activity.
A strong CoE measures outcomes. I would track realized value, adoption, time to production, pilot-to-production conversion, reuse, cost per successful task, reliability, human overrides, risk incidents, and benefit realization against the approved business case.
Productivity claims need extra care. Saving 10,000 employee hours does not mean the organization saved the financial value of 10,000 hours.
You need to know what happened to the released capacity. Was work removed? Did external spend fall? Did throughput increase? Were people moved to higher-value work? Did service quality improve?
Without this discipline, every AI initiative eventually reports success.
The CoE Should Evolve
A successful AI CoE should not keep growing forever.
Its early role is often central. Scarce expertise needs concentration. Standards, platforms, governance, and initial products need hands-on support.
Then the model should change. Domain teams learn. Shared platforms stabilize. Delivery patterns become reusable. Local AI product leadership develops.
The center should move from building everything toward helping others build well. It retains portfolio oversight, common platforms, standards, governance, reusable assets, and specialist support. Domain teams take greater responsibility for products and outcomes.
The objective is not permanent dependence on the CoE. The objective is to make sound AI delivery a normal organizational capability.
What I Would Establish in the First 90 Days
The first three months should produce a working delivery system, not a large organizational design exercise.
At day 90, leadership should review the evidence. Weak initiatives should stop. Strong ones should receive production funding. The CoE should publish its first standards, service catalogue, scorecard, and delivery roadmap.
The Operating System for an AI-Native Organization
My work on AI and data products in Abu Dhabi Government changed how I think about AI transformation.
Strategy has to connect to a portfolio. The portfolio has to connect to products. Products need owners. Owners need data and platforms. Delivery needs common patterns. Governance needs to work inside that process. Leaders need evidence that investment creates value.
That is what I now see when people talk about an AI Center of Excellence.
It is not a room full of AI experts. It is the operating system that moves an organization from scattered AI activity to repeatable AI delivery.
When the ambition is to become AI-native, that operating system matters as much as the AI itself.
This article condenses the main argument from the full whitepaper, AI Centers of Excellence: Operating Model, Economics, and Implementation Blueprint.
