SOVATA
Last updated 17 July 2026
Most AI projects fail on foundations, not technology. The common causes are poor data quality, no governance or accountability, weak adoption, and use cases chosen for novelty rather than measurable value. The model is rarely the problem. Organisations that protect their investment start by fixing foundations and choosing high-value, feasible use cases — usually via a readiness assessment — before committing to a build.
How often do AI projects actually fail?
Failure and abandonment rates are high enough that leaders should plan for the risk deliberately. Analysts consistently report a large share of AI proofs of concept never reaching production, undone by data problems, unclear value, weak governance and cost overruns — the organisational issues, not the algorithms.
What are the most common reasons AI projects fail?
- Poor or fragmented data the AI can’t rely on.
- No governance owner or accountability for AI decisions and risk.
- Weak adoption — tools deployed without training or change management.
- Use cases chosen for novelty, with no measurable business outcome.
- Jumping to a pilot before checking the foundations can support it.
How do you protect your AI investment?
The pattern among organisations that succeed is unglamorous: they start with the business problem, verify their data and governance foundations, choose a small number of high-value and feasible use cases, keep humans in the loop, and measure results before scaling. Doing a readiness assessment first is the cheapest insurance against an expensive false start.
What should you do before starting an AI project?
Confirm three things: that the use case has a measurable business outcome, that your data and governance can support it, and that you have an adoption plan. If any of those is missing, that's your first project — not the AI build itself.
What are the warning signs a project is heading for failure?
They show up early if you look. The use case is described in terms of the technology ("let’s use AI") rather than a business outcome. No one can name who owns the data it depends on, or that data lives in a dozen inconsistent places. There is a budget for the build but none for training and change. Success has no agreed metric, so no one will be able to say whether it worked. And the plan jumps straight to a pilot without anyone checking whether the foundations can carry it. Any two of these together is a reason to pause and fix the foundation before spending more.
How does this play out for New Zealand organisations specifically?
Two local factors sharpen the risk. First, data sovereignty: a promising pilot can stall late when someone finally asks whether sending personal or regulated data to an offshore tool is defensible under the Privacy Act — a question that is far cheaper to answer at the start. Second, scale: New Zealand teams are often lean, so an AI project competing with day-to-day delivery needs an explicit owner and time allocation, or it quietly dies from neglect rather than any technical fault. Naming the sovereignty constraint and the ownership up front removes the two most common late-stage killers.
Frequently asked questions
Rarely. The dominant causes are organisational — data quality, governance, adoption and unclear value. Modern AI models are capable; the surrounding foundations are usually what break.
Start with the problem and the foundations, not the tool. Choose high-value, feasible use cases, keep humans in the loop, and measure results. A readiness assessment de-risks this before you spend.
Yes. A narrow, well-scoped first use case with a clear metric lets you prove value and build confidence before scaling — far safer than a large, ambiguous programme.