An AI center of excellence usually begins with a memo and a budget line, and eighteen months later it owns a review board, a model inventory spreadsheet, a training curriculum, and a slide library that gets cited more often than any of its systems. Nobody planned that. It happens because the center was chartered to set standards, and standards are the one output a group can produce without ever touching a production system. The version that works is chartered differently: it owns a platform, it ships code into business units, and it is funded on the systems it puts into production rather than the policies it publishes.
This is written for the executive who has been handed that charter, or who has one running and can tell it has drifted. The distinction between the two versions is not talent and it is not budget. It is structure. A center of excellence that reviews is measured on reviews. A center of excellence that builds is measured on running software. What follows is how we structure the second kind, what the first ninety days should produce, how to staff it while internal hiring catches up, and the small set of numbers that tell you each quarter whether it is working.
Why the review-board version happens
Nobody sets out to build a bureaucracy. Four forces push a new center toward one, and each of them looks reasonable at the moment it acts.
Governance is the first real demand. When a center is announced, the first inbound requests are almost always about permission. A business unit wants to know whether it may use a particular vendor model. Legal wants to know what happens to customer data. Risk wants an inventory. Answering those questions is genuine work, and it arrives before any build request does, so the center staffs for it. Within two quarters the center is the approvals desk and the queue is full.
Building requires access the center does not have. A central team cannot ship into a business unit's system without credentials, a deployment path, and a place in that unit's release process. Those take months of negotiation per unit. Writing a standard takes an afternoon. Under pressure to show progress, the center produces what it can produce alone.
The funding model rewards activity. Most centers are funded from a corporate line and report headcount, training sessions delivered, models registered, and use cases assessed. Every one of those numbers can rise while zero systems reach customers. If the reported metric is activity, the center optimizes activity, and it is not being cynical when it does.
Conditions that predict a center of excellence produces running systems
Editorial weighting, illustrative rather than measured. The last row is deliberately low: veto authority converts a build group into an approvals desk.
What the center should actually own
A center that ships owns four things and rents the rest. Everything outside these four belongs to a business unit, to platform engineering, or to risk.
The platform. One place where a model gets trained, versioned, evaluated, deployed, and watched. Not a vendor list. A running system with an account, a bill, an on-call rotation, and users who file tickets against it. If the center has no service it operates, it has no operational instinct, and it will write standards that are impossible to meet because it has never had to meet them.
The reusable middle layer. Retrieval, evaluation suitees, prompt and model versioning, feature computation, feedback capture, audit logging, cost attribution. These are the parts every use case needs and no business unit wants to build twice. They are also the parts that are genuinely hard, which is why the center should hold the best engineers it can get and point them here.
Embedded engineers. People who sit with a business unit for the length of a build, write code in that unit's repository, and leave behind something that runs. This is the mechanism by which a central group has any effect on a decentralized company. Not a review. Not a workshop. A person committing code next to the unit's own engineers for three months.
The platform, concretely
Vague platform talk is how centers spend a year and produce a diagram. Here is the shape we build, in enough detail that an engineer reading it knows whether it matches their situation.
The data plane
Two paths, not one. A batch path for anything that trains or scores on a schedule, and a low-latency path for anything a user waits on. The batch path lands in a governed store with table-level lineage and a schema registry, because the question "which version of this table produced that score" gets asked during every incident and every audit. The low-latency path reads from a feature store or a cache that is populated by the batch path, so the numbers a live model sees and the numbers a training job saw come from the same computation. Skew between training and serving inputs is the single most common cause of a model that tests well and behaves badly, and it is an architecture problem rather than a modeling one.
The model plane
Every model, including a prompt template against a vendor endpoint, gets a registry entry with the training or configuration commit, the data snapshot identifier, the evaluation results, the owner, and the approval state. Prompts are models for this purpose. A team that versions its fine-tuned classifiers rigorously and edits production prompts in a console has a governance gap it cannot see.
Serving is one interface regardless of what sits behind it. A hosted vendor model, an open-weights model on internal accelerators, and a small in-house classifier should all be reachable through the same call with the same authentication, the same logging, and the same cost attribution. This is what makes model substitution a configuration change rather than a project, and model substitution happens more often than anyone plans for, because vendor pricing moves and capabilities move.
The evaluation plane
Offline evaluation sets that live in version control with the code. Automated evaluation on every change, with results attached to the registry entry. A held-out set that the building team cannot see, held by the center, run before any promotion to production. Online measurement with a control group where the business allows it. And a human review queue for a sample of production outputs, with the reviewers' judgments feeding back into the offline set so the evaluation gets harder over time rather than staler.
The center should own the held-out sets and the review queue. That is the one place where central authority is genuinely useful, because a team cannot grade its own homework and a shared, growing evaluation corpus is an asset the whole company compounds on.
The operations plane
Structured logs of every request and response with the model version, latency, token or compute cost, and a stable identifier that lets a downstream business outcome be joined back to the specific inference that produced it. Alerting on input distribution shift, output distribution shift, latency, error rate, and cost per unit of business volume. A documented rollback that a person on call can execute at two in the morning without a machine learning engineer present. And a kill switch per model, tested, that falls back to a rule or to a human queue rather than to an error page.
How the embedded model works in practice
The embedding is the part most centers get wrong, usually by making it too light. A person who attends a business unit's standup twice a week is a liaison, not an embedded engineer, and the unit will treat their contribution accordingly.
What works: two to four engineers move into the unit's working environment for a defined engagement of roughly one quarter. They get credentials to the unit's systems, commit to the unit's repositories, and appear in the unit's release process. The unit provides a business owner who can approve a scope change and a subject-matter expert available for several hours a week. The engagement has a written acceptance test agreed before the first commit. At the end, the unit's own engineers deploy the system while the embedded team watches, and the embedded team leaves.
What they leave behind is the part that compounds. Code in the unit's repository, not the center's. A runbook the unit's on-call can follow. An evaluation suite the unit can run. And at least one of the unit's engineers who has done the work alongside them and can now do the next one. The measure of a good embedding is that the second system in that unit needs half the central support the first one did, and the third needs almost none.
Funding it so that shipping is the rewarded behavior
The funding model determines the output more reliably than the org chart does. Three shapes are common and they produce three different centers.
| Funding shape | What it pays for | What it produces | Where it breaks |
|---|---|---|---|
| Central overhead line | Headcount and tooling, allocated across the company | Standards, training, an inventory, an approvals queue | No business unit has skin in the outcome; the center is a cost to be cut |
| Full chargeback per engagement | Each unit buys the center's engineers at an internal rate | Responsiveness to whoever has budget this quarter | Nobody funds the shared platform, so every unit builds its own middle layer |
| Split: platform central, delivery charged | Central line funds the platform and shared components; units fund their own builds | A maintained platform plus builds the units genuinely wanted | Requires an honest internal rate and a platform good enough to be worth using |
| Outcome share | Center takes a share of the measured benefit | Focus on the few use cases with clean attribution | Attribution arguments consume more time than the builds |
The split model is the one we see hold up. The platform is a public good inside the company and has to be funded as one, or it decays and every unit rebuilds it badly. Delivery is a service and has to be paid for by the unit that wants it, or the center's queue fills with the requests of whoever asks most loudly rather than whoever has the most valuable problem.
Where a first engagement should start, weighted by how fast it produces a running system
Editorial weighting, illustrative rather than measured. The last row is deliberately low: the first build should be winnable, not important.
What to measure every quarter
Most center scorecards measure effort. Here is a set that measures effect. None of these requires new instrumentation beyond what the platform already produces.
- Systems in production, and how many are still in production a year later. The second half of that sentence is the honest one. A center that ships six systems a year and retires four of them within twelve months has a targeting problem worth naming out loud.
- Cycle time from funded decision to first production traffic. Measured per build, tracked as a distribution rather than an average. This is the number that tells you whether the platform is helping. It should fall as shared components accumulate, and if it does not, the components are not being reused.
- Reuse rate. What fraction of a new build's components came from the shared layer rather than being written fresh. Low reuse means the shared layer does not fit real problems, which is a signal to go build alongside a unit rather than to write a standard telling them to use it.
- Adoption inside the using unit. Not licenses issued. Active users as a share of the population the system was built for, and the frequency of use. A system used weekly by ten percent of its intended users has not landed, regardless of how well it performs offline.
- Business effect with a stated method. One number per system, agreed with the business owner before the build, measured the way it was agreed. Where a control group is possible, use one. Where it is not, say so and use the second-best method rather than quietly using the best-sounding one.
- Cost per unit of business volume. Inference cost, compute cost, and the human review cost, divided by whatever the business counts. This one keeps the center honest about the systems that work but do not pay.
- Time the platform was available, and incidents. If the center runs a service, it reports on the service like a service. This is also what earns it the standing to ask business units to meet an operational bar.
- Capability transferred. Number of business-unit engineers who have shipped a system with the center and could now ship one without it. This is the number that says whether the center is building a company capability or a permanent dependency.
The first ninety days
A new center gets one chance to set the pattern. The first ninety days should end with something running, not with a strategy document, because the pattern established in that period is the pattern the center keeps.
Weeks one through three: pick one business unit with a real, funded problem and a willing owner. Not the most important problem in the company. The one where the data exists, the owner answers email, and a working system would be visibly useful within a quarter. Write the acceptance test with the owner and get it signed.
Weeks two through six: stand up the thinnest platform that supports that one build end to end, and nothing more. Weeks four through twelve: build the system with the unit's engineers, in the unit's repository, against the acceptance test. Ship it into production traffic even if the first version handles a narrow slice or runs behind a human review step. Production traffic surfaces the problems that no amount of offline work would have found, and it converts the center from a proposal into a fact.
Week twelve: the unit deploys a change without the center in the room. Publish the numbers, including the ones that disappoint. Then pick the second unit, and notice which parts of the platform you did not have to rebuild.
How we work inside your organization
Precision Federal builds AI systems, data platforms, and the software around them, and we deliver them into production, including inside U.S. federal agencies where the bar for authorization, accessibility, and data handling is set by someone other than the sponsor. That work is why our default posture is operational rather than advisory: we assume the system has to survive a security review, an accessibility review, and an on-call rotation, and we build accordingly from the first sprint.
Inside a center of excellence, we take one of two shapes. We build the platform, delivering the registry, serving interface, evaluation suite, logging schema, and deployment pipeline as working software with the infrastructure defined as code. Or we are the embedded engineering team for a business-unit build, working in your repositories against an acceptance test your business owner signed, while your engineers work beside us and take it over.
What the first weeks produce: an architecture and a written scope with measurable acceptance criteria in the first two weeks; a working slice against your real data in your environment by roughly week six; and production traffic, even a narrow slice of it, inside the first quarter. We would rather have a small thing running than a large thing designed.
What you keep: all of it. The code is written in your repositories and assigned to you outright, with any pre-existing tooling we bring named in the agreement and licensed to you perpetually so a future maintainer is never blocked. Your data stays in your environment and is never used to train anything outside your system. The evaluation sets, the runbooks, the infrastructure definitions, and the handover are deliverables tied to payment, not favors after it. Your relationships with your business units stay yours; we are visible or invisible as you prefer.
How it is priced: fixed-price milestones tied to the acceptance criteria for a defined build, or a committed team at a fixed monthly rate when the roadmap is genuinely open. Not hours against a timesheet, because hours make us accountable for attendance and you need us accountable for a result.
The first step is one email with a one-page brief: the business problem and who owns it, the systems the result must live inside named by product, what data exists and who grants access, the security destination, and the date that matters. We return a scoped, priced statement of work with the acceptance criteria written as tests rather than adjectives.
Five ways this goes wrong
The center is given authority instead of a product. Veto power over model choices makes the center the thing business units route around. Build something they want to use and the standards follow, because the standards are compiled into the platform rather than written in a document.
The platform is built before the first build. A year of platform work with no user produces a system that fits nobody's problem. One build first, then generalize the parts that repeated.
The embedded team leaves nothing behind. Code in the center's repository, a runbook nobody read, and no unit engineer who touched it. The system is orphaned within two quarters and the center gets blamed for a failure it built into the engagement.
The scorecard measures activity. Use cases assessed, models registered, people trained. All rise while nothing ships. Change what is reported and the behavior follows within a quarter, faster than any reorganization would produce.
Hiring is treated as the only path to capacity. A senior machine learning engineer takes months to find and longer to make productive, and the center's credibility is decided in its first two quarters. Bring in an engineering team for the first builds, hire against the demand those builds prove, and let the two overlap so the knowledge lands internally rather than leaving.
Bottom line
A center of excellence becomes a review board when its charter, its funding, and its scorecard all reward output that can be produced without touching a production system. Reverse all three and the same people produce running software. Give it a platform it operates, engineers who embed inside business units and leave code behind, a split funding model where the platform is central and delivery is paid for by the unit that wants it, and a quarterly scorecard measuring systems in production, cycle time, reuse, adoption, business effect, cost per unit of volume, and engineers who can now build without you. Then spend the first ninety days shipping one narrow system into real traffic with one willing unit. The pattern set in that quarter is the pattern the center keeps for years.
Frequently asked questions
Four things: a platform it operates as a service, a reusable middle layer of retrieval, evaluation, versioning, feedback capture and cost attribution, embedded engineers who build inside business units and leave code behind, and honest measurement of adoption and effect. It should not own the decision about which use cases are worth doing, the profit and loss they affect, the risk sign-off, or the vendor contracts. Those belong to people who already own them, and a center that collects them collects resentment along with them.
Because governance questions arrive before build requests do, building requires deployment access that takes months to negotiate per business unit, the funding model usually rewards activity such as assessments and training rather than production systems, and hiring lags the mandate by about a year so the early team is staffed with people who write assessments. Each force is reasonable on its own. Together they produce a group measured on reviews, and a review culture is hard to reverse after a year of habit.
Split the funding. A central line pays for the platform and shared components, because those are a public good inside the company and decay if every business unit has to justify them separately. Business units pay for their own builds at an internal rate at or below what they would pay outside. The test is whether units route around the center. If they do, the platform is not good enough to be worth using, and the answer is better software rather than a policy forbidding the workaround.
Systems in production and how many survive a year, cycle time from funded decision to first production traffic, the share of each new build assembled from shared components, active adoption as a fraction of intended users, business effect measured by a method agreed before the build, cost per unit of business volume including human review, platform availability and incidents, and the number of business-unit engineers who could now ship a system without central help. That last one distinguishes a company capability from a permanent dependency.
Do both, overlapping. A center's credibility is decided in its first two quarters and senior machine learning hiring takes longer than that, so waiting for the team means the center's first visible output is a document. Bring in an engineering team for the first one or two builds, hire against the demand those builds prove rather than against a forecast, and have the new hires work alongside the partner so the knowledge lands internally. The handover rehearsal, where your engineers deploy while the partner watches, is the gate that makes the transfer real.