Rethinking the cost and budget structure of government AI
Government AI programs rarely fail on the algorithm. They fail because of the 80% to 85% of implementation costs that never appear in the vendor’s quote, according to Paul Lalovich and Philipp Kishkovarov, who explain how a dual-running architecture can help governments identify and budget for these hidden costs before they spiral into a crisis.
When a ministry or agency prepares a budget for an artificial intelligence (AI) program, the cost structure is usually built around the same template used for software procurement: license fees, implementation charges, training, and a contingency line. That is a reasonable starting point if you are buying an enterprise resource planning system.
It is, however, not a reasonable starting point for deploying AI into a government environment. The work is different, the cost distribution is different, and the consequences of underfunding are different.
Over the past several years, we have advised government entities and large public-sector organizations on the architecture of digital transformation programs across multiple jurisdictions. What follows is not a critique of any particular program or vendor. It is an observation of where the money actually goes in government AI initiatives that reach production – and why the pattern is best understood through the lens of dual-running architecture.
Where the money actually goes
Across programs that have been transparently accounted for, four cost categories recur with proportions consistent enough to plan against.
AI models and platforms – the machine learning models, language engines, computer vision systems, cloud compute, and licenses – account for 15% to 20%. This is the visible layer, the one procurement teams estimate most comfortably because it resembles traditional software licensing. It is also the smallest share of any program that moves beyond pilot.
Data preparation and engineering consumes 25% to 30%. Government data is rarely ready for AI in its current state. It sits in formats designed for reporting, not algorithmic consumption, spread across ministries with different classification schemes, update cycles, and levels of digitization. Before any model can be trained, that data must be located, assessed, cleaned, structured, and made accessible through secure pipelines that respect privacy and classification rules – and then maintained, because this is not a one-time task.
Integration and operational transition is the largest share, at 35% to 45%, and the one most commonly underestimated. It covers connecting AI output to the systems civil servants and citizens already use: API development, middleware, workflow redesign, staff re-training, and managing the period when old and new processes run side by side.
A customs officer who has spent twenty years assessing risk on instinct and documentary evidence cannot be expected to trust an algorithmic risk score on day one – not without training, recourse procedures, and clarity on what to do when the score conflicts with their judgment. That is not resistance to change. It is a legitimate operational requirement, and it costs money.
Finally, governance architecture takes 10% to 15%: audit mechanisms, bias testing, explainability frameworks, recourse procedures, and the monitoring that keeps the system performing as intended after deployment. In jurisdictions that have scaled AI successfully, this is designed before deployment, not bolted on by the legal department afterward.
Why the standard model underfunds AI
The standard procurement model assumes the vendor quote is the baseline and everything else is margin or contingency. In AI programs, that quote typically covers only the first category. The remaining 80% to 85% is either invisible in the initial business case or scattered across budgets managed by different departments: data preparation assigned to IT as maintenance, operational transition filed under HR training with timelines that never align with the technology rollout, governance left to a legal team without the technical capacity to judge whether the system is auditable in practice.
The result is rarely outright failure. It is more commonly a program that is technically functional but operationally underfunded. The AI works. The integration is technically complete. But civil servants do not use it, or use it in ways that create more manual work than the process it replaced, or the system produces outputs that cannot be defended when challenged by a citizen or an auditor.
The program then enters a cycle of supplementary funding requests, scope revisions, and delayed benefits – institutional fatigue that could have been avoided if the full cost structure had been visible from the start.
A dual-running architecture for AI: ANDRA
Our AI-native dual-running architecture method (ANDRA) starts from a thesis that applies with particular force in government: AI-native is a coexistence problem, not a replacement problem. No ministry moves from legacy to AI-native in a single cutover. Paper-era records, decades-old case management systems, and human-led decision processes keep running while AI capabilities come online.
Seen through that lens, the four cost categories stop looking like overhead and start looking like what they are: the price of running four operating states – legacy operations, AI overlays, redesigned value streams, and the AI-native target – in parallel under one governed architecture.
The mapping is direct. Data preparation is ANDRA’s executable company brain: turning policies, eligibility rules, and case histories from PDFs and spreadsheets into governed, queryable, machine-legible assets with named owners and audit trails. Integration and transition is the transition architecture itself – the explicit design for the period when a caseworker’s old workflow and the AI-assisted one run side by side, with every legacy system classified as retain, wrap, modernize, or retire.
Governance is runtime governance: agent authority made explicit, audited, and reversible, with a named human principal and a kill switch for every system that acts. The 80% to 85% is not ancillary cost. It is the architecture that surrounds the algorithm.
Two real-life examples
Two examples make the point concrete. In one diagnostic of a large regulated institution, the composite readiness score looked respectable until the layer breakdown showed institutional knowledge scoring lowest of all: policies in PDFs, pricing rules in spreadsheets, regulatory obligations living in the heads of experienced officers.
Until that layer moved, no AI system could operate reliably in a regulated context – and every dirham spent on models ahead of it was spent out of sequence. The government parallel is exact: a permit ministry that licenses a language model before its regulations are machine-legible has bought the 15% and deferred the 30%.
The second example runs the other way. Federal HR authorities that completed structured process redesign before technology implementation have reported two to three times higher returns on subsequent system investments than peers that went technology-first.
The jurisdictions most often cited for scaled government AI – Dubai, Singapore and several Nordic states – share the same structural feature: the full cost structure was budgeted and governed as a single program, not as a technology purchase with ancillary costs scattered across departments. The common element is not superior technology. It is architecture discipline.
What this means for the budget
For a CFO or procurement board reviewing an AI business case, the practical implication is straightforward. The vendor quote should be treated as a component cost, not as the program baseline. The business case should account explicitly for all four categories, calibrated to the maturity of the existing data infrastructure and the complexity of operational integration.
A ministry that has already invested in unified data architecture will spend less on preparation and integration; one starting from fragmented legacy systems should expect those shares at the top of the range. Neither is better or worse. They are different starting points requiring different budget structures – which is why ANDRA begins every engagement with a readiness diagnostic rather than a platform selection.
Vendor evaluation follows the same logic. A low license fee that demands extensive custom integration can cost more over the program lifecycle than a higher fee that ships with standard integration tooling and transition support. Total cost of ownership means all four categories, not the headline price.
And when the four readiness assessments – technology, data, integration, governance – are completed before procurement begins, the budget that emerges is usually larger than the initial estimate, but it is also accurate. Programs built on that structure reach operational scale without the mid-program funding cycle that erodes political capital and institutional patience.
Key takeaways
Government AI is not inherently more expensive than enterprise AI. It is differently expensive. The cost is not in the algorithm; it is in the data, the integration, the governance, and the operational transition that surround it. Understanding that distribution will not prevent every overrun. But it prevents the more common problem: programs underfunded before they begin, and pilots that succeed technically yet never find the resources to become operations.
Budget government AI as a dual-running architecture program, not a software purchase: treat the vendor quote as one component among four, complete the data, integration, and governance readiness assessments before procurement, and govern all four cost categories as a single program. That is the difference between a technically successful pilot and an operational capability.
About the authors
Paul Lalovich is Managing Partner of Agile Dynamics. He leads the firm’s Organizational Effectiveness & Strategy Execution practice and is the architect of the ANDRA dual-running method for AI-native transformation.
Philipp Kishkovarov is a Principal at Agile Dynamics. He works with clients on digital transformation and AI program delivery, with a focus on the integration, data, and governance aspects of transformation.
