The purchase price of an AI product represented only a fraction of implementation cost. Companies often discovered that fragmented data, legacy systems, scarce expertise, organisational training, continuing maintenance and governance required more money and time than the initial software contract.
AI needed clean, structured and synchronised data, which meant engineers, storage, integration work and maintained pipelines. Experienced data scientists and machine-learning engineers were expensive, while a useful team required several complementary skills rather than one specialist.
Existing systems could demand custom middleware, redesign, downtime and backup arrangements. Employees also needed substantive training to interpret outputs, make decisions and recognise limitations, alongside change-management support for differing levels of acceptance.
Models required monitoring, retraining, security updates and technical support as data and business conditions changed. Legal advice, bias review, audit trails and compliance staff added further overhead. The article advised CEOs to budget two to three times early estimates.
The development should be read in its original publication context. It described the evidence, forecasts and vendor claims available at that time; later outcomes should not be projected backwards into promises that had not yet been tested.
A useful assessment separates demonstrated functions from proposed scale. It compares the new approach with a realistic baseline, including manual work, waiting time, existing infrastructure and the cost of correcting errors.
Long-term value requires more than launch performance. Data, models, organisations and external rules change, so version records, periodic checks and a named owner are needed to detect drift and decide whether the original case still holds.
Distribution also matters. An average gain can conceal predictable weakness for a language, site, workload or user group. Breaking results down and inviting feedback from people closest to the process makes expansion decisions more defensible.
Before scaling, leaders should map the complete delivery chain. Data sources, interfaces, cloud services, suppliers and human review can each become the limiting factor, even when the most visible model performs well. That map also exposes concentration, security and recovery requirements that a product demonstration rarely shows.
Financial analysis should follow outcomes rather than activity. More generated code, processed alerts or trained participants is not automatically more value. Measures such as completed tasks, avoided incidents, verified skills, lower correction effort and improved service quality give decision-makers a stronger basis for continuing investment.
Reversibility is equally important in a fast-moving market. Portable records, documented interfaces and clear stop criteria let an organisation change provider, narrow a deployment or return a decision to people when performance, pricing or policy changes. That flexibility is practical resilience, not a lack of commitment.
Data Readiness Came Before Model Value
Scattered and inconsistent information could prevent a new system from producing reliable results. Cleaning, formatting, integrating and governing that data created an infrastructure programme before the visible AI feature began.
The practical importance was that leaders needed to price data ownership and continuing pipeline maintenance into the original business case. A credible evaluation would connect the claim to representative outcomes, record exceptions and human intervention, and identify who could act when conditions changed. It should compare different workloads or user groups and document the resources required to sustain the result, preventing one headline metric from substituting for operational evidence. Teams would also need a baseline, a review schedule and a defined threshold for pausing or changing the system. Those controls would make progress measurable while preserving room to respond when costs, risks or user needs diverged from the original assumptions.
Talent Costs Extended Beyond Recruitment
A production programme needed data, ML, domain, security and operational expertise, plus retention and ongoing training. Competition for experienced staff increased both salary and delivery risk.
The practical importance was that a vendor could supply technology but not replace internal responsibility for business decisions. A credible evaluation would connect the claim to representative outcomes, record exceptions and human intervention, and identify who could act when conditions changed. It should compare different workloads or user groups and document the resources required to sustain the result, preventing one headline metric from substituting for operational evidence. Teams would also need a baseline, a review schedule and a defined threshold for pausing or changing the system. Those controls would make progress measurable while preserving room to respond when costs, risks or user needs diverged from the original assumptions.
Legacy Integration Changed Timelines
Supposed plug-and-play products often met old interfaces, undocumented workflows and systems not designed for machine decisions. Customisation and testing could turn a short pilot into a multi-quarter change programme.
The practical importance was that baseline architecture review was essential before leaders promised dates or returns. A credible evaluation would connect the claim to representative outcomes, record exceptions and human intervention, and identify who could act when conditions changed. It should compare different workloads or user groups and document the resources required to sustain the result, preventing one headline metric from substituting for operational evidence. Teams would also need a baseline, a review schedule and a defined threshold for pausing or changing the system. Those controls would make progress measurable while preserving room to respond when costs, risks or user needs diverged from the original assumptions.
Maintenance and Governance Were Permanent
Drift, new threats and changing regulation made monitoring, model refreshes, documentation and legal review recurring costs. These activities were not optional finishing work after deployment.
The practical importance was that AI should be budgeted as an operating capability with named owners rather than a one-time purchase. A credible evaluation would connect the claim to representative outcomes, record exceptions and human intervention, and identify who could act when conditions changed. It should compare different workloads or user groups and document the resources required to sustain the result, preventing one headline metric from substituting for operational evidence. Teams would also need a baseline, a review schedule and a defined threshold for pausing or changing the system. Those controls would make progress measurable while preserving room to respond when costs, risks or user needs diverged from the original assumptions.
Across the announcement, technical capability was only one part of the system. Skills, access, integration, governance, cost and affected people could each determine whether the promised value survived outside a demonstration.
The durable lesson is to preserve traceability and choice. Organisations should document assumptions, keep consequential outputs reviewable, monitor downstream effects and retain a realistic exit route. Those controls allow ambitious AI work to improve without making early momentum an irreversible commitment.
