The software worked. The project failed anyway.
You have probably watched that happen from close by. Or you are about to start something and are not sure it is worth the money. Either way, the question is not whether the technology works. It is whether your organisation gets anything out of it, and that makes this an investment decision rather than a technology choice.
This page will not explain that AI is hard. It sets out why AI projects fail in the projects we see: four causes, organisational rather than technical, and what you can do about each before you start.
Your scepticism is warranted, and nothing here is an argument for starting anyway. Which raises the question of what “failing” means, and how much of it there really is.
The statistic everyone quotes about why AI projects fail
The number that turns up everywhere, “85 per cent of AI projects fail”, comes from a prediction Gartner made in February 2018. And it says something different from what it is taken to say. Through 2022, 85 per cent of AI projects would deliver erroneous outcomes because of bias in the data, the algorithms or the team. That is not a failure rate, and the horizon of that prediction is behind us.
What is actually measured is something else: how far AI has been scaled, and what it returns. McKinsey surveyed companies about their AI use in the summer of 2025 and published the results that November. Nearly two-thirds of organisations have not yet begun scaling AI across the enterprise. And of the companies that do see it in their results, 39 per cent, most say it accounts for less than 5 per cent of their operating profit.
With the clients we work with, “failed” rarely means nothing works. It means one of four things:
– the time saving never materialises;
– the system runs technically but nobody uses it;
– it stalls halfway after the money is spent and nothing is visible;
– it works in the pilot and nowhere else.
All four describe a project that is finished on paper and changes nothing. In the projects we see, the cause almost never sits in the technology itself. What it does sit in comes down to four causes, all decided before a line of code is written.
Cause 1: the process wasn’t ready for technology
In practice that looks like this: automate a chaotic process and you get automated chaos. If three people handle the same document in three different ways, an automated system produces three outcomes. And there is no agreed standard for deciding which of the three is right. That is the real problem: not that the system gets it wrong, but that nobody can show that it did.
That starts with the process. Of the four causes, this is the one we run into most often in our own projects, and at the same time the one that gets named least when the post-mortem is written. In 2024, RAND arrived at the same place: misunderstandings about what the project was supposed to solve are, according to that research, the most common reason AI projects fail.
The work that prevents this happens before any technology is chosen. You write the process down, you map the exceptions, and you agree what the output should look like. None of that is technical work, and that is why it gets skipped: it does not look like an AI project.
Take a company that wants to automate its incoming invoices. Suppliers send those invoices in ten different layouts, and how they get processed internally is written down nowhere. It sits in the heads of three people who have been doing it for years. The automation does not fail on the software there. It fails because nobody owns the question of how the process is supposed to run. Nobody had agreed up front what good enough meant.
Our rule of thumb: put at least as much time into designing the process as into designing the technology.
A standardised process still tells you nothing about the quality of what it will be reading.
Cause 2: the data wasn’t ready
An AI system learns from examples from the past. If that data is incomplete, inconsistent or unreliable, the system learns exactly that. A document recognition system trained on poorly labelled examples does not make the occasional mistake, it makes the same mistake every time. And you cannot tune that mistake out of the model afterwards.
That is not only our reading. When Gartner listed the reasons generative AI projects are abandoned after the proof of concept in January 2026, poor data quality came first. RAND flags the most underestimated trap alongside it: reusing data that was collected for something else to train an AI model.
This is not a problem you repair after go-live. It is a precondition you establish before the build starts. Establishing that honestly is uncomfortable, because the answer can be that today is not the moment.
Whether your data is ready for AI is a question of its own, and a wider one than this page settles. Process and data can both be in order, though, and the project can still stall because nobody feels responsible for it.
Cause 3: no owner in the business
In the projects we see, an AI project that stays an IT project gets a delivery but no use. The technology gets built, the people who have to work with it do not adopt it, and that is not obstruction: there is simply nobody accountable for the use. That is an organisational choice, not anybody’s mistake.
What is missing is one person from the business, with four things on their plate:
– guarding the business case;
– deciding what “good enough” means;
– driving adoption in their own team;
– reporting back on what does not work.
Not a committee, and not a name on a slide. Someone with a team, a target and a reason to care whether the thing gets used. Without that person, the delivered system becomes an orphan: it exists, it is maintained, and nobody notices when it stops.
Name the owner before you start, not after the technology is finished. An owner appointed at handover inherits decisions they were never part of.
Even then, a named owner does not yet make the project safe, which raises the question of when you are allowed to go wide.
Cause 4: scaling before you have proof
The most expensive failure is the wide rollout before the test. Say you roll an AI system out to five hundred people before anyone has checked whether it works with your documents, in your environment.
A demo is not that check. A demo runs on documents chosen for the demo. Your IT environment is not in it, your document formats are not in it, and your exceptions certainly are not. In the projects we see, that is the difference between a system that convinces in the meeting room and one that holds up on a Monday morning.
The alternative is a contained proof of concept: one use case, real documents, the real environment, and an agreed end date. If it works, you know what you are buying. If it does not, you established that on a contained trial instead of on a full rollout, for a fraction of what that rollout would have cost.
A proof of concept is not the step you skip to move faster. It is the step that tells you whether you are moving in the right direction at all. And that is the useful thing about all four causes: every one can be settled in advance.
What an approach that holds up looks like
The AI projects that do hold up at Belgian SMEs have six things in common, in our experience.
1. A sharp use case. One process, not every process at once. RAND sums it up in one line: successful projects are laser-focused on the problem to be solved, not the technology.
2. Process design first. Document the process before you choose the technology.
3. A data audit. Check quality and completeness before you begin.
4. A business owner.Named and active, not passive.
5. Proof before rollout. Evidence in your own context before you scale.
6. Improve in iterations. Not 100% accuracy on day one; plan the improvement rounds in.
Together they describe one decision: settle what you are doing, and on what, before you commit budget.
That is how we structure the Document Automation PoC: one use case, your own documents, your own environment. After the trial, you know whether investing further makes sense.
Most of these six characteristics you do not need us for. Scoping the use case, naming the owner, agreeing the success criteria, starting small: you can arrange all of that yourself, and it costs you nothing in outside help. The data audit is the one point where that is harder, and it is also the point where most of the time gets lost.
And if you do ask us: a trial that shows you are better off not starting is, to us, a successful trial. That is exactly what it is for.