An impressive demo is not the same as a useful working process. To assess an AI project, look at workflow fit, ownership and measurable outcomes — and be careful about applying enterprise statistics to your own situation.
What the research actually measured
The preliminary 2025 NANDA report, The GenAI Divide, describes a gap between enterprise AI adoption and measurable profit-and-loss impact. Its widely quoted 95% figure is not a failure probability for an individual coaching session or a small-business productivity task.
The authors note limitations in the interviews, sample sizes and definitions of success. Use the report as context, then measure your own task before and after a trial.
Common reasons a project can stall
After building automations for operations-heavy businesses for years, I see the same handful of reasons, over and over:
1. Chasing the model, not the process
Most effort goes into picking the cleverest tool and arguing about which one just topped the leaderboard. But the model is rarely the constraint. The constraint is the messy, manual process around it — the data typed into four systems by hand, the report rebuilt every week, the approval that waits in someone's inbox. Bolt AI onto a broken process and you get a faster broken process.
2. Starting with the flashy use case
Teams reach for the impressive demo — the chatbot, the agent, the thing that looks good in a screenshot — instead of the unglamorous task that quietly eats ten hours a week. The flashy work rarely survives contact with reality. The boring work is where the time (and the money) actually is.
3. Ignoring the operational and compliance reality
A pilot built in a vacuum dies the moment it meets the real world: data it's not allowed to touch, an audit it can't pass, an edge case no one designed for. In regulated industries especially, AI that ignores the rules isn't an asset — it's a liability waiting to happen.
4. No one actually owns it
AI gets squeezed in around everyone's day job. There's enthusiasm, a pilot, a flurry of activity — and then it stalls, because no one has the time or mandate to take it from "interesting" to "running every day."
The pattern: failed AI projects optimise the technology. Successful ones fix the work, then add just enough technology to automate it.
What useful projects do differently
The projects that actually pay off are almost boringly consistent:
- They start with one repetitive task — the thing done twenty times a week without thinking — not a grand "AI strategy".
- They fix the process first. Map how the work really happens, cut what shouldn't exist, then automate what's left.
- They keep it small and get it into production. A modest automation running every day beats an ambitious one stuck in "pilot purgatory".
- They build guardrails in — data stays private and controlled, and nothing runs that can't be seen or switched off.
- They measure the hours saved, then use that proof to earn the next step.
The short version
- Enterprise profit-and-loss impact and individual time savings are different measures.
- The bottleneck is the broken process, not the model.
- Start with one boring, repetitive task and fix the process around it.
- Keep it small, get it into production, measure the time saved, then scale.
- Boring and reliable beats clever and fragile.
So where do you start?
Pick the one task you'd happily never do again — the one you do every week without thinking. That's almost always the right place to begin. Not the smartest model on the leaderboard. The one repetitive job that, taken off your plate, gives you your evenings back.