There is a statistic that stops most people in their tracks when they first encounter it: somewhere between 70 and 85 percent of AI projects are expected to fail. Not stumble. Not underperform. Fail. And yet organisations continue to invest billions into AI initiatives every year, often with the same approaches that did not work the last time.
I have spent considerable time studying this problem: why the failure rate is so stubbornly high, what the successful projects have in common, and what a more disciplined approach to AI actually looks like in practice. As I move into consulting, this question sits at the centre of the work I want to do. Because the problem is not that AI does not work. It is that we consistently mismanage it.
The most common mistake: treating AI like software
When most organisations kick off an AI project, they reach for the tools they already know. They set up a project plan, assign developers, define features, and run sprints, the same way they would build a CRM or a mobile app. It feels familiar. It feels safe.
But AI is not a software project. It is a data project.
The distinction matters enormously. In a traditional software project, if you write good code and the logic is sound, the system works. In an AI project, the model can be technically flawless and still fail completely, because the data it was trained on was incomplete, biased, outdated, or simply the wrong data for the problem. A rough rule of thumb in the field: 80 percent of an AI project is a data problem. Only 20 percent is about the model itself.
This is the misalignment that derails so many teams. They spend their energy optimising algorithms and debating model architectures while the real issue (the quality, quantity, and relevance of their data) quietly poisons the foundation.
Starting in the wrong place
Even before the data conversation begins, there is a more fundamental question that gets skipped far too often: should we be using AI at all?
It sounds almost naive to ask, but the pressure to adopt AI (driven by competitive anxiety, executive mandates, or vendor enthusiasm) regularly pushes organisations into AI projects that never needed to be AI projects. A rule-based automation system might solve the problem faster, cheaper, and more reliably. A well-designed BI dashboard might answer the business question without a single machine learning model in sight.
AI earns its place when the problem genuinely requires it: when the rules cannot be hardcoded, when patterns are too complex for traditional analytics, when scale or speed exceeds human capacity. The test I find most useful is straightforward: if you can write down the logic as a fixed rule and it always produces the same correct result, you do not need AI. You need good engineering.
Getting this decision right from the start is not a small thing. It changes everything that comes after.
Data: the part nobody wants to talk about
Once an organisation has confirmed that AI is the right tool for the problem, they typically want to move quickly to the exciting part: picking algorithms, building models, running experiments. In most organisations, the data conversation is treated as a precondition to be cleared, not a discipline to be invested in.
This is where projects quietly begin to die.
The challenges are rarely obvious at first. Data is stored in silos across departments that do not communicate easily with each other. Access requests take weeks. Some of the most valuable data turns out to be locked behind legal or compliance constraints. Historical records are inconsistent: different teams logged the same event in different ways, different regions used different formats, and nobody thought to reconcile them.
And then there is the quality question. One of the most widely used image datasets in computer vision research was found to have a five percent label error rate: images of deer tagged as magpies, mushrooms labelled as spoons. At scale, a five percent error in training data does not produce a five percent degradation in model performance. It can corrupt the model's ability to generalise entirely.
What this means practically is that data preparation is not a phase you get through on the way to building models. It is the work. It accounts for roughly 80 percent of a well-run AI project's effort and time. Teams that budget for it, staff for it, and plan for it tend to produce models that actually hold up in the real world. Teams that treat it as overhead tend to produce models that perform beautifully in the lab and collapse the moment they encounter real data.
Building a model is only the beginning
When a model does finally get built, there is a natural temptation to treat it as the finish line. It is not. It is closer to the starting line.
A model trained today will begin to drift from reality almost immediately, for the simple reason that the world does not hold still. Customer behaviour evolves. Regulatory environments change. Seasonal patterns shift. The data the model sees in operation gradually diverges from the data it was trained on, and as that gap widens, performance degrades.
The COVID-19 pandemic is one of the starkest illustrations of this. Predictive models tuned to normal consumer behaviour (seasonal shopping patterns, standard shipping timelines, typical product preferences) collapsed within days as panic-buying emptied shelves, delivery networks buckled, and everything the models had learned about the world became temporarily irrelevant. The models were not wrong. The world had simply changed faster than anyone anticipated.
This phenomenon, model drift and data drift, is one of the most underappreciated challenges in AI operations. Organisations that account for it build monitoring systems, schedule retraining pipelines, and treat ongoing model management as a core operational function. Organisations that do not account for it discover the problem only when something goes visibly wrong, often at significant cost.
The evaluation trap
There is another pitfall that catches even technically sophisticated teams: measuring the wrong thing.
A model that achieves 95 percent accuracy sounds like a success. But if you are building a fraud detection system and only two percent of transactions are actually fraudulent, a model that simply predicts "not fraud" for every single transaction will achieve 98 percent accuracy while catching zero fraud. The metric looks good. The business value is zero.
This is why evaluation has to be anchored to business outcomes, not just technical benchmarks. The real questions are: Does this model do what we actually need it to do? Is it catching the fraud? Is it identifying the at-risk customers? Is it reducing the time our team spends on manual reviews? Technical accuracy is a means to those ends, not the end itself.
And when a model does not meet the bar, when the business KPIs are not moving in the right direction, the structured response is not to push harder or declare the model "close enough." It is to go back, systematically, to where the problem originated. Maybe it is the model. Maybe it is the data preparation. Maybe it is the data itself. Maybe it is the original framing of the business problem.
Why structure matters more than you might think
Everything I have described here, from the misalignment between data and business goals, to the underinvestment in data preparation, the failure to plan for drift, and the measurement problem, is not random. It shares a common root: the absence of a structured approach to managing AI projects.
There is now a well-developed methodology for this, built on decades of data science practice and updated for the current AI landscape. It treats every AI project as progressing through six phases: understanding the business problem, understanding the data, preparing the data, developing the model, evaluating it rigorously, and then operationalizing it in a way that sustains performance over time. Crucially, it is iterative. Progress is not linear. You go back when you need to. You catch problems early rather than carrying them forward to become bigger problems later.
The methodology also insists on a discipline that does not come naturally to most organisations: asking hard questions at every phase before moving to the next one. Do we actually have the data we need? Is it good enough? Has the model met our business KPIs, not just our accuracy metrics? Are we prepared to monitor and maintain this system after deployment? Does our approach satisfy the ethical and regulatory requirements of the environment we are operating in?
These are uncomfortable questions, especially under the pressure of project timelines and stakeholder expectations. But they are the questions that separate AI projects that deliver lasting value from those that join the long list of expensive initiatives quietly shelved.
The human element
One thing this work has reinforced for me is that the most important challenges in AI are not technical. They are organisational and human.
Who owns the data? Who has the authority to grant access to it? Does the leadership team understand that they are signing up for an ongoing operational commitment, not a one-time build? Have the people whose roles will be affected by the AI system been genuinely brought into the conversation? Is there a plan for what happens when the model produces a result that surprises everyone?
AI at its best is not about replacing human judgment. It is about extending it: giving people better information, faster, at scales that would be impossible otherwise. The organisations that get this right tend to be the ones that approach AI as a collaboration between human expertise and machine capability, with clear lines of accountability and a genuine commitment to operating the system responsibly over time.
What I carry into consulting
As I begin working with organisations on their AI initiatives, the conviction I bring is this: the question is never really whether AI can solve the problem. In most cases, technically, it can. The question is whether the organisation is ready to manage AI: as a data discipline, as an operational commitment, and as a responsibility to the people it affects.
The difference between an AI project that delivers and one that does not is rarely the sophistication of the algorithm. It is the quality of the thinking before the first line of code is written: the rigour of the data strategy, the clarity of the business objectives, the honesty of the go/no-go decisions along the way, and the commitment to maintaining the system long after the launch celebration has faded.
That is the work I am interested in. And I think it is where the real value of AI consulting lies.