In Issue #6, we discussed the fate of AI projects stuck in ‘pilot purgatory’. Many promising initiatives deliver a compelling proof-of-concept only to wither when faced with the realities of a full-scale deployment. The technical reasons for this are varied, but the financial reason is often singular: a profound misunderstanding of the Total Cost of Ownership (TCO). The fixation on upfront development costs and licence fees creates a flawed business case that is guaranteed to collapse under the weight of its own success.
An AI system is not a piece of software you buy; it is an industrial process you operate. Its financial profile resembles a factory, where the marginal cost of producing each ‘good’—each prediction, classification, or piece of generated text—is a dominant and recurring reality. Leaders who build their financial models around the one-time cost of building the factory, rather than the continuous cost of running it, are steering their organisations towards a budget overrun. The true, long-term financial commitment is overwhelmingly operational. To build a defensible business case, we must look beyond the initial invoice and dissect the anatomy of AI’s total cost.
The Briefing#
The EU’s AI Act was supposed to be the bedrock of global regulation, a stable North Star for compliance. Yet, just as its initial provisions for general-purpose AI models came into force in August, the European Commission is already having second thoughts On 16 September, it launched a formal “call for evidence” to inform a new legislative package aimed at “simplification”. The stated goal is to create a more “innovation-friendly rulebook” with “less paperwork, fewer overlaps and less complex rules”. It is a direct response to a growing chorus of concern that the Act, in its current form, undermines European competitiveness. The intervention of former ECB President Mario Draghi, who has publicly called for a “pause” on the implementation of rules for high-risk systems, labelling the regulation a “source of uncertainty,” has turned a technical debate into a high-stakes political one. The strategic implication for any global business is profound. The AI Act can no longer be treated as a fixed compliance target; it is now a dynamic and politically contested framework. The famed “Brussels Effect,” where EU regulation sets the de facto global standard, is showing its first real signs of strain.
In early September, the SANDBOX Act was introduced in the US Congress, a legislative proposal designed to formalise a “light-touch” regulatory strategy. Backed by the White House’s AI Action Plan, which explicitly calls for removing regulatory barriers to “win the global race for AI dominance,” the Act would create supervised environments where developers can apply for temporary waivers from existing rules that might impede the testing of new technologies. This is not merely a different policy; it is a strategic geopolitical manoeuvre. By explicitly prioritising speed and experimentation, the US is positioning itself as a more attractive destination for AI talent and capital. This creates a clear scenario of “regulatory arbitrage,” forcing C-suite leaders to make a difficult choice. Do you develop and test advanced systems in the US market, which prizes innovation, before adapting them for the more stringent, trust-focused EU? This transforms AI strategy into a question of geopolitics, where the location of an R&D centre is now a decision with far-reaching consequences.
The focus of AI litigation has historically been on the data used to train models—issues of copyright and privacy. A landmark wrongful death lawsuit filed in California against OpenAI signals a new frontier of legal risk, focused on the direct harm caused by an AI’s outputs. The plaintiffs allege that the company’s chatbot played a direct role in their son’s suicide by fostering a psychological dependency and providing harmful, encouraging responses to his expressions of self-harm. This case moves beyond traditional software liability — it argues that the AI’s interactive output was directly responsible for causing harm, treating the system less like a passive tool and more like a service provider with an implicit duty of care. Should this legal theory gain traction, it could establish a new precedent for “algorithmic malpractice”. This dramatically expands the risk surface for any enterprise using AI-powered chatbots for customer service or any other interactive application that provides advice or guidance.
The Data Tax: Your First, Largest Cheque#
Before a single line of code is written for a new model, the most significant cost has likely already been incurred. Data preparation—the work of acquiring, cleaning, labelling, and governing the information that fuels the system—is not a preliminary step. It is the foundational engineering upon which the entire structure rests. Attempting to build a sophisticated AI system on a base of poor-quality data is like constructing a skyscraper on marshland. The eventual collapse is not a risk; it is a certainty. Studies consistently show that up to 80% of the effort in any AI project is dedicated to this data work. It involves sourcing information from fragmented legacy systems, scrubbing records for inconsistencies, and establishing clear data lineage and governance. Underinvesting here is not a saving; it is the accrual of a technical and financial debt that must be repaid with interest. Poor data quality is a direct financial liability. A realistic budget must account for licensing third-party data, the hourly rates of specialists to manage complex cleansing operations, and the substantial operational expense of manual data labelling (depending on type of model and system and its application). Budgeting for data readiness is therefore a non-negotiable prerequisite, not a discretionary phase.
The Human Cost of Fine-Tuning#
The typical strategy for enterprise AI is not to build a large model from scratch, but to fine-tune a capable open-source model on a proprietary dataset. This is presented as a cost-effective alternative, and from a pure compute perspective, it often is — a single training run on a cloud GPU is not a significant expense. However, the dominant cost driver in any fine-tuning project is not the silicon, but the specialist human capital required to manage the process. Fine-tuning is not a simple, mechanical task; it is an iterative, experimental scientific process that demands the focused time of a scarce and expensive resource: the Machine Learning Engineer. The process involves formulating hypotheses, preparing and testing multiple versions of a dataset, running numerous experimental tuning runs, and rigorously evaluating the outputs. A project requiring two months of an engineer’s time will incur a human capital cost that dwarfs the compute bill. Furthermore, this calculation ignores the significant opportunity cost. The time that engineer spends iterating on one model is time they are not spending on other high-value initiatives. The critical financial variable is not the price of GPU-hours, but the allocation of high-value engineering time.
The Inference Iceberg#
You should not confuse the cost of creating a model with the cost of using it — the development phase is a visible, one-time expense. The true, sustained cost lying submerged below the surface is inference. This is the process of running the trained model in production to generate outputs, and it is an ongoing, operational expense that scales directly with usage. For any successful application, the cumulative cost of inference will exceed the initial development cost by an order of magnitude. Industry analysis shows that inference accounts for 80% to 90% of the total machine learning compute demand. Within a few months of a successful launch, the recurring bill for running the model will have overtaken the entire initial build cost. That’s why from financial perspective using GenAI is similar to using the cloud. A budget based on a fixed annual cost is not fit for purpose — he business case must be built upon unit economics: the cost per inference versus the value it generates. A financial plan that does not model costs at ten and one hundred times the pilot volume is incomplete. It fails to account for the financial consequences of its own success, creating a plan that is only viable as long as the project remains small and strategically unimportant.
A Framework for a Realistic Business Case#
Building a defensible AI business case requires looking beyond the obvious expenses. In Issue #12, we explored the choice between open-source and proprietary models. A proper TCO analysis is the only way to make that decision rationally. It requires a pragmatic examination of the less visible, long-term costs. A credible proposal must provide clear, quantified answers to the following questions:
1. Data Readiness: What is the specific budget for data cleaning, labelling, and acquisition before the project begins? This requires a line-item budget for data sourcing, tooling for annotation, and the man-hours for cleansing. What is the contingency for discovering critical data quality issues mid-project? What are the ongoing costs of data governance and maintaining lineage?
2. Specialised Human Capital: Have we accurately calculated the fully-loaded cost of the specialist engineers required, not just for the build but for the entire operational lifecycle? This model must include salaries, benefits, training allowances, and the cost of the specialised development environments they require. This is the team that will monitor, maintain, and retrain the model for years to come.
3. Inference at Scale: Does the financial model project inference costs at 10x and 100x our pilot volume? Is the unit economic model sustainable as usage grows? This means calculating a “cost per prediction” and mapping it directly to a tangible business value. If the cost of generating a recommendation exceeds the marginal profit from the resulting sale, the model is not commercially viable.
4. Monitoring and MLOps: Is there a dedicated, multi-year budget for the tools and personnel required for continuous model monitoring? Production AI systems are not static. Their performance degrades over time as the real world changes. A budget must be allocated for the MLOps platforms and engineers needed to detect performance degradation, trigger alerts, and manage the retraining pipeline. This is the immune system of your AI process.
5. The Human Loop: Have we costed the operational expense of human reviewers required for quality control and compliance as a permanent, recurring cost? In regulated industries, this is non-negotiable architectural feature. For a system making thousands of decisions per day, even a small percentage flagged for human review creates a significant operational workload. This team, and its associated costs, must be a permanent fixture in the budget.
6. Model Maintenance: What is the budgeted annual cost for retraining the model to combat performance decay? A model is an asset with a limited shelf-life. A benchmark of allocating 10-20% of the initial development cost for annual retraining and maintenance is a sensible starting point. This is not a sign of failure; it is the planned, professional maintenance required to keep a high-performance asset in service.
Conclusion: From Software Project to Industrial Process#
Viewing AI as a software project to be bought and installed is an error. It leads to business cases that are misleading. A more accurate and useful mental model is that of an industrial process. There are upfront capital costs to build the capability, but the vast majority of the lifetime expense is operational, tied directly to the volume of production. This reframing forces a more rigorous and realistic approach to financial planning. It shifts the focus from the cost of the licence fee to the unit economics of each prediction. It moves the conversation from a one-time project budget to a long-term operational model. For leaders accountable for ROI, making this mental shift isan important step in building an AI strategy.
Until next time, build with foresight.
Krzysztof