Why AI projects fail in practice

When AI projects succeed, the returns can be substantial: in a survey, the top-performing adopters reported $10.30 in value for every $1 invested in AI, well above the $3.70 average across all adopters. But getting there is hard. In another survey, 42% of companies abandoned most of their AI initiatives and the average scrapped initiative carried a sunk cost of $7.2 million.

We've watched plenty of these failures play out over the past few years, and this post is about the most common reasons behind them. We focus mainly on AI built inside companies that aren't "AI-first". That excludes coding agents as most companies in 2026 buy ready-made solutions (Codex, Claude Code, etc.). Across the use cases we looked at, model "intelligence" was never the main bottleneck.

Use cases

Many AI projects fail at the outset because they are taken on as a technical challenge rather than a calculated investment. This shows up in two ways:

1. People misestimate cost and merit at the start. They then only realize in hindsight that the improvement over the status quo is smaller than hoped, or building and maintaining the solution costs more than expected. The project is cancelled, correctly but too late.
2. People don't define what "good enough" looks like at the start. A genuinely useful system might get killed for missing some imagined bar.

The same lens explains which projects are worth taking on and which aren't. The highest returns usually sit in unglamorous, repetitive workflows like document processing, invoice extraction, contract review, etc. They are boring because they're high-volume and rule-bound, which is exactly what makes them tractable. Yet the projects that actually get pursued tend to be shiny ones like automating the most complex work, replacing skilled professionals outright (think lawyers), etc. These are more visionary, more fun to build, and easier to take credit for, which is often enough to win the budget even when the boring work would return more.

Data readiness

Many company databases have been evolving for decades. They often stitch together several data stores into hundreds of tables, with column names that mean nothing without the context that's been lost. They were built by teams that no longer exist, to serve systems that have been replaced twice over. One enterprise warehouse we looked at has two near-duplicate tables, FCLT_HIST and FCLT_HIST_1, where only experience tells you which one people actually use (and in the same database, there are 100s of examples just like this). Even the analysts, engineers, and domain experts needed years to build the tribal knowledge required to navigate it.

This is an old problem and predates AI. But AI wears it in a new disguise: because a model inherits none of that institutional knowledge, it faces the same mess these experts face, minus the ten years of scar tissue that taught them how to navigate the data. For example, we tried to use the latest coding agents (Codex, Claude Code, etc.) to translate English questions into SQL queries over the database. They only translated 15% of queries correctly, even though they were able to explore and query the whole database for as long as they wanted.

This is what we're building at Sovara Labs, and it's why we go at it from the opposite direction. Instead of asking people to maintain a knowledge base, Sovara uses AI to reverse-engineer the data: it detects exactly where a query needs context the schema can't supply, reaches out to the right person, asks the one question that resolves it, and banks the answer so it never has to be asked again. On the same warehouse and the same scoring as that 15% result, this takes us to 82%. And because every gap we hit becomes a question asked and a piece of knowledge captured, that number climbs as the system runs.

So we're biased, and we won't pretend to give a neutral outlook here: to some extent, the outlook on this problem is the outlook of Sovara!

Trusting AI

People only deploy AI if they trust it, and trust comes from being able to anticipate it: seeing the input and knowing what will come back. That takes both correctness, so the answer is right, and consistency, so it's the same right answer every time.

AI is neither of them by default. On correctness: one company working on text-to-SQL told us, "The moment AI gets less than 99% of queries right, we cancel the project." As the last section showed, Codex and Claude Code got 15% right on a similar enterprise database. That's a long way to 99%! On predictability: another company told us, "If you can make our AI produce the same, consistent results across queries, we'd pay money for that." It shows how hard it is to get even these basic guarantees out of AI at scale.

This is the bar every business process already meets: a close lands the same day every month, an invoice is handled the same way every time, a compliance check follows the same logic no matter who's asking. Until AI can do the same, the highest-value, zero-tolerance processes stay out of reach.