The technology does what it is supposed to do. And still, 95% of the organisations in MIT’s 2025 research get zero return on their investment in generative AI. That figure covers the applications companies have built for them or buy in. For general tools such as ChatGPT and Copilot the same research measures something else: over 80% of organisations have explored or piloted them, and nearly 40% report deployment.
Why do AI projects fail then? In the projects we observe, the cause lies not in the model but around it: with the people, the agreements and the organisation. Perhaps you recognise it: there’s a pilot that just won’t finish, or management is asking for “something with AI”. Whether your data is ready for AI plays a role, but that’s not what this page is about.
Juvo has been guiding AI and data projects with Belgian organisations for approximately ten years. Below are four pitfalls from these projects, and what they have in common. One nuance beforehand: the MIT report is not a peer-reviewed publication. The direction of the figure holds, but its precision does not.
What the numbers on failed AI projects actually say
That figure comes from The GenAI Divide: State of AI in Business 2025 by MIT Project NANDA, July 2025. The research is based on more than 300 publicly disclosed AI initiatives, discussions with representatives from 52 organisations, and 153 completed questionnaires from senior leaders. That is the size of the sample, not evidence that it is representative.
Gartner juxtaposes two predictions, which do not concern the same thing. In June 2025, Gartner predicted that more than 40% of agentic AI projects would be scrapped by the end of 2027, due to rising costs, unclear business value, or inadequate risk controls. In July 2024, Gartner predicted that at least 30% of generative AI projects would be halted after the proof of concept by the end of 2025. That latter figure pertains to the pilot that lingers with you. So the technology is not what these numbers measure. Where does it go wrong?
Pitfall 1: the project starts with AI instead of with a problem
In the projects we see, the question about AI most often comes from IT rather than from the business. That is not a criticism of IT: IT hears about the technology first, so that is where the conversation starts. The problem is the order, not the department.
Starting with the technology means looking for a problem that fits it. A team finds a use case that suits the tool and builds something that demonstrates well. Only then does someone in the business get asked to recognise their own problem in it, and by then the problem has been picked by the people furthest from it.
In episode 1 of the Juvo podcast it is put like this: “Dus het is eigenlijk geen IT-feestje alleen meer” — it is no longer just an IT party. (04:43)
IT stays necessary. Someone has to judge what is technically possible, build towards a proof of concept or an MVP, and keep it running. What IT cannot decide is which value the project has to deliver. That sits with the business, which knows which process hurts and what a fix is worth.
The honest first question is not what AI could do for you. It is which problem you would pay to have solved, and what the ROI on that looks like. That is the business case, and it needs an owner. The next pitfall is what happens when it has none.
Pitfall 2: nobody loses sleep over it
An AI project needs an owner, and ownership here is not enthusiasm. It is a budget and a P&L that improves when the thing works.
Episode 1 puts it as a question: “Wie zijn P&L gaat er eigenlijk op vooruit als we daarin stappen zetten?” — whose P&L improves if we take steps here? (05:37) If nobody in the room can answer that, the project has no owner yet, whatever the steering document says. You can see the difference most clearly in the budget.
If the budget comes from an empty IT pot, the initiative is dragged on without anyone making a decision. We see this reflected in our projects. There is neither a ‘no’ nor a ‘yes’, and thus the project continues to exist without making progress. Every question regarding priority then becomes an escalation to someone who is unfamiliar with the file.
A facilitator behaves differently than a client at a distance. A client delegates the task and returns in three weeks to fetch the results. A facilitator is part of the steering group, makes decisions regarding the scope, and allocates time for their own staff. They explain to the rest of the organisation why this is in place. That last task is not a communication exercise carried out afterwards. It determines whether the result will be used later on.
None of this is specific to AI. A conventional IT project that nobody loses sleep over gets stuck in exactly the same way. Say the owner is in place, budget and all. Why do projects still stop after the pilot?
Pitfall 3: trying for the sake of trying
In the projects we run, pilots and proofs of concept get stuck because they start too quickly and results are expected too quickly. In episode 1 that habit gets a name: “Proberen om te proberen.” (trying for the sake of trying). (07:31)
Trying is not the problem. Trying without an agreed finish line is, because there is no moment at which anyone may say this is done. Answer four questions before you start:
1. What do we consider a success, in a number that we can determine afterwards?
2. When do we stop, and who decides that?
3. How much time do we allocate for it?
4. Which of you are involved, and how many hours per week are allocated for that?
We put a maximum of six weeks on a proof of concept, with a go/no-go at the end. Six weeks is a ceiling, not a target, and it says nothing about the outcome. A no-go is not six wasted weeks either. You bought an answer about your own data, your own processes and your own appetite.
Question four is the one that gets nodded through. If a client does not free up time with their own people, a three-week track can stretch to nine weeks or more. We have seen that happen in our own projects.
If the people who have to carry it get no time, we advise against starting rather than starting anyway. That costs us the work, and it saves you a proof of concept that stalls and never gets stopped.
And which use case is that conversation about?
Pitfall 4: 120 use cases and not one in production
One organisation came to the table with 120 defined AI use cases. Not one of them was in production.
The list itself was not the problem. It was the residue of a process that felt productive: a workshop per department, ideas from everyone, a long document as the deliverable. What the list could not produce was a decision.
Prioritising fails for lack of mandate, not for lack of method. Scoring models are easy to find. Every department puts its own case at the top and defends it with real arguments. Without someone who is allowed to choose, the ranking becomes a negotiation nobody wins. The list keeps growing, because adding is free and cutting is not.
Start from the other end. In our discovery conversations with a small number of key people from the business, one to at most three real pain points typically surface. Those are the things people work around every week. Pick one, give it the owner from the second pitfall, and bring in the people who feel it from the first week.
Those same people carry the result into production, which is the thread running through all four pitfalls.
The common thread is not technology, it is people
Read the four pitfalls again and notice what is missing. The technology does not appear in any of them. Not the model, not the platform, not the integration. Each of the four is a decision about people: who asks the question, who owns the answer, who agrees when to stop, who is in the room.
We do see projects actually going into production, and in our experience, this has always been related to the same four factors:
- a business problem as a starting point,
- an owner with a budget,
- agreements made in advance,
- and people participating from day one.
That last point requires a lot of work and receives little attention. Key users who think along from the start understand where it is heading and what it yields for them. Those who do not know use it because they have to, and that does not last long. Therefore, training and change management, as well as open communication to the entire organisation, are necessary.
This also shifts the moment when you call a project successful. A delivery is not yet a success. Adoption is the success criterion: a solution that no one uses is an expensive demo with a manual.
So what do you do differently on the next one?
How to run an AI project that does reach production
Seven rules you can apply yourself tomorrow. If you are unsure where you stand today, then start with a self-assessment that shows where you are.
1. Start from a business problem that is currently costing money or time, and not from the technology you have just seen.
2. Appoint one owner with a budget and a profit and loss account that benefits from it.
3. Limit yourself to one to three use cases, chosen from the pain points that the business itself identifies.
4. Define your success criteria and your go/no-go moments before you start, and not along the way.
5. Set a timeframe: for us, that is a maximum of six weeks for a proof of concept.
6. Involve the key users from day one and genuinely free up their time.
7. Communicate openly to the entire organisation, and not just to the people who were at the table.
Frequently asked questions about failing AI projects
- Why do so many AI projects fail?
- How many AI projects never reach production?
- How long should a proof of concept take?
- What is the difference between a pilot, a proof of concept and an MVP?
This episode, and what comes next
Would you prefer to watch and listen rather than read? This is episode 1 of a series about AI and data projects in Belgian organisations:
Do you not know where your data is?
De JUVO Data & AI Readiness Scan provides you with an honest overview and a concrete action plan within two weeks.