In the spring of 2023, a mid-sized logistics company in the American Midwest announced it had deployed a large language model across its customer service operation. The press release was confident: reduced response times, lower staffing costs, a competitive edge in a sector known for thin margins. Eighteen months later, the company quietly scaled the system back. The model hallucinated shipping dates. It gave customers incorrect refund policies. And the engineering team that was supposed to be freed up by the automation had instead spent the better part of a year firefighting edge cases the vendor had never warned them about.
This is not an unusual story. It is, in various forms, a pattern playing out across industries as organisations rush to implement artificial intelligence systems without a complete picture of what implementation actually costs — not just in dollars, but in time, organisational capacity, and strategic attention. The headline figure a vendor quotes for an enterprise AI contract rarely reflects what the organisation will actually spend. The gap between the two numbers is where most AI projects fail.
Understanding that gap requires looking at the full cost structure of AI adoption: the infrastructure requirements that arrive after the contract is signed, the human capital costs that rarely appear on procurement spreadsheets, the technical debt that accumulates quietly in the background, and the opportunity costs of executive attention that gets consumed by systems that were supposed to free it up.
The Procurement Illusion
Enterprise AI contracts are typically priced on a per-seat, per-call, or per-token basis, with an annual licence fee sitting on top. What the contract rarely includes is everything the organisation needs to do before the system can run — and everything it will need to do continuously to keep it running well.
A 2023 analysis by KPMG found that for every dollar spent on AI software licences, enterprises typically spend between $3 and $5 on implementation, integration, and ongoing management. A separate survey by McKinsey & Company found that only 16% of companies that had deployed generative AI tools said their initial cost estimates had been accurate. The most common reason for underestimation: organisations had not fully accounted for the cost of data preparation.
Data preparation — cleaning, labelling, structuring, and validating the data that AI systems require to function accurately — is the unglamorous foundation of every enterprise AI deployment. It is also consistently the most expensive part. Academic research from 2020 published in the Harvard Data Science Review estimated that data scientists spend between 60% and 80% of their project time on data preparation rather than model development or deployment. That ratio has not improved significantly with the arrival of foundation models: even systems trained on public data require an organisation's proprietary data to be cleaned, formatted, and integrated before they can produce outputs that are specific enough to be useful.
For organisations without mature data infrastructure — which includes the majority of mid-market companies — this creates a situation where the AI project becomes, first and foremost, a data infrastructure project. That project may take twelve to eighteen months and require hiring data engineers who are in short supply and therefore expensive. The AI system the organisation wanted to deploy has not yet produced a single output, but the spending has already begun in earnest.
Infrastructure Costs That Don't Appear in Demos
The environments in which enterprise AI vendors demonstrate their products are optimised. Clean data, fast networks, sufficient compute, controlled edge cases. The environment in which most organisations actually operate is not optimised. It is layered with legacy systems, inconsistent data standards, security requirements that create latency, and compliance obligations that restrict what data can be processed where.
Compute costs alone represent a significant and frequently underestimated line item. Running inference on large language models at enterprise scale — meaning thousands of queries per day, not hundreds — requires substantial GPU capacity. Organisations that choose to deploy models on their own infrastructure rather than via API calls face hardware procurement timelines and capital expenditure that can stretch into the millions. Those that rely on cloud-based inference pay per token or per call, and those costs scale directly with usage in ways that are difficult to predict before deployment.
A retail chain that deploys an AI-powered product recommendation engine expecting to pay $200,000 per year in API costs may find, once actual customer traffic patterns are factored in, that the real figure is $800,000. The difference is not vendor dishonesty — it is that realistic usage projections require production data, which doesn't exist until the system is running.
Network latency compounds the problem. AI systems that need to query external APIs add round-trip latency to every interaction. In customer-facing applications, this can degrade the user experience in ways that are measurable and, in competitive industries, commercially significant. Solving for latency often requires caching infrastructure, edge compute deployments, or architectural changes to existing applications — all of which cost money and engineering time that was not in the original project scope.
Then there is storage. Modern AI applications produce logs, embeddings, model outputs, and audit trails. In regulated industries — financial services, healthcare, legal — these records must be retained for specified periods and made available for audit on request. The storage, governance, and retrieval infrastructure for this data is not trivial, particularly at scale. Organisations that fail to plan for it often discover the gap at the worst possible moment: during a regulatory inquiry or a legal discovery process.
The Human Capital Problem
Every enterprise AI deployment requires people who understand the system well enough to configure it, monitor it, interpret its outputs, and intervene when it goes wrong. Finding those people — and keeping them — is among the most persistent and underappreciated challenges of AI adoption at scale.
The supply of workers with genuine, practical expertise in deploying enterprise AI systems is constrained. The demand for them is growing faster than educational institutions can produce graduates. This labour market dynamic translates directly into cost: machine learning engineers, MLOps practitioners, and AI product managers command salaries that have risen sharply since 2021 and show no sign of declining.
But the human capital problem is not only about specialists. It also extends to the broader workforce that will use or be affected by AI systems. Change management — the structured process of helping employees understand, accept, and work effectively alongside new technology — is consistently underfunded in AI projects. A 2022 survey by Prosci, a change management research firm, found that projects with excellent change management practices were six times more likely to meet their objectives than those with poor change management. Yet change management budgets in most AI deployments represent less than 5% of total project spend.
The consequences of this underfunding are visible in the usage data of many enterprise AI deployments. Systems are adopted unevenly: enthusiastic early adopters use them intensively while sceptical colleagues avoid them. The result is that the productivity benefits the system was supposed to generate accrue only to a fraction of the intended user base, and the aggregate return on investment falls well short of the business case projection.
Resistance to AI adoption is not irrational. Workers who understand their jobs are often correct when they identify limitations or failure modes in AI systems that vendor demonstrations did not surface. Dismissing this resistance as technophobia rather than treating it as a source of operational intelligence is a management error with real costs. Organisations that create feedback loops between frontline users and system developers consistently achieve better outcomes — and faster paths to genuine productivity — than those that deploy top-down without engagement.
Maintenance, Drift, and the Illusion of Set-and-Forget
Software systems require maintenance. AI systems require maintenance that is qualitatively different from traditional software in ways that are not always well understood by non-technical executives who approve their deployment.
Traditional software does what it is programmed to do until the code changes. An AI model does what it was trained to do — until the world it was trained on diverges sufficiently from the world it is now operating in. This divergence is called model drift, and it is not a failure mode. It is an inevitable consequence of deploying a statistical model in a changing environment.
A language model trained on customer service interactions from 2022 will gradually become less accurate as product lines change, pricing structures evolve, and customer expectations shift. A fraud detection model trained on transaction patterns from before an economic downturn may perform poorly when spending behaviour changes significantly. A demand forecasting model trained on pre-pandemic supply chain data will give systematically incorrect predictions when supply chain conditions normalise in different patterns than they disrupted.
Detecting drift requires monitoring infrastructure: systems that continuously evaluate model outputs against ground truth, alert when performance degrades below acceptable thresholds, and generate the data that engineers need to diagnose and correct the problem. Building and operating this monitoring infrastructure is an ongoing cost that does not diminish over time. It is also a cost that is almost never included in the initial project budget.
Retraining models when drift is detected requires access to fresh labelled data. Labelling data — creating the human-verified examples that supervised learning requires — is labour-intensive and difficult to automate fully. For specialised domains, it requires subject matter experts, not just crowdworkers. A healthcare AI system that monitors patient records for early indicators of deterioration needs clinicians to review and validate training data, not general annotators. That expertise costs money, takes time, and creates scheduling dependencies that can delay retraining cycles significantly.
The practical consequence is that many enterprise AI systems that are described as deployed are actually running on increasingly stale models, producing outputs that are less accurate than they were at launch, with no one monitoring the degradation because the monitoring budget was cut to hit the original project timeline. This is not a hypothetical — it is the situation that RAND Corporation researchers documented in a 2023 study of government AI deployments, and there is no structural reason to believe the private sector is doing meaningfully better.
Security, Liability, and Compliance
AI systems introduce security attack surfaces that are genuinely novel and not yet fully understood by most corporate security teams. Prompt injection — a class of attack in which malicious input causes an AI system to ignore its instructions and execute attacker-controlled commands — has no direct analogue in traditional software security. SQL injection is a thirty-year-old problem with well-understood defences. Prompt injection is still being actively researched, and defences that work reliably at enterprise scale remain an open problem in the security literature.
For organisations that deploy AI systems with access to sensitive data or privileged system access, the security implications are significant. A customer service chatbot that can look up account information can, if inadequately secured, be manipulated into revealing that information to unauthorised parties. A coding assistant that has access to internal repositories can be used to extract proprietary source code. These are not theoretical scenarios — both have occurred in documented incidents since 2023.
The legal liability landscape around AI outputs is still forming, but it is forming in a direction that assigns responsibility to deploying organisations, not just to model developers. The European Union's AI Act, which entered into force in August 2024, creates specific obligations for organisations deploying high-risk AI systems, including requirements for human oversight, transparency documentation, and risk assessments. Non-compliance carries fines of up to 3% of global annual turnover.
In the United States, the regulatory picture is more fragmented, but sector-specific regulators — the Consumer Financial Protection Bureau for financial services, the Food and Drug Administration for healthcare applications, the Equal Employment Opportunity Commission for hiring systems — have all issued guidance indicating that AI systems are not exempt from existing legal obligations around discrimination, transparency, and accuracy. Organisations that discover after deployment that their AI system produces discriminatory outputs — even unintentionally — face both regulatory risk and reputational exposure.
Compliance documentation alone represents a meaningful cost. Demonstrating that an AI system does not discriminate, does not hallucinate in ways that cause harm, and maintains adequate data governance requires audit trails, explainability tools, and legal review processes that add overhead to every deployment and must be updated whenever the model or its use case changes.
The Strategic Opportunity Cost
There is a cost to AI adoption that does not appear on any invoice and is therefore almost never calculated: the opportunity cost of the executive attention, engineering capacity, and organisational energy that the adoption process consumes.
Enterprise AI projects typically require significant involvement from senior leadership — not just at the point of procurement, but throughout deployment, troubleshooting, and optimisation. The chief technology officer who spends 30% of their time for eighteen months shepherding an AI deployment is not spending that time on other strategic initiatives. The product engineering team that is redirected to AI integration work is not building the features that customers are actually requesting. These diversions are often invisible in post-mortems because they represent things that did not happen, not things that went wrong.
The opportunity cost problem is compounded by the enthusiasm cycles that characterise enterprise technology adoption. When a new class of technology receives intense media and analyst coverage — as generative AI did from late 2022 onwards — organisations face competitive pressure to adopt it regardless of whether their specific context makes adoption rational. The fear of being left behind drives procurement decisions that are less rigorous than they would be for technology that was not dominating every conference agenda.
Clayton Christensen's research on disruptive innovation has long established that the organisations that survive technological transitions are not always the first movers — they are the ones that understand the technology clearly enough to know when adoption creates genuine value and when it creates the appearance of progress while consuming resources that would have been better deployed elsewhere. That analysis requires a level of AI literacy at the executive level that most organisations have not yet developed, and developing it is itself a cost that rarely appears in adoption budgets.
What Realistic Adoption Looks Like
None of this is an argument against AI adoption. The productivity gains from well-deployed AI systems are real, documented, and in some cases transformative. A well-implemented AI-assisted coding environment can measurably increase engineering throughput. A well-trained document processing system can reduce manual review time by factors that justify substantial investment. The point is not that the technology is oversold — it is that the accounting for adoption costs is systematically incomplete, and that incomplete accounting leads to bad decisions.
Organisations that have achieved genuine returns from AI adoption share several characteristics. They started with a specific, well-defined problem rather than a general mandate to "use AI." They involved operational staff in defining requirements rather than handing the project entirely to a technology team. They budgeted explicitly for data preparation, integration, monitoring, and change management rather than treating these as secondary considerations. They set conservative timelines and realistic expectations for executive sponsors. And they built in formal review points at which the project could be stopped, scaled back, or redirected without political cost.
They also maintained a clear-eyed view of what the technology could not do. The organisations that have experienced the most public AI failures are typically ones in which the limitations of the system were known to the technical team but not communicated effectively to decision-makers, who then made commitments — to customers, to investors, to the press — that the system was not capable of supporting.
The internal communication discipline required to maintain that clarity is not a technical challenge. It is a management challenge, and it is one that the enterprise software industry has not historically helped organisations meet. Vendors have structural incentives to emphasise capability and downplay limitation. Procurement processes reward confident projections over honest uncertainty ranges. The organisational culture around technology adoption often treats scepticism as obstruction rather than rigour.
Changing that culture is perhaps the most important single thing an organisation can do to improve its AI adoption outcomes — and it costs nothing except the willingness to ask harder questions before signing contracts rather than after the first production incident.
Vendor Selection and the Reference Customer Problem
Enterprise AI procurement is complicated by a structural information asymmetry that favours vendors. A vendor's sales team has seen dozens or hundreds of deployments. The procurement team on the other side of the table has seen, at most, a handful. This disparity in pattern recognition means that buyers often do not know what questions to ask, and vendors have little incentive to volunteer information that would complicate the sale.
The reference customer problem makes this worse. When a vendor provides reference customers during the sales process, those customers are self-selected: they are the deployments that went well, not the ones that were quietly decommissioned. A buyer who speaks only to reference customers is sampling from the best tail of the distribution and constructing an expectation of typical performance from an atypical sample. The failures — which are where the most useful learning lives — are invisible by design.
There are ways to mitigate this, but they require deliberate effort. Asking vendors not just for reference customers but for a description of the three most common reasons their deployments underperform surfaces information that would otherwise remain hidden. Requesting access to anonymised post-implementation reviews, where they exist, provides a more balanced picture than curated success stories. Engaging independent technical consultants who have worked with multiple vendors in the same category — and who therefore have unselected exposure to both successes and failures — provides an outside view that internal teams rarely have.
Pilot programmes, structured correctly, are among the most valuable tools available to enterprise buyers. A pilot that runs on production data, in a realistic operational environment, over a period long enough to encounter edge cases and failure modes, is worth more than any number of vendor demonstrations. The important word is "structured" — a pilot that is not designed with clear success and failure criteria in advance will produce ambiguous results that can be interpreted to support whichever conclusion the organisation was already inclined to reach.
The financial model of AI vendor pricing also warrants scrutiny. Consumption-based pricing — where cost scales with usage — creates a situation in which the vendor's revenue grows precisely as the system becomes more embedded in the customer's operations. This is not inherently problematic, but it does mean that cost projections made before deployment are structurally optimistic: they are made before the organisation understands its real usage patterns, and the vendor has no financial incentive to correct over-optimistic projections before the contract is signed.
The Measurement Gap and Why ROI Is Usually Fiction
The business cases that accompany most enterprise AI proposals contain a return on investment calculation. These calculations almost always show a positive return, often within two years. This is not surprising, because a business case that showed a negative return would not be approved. What is surprising is how rarely anyone goes back to check whether the projected return materialised.
Measuring the actual return from an AI deployment is genuinely difficult, for reasons that are not excuses. Productivity improvements are hard to isolate: if an engineering team using an AI coding assistant ships features faster, how much of that improvement is attributable to the AI versus improved processes, team composition changes, or simply the Hawthorne effect of being observed and supported? Customer satisfaction changes following AI deployment may reflect the AI system, seasonal variation, pricing changes, or any number of other factors. Separating signal from noise requires controlled experimental design that most organisations do not have the capacity to implement in production environments.
The result is that most organisations operate on faith: they believe their AI deployments are working because the vendor's dashboard shows high usage rates, or because the executive sponsor has become publicly committed to the narrative of success and the organisation lacks the psychological safety to challenge it. Usage rates are not returns. A system that is used frequently but produces outputs that require significant human correction before they can be acted upon may be generating less value than no system at all, once the correction time is factored in.
A more honest accounting would start with the total cost of ownership — licence fees, infrastructure, data preparation, integration, monitoring, retraining, security, compliance, change management, and the ongoing staffing costs of the team that operates the system — and compare it not to the theoretical productivity gains identified in the pre-deployment business case, but to the measured productivity gains observable in post-deployment data. This accounting is uncomfortable because it often produces numbers that are less flattering than the story the organisation has been telling itself. But organisations that do this accounting honestly are the ones that make better decisions about subsequent deployments — because they understand what the technology actually costs and what it actually delivers, rather than what the sales deck promised.
A Different Procurement Conversation
The questions that experienced AI practitioners ask before committing to a deployment are different from the questions that appear in most enterprise RFP processes. They include: What does our data need to look like for this system to work, and what is the gap between that and our current state? What monitoring infrastructure will we need to build, and who will operate it? What is the retraining cadence, and who provides the labelled data? What are the failure modes that will most affect our customers, and how will we detect and recover from them? What does full-scale usage cost, and what assumptions does that estimate rest on?
Vendors who answer these questions honestly are worth more than vendors who answer them confidently. The confidence of a sales presentation is not evidence of accuracy. It is evidence that the sales team has been well trained.
The organisations that will extract the most value from AI over the next decade are not the ones that moved first. They are the ones that moved carefully — with clear eyes about what the technology costs, what it can and cannot do, and what it requires of the organisation that deploys it. That clarity is available to anyone willing to ask the right questions. Most organisations simply haven't been asking them.