Enterprise AI runs on data engineering

When an enterprise AI project stalls, the first instinct is to treat it as a model problem. Swap in a larger model, rewrite the prompts, wait for the next release. That instinct is usually wrong. The model is rarely where these initiatives break. The data underneath them is.

This is not a contrarian take. It is close to the consensus of every recent study that has looked at why enterprise AI fails to deliver, and it has a direct consequence for where a team should spend its next quarter.

The evidence points one way

A 2024 RAND Corporation study, built on structured interviews with 65 data scientists and engineers, found that by some estimates more than 80 percent of AI projects fail, roughly twice the rate of IT projects that do not involve AI. One interviewee put the cause plainly: “80 percent of AI is the dirty work of data engineering.”

The analyst and vendor data agrees, from different angles:

• Gartner predicted in February 2025 that, through 2026, organizations would abandon 60 percent of AI projects that are not supported by AI-ready data.
• In April 2026, Gartner reported that organizations with successful AI initiatives invest up to four times more, as a share of revenue, in foundations like data quality and governance.
• Cloudera’s April 2026 survey of 1,270 IT leaders found nearly 80 percent say AI is held back by data access challenges.

Cleanest of all, a 2026 survey of cloud IT leaders by Eon found that 57 percent named data problems as the single biggest barrier to AI progress, against only 11 percent who blamed the models or tooling.

These are different samples run by different people, and several are vendor-commissioned, so no single number is gospel. But they all lean the same way, and that direction is not toward the model.

What actually breaks

The failure is rarely one dramatic outage. It is quieter than that, and an engineer will recognize every item on the list.

Schema drift changes what a column means without triggering an alert. Training and serving pipelines compute a feature two slightly different ways, so the model sees one distribution in development and another in production. A batch job does not run over a holiday, and the model serves on stale features while the freshness checks, calibrated for weekday patterns, stay silent. None of these throw an error. They degrade decisions slowly, and by the time anyone notices, the trail is cold.

The generative-AI version is newer but the same shape. Unvalidated content reaches a model’s context window and quietly corrupts the answer, a failure mode that Elastic’s engineering team has written up as context poisoning and that the OWASP project now ranks as the top LLM application risk. A bigger context window does not fix it. It enlarges the surface area for it.

Retrieval makes the point sharply

Retrieval-augmented generation is where the argument stops being abstract, because the quality of the output is largely set by data-engineering choices made before the model generates a single token.

Anthropic’s Contextual Retrieval work is the clearest illustration. Prepending a short generated context to each chunk before indexing cut the retrieval failure rate by 35 percent. Combining that with keyword search and a reranking step cut it by 67 percent. Same corpus, same model. The improvement came entirely from the pipeline around the model.

Reduction in failed retrievals, from pipeline changes alone

Same corpus, same model throughout. Each step adds to the one above it.

Item	Reduction in retrieval failures
Contextual embeddings	35%
Plus keyword search	49%
Plus reranking	67%

As MongoDB’s chief product officer for AI put it in May 2026: “Agents don’t fail because of the LLM. They fail because they can’t retrieve the right context, can’t remember a conversation, and can’t do either reliably at scale."

"AI-ready data” is something you build

The phrase “AI-ready data” gets used as if it describes a state a dataset happens to be in. It is closer to an engineering artifact you build and maintain. Databricks’ own guide for data engineers walks through what it takes: layered pipelines that progressively clean and curate data, feature definitions with shared lineage, metadata and semantic context available at query time, and governance that records what was accessed and when.

That is built with the same discipline as production software. Version control, automated tests on the data itself, continuous integration, infrastructure as code. This is ordinary practice on a large data team, and it is exactly what a scaling company usually has not built yet when it starts asking a model to reason over its data.

Aeolus view. The teams getting real value from AI are not the ones with the best models. Anyone can call the same APIs. They are the ones whose data is trustworthy enough that a model’s output can be trusted in turn. That is an engineering problem, and it is a solvable one, usually before you spend another quarter tuning the model.

A note on the numbers

It is worth being careful with the statistics in this space, because a few well-worn ones do not hold up. The often-quoted line that “85 percent of AI projects fail” traces to a Gartner prediction from 2018 about a window that closed in 2022, not a current measurement. The claim that “87 percent of data science projects never reach production” comes from a 2019 conference remark with no traceable study behind it. We have leaned on the more recent, better-sourced figures above and left the folklore out. The case does not need it.

Where this leaves you

If your AI outputs are not yet trustworthy, the fix is usually not a different model. It is the pipeline underneath, and that work is both less glamorous and more tractable than another round of model selection.

That is the work we do. A short, fixed-fee data and AI-readiness audit maps what you have, finds what breaks under an AI workload, and hands back a prioritized plan, before you commit to a larger build. And if your data is not ready for AI yet, we will tell you straight.