Liam Whitfield is the Chief Information Officer for a state government's central IT authority, a body that serves 38 executive branch agencies, a combined IT workforce of about 1,600 people, and a technology budget the Governor's office reviews line by line every October. For two years he has fielded the same request from 14 different agency CIOs: help us stand up AI capability. Each wanted something slightly different, a document summarization tool here, a chatbot there, a predictive analytics platform for another, and each request arrived with its own procurement timeline, its own vendor preference, and its own estimate of the staff time required to run and govern the tool. Every request was individually reasonable. Taken together they described a state government about to buy the same foundation fourteen times over.

When Liam added the numbers up, 14 separate AI deployments would consume approximately $18 million in combined first-year licensing and implementation cost, would require at least 28 full-time equivalent staff across those agencies to manage and govern, and would produce 14 separate vendor relationships under 14 separate contract structures. He took a different proposal to the Governor's office: a shared AI platform serving all 38 agencies from centralized infrastructure, with shared governance, shared procurement, and shared security review. The first-year cost estimate was $4.3 million, and the projected reach was every agency with access to tested, governed AI tools within 18 months of approval.

Why Fragmentation Is Expensive

When government AI development proceeds agency by agency, each agency reinvents the same infrastructure. Every agency negotiates its own cloud contracts, establishes its own data pipelines, builds its own security review process, and trains its own governance staff. The capabilities they end up with may differ at the surface, but the foundation underneath is largely identical: storage, compute, model access, monitoring, security controls, and audit logging. Paying 14 times for one foundation is the most visible cost of fragmentation, and it is not the most damaging one.

Fragmented development also fragments accountability. When each agency runs its own AI deployment, the risks scatter across 38 separate risk registers, 38 separate oversight chains, and 38 separate conversations with the legislature and the public. Errors that a shared monitoring function would catch stay invisible until they surface as individual agency incidents. Good practice developed by one agency does not reach the others by any route except chance and personal networks. Nobody can answer the legislature's simplest question, which is how many AI systems the state operates and what they do.

Then there is the contract burden, which is easy to overlook because it falls on procurement staff rather than on technologists. Fourteen deployments mean 14 vendor relationships under 14 separate contract structures, each with its own renewal date, its own data handling terms, its own service levels, and its own security representations. Every one of those has to be negotiated, monitored, and renewed by people who are not AI specialists, and any AI-specific protection the state wants, such as a prohibition on training vendor models with state data, has to be won 14 separate times against 14 different negotiating positions.

Shared services and infrastructure models address this by treating AI as a platform rather than as a collection of unrelated projects. The platform serves multiple agencies from a common technical foundation. The governance structures, security reviews, procurement frameworks, and monitoring capabilities are built once and shared. Consuming agencies get infrastructure they could never individually justify or maintain, and the central authority gets economies of scale, consistent oversight, and cross-agency visibility into AI performance and risk that no federated arrangement produces on its own.

Reading Liam's Numbers Honestly

Liam's two figures are the strongest slide in his deck, which is exactly why he needs to present them carefully. The $18 million estimate covers first-year licensing and implementation for the 14 agencies that asked. The $4.3 million estimate covers a platform intended to serve all 38. Those are not the same denominator, and an auditor will notice within a minute. The shared platform is being credited with broader reach and lower cost at the same time, and a budget office that discovers the mismatch after approval will discount every future number the central authority produces.

The honest framing keeps both inputs visible and lets the reader do the arithmetic. Fourteen agency deployments at approximately $18 million, against one platform at $4.3 million reaching 38 agencies, is a real argument, and it is stronger when the difference in scope is stated rather than buried. Liam should also mark clearly what the $4.3 million does not include: the agencies' own application development on top of the platform, their own staff time for governance, and the change management inside 38 organizations. Understating those is how shared-service business cases lose credibility in year two.

Beware the tidy percentage in particular. Reduction claims expressed as a single ratio invite challenge precisely because they compress the scope difference out of view, and a percentage that does not reconcile with the two figures underneath it will be treated as evidence that the whole case was assembled backwards from a conclusion. Publish the inputs, name the assumptions behind each, and let the oversight body compute the savings itself. A number the legislature calculated is a number the legislature will defend.

The staffing figure deserves the same treatment as the money, and usually gets less. At least 28 full-time equivalent staff across the 14 agencies is a real constraint, and in most jurisdictions it is harder to satisfy than the budget, because vacant technical positions cannot be filled at the speed a deployment schedule assumes. A shared platform does not eliminate that staffing need. It moves part of it to the central authority and leaves each agency responsible for its own application, its own data stewardship, and its own programmatic oversight. State plainly which part moves and which part stays.

The Three Principal Models

Government AI shared services typically take one of three forms, or a hybrid that borrows from more than one. The choice is not primarily technical. It follows from how much variation exists in agency mission requirements, how uneven technical capacity is across the agencies, and how much central authority the jurisdiction's budget and governance structure actually grants the central IT organization.

The centralized platform model provides a single AI infrastructure stack, covering cloud compute, data storage, a model deployment environment, a monitoring dashboard, and security controls, maintained by a central IT authority and consumed by agencies through a service catalog. Agencies request access to specific capabilities such as a large language model interface, a document processing service, or a predictive analytics environment, receive provisioned access with standard security controls already applied, and run their own applications on the shared infrastructure. Liam's proposal follows this model: the central authority maintains the platform, and agencies build or configure on top of it.

The federated model keeps agency-level AI infrastructure but establishes shared standards, shared procurement vehicles, and shared governance frameworks that agencies adopt independently. Each agency deploys its own tools, but every tool must be procured through an approved vendor route, must meet a common security baseline, and must be registered in a central AI inventory. The central authority supplies shared governance resources, including standard risk assessment frameworks, bias testing methodologies, and incident report templates, that agencies use without being required to run on the same technical platform.

The Center of Excellence as shared service model maintains a central team of practitioners, meaning engineers, data scientists, security specialists, and governance experts, who supply expertise to agencies project by project rather than operating a central technical platform. Agencies own their own infrastructure and draw on the Center of Excellence for design consultation, risk assessment support, bias testing, and implementation guidance. This model works best where agency AI capacity varies widely: agencies with strong internal technical teams operate largely on their own, and agencies with thin capacity get expertise they could never justify hiring full time.

The disadvantages column deserves as much attention in the business case as the advantages. A centralized platform concentrates risk as efficiently as it concentrates cost: a platform-level outage or a platform-level security finding lands on every consuming agency simultaneously, which is a materially different incident profile from 14 independent systems failing independently. That concentration is manageable, but only if it is designed for and disclosed up front rather than discovered during the first incident. The federated model inverts the same trade: its failures stay local, and so does everything it learns from them. Neither pattern is safer in the abstract, and the sensible question is which failure mode your jurisdiction is better equipped to absorb.

What a Shared Platform Actually Provides

It helps to be concrete about what is being shared, because executives approving a platform and engineers building one often have different pictures in mind. The technical foundation is storage, compute, model access, monitoring, security controls, and audit logging. That list is unremarkable, and that is the point: it is substantially the same list every agency would otherwise assemble independently, which is why building it once is worth the coordination cost of getting 38 organizations to agree on anything.

Agencies reach that foundation through a service catalog. An agency requests access to a specific capability, receives provisioned access with the standard security controls already applied, and then builds or configures its own application on top. The division of labor matters: the central authority owns the platform and the controls, and the agency owns the application, the data it puts in, and the programmatic decision about whether AI belongs in that process at all. Blurring that line is how central authorities end up accountable for mission decisions they did not make.

The less visible half of the platform is the governance apparatus, and it is usually the half that justifies the investment. A security review process, a risk classification scheme, bias testing methodology, incident report templates, and a monitoring function are all built once and applied consistently. An agency that consumes the platform inherits all of it on day one. An agency building alone would have to develop each artifact itself, typically with two or three staff who have other jobs, and would produce something less rigorous a year later.

Cost-Sharing Models and Budget Mechanics

Shared AI infrastructure needs a funding model that survives contact with government budgeting. The complication is structural: agencies typically operate from separate appropriated budgets, and the benefit of shared infrastructure, which is a lower cost per agency, may not appear as a line in any single agency's budget. A platform that is technically excellent and financially unsponsored will be defunded in the second or third budget cycle, usually at the point where the original executive sponsor moves on. Cost mechanics are therefore a design decision, not an administrative afterthought.

Usage-based billing charges each agency for the compute, storage, and service calls it consumes on the shared platform. It aligns cost to benefit and creates a natural incentive for agencies to manage their own consumption. It also obliges the central authority to maintain accurate usage metering and to produce invoices clear enough that an agency budget officer can reconcile them against program costs without a support ticket. Where metering is opaque, agencies stop trusting the bill, and distrust of the bill becomes distrust of the platform.

Flat-rate subscription charges each agency a fixed annual amount for access to the full service catalog regardless of usage. It is simpler to administer and far more predictable for agency budget planning, which matters more in government than in most commercial settings because agencies must forecast a year ahead. It creates less incentive to manage consumption, and it may be the right choice anyway where usage is difficult to meter or where consistent access is a policy goal independent of volume.

Central appropriation funds the platform directly through the central IT authority, and agencies consume it at no charge to themselves. This is most common where the legislature has made a deliberate decision to fund shared digital infrastructure centrally. It removes per-agency billing complexity entirely and maximizes adoption, at the cost of concentrating budget risk: when the platform's appropriation is reduced, there is no diversified revenue base to absorb the reduction, and every consuming agency is affected by a decision none of them participated in.

The strongest argument for shared AI infrastructure is not the cost saving at all. It is that a well-governed central platform tends to produce better and safer AI than 38 agencies each assembling governance from scratch with two or three staff members and a fresh procurement every year. Cost is the argument that opens the budget conversation. Governance quality is the argument that should decide it, and it is the one that holds up when a cheaper fragmented alternative appears.

Governance of Shared Resources

Shared AI infrastructure needs a governance structure that balances central oversight against agency mission autonomy. The central authority has to maintain security, manage vendor relationships, enforce the common governance baseline, and arbitrate disputes about platform access and priority. The agencies have to retain authority over their own AI applications, their own data, and their own decisions about when and how AI is used in their programs. Getting this boundary wrong in either direction is fatal: too little central authority and the baseline is fiction, too much and agencies route around the platform.

Four mechanisms carry most of the weight. A platform governance board with representation from both the central authority and the largest consuming agencies makes the decisions that affect everyone. A standard onboarding process for new AI applications sets what security review, risk classification, and governance documentation are required before an application goes live. A change management process for platform updates gives agencies advance notice and testing time before anything moves underneath them. A clear incident escalation path handles platform-level failures that hit multiple agencies at once, including who notifies whom, in what order, and within what timeframe.

Onboarding is where the governance baseline is actually enforced, so it is worth designing rather than improvising. A standard onboarding path asks the same questions of every new application: what the system does, what data it touches, what decision it informs, who owns it, what security review it has passed, what risk classification it carries, and what governance documentation exists. The value is not the paperwork. It is that the platform's inventory is complete and current by construction, because nothing reaches production without passing through the same gate.

A governance board with no agency representation does not produce compliance; it produces shadow deployments. Agencies whose needs the platform is not meeting will procure outside it, usually as a feature inside software they were buying anyway, and the central authority will discover the deployment later through an audit or an incident. Structured agency input is therefore not a courtesy extended to consuming agencies. It is the mechanism that keeps the AI inventory honest, and the inventory is the artifact every oversight body will eventually ask to see.

Who Benefits Most, and Who Has to Be Persuaded

Shared infrastructure delivers the most value to the smallest agencies. A large agency can usually justify its own AI governance function, its own security review capacity, and a technical staff deep enough to evaluate a vendor claim. A small agency with a handful of IT staff cannot build any of that, and it is precisely the small agency whose unsupported AI deployment is most likely to cause a public failure. Shared security review, shared governance frameworks, and shared expertise transfer capability to exactly the organizations that have no route to acquiring it alone.

The corollary is that the largest agencies are the hardest to recruit and the most important to keep. They bring the usage volume that makes the economics work, and they are the ones with viable alternatives, because they can genuinely run their own stack. A platform strategy that treats large-agency participation as automatic will lose it. Their price for joining is usually influence over the roadmap, credible service levels, and an exception path for genuinely specialized requirements, and all three are cheaper to grant at design time than to negotiate after a major agency has announced it is going its own way.

Some jurisdictions resolve this by adopting a hybrid deliberately: a centralized platform as the default, a Center of Excellence for agencies whose needs the platform does not fit, and federated standards binding everything registered in the central inventory regardless of where it runs. That arrangement costs more to govern than any single model, and it is often the only one that survives a real portfolio of agencies with genuinely different missions. What matters is that the hybrid is chosen and documented, rather than arrived at by accumulating exceptions until no one can describe the operating model.

One caution applies whenever a shared-service business case cites another jurisdiction's arrangement or a specific government-wide contract vehicle as precedent. Named vehicles, shared-service providers, and interagency programs are reorganized, consolidated, and retired more often than planning documents are updated, and several well-known names in this space now refer to something other than what they referred to when the case study was written. Confirm the current status, scope, and eligibility of any named vehicle or provider with your own procurement office before a plan depends on it.

Anti-Patterns

Selling the platform on a savings percentage that does not reconcile

The failure looks like a single confident ratio in the executive summary, unattached to the figures that produced it. It is the easiest claim in the deck to check and the fastest one to discredit the whole case, particularly when the fragmented estimate covers a different set of agencies than the shared estimate. Publish both totals and both scopes, state what each excludes, and let the budget office compute the difference. A savings figure the reader derived is durable; a savings figure you asserted is a target you will be measured against.

Building the platform before designing the cost model

Teams build first because the technical work is more tractable than the funding question, then discover in the second budget cycle that no agency has a line item for platform consumption and the central appropriation was one-time. The platform then either shuts down or limps along unmaintained, which is worse than never having built it because agencies have already migrated onto it. Decide between usage-based billing, flat-rate subscription, and central appropriation before the first agency is onboarded, and get the mechanism written into the budget instructions.

Governing the platform without the agencies in the room

A central authority that sets platform priorities alone will optimize for what it can see, which is infrastructure cost and security posture, and will systematically underweight what it cannot see, which is agency mission urgency. Agencies respond by buying AI capability as a feature inside other software, where no platform governance reaches it. The visible symptom is a central inventory that is quietly incomplete. Seat the largest consumers on the governance board and give the smallest ones a real route to raise a requirement.

Treating consolidation as governance

Consolidating 14 deployments onto one platform relocates risk; it does not by itself reduce it. A shared platform with weak monitoring, unclear risk classification, and no incident escalation path is a single system with 38 agencies' exposure attached to it, and its failures are correlated rather than independent. The platform earns its governance claim only through the review, monitoring, and escalation machinery actually standing behind it, and that machinery has to be funded and staffed as explicitly as the infrastructure is.

Letting the exception path become the operating model

Every platform grants exceptions, and each individual exception is defensible. The pattern to watch is the aggregate: once enough agencies operate outside the standard baseline, the jurisdiction has a federated model it never chose, without the shared standards and central inventory that make a federated model work. Track exceptions as a portfolio, review them on a schedule, and if the exception rate keeps climbing, change the model deliberately rather than letting it drift.

Practice Prompts

Work these against your own jurisdiction rather than against Liam's, using real agency names and real budget figures wherever you have them and marking clearly where you are estimating. The output of each should be short enough to put in front of a budget office without a covering memo, and specific enough that someone who disagrees can point to the exact assumption they dispute.

1. Inventory every AI deployment and AI procurement request currently in flight across your agencies. For each, record the sponsoring agency, the estimated first-year cost, the staff required to operate and govern it, and the vendor. Identify where two or more agencies are buying substantially the same capability.
2. Build the fragmented-versus-shared comparison for your own portfolio. State the total first-year cost of the separate deployments, the total for a shared alternative, and the number of agencies each figure covers. Write one sentence naming what each estimate excludes.
3. Choose between the centralized platform, federated, and Center of Excellence models for your jurisdiction, and write the case in one page. Justify the choice against three specific conditions: variation in agency mission requirements, spread of technical capacity across agencies, and the actual authority your central IT organization holds.
4. Draft the cost-sharing mechanism. Pick usage-based billing, flat-rate subscription, or central appropriation, and work through what happens to each consuming agency in a year when the platform's funding is cut. Name who absorbs the reduction under your chosen mechanism.
5. Design the platform governance board. Specify which agencies hold seats and why, how a small agency raises an unmet requirement, how exceptions are granted and reviewed, and what the escalation path is for an incident that affects every consuming agency at once.

Reflection

Think about the AI capability already running across your agencies, including the systems that arrived as features inside software bought for another purpose. How many of them could you name without asking anyone? If the number is lower than you would like to admit, that gap is the actual starting condition for any shared-service strategy, because a platform cannot consolidate what nobody has counted.

Then consider the incentive question from the other side of the table. If you ran one of your jurisdiction's largest agencies, with your own technical staff and your own vendor relationships, what would a central platform have to offer before you gave up control of your own stack? What would make you quietly buy outside it instead? The honest answer to the second question is the specification for the first, and it is usually about roadmap influence and response times rather than about price.

Glossary

• Shared service. A capability built and operated once by a central organization and consumed by multiple agencies, rather than rebuilt separately inside each one.
• Centralized platform model. A shared AI infrastructure stack maintained by a central IT authority and consumed by agencies through a service catalog, with standard security controls already applied.
• Federated model. An arrangement in which agencies run their own AI infrastructure but adopt shared standards, shared procurement routes, and a central inventory.
• Center of Excellence. A central team of technical and governance practitioners that supplies expertise to agencies project by project rather than operating a platform.
• Service catalog. The published list of capabilities a platform offers, the terms of access to each, and the process by which an agency requests provisioning.
• Chargeback. The mechanism by which the cost of a shared service is recovered from consuming agencies, whether by metered usage, a flat subscription, or not at all under central appropriation.
• Shadow deployment. An AI system procured or enabled outside the governed platform and absent from the central inventory, often as a feature inside other software.

Related Lessons

• Leading Government-Wide AI Initiatives covers the sponsorship, mandate, and political groundwork that a cross-agency platform proposal depends on before any architecture decision is made.
• Data Sharing Agreements for AI addresses the agreements that govern whose data moves onto shared infrastructure, under what conditions, and with what restrictions on reuse.
• Cross-Agency Governance Coordination goes deeper into the board structures, decision rights, and escalation paths that shared resources require.
• AI Infrastructure Cost Optimization takes the cost side further once a platform exists and consumption has to be managed within a fixed appropriation.

Closing

Liam's proposal will succeed or fail on something other than its architecture. The technical case for consolidating 14 fragmented deployments onto one governed platform is not seriously contested by anyone who has watched a small agency try to negotiate an AI contract alone. What is contested is who decides, who pays, who is accountable when the platform fails, and what a large agency gives up to join. Those questions are settled in governance design and budget mechanics, and they are settled before the first server is provisioned or not at all.

The discipline worth carrying out of this lesson is to present the case honestly enough that it survives scrutiny. Show both cost figures and both scopes rather than a compressed percentage. Say what the shared estimate excludes. Name the concentration risk that consolidation creates alongside the savings it produces. A shared-service business case that acknowledges its own weaknesses is the one that still has credibility in year three, when the appropriation is under pressure and someone proposes that each agency should just handle its own AI after all.

Key Takeaways

• Fragmented agency-by-agency AI development multiplies cost and fragments accountability. Fourteen separate deployments in Liam's state carried an approximate first-year cost of $18 million and at least 28 full-time equivalent staff, against $4.3 million for a platform intended to serve all 38. Present both figures and both scopes, never a single savings percentage.
• The centralized platform model maximizes economies of scale and concentrates risk. Agencies must accept a common baseline, and a platform-level failure reaches every consuming agency at the same moment.
• The federated model preserves agency autonomy at higher cost. Shared standards, procurement routes, and a central inventory let differentiated agencies buy purpose-built tools, at the price of more per-agency investment and less consistent governance.
• Center of Excellence models suit uneven agency capacity. Where some agencies have strong internal teams and others have none, a central expert team consulting project by project can deliver more than a platform the weakest agencies cannot use.
• Design the cost-sharing mechanism before the platform is built. Usage-based billing, flat-rate subscription, and central appropriation differ in where funding risk lands, and the choice drives adoption more than the technology does.
• Governance boards must seat the consuming agencies. Central authorities that set priorities alone lose adoption to shadow deployments bought as features inside other software, and the first symptom is an inventory that is quietly incomplete.
• Consolidation relocates risk rather than removing it. A shared platform earns its governance claim only through the review, monitoring, and escalation machinery actually funded behind it.
• Shared infrastructure matters most to the smallest agencies and must be sold to the largest. Large agencies have alternatives and will use them unless roadmap influence, service levels, and an exception path are granted at design time.

Frequently Asked Questions

How do we compare a fragmented estimate against a shared estimate fairly?

Hold the scope constant or state the difference explicitly. Liam's fragmented figure covers 14 agencies and his shared figure covers 38, which makes the shared platform look better on both cost and reach at once. That is a real advantage, but presenting it as a single savings ratio hides the scope change and invites the budget office to reject the whole analysis when they find it. Publish both totals, both agency counts, and what each estimate leaves out.

Which model should a jurisdiction choose?

It depends on three conditions rather than on any general ranking. Where agency requirements are broadly similar and the central IT organization holds real authority, the centralized platform captures the most value. Where agencies have genuinely differentiated missions and independent procurement power, a federated model with shared standards and a central inventory is more realistic. Where the binding problem is that capacity varies enormously between agencies, a Center of Excellence reaches the agencies a platform would leave behind.

What stops agencies from bypassing the shared platform?

Nothing technical, which is why this is a governance question. Agencies bypass platforms when the platform is not meeting a mission need and the alternative is a checkbox inside software they are already buying. The controls that work are a mandatory registration requirement covering embedded AI features, procurement review that catches AI capability arriving inside other purchases, agency representation on the governance board, and a documented exception path that is faster than going around.

Is a Center of Excellence a substitute for a platform?

No, and treating it as one is a common mistake. A Center of Excellence supplies expertise, not infrastructure, so agencies still carry their own compute, their own security controls, and their own vendor relationships. It reaches agencies that would be excluded from a platform they cannot integrate with, and it scales only as far as the central team's capacity. Many jurisdictions run both, with the Center of Excellence serving the agencies the platform does not fit.

What is the single highest-value artifact to build first?

The inventory. Before any model choice, a jurisdiction needs a single list of every AI deployment and every AI procurement in flight, with the sponsoring agency, the cost, the staffing, and the vendor for each. It requires no platform and no data scientists, it is what makes the fragmentation argument concrete rather than rhetorical, and it is the first thing an oversight body will ask for. Every subsequent decision, including whether to consolidate at all, depends on it.