The failure rate is high, but not random Gartner predicted in 2018 that through 2022, 85% of AI projects would deliver erroneous outcomes due to bias in data, algorithms, or the teams responsible for managing them — a prediction that subsequent industry data has broadly confirmed. McKinsey reports that only 22% of companies deploying AI at scale report significant financial impact from their AI investments. VentureBeat’s analysis suggests that 87% of data science projects never make it to production. The specific percentages vary by methodology and definition, but the directional finding is consistent: most enterprise AI projects fail to deliver their intended business outcome. This failure rate is not random. The failures cluster around a small number of predictable patterns — patterns that are identifiable before the project begins, during the scoping phase when the investment commitment is made. The organisations that succeed at enterprise AI do not have better models or better data scientists. They have better project selection, clearer success criteria, and more realistic scoping. Generative AI projects face these same patterns along with their own specific failure modes — GenAI projects frequently fail before they launch due to scope inflation, evaluation gaps, and demo-to-production underestimation. Why does data readiness cause the most failures? The most common root cause of enterprise AI project failure — and the most underestimated during scoping — is data readiness. The model requires data. The data must exist, be accessible, be clean, be representative, and be available in sufficient volume. Each of these requirements fails independently and frequently: The data does not exist. The project requires historical data that was never collected. A demand forecasting model requires 24 months of point-of-sale data by SKU and location. The organisation has aggregate monthly sales by category. The gap is not bridgeable by model sophistication. The data exists but is not accessible. The data lives in a legacy system with no API, in a third-party platform with licensing restrictions, or in departmental silos where data sharing requires governance approvals that take months. The data exists and is accessible but is not clean. Missing values, inconsistent formatting, duplicate records, and stale entries degrade model performance in ways that are not obvious until the model is trained and evaluated. In our experience across data-readiness engagements, we have seen projects where 60% of the engineering effort was data cleaning (an observed pattern, not a benchmarked industry rate) — and the project was scoped assuming the data was ready. The data is not representative. The training data reflects historical patterns that do not represent future conditions. A fraud detection model trained on 2019 transaction data performs poorly on 2024 transaction patterns because customer behaviour, merchant types, and fraud methods have changed. The fix is a data readiness assessment before the project is committed — not a data audit report that lists datasets, but a hands-on evaluation that examines the actual data quality, coverage, and accessibility against the specific requirements of the proposed model. Pattern 2: Success criteria are not defined “We want to use AI to improve customer service.” What does “improve” mean? Reduce average response time? Increase first-contact resolution rate? Reduce staffing cost? Increase customer satisfaction scores? Each of these is a different project with different data requirements, different model approaches, and different integration needs. Projects without specific, measurable success criteria cannot be evaluated — and projects that cannot be evaluated cannot be course-corrected. The team builds something, the stakeholders look at it, and the judgment is subjective: “this doesn’t seem right” or “I expected something different.” Without predefined criteria, the project enters an indefinite iteration cycle with no convergence criterion. The fix is to define success criteria before development begins: specific metrics (reduce average response time from 4 hours to 1 hour), measurement methodology (how will we measure response time — from ticket creation to first response, or from first response to resolution?), and acceptance thresholds (the model must achieve this metric at this level for the project to be considered successful). Pattern 3: Integration is underestimated An AI model produces a prediction. For that prediction to have business impact, it must be delivered to the right person, at the right time, in the right system, with the right context. This is integration — and it is consistently the most underestimated component of enterprise AI projects. The model that detects fraud must be integrated with the transaction processing system to block suspicious transactions in real time. The model that predicts equipment failure must be integrated with the maintenance scheduling system to trigger work orders. The model that classifies customer inquiries must be integrated with the ticketing system to route tickets to the right team. Each integration requires: API development, data format translation, error handling, authentication, latency management, and testing against the production system. In our experience, integration work accounts for 40–60% of the total project effort. Projects that budget 80% for model development and 20% for integration are systematically underestimated. The GenAI prototype-to-production gap is a specific instance of this general pattern — the prototype demonstrates model capability, but the production engineering (integration, monitoring, guardrails, cost management) is the majority of the remaining work. Pattern 4: The problem does not require AI Not every business problem that involves data requires a machine learning model. A rule-based system, a well-designed dashboard, a process improvement, or a simple statistical analysis may solve the problem more reliably, more cheaply, and more quickly than an AI model. A project to “predict which customers will churn” may discover that the top three churn predictors are: the customer called support more than 5 times in the last month, the customer’s contract is in the last 30 days, and the customer received a price increase. These rules can be implemented in a CRM workflow in a day. As an illustrative example from our consulting engagements (an observed pattern, not a benchmarked industry rate): the ML model that predicts churn with 78% accuracy took three months to build and requires ongoing maintenance. The fix is to evaluate whether the business problem genuinely requires the adaptive, data-driven decision-making that AI provides — or whether a simpler approach would deliver the same outcome. The AI solution is appropriate when the decision is complex (too many variables for rules), when the patterns are non-obvious (the data contains relationships that humans cannot detect by inspection), or when the scale of decisions is too large for human review (millions of transactions, millions of documents, millions of customer interactions). How to predict which projects will fail Every failed project we have reviewed exhibited at least one of these patterns at inception — before any code was written. The patterns are detectable through structured assessment: Data readiness. Hands-on evaluation of data quality, coverage, and accessibility against model requirements. Red flag: no one has looked at the actual data. Success criteria. Specific, measurable definitions of what success looks like. Red flag: success is described in qualitative terms (“better,” “faster,” “smarter”). Integration scoping. Identification of all systems the model must integrate with, with effort estimates for each integration. Red flag: integration is a line item in the plan, not a detailed breakdown. AI necessity. Evaluation of whether the problem requires AI or can be solved with simpler approaches. Red flag: the project was initiated because “we need to use AI,” not because a specific business problem was identified. For generative AI projects specifically, evaluating use case feasibility before building applies these same principles to GenAI-specific challenges — hallucination tolerance, RAG quality requirements, and cost-at-scale projections. Scenario: the predictable £400K failure A mid-sized logistics company committed £400,000 to an AI-driven route optimisation system. The project triggered every failure predictor above — but none were assessed before the budget was approved. No one had examined the actual GPS and delivery data; when the team finally did, 40% of historical route records had missing waypoints and inconsistent timestamps (operational measurement from that project). Success was defined as “better routes” with no target metric for delivery time reduction or fuel savings. Integration with the fleet management system was a single line item — £30K — that ultimately required £140K of API development, real-time data pipeline work, and driver-app modification. A rules-based approach using three scheduling heuristics, tested in a two-week pilot, later achieved 80% of the projected benefit at under £25K (operational measurement from that pilot). The project was cancelled at month six after consuming £380K. A structured assessment against the four failure predictors — conducted in two weeks for under £15K — would have identified every one of these issues and redirected the investment toward the rules-based approach, saving approximately £360K. If AI projects in the pipeline have not been evaluated against these failure patterns, an AI Project Risk Assessment identifies which ones are likely to succeed and which should be restructured or cancelled before the investment accumulates.
