Why AI Projects Fail Due to Data Quality (and Where Bad Data Hides)

AI projects fail due to data quality when the few records a task depends on are missing, wrong, out of date, or quietly change after launch, and nobody finds out until the AI has repeated the problem hundreds of times. AI doesn't correct your records. It learns from them and copies from them, faster than any person, so a stale price list becomes a stream of wrong quotes and a field that was filled in carelessly becomes the pattern the model learns. The damage usually traces to one or two specific fields that nobody checked until too late.

Data quality sits at the top of the usual list of causes. In July 2024, Gartner predicted that at least 30% of generative AI projects would be abandoned after proof of concept by the end of 2025 "due to poor data quality, inadequate risk controls, escalating costs or unclear business value" (Gartner, July 2024). Our guide to why AI projects fail covers all the common causes and what each famous failure figure counts. For a business of 10 to 200 people, the practical question is where bad data breaks a project, at which stage, and how to catch it first.

Key Takeaways

• Gartner's 2024 forecast that at least 30% of generative AI projects would be abandoned after proof of concept lists poor data quality first among four causes. No major study isolates bad data as the single cause of most failures.
• The circulating claim that "85% of AI projects fail because of bad data" traces to a 2018 Gartner prediction that 85% would "deliver erroneous outcomes due to bias in data, algorithms or the teams responsible for managing them."
• Bad data breaks projects at five points: a record that was never kept, a record that stores the wrong thing, a reference file that's out of date, a feed that changes upstream, and a world that moves after launch.
• Unity Software estimated a $110 million hit to its 2022 revenue after an accuracy problem in its ad-targeting tool, caused in part by "ingesting bad data from a large customer."
• Models age. A 2022 study in Scientific Reports found quality degradation over time in 91% of cases it tested, across 32 datasets from four industries.
• Perfect data isn't the goal, and a company-wide cleanup is its own way to fail. Even the test sets of ten widely used machine learning benchmarks average at least 3.3% label errors. What works is checking the fields one task uses and watching them after launch.

Table of Contents

• Why do AI projects fail due to data quality? The short answer
• Where the "bad data" failure numbers come from
• Five places bad data breaks an AI project
• Why the problem often shows up months after launch
• The opposite failure: when the cleanup becomes the project
• A 70-person moving company's quoting model
• How to keep data quality from sinking your project
• Where Avolis fits
• Frequently Asked Questions
• Continue Learning

Why Do AI Projects Fail Due to Data Quality? The Short Answer

AI projects fail due to data quality because the AI treats your records as the truth, and the records a single task depends on are often less true than anyone in the business realized. A model that predicts job hours learns whatever the hours field says, even if someone typed the estimate into it. A tool that drafts quotes from your price list copies the price list, even if it's a year old. A system that worked in March can drift by September because the inputs changed while the model stayed put.

Here's the idea in simple terms: a person doing the same job carries a lot of quiet knowledge about which records to trust. The estimator knows the old price sheet is stale and checks the supplier's site. The dispatcher knows that one crew lead never logs overtime. The AI has none of that context, so every gap a person was quietly working around becomes a gap the AI walks straight into, at full volume.

That's also why "our data is messy" is the wrong diagnosis on its own. Almost every business's data is messy somewhere, and most of the mess never touches the task in question. The projects that fail on data usually fail on a handful of specific fields, and the failure is less about how dirty those fields are than about nobody checking them against reality before, and after, the AI started relying on them.

Where the "Bad Data" Failure Numbers Come From

Search for this topic and you'll find confident figures: 85% of AI projects fail because of poor data, 70% fail on data quality and integration, 87% never reach production. Most of them appear on vendor blogs without a primary source, and the best-known one says something different from what it's quoted as saying.

The "85%" comes from a February 2018 Gartner release, which predicted that "through 2022, 85 percent of AI projects will deliver erroneous outcomes due to bias in data, algorithms or the teams responsible for managing them" (Gartner, February 2018). It's a forecast about wrong outputs, with data as one of three named causes, and Gartner's July 2024 forecast likewise names data quality as one of four causes of a predicted 30% abandonment rate. Our pillar guide traces where each of the famous failure figures comes from and how the major studies rank data against other causes.

What you can find are documented cases where a company put a number on a data failure. The clearest is Unity Software, which in May 2022 told investors that its Audience Pinpointer ad-targeting tool had lost accuracy. Chief executive John Riccitiello said Unity had "lost the value of a portion of our data, training data due in part to us ingesting bad data from a large customer," and estimated the impact at "approximately $110 million in 2022." On the same call, a Unity executive cautioned that "the whole impact is not because of this one data from the customer," and the company said it was deploying "monitoring, alerting and recovery systems and processes" (Unity Software Q1 2022 earnings call, via The Motley Fool, May 2022).

That's the usual shape of a data failure. Bad data is rarely the only cause, but it's often the one that turns a working system into a costly one, and the fix Unity described was ongoing monitoring rather than a one-time cleanup.

Five Places Bad Data Breaks an AI Project

Bad data breaks AI projects at five distinct points, and each one shows up at a different stage of the project. Knowing which stage you're in tells you what to look for. A problem that would be caught in a ten-minute look at the records before the build can cost months if it surfaces only after launch.

1. The record the task needs was never kept

The simplest data failure is a missing record. A model meant to predict which bids you'll win needs past bids marked won or lost, and a scheduling tool needs real job durations, and many businesses have never recorded either in a system. The information lives in the estimator's memory or a project manager's inbox, which works fine for people and not at all for software.

This is the cheapest failure to catch, because it shows up the moment someone asks where the record is and goes to look. It's also the one a data readiness assessment is built to find, with a sample of real records checked field by field. The fix usually costs very little (add the field and make it required), but if the AI needs history, it takes months or years before there's enough to learn from.

2. The record exists but stores the wrong thing

The more dangerous failure is a field that's filled in and wrong, because it passes a quick inspection. A common version in operations businesses is a field meant to record what happened that actually records what was planned, often because someone fills it in from the plan to close out the job. The history looks complete, and a model trained on it learns to reproduce the plan, mistakes and all.

A subtler version is a history that's accurate and still wrong for the job, because it faithfully records past decisions you don't want repeated. Amazon learned this with an experimental hiring tool. According to Reuters, its models "were trained to vet applicants by observing patterns in resumes submitted to the company over a 10-year period," most of which came from men, and the system "penalized resumes that included the word 'women's'." Amazon disbanded the team, and Reuters reported that recruiters looked at the tool's recommendations but never relied solely on them (Reuters, via CNBC, October 2018).

The same thing happens on a smaller scale with pricing and scheduling. A quoting model trained on five years of your quotes learns your old estimators' habits. That's useful if those habits made money and harmful if they're the reason margins slipped, so the question to ask of any history is whether it records the outcome you want or just the decisions people made.

3. The AI copies a stale reference file

Generative AI, the kind that drafts emails, quotes, and answers from your documents, has a data-quality problem of its own. It depends less on years of history and more on reference files being current: the price list, the labor rates, the warranty terms, the procedure manual. When those files are out of date, the AI repeats them. When there are three versions of the same policy in the shared drive, it may answer from any of them.

Good source material narrows this kind of error without ending it. Researchers at Stanford tested AI legal research tools from LexisNexis and Thomson Reuters, which draw their answers from curated legal databases, and found that each one produced incorrect or misgrounded answers "between 17% and 33% of the time" (Magesh et al., "Hallucination-Free?", arXiv, May 2024). Those tools sit on some of the best-maintained document collections in any industry. The practical lesson for a smaller business is twofold: name one current version of each reference file and an owner who updates it on a schedule, and keep a person reviewing drafts that go to customers, because clean files alone won't catch every error.

4. A feed from another system changes

Most AI systems in an operations business depend on data produced by something else: the job management software, a supplier's invoices, a customer's purchase orders, a crew app. When any of those changes, the AI's inputs change with it, and nobody inside the AI project is told.

Engineers at Google described this risk in a widely cited 2015 paper on the hidden costs of machine learning systems. They found that data dependencies carry the same capacity for building up hidden costs as code dependencies "but may be more difficult to detect," and they warned about "unstable" inputs that "qualitatively or quantitatively change behavior over time," especially when a different team owns them (Sculley et al., "Hidden Technical Debt in Machine Learning Systems", NeurIPS 2015). One scenario they describe will be familiar to any distributor or parts manufacturer: a system left carrying both an old and a new product numbering scheme during a transition, which left it needlessly vulnerable to change once the old numbers fell out of use.

Unity's loss is the large-company version of the same failure, with the bad data arriving from a customer. In a 40-person contractor, it's more likely to be the office switching to a new estimating app, a supplier redesigning its invoice, or a new hire entering job types differently from everyone else. Unity's fix after the fact was monitoring and alerting. In a small business that can be one person comparing the AI's results with reality every week, so a change upstream shows up as a jump in errors within weeks rather than as a complaint months later.

5. The world moves and the model ages

The last failure point is the hardest to see, because nothing in the data is wrong. The records were accurate when the model learned from them, but the conditions they describe have changed: material costs, labor rates, the mix of customers, the length of jobs after a new building code. Data scientists call this drift. A model trained on the last three years is, in effect, a forecast that the next year will look like the last three.

Zillow's home-buying business is the best-known example of how expensive that assumption can get. Zillow Offers bought homes based on its own price forecasts and resold them. In November 2021 the company announced it would wind the business down, recording an inventory write-down of about $304 million for the third quarter and planning to cut roughly 25% of its workforce. Chief executive Rich Barton said "the unpredictability in forecasting home prices far exceeds what we anticipated" (Zillow Group, November 2021). Zillow's records were accurate. The market moved faster than a model built on past prices could follow, and the company also cited capacity and operational constraints.

Why the Problem Often Shows Up Months After Launch

The usual advice on data quality is about getting the data right before you build, but two of the five failure points can't be caught that way, because they haven't happened yet. That makes data quality a running cost of an AI system that most project plans leave out.

The research on model aging is blunt about how common this is. A 2022 study in Scientific Reports trained four standard types of machine learning model on 32 datasets from four industries (weather, hospital operations, airline departure delays, and stock prices) and tracked how their quality held up as time passed since training. The authors "observed temporal model degradation in 91% of cases" (Vela et al., "Temporal quality degradation in AI models", Scientific Reports, July 2022). Some models degraded gradually and some suddenly, and the authors treat this aging as a problem distinct from changes in the data itself, which means a model can need attention even when nothing obvious has changed.

Those were models trained from scratch on numeric data, which is a different setup from a small business using a generative AI tool to draft quotes. But the operational point carries over. Any AI that depends on your prices, your customers, or your job mix will slowly fall out of step with them unless someone is watching the results and has the authority to pause it, adjust it, or retrain it.

What a small business needs for that is modest. One named person compares the AI's output with what actually happened, on a regular schedule (quoted hours against actual hours, drafted prices against invoiced prices, predicted dates against completed dates), and the business keeps a short list of the changes that should trigger an immediate check: new software, a new price list, a new major customer, a new product line. That comparison is what turns an upstream change into a visible jump in errors instead of a slow leak in margin.

The Opposite Failure: When the Cleanup Becomes the Project

There's a second way data quality sinks AI projects, and it runs in the opposite direction. A business hears that AI needs clean data, commissions a data cleanup, and spends six months and a meaningful budget correcting old records before anything useful is built. The cleanup finishes, or more often runs out of money, and the AI project never starts. Nothing in the failure statistics counts this, because no AI was ever built to fail.

A cleanup scoped to the whole company keeps finding errors, so it keeps getting extended, and the AI it was meant to prepare for never gets built. Even the datasets researchers curate carefully to measure AI progress contain errors. A 2021 study from MIT and Amazon Web Services researchers examined the test sets of ten of the most widely used machine learning benchmarks and estimated "an average of at least 3.3% errors across the 10 datasets," including at least 6% of the ImageNet validation set. The authors noted that practitioners' own real-world datasets "are often more noisy than carefully-curated benchmark datasets" (Northcutt, Athalye, and Mueller, "Pervasive Label Errors in Test Sets Destabilize Machine Learning Benchmarks", NeurIPS 2021).

In other words, the useful question is whether the few fields this task reads are wrong in ways that change the output, and whether a person catches those errors before they matter. A company-wide cleanup corrects thousands of records no workflow will ever read. It can still miss the one that matters, like the price list that went stale last spring. The better order is to choose the workflow first, check the fields it uses, and fix the process that creates those records going forward, which is what our guide to data readiness assessment sets out step by step.

Citation-ready summary: AI projects fail due to data quality in two opposite ways. Some skip the check and let the AI repeat a missing, wrong, stale, or changed record at volume. Others try to clean every record first and never build anything. The approach that works checks only the fields one workflow uses, then watches them after launch, because even the test sets of ten widely used machine learning benchmarks average at least 3.3% label errors.

A 70-Person Moving Company's Quoting Model

Consider a 70-person residential and commercial moving and storage company with 14 crews (an illustrative composite). Customers send a video walk-through of their home, an estimator turns it into an inventory list, and from the list the estimator quotes crew hours, crew size, and truck size. In the busy season, three estimators produce about 140 quotes a week at roughly 20 minutes each. Most quotes are binding, so if a job runs long, the company absorbs the overtime.

The first attempt was a quoting model built on three years of past jobs, about 4,000 moves, each with its inventory list and its actual crew hours. In testing on past jobs it matched the recorded hours closely, which looked like success. In its first month of live use, large-home moves began running well over their quotes, and the operations manager was signing off on overtime the quotes hadn't covered. The owner stopped using the model in week six.

The problem turned out to be the "actual hours" field. The dispatcher closed out jobs in a batch every Friday, and whenever the crew lead hadn't left a note, she typed in the quoted hours to clear the job. On roughly six jobs in ten, the recorded actual hours matched the quote to the minute. The model hadn't learned how long moves take. It had learned how the old estimators quoted, including their habit of quoting big homes light to win the job, and in testing it looked accurate because it was being checked against the same copied numbers.

The real hours had been sitting in another system the whole time. Crews clocked in and out on the payroll time clock, and most timecards carried the job number. The rebuild matched each past job to its timecards, by job number where it was recorded and by date and crew lead where it wasn't, and set aside the jobs that couldn't be matched. Retrained on payroll hours, the model's estimates for large homes rose noticeably, and when the estimators reviewed them against jobs they remembered, the new numbers looked right.

The second version also changed how the model was used. It now proposes hours, crew, and truck size beside the estimator's own numbers, and the estimator decides. The dispatcher's Friday close-out no longer touches the hours field, which fills from the time clock instead. The operations manager owns the model and reads a Monday report that compares quoted hours with clocked hours by job size, with any size band running more than 10% over flagged in red.

Five months later the company moved to a new inventory app, which listed packed boxes as a single line with a count instead of room by room. Nobody connected the switch to the quoting model. Within three weeks, the Monday report showed packing jobs running over their quotes, and the operations manager traced it to the new item format. Packing jobs went back to estimator-only quoting for ten days while the new item names were mapped, and then the model resumed. A change that could have quietly eaten margin through a whole season cost three weeks of under-quoted packing jobs and ten days of manual quotes.

How to Keep Data Quality From Sinking Your Project

Data quality failures are mostly preventable with a few specific checks, made at the right stage by someone who knows the work. None of them requires a data team, and most take hours rather than weeks. The table below sets out what to check, when, and who in a 10-to-200-person business is usually best placed to do it.

The last two rows are the ones most projects skip, and they're the rows that caught the moving company's inventory-app change within three weeks. For a project that's already in trouble, our guides to why AI projects stall before production and how to recover a failing AI project cover what to do next. If the AI acts on its own rather than drafting for a person, data errors travel further, which our page on why agentic AI projects fail explains. In a business that handles patient, client, or financial records, there's one more data question to settle first, whether the data may legally go where the tool sends it, covered in our page on why AI projects fail in regulated industries.

Where Avolis Fits

Most data-quality failures come down to checking the wrong data, or checking it at the wrong time, and our diagnostic is designed to settle both. Every engagement starts with it. Working through each workflow with the people who run it, we measure how it runs (volumes, time per task, where work changes hands and stalls), and we check the fields that workflow depends on against the source documents, including whether a history field records what happened or what was planned, and whether a better record already exists in another system. We rank the workflows by what each would return against what it would take to build. The ranked result is yours to keep, whatever you do next.

From there, we build the first workflow inside the systems your team already uses, with the reference files, the review step, and the weekly comparison of AI output against real results built in from the start, and we name the person in your business who owns it. We stay embedded while it settles and while the next one is built, so when your software, suppliers, or prices change, someone who knows the system is there to adjust it. Our guide to AI readiness assessment services explains what a good diagnostic produces, and our guide to which AI consulting company to choose covers how to evaluate any partner who tells you your data needs work first.

Frequently Asked Questions

Why do AI projects fail due to data quality?

AI projects fail due to data quality because AI repeats the records it relies on at volume. They usually fail on a few specific fields rather than on messy data overall: a record that was never kept, one that stores the plan instead of the outcome, a stale reference file, a feed that changes upstream, or conditions that drift after launch.

What percentage of AI projects fail because of bad data?

No reliable study measures it. The widely quoted "85%" comes from a 2018 Gartner prediction that 85% of AI projects would deliver erroneous outcomes due to bias in data, algorithms, or teams. Gartner's 2024 forecast that at least 30% of generative AI projects would be abandoned after proof of concept lists poor data quality as one of four causes.

Do I need clean data before starting an AI project?

No. You need the specific fields one workflow depends on to be recorded, accurate enough, and current, and you need to check them on a sample of real records. Cleaning every record first rarely ends, because even the test sets of ten widely used machine learning benchmarks average at least 3.3% label errors, and most of your records won't touch the first workflow.

What is data drift, and does it affect small businesses?

Data drift is when the conditions a model learned from change after it's built, such as prices, labor rates, customer mix, or job types. It affects any business whose AI depends on its own records. Models also lose quality simply with time: a 2022 Scientific Reports study observed degradation in 91% of the model-and-dataset combinations it tested.

Can generative AI work with messy documents?

Often, yes. Generative AI reads documents the way a person does, so inconsistent wording or formatting matters less than it does for prediction. What matters more is that each reference file is current and that only one version exists. Stanford researchers found that even legal AI tools built on curated databases gave incorrect or misgrounded answers 17% to 33% of the time.

Continue Learning

Bad data rarely sinks an AI project on its own. It does the damage when nobody has checked the few fields a task depends on, or when nobody is watching those fields after launch, and both are fixed by naming an owner before launch.

Before your next AI project starts, name the five to ten fields it will depend on and the person who will compare its results with reality every week.

Why projects fail, in detail:

• Why do AI projects fail? Common reasons and statistics
• Why agentic AI projects fail
• Why AI projects fail in regulated industries
• Why are AI projects failing? What's different about the current wave

Checking your data:

• Data readiness assessment for AI: check the fields, not the database
• How to recover a failing AI project

Starting the right way:

• AI readiness assessment services
• Which AI consulting company should I choose?

---

Sources

• Gartner, "Gartner Predicts 30% of Generative AI Projects Will Be Abandoned After Proof of Concept By End of 2025," 29 July 2024, retrieved 2026-10-26: https://www.gartner.com/en/newsroom/press-releases/2024-07-29-gartner-predicts-30-percent-of-generative-ai-projects-will-be-abandoned-after-proof-of-concept-by-end-of-2025
• Gartner, "Gartner Says Nearly Half of CIOs Are Planning to Deploy Artificial Intelligence," 13 February 2018, retrieved 2026-10-26: https://www.gartner.com/en/newsroom/press-releases/2018-02-13-gartner-says-nearly-half-of-cios-are-planning-to-deploy-artificial-intelligence
• Unity Software, Q1 2022 earnings call, 10 May 2022, transcript published by The Motley Fool, 11 May 2022, retrieved 2026-10-26: https://www.fool.com/earnings/call-transcripts/2022/05/11/unity-software-inc-u-q1-2022-earnings-call-transcr/
• Jeffrey Dastin, "Amazon scraps secret AI recruiting tool that showed bias against women," Reuters, 10 October 2018, as republished by CNBC, retrieved 2026-10-26: https://www.cnbc.com/2018/10/10/amazon-scraps-a-secret-ai-recruiting-tool-that-showed-bias-against-women.html
• Varun Magesh, Faiz Surani, Matthew Dahl, Mirac Suzgun, Christopher D. Manning, and Daniel E. Ho, "Hallucination-Free? Assessing the Reliability of Leading AI Legal Research Tools," Stanford University, arXiv:2405.20362, 30 May 2024, retrieved 2026-10-26: https://arxiv.org/abs/2405.20362
• D. Sculley et al., "Hidden Technical Debt in Machine Learning Systems," Google, Advances in Neural Information Processing Systems 28 (NeurIPS 2015), section 3, retrieved 2026-10-26: https://proceedings.neurips.cc/paper/2015/file/86df7dcfd896fcaf2674f757a2463eba-Paper.pdf
• Zillow Group, "Zillow Group Reports Third-Quarter 2021 Financial Results & Shares Plan to Wind Down Zillow Offers Operations," 2 November 2021, retrieved 2026-10-26: https://investors.zillowgroup.com/news-and-events/news/news-details/2021/Zillow-Group-Reports-Third-Quarter-2021-Financial-Results--Shares-Plan-to-Wind-Down-Zillow-Offers-Operations/default.aspx
• Daniel Vela et al., "Temporal quality degradation in AI models," Scientific Reports 12, 11654, 8 July 2022, retrieved 2026-10-26: https://pmc.ncbi.nlm.nih.gov/articles/PMC9270447/
• Curtis G. Northcutt, Anish Athalye, and Jonas Mueller, "Pervasive Label Errors in Test Sets Destabilize Machine Learning Benchmarks," NeurIPS 2021 Datasets and Benchmarks Track, arXiv:2103.14749 (v4, 7 November 2021), retrieved 2026-10-26: https://arxiv.org/abs/2103.14749

On the Gartner figures. Both are predictions, not measured outcomes. The 2018 figure concerns erroneous outcomes from bias in data, algorithms, or teams, not abandoned projects. The 2024 figure names four causes without saying how much of the predicted 30% each accounts for.

On Unity. The $110 million figure is Unity's own estimate of the 2022 revenue impact of the Audience Pinpointer accuracy problem, which the company attributed to a platform fault and to the loss of value in part of its training data, "due in part" to bad data from a large customer. A Unity executive said on the same call that the whole impact was not due to that one customer's data.

On Zillow. The $304 million is the third-quarter 2021 inventory write-down Zillow reported for homes bought at prices above its estimates of future selling prices. Zillow attributed the wind-down to the unpredictability of forecasting home prices, along with capacity and operational constraints. It's an example of conditions moving away from a model's assumptions, not of dirty data.

On the Amazon tool. The account comes from Reuters' reporting based on people familiar with the project. Amazon declined to comment on the recruiting engine at the time.

On the Stanford study. The 17% to 33% range covers the three commercial legal research tools tested in 2024, on the researchers' set of legal queries, counting answers that were incorrect or misgrounded. Those tools have since been updated.

On the model-aging study. The 91% figure is the share of model and dataset combinations (four model types on 32 datasets) in which the authors observed quality degradation over time. The datasets came from weather, hospital operations, airline departure delays, and stock prices, not from small businesses.

On the moving company. It's an illustrative composite, not a client. Its figures (70 people, 14 crews, three estimators, about 140 quotes a week, 20 minutes a quote, about 4,000 past jobs, six jobs in ten with copied hours, six weeks, five months, three weeks, ten days, and the 10% flag) are representative examples, not measurements or benchmarks.

On the five failure points. The five-stage framework and the prevention table are Avolis's own synthesis, not a published standard.

---

About Avolis Research Group

Avolis Research Group is Avolis's in-house research practice, focused on how operations-heavy small and mid-sized businesses actually adopt AI. It synthesizes primary economic research, government survey data, and results from real implementations into practical, vendor-neutral guidance.

More about Avolis and how we work · Get in touch