Ask me why AI projects fail and I won't start with the technology. After a few hundred first conversations with founders and teams across the Netherlands, I can usually tell within the first half hour whether a project is going to work — long before anyone writes a line of code, picks a model, or sketches an architecture diagram. When a project does fail, the failure was almost always visible at the very start. It just wore a disguise: a slick demo, a confident roadmap, a budget already approved.
This isn't pessimism, and it certainly isn't a sales tactic. I want the projects I take on to succeed — that's precisely why I've learned to read the early signals honestly, for the client's sake as much as my own. Turning down work that will fail is cheaper for everyone than discovering the failure six months and fifty thousand euros later. So here's what I actually listen for in those first conversations, and what it tells me.
Why AI projects fail — and why it's rarely the technology
The uncomfortable numbers line up with what the conversations reveal. Gartner predicted that at least 30% of generative AI projects would be abandoned after proof of concept by the end of 2025, blaming poor data quality, unclear business value, and escalating costs — not model performance. A RAND study built on interviews with experienced data scientists and engineers put the failure rate of AI projects north of 80%, roughly twice that of comparable IT projects that don't involve AI, and traced the root causes overwhelmingly to people and purpose rather than algorithms.
That matches my experience almost exactly. The model is hardly ever the thing that sinks a project. Modern language models, vision systems, and forecasting tools are astonishingly capable out of the box. The problem lives upstream of all of that — in how the project was framed, who is behind it, and whether the organisation is actually ready to change something because of what the system produces. Get those wrong and the most elegant model in the world just automates a decision nobody was going to act on.
There's no such thing as an "AI project"
Part of the trouble starts with the label. The moment something is called an "AI project" it gets treated as a technology initiative — owned by whoever is most excited about the tech, measured by whether the tech got built, and declared a success the day it goes live. But no business has ever needed AI. They need shorter queues, fewer errors, faster quotes, lower churn. AI is one possible means to those ends, and framing the work around the end rather than the means changes everything: who owns it, how you measure it, and whether you'd even notice if a simpler solution did the job. When I gently refuse to call something an AI project and insist on calling it a "cut-the-quote-time project" instead, the conversation almost always gets sharper.
This reframing also protects you from the hype cycle. Tools change monthly; the underlying business problem is stable for years. A project anchored to the problem survives a model upgrade or a vendor falling out of fashion. A project anchored to a specific tool has to be re-justified every time the landscape shifts.
The red flags I listen for in the first call
None of these are about intelligence or ambition. Smart, serious people walk into all of them. They're structural — which is good news, because structural problems can be fixed before you spend real money.
No one can name the decision that will change
My first real question is almost always some version of: "When this works, what will you do differently on a Tuesday morning?" If the answer is crisp — "we'll auto-triage these 400 daily tickets and route the top 10% to a specialist" — I relax. If the answer drifts into "we'll have better insight" or "we'll be more data-driven," a small alarm goes off. AI that doesn't change a concrete decision or action produces a dashboard nobody opens twice. The projects that succeed are anchored to a specific human behaviour that will change on the other side.
The data doesn't exist yet — or nobody owns it
People vastly underestimate this one. An AI system learns from, or reasons over, your data — so if that data is scattered across inboxes, locked in a supplier's system, riddled with gaps, or simply never captured, the project is already on tilt. Worse than messy data is unowned data: nobody who can say authoritatively what a field means or whether it's trustworthy. I'd rather hear "our data is a mess and here's who owns fixing it" than a confident "the data's all there" that turns out to mean three incompatible spreadsheets. This is why we so often start with the plumbing; honest data engineering work is frequently the real project hiding behind the AI ask.
The sponsor has enthusiasm, but not authority
Some of the most energising first calls are with someone who has read everything, tried the tools, and is genuinely excited. Enthusiasm matters. But if that person can't free up budget, can't get the data team to prioritise access, and can't make an operational team change how they work, the project will stall the moment it meets organisational friction — and it always meets organisational friction. I've watched brilliant proofs of concept die quietly because the one person championing them didn't have the authority to make anyone adopt the result.
The success metric is "we're using AI"
When the goal is framed as adopting AI rather than solving a problem, the project has no finish line. "We want to use AI in customer service" is a direction, not an objective. "We want to cut first-response time on our top 20 support intents from four hours to under one minute" is something we can build toward, measure, and know whether we hit. Vague goals are impossible to fail — and therefore impossible to succeed. Sometimes the most valuable thing I can do in a first call is help translate an AI ambition into a measurable business outcome.
They've already chosen the solution
"We need a chatbot." "We want a RAG system on our documents." Occasionally that's exactly right. But when a team has locked onto a specific solution before we've agreed on the problem, we've skipped the most important step, and I get cautious. The right sequence is problem, then constraints, then the simplest thing that could work — which is sometimes not the AI-heavy option at all. Being vendor-neutral means I'm happy to tell someone their problem is better solved by fixing a form or a workflow than by training a model. Occasionally the right answer is to do nothing, and a good partner will say so.
The plan assumes a straight line
AI work is empirical. You try something, you measure, you're often surprised, you adjust. When a plan is laid out as a tidy Gantt chart with "deploy AI model" sitting neatly in week six and no room for the thing not working the first time, that rigidity itself is a risk. The successful projects budget for learning. They treat the first build as a question, not a commitment, and they're structured so an early "this won't work as imagined" is a cheap, useful finding rather than an expensive embarrassment.
The quieter signals — culture, not code
Beyond the specifics, there's a set of softer signals that are harder to put on a checklist but just as predictive.
The first is change fatigue. If a team has just survived a painful ERP migration or a reorganisation, they may have no appetite left to change how they work, no matter how good the tool is. Adoption is where AI value is realised or lost, and exhausted teams don't adopt. The second is the absence of an owner for after go-live. Plenty of projects have someone to build them and no one to run them; a model that nobody tends will drift, its data will go stale, and within months it quietly stops being trusted. The third is treating adoption as an afterthought — "we'll sort out getting people to use it later." Later rarely comes. If the plan for change management is a single training email, the tool will join the long list of software people were told to use and didn't.
These aren't reasons to walk away. They're reasons to design the project differently — to shrink the initial scope, to name an owner up front, and to build the human change into the plan from day one rather than bolting it on at the end.
What a project that will succeed sounds like
It's worth describing the opposite, because it's surprisingly consistent. The projects that work tend to arrive with a narrow, almost boringly specific problem: one workflow, one decision, one team. There's a named person who feels the pain daily and has the authority to change how their team operates. When I ask about data, someone can tell me where it lives, roughly how clean it is, and who to talk to. The success metric is a number attached to money or time. And there's a healthy humility about the unknowns — a willingness to prove the risky assumption cheaply before scaling.
Notice that none of this is about being technically sophisticated. Some of the best projects I've worked on came from teams who barely used the word "AI" and just wanted a specific, painful thing to stop being painful. The clarity of the problem did more for the odds of success than any amount of technical ambition.
A tale of two first calls
Two conversations from the past year sit next to each other in my memory. The first was with a well-funded team that arrived with slides, a chosen architecture, and a six-week plan to "roll out an AI assistant across the business." When I asked which team would use it first and what they'd stop doing as a result, the room went quiet. There was no first team — it was for everyone, which meant it was for no one. I suggested we start with a single department and a single workflow; they wanted the big launch. We didn't work together, and as far as I know the assistant never shipped.
The second was almost the opposite: a smaller company, no slides, one frustrated operations lead who spent two hours a day copying data between a supplier portal and their own system. She could tell me exactly what the task was, where the data lived, and what an hour of her time was worth. There was no grand AI vision — just a specific, expensive irritation. That one worked, because everything a project needs was already in the room. The difference between the two had nothing to do with budget or technical sophistication. It was clarity.
How we de-risk a project before committing
Reading the signals is only useful if you act on them, so the whole engagement is structured to surface failure early and cheaply rather than late and expensively. That's the logic behind working in stages. We usually begin with a short, paid audit — from around €2,500 — to map the real use case, check whether the data can support it, and confirm there's a decision worth changing. If the audit says the project shouldn't happen as imagined, that's a good outcome: you've spent the cost of a laptop to avoid the cost of a car.
If it's worth building, a proof of concept (from roughly €20,000) proves the risky part works on your real data before anyone commits to production — and you usually have a working prototype by the second call. Only then does it make sense to scale to a production system. Structuring risk this way is also what good AI governance frameworks recommend; the NIST AI Risk Management Framework is built around identifying and managing risk continuously rather than hoping it away. You can see the shape of these engagements in our case studies, and the full breakdown on our pricing page.
The one question that reveals the most
If I could keep only one diagnostic, it would be that Tuesday-morning question: when this works, what changes in someone's actual day? It's deceptively simple, and it quietly tests everything at once. To answer it well, a team has to know whose day changes (the owner), what they do now (the workflow), what they'd do instead (the decision), and how you'd know it worked (the metric). A team that can answer it in one clean sentence is usually ready. A team that needs ten minutes and a whiteboard to get there has just discovered, cheaply, that the project isn't defined yet — a far better place to learn it than three months into a build.
Notice what the question doesn't ask about: which model, which framework, which vendor. Those are real decisions, but they come later and they're the easy part. The hard part — the part that decides success — is entirely contained in that one human sentence about a Tuesday. Get the sentence right and the technology tends to follow. Get it wrong and no amount of engineering rescues it.
When "not yet" is the honest answer
Some projects aren't failures waiting to happen so much as good ideas that have arrived too early. The decision is real and the value is real, but the data hasn't been collected yet, or the team that would own it is mid-reorganisation, or last quarter's priority still hasn't landed. In those cases the most useful thing I can offer isn't a build — it's a short list of what needs to be true first, and an honest "come back when these three things are in place." It rarely wins me the immediate work, but it's the reason people come back, and the reason the projects we do take on tend to succeed. A partner who never says "not yet" is telling you something about how they measure success, and it isn't your outcome.
If you recognise your project in this
Seeing your own project in a couple of these red flags isn't a death sentence — it's a gift, if you catch it now. The fix is almost always to get smaller and clearer before you get more ambitious. Narrow the scope to a single decision. Find the person who owns that decision and the data behind it. Replace "use AI" with a number you'd be happy to be measured against. Agree to prove the riskiest assumption cheaply before you build the whole thing. Do those four things and most of the failure modes in this article simply evaporate.
And if you're not sure whether your project is a good one — that's exactly the conversation worth having early. Review our transparent pricing, or book a free consultation and we'll map your first use case together, honestly, including telling you if the honest answer is "not yet." I'd far rather have that conversation now than after the budget's gone.
Frequently asked questions
Why do most AI projects fail?
Most AI projects fail for reasons upstream of the technology: an unclear decision the AI is meant to change, data that doesn't exist or has no owner, a sponsor without the authority to drive adoption, and vague success metrics. Studies from Gartner and RAND put failure and abandonment rates high, and both point to people, data, and purpose rather than the model itself.
Can you tell if a project will fail before building it?
Often, yes. In the first conversation the strongest predictors are whether the team can name the specific decision that will change, whether the data exists and is owned, whether the sponsor can actually change how people work, and whether the success metric is a real number. A short paid audit is designed to test exactly these before you commit to a build.
How do you reduce the risk of an AI project failing?
Get smaller and clearer before you get more ambitious. Narrow the scope to one decision, name the owner of that decision and its data, replace 'use AI' with a measurable outcome, and prove the riskiest assumption cheaply with a proof of concept before scaling. Working in stages — audit, then PoC, then production — surfaces failure early and cheaply.
Is the AI model usually the reason a project fails?
Rarely. Modern models are highly capable out of the box, so the technology is seldom the bottleneck. Failure almost always traces back to framing, data readiness, organisational mandate, and adoption. That's why an honest partner spends the first conversation on the problem and the organisation, not on which model to use.