Somewhere between the pilot and production, most AI projects quietly die.
At the Dropsolid x Beltug event in Ghent, Jan Smedts cited a recent MIT study with a sobering figure: 95% of AI projects fail. Not fail spectacularly or publicly, most simply stall, lose momentum, or never make it past the proof-of-concept stage. The panel that followed his keynote spent the better part of an hour unpacking why, and the answer had far less to do with the technology than most people expect.
Smedts offered an analogy that stuck with the room: adopting AI without addressing the underlying organization is like putting a sports car in a traffic jam. The car isn't the problem. It doesn't matter how powerful the engine is if the road ahead is gridlocked. And the instinctive response, swap in an even more powerful engine, doesn't help either. You're still stuck, just with more horsepower going nowhere.
His breakdown of where AI transformation effort should actually go was blunt: roughly 10% technology, 20% change management, and 70% people. Most organizations invest in almost the exact inverse ratio.
Rafael Weuts, who worked for several years with the Belgian healthcare department RIZIV, described a different kind of failure mode, one where the technology itself worked, but the surrounding conditions weren't ready. His team had used AI to fix a genuinely painful search problem: a doctor searching for "sprained ankle" guidance could previously surface completely unrelated results due to word overlap. AI fixed that, and fixed it well.
But success created a new problem. Once an American medical chatbot became popular among doctors, the pressure to build something comparable, but locally relevant, sharpened. The catch: any system offering patient-specific advice automatically triggers the EU AI Act's high-risk classification for medical devices, and the certification norms for that category simply aren't ready yet.
Their workaround was pragmatic, RIZIV built something closer to a medical atlas rather than a system offering patient-specific advice, avoiding the regulatory trap while still delivering value. Weuts' broader point: succeeding here required someone who understood the technology, the regulation, and the domain simultaneously. An engineer alone builds something that can't be certified. A lawyer alone tells you it's illegal and stops there. Neither perspective alone gets the project across the line.
Across every failure story shared on the panel, the same root cause kept resurfacing: the human factor. Weuts pointed to something that shows up in a lot of knowledge-based organizations, some employees not yet AI-literate feel pressure as colleagues using AI tools work visibly faster, and the traditional KPIs (like "how many outputs per month") only intensify that pressure.
His proposed fix was reframing the KPI itself: instead of measuring raw output quantity, measure quality of human-in-the-loop review. Combined with genuine AI literacy training, that reframe turns a source of resentment into a shared incentive to use the tools well.
Pulling the threads together, the projects that don't die in the proof-of-concept stage tend to share a few traits:
The technology, in nearly every story told on that panel, was the easy part. The organization around it was where the real work happened.
