Month: September 2026

Somewhere in the process of figuring out why an AI initiative is producing unreliable results, sometimes the problem narrows down to one specific type: the data it depends on exists, it is simply not accurate or consistent enough to trust yet, distinct from the other common cause, where the data needed was never captured in the first place. That distinction tells you what kind of problem you are dealing with, but it does not yet tell you which of your records actually need correcting, how far that correction has to go, or when the work is genuinely finished, and that gap is exactly where a fast, contained fix quietly turns into something much bigger than anyone planned or funded.

In Brief

• A confirmed quality-bottleneck diagnosis names the problem. It does not scope the fix, and that is a separate decision most teams skip.
• Gartner’s own guidance states directly that data quality efforts should never target everywhere at once, scope gets set by which specific use case actually needs it.
• How widely a piece of data is shared across the organization, not just how broken it is, determines how large the fix should be.
• This piece covers scoping the fix for one diagnosed AI use case specifically. A separate, larger question, building lasting organization-wide data quality, is covered elsewhere.

Why “Just Fix the Data” Is Not a Real Plan

That gap does not close itself, and it is not for lack of trying. Data and analytics leaders often reach for two familiar responses, starting with whichever records happen to look worst, or deciding the fix should touch every system that could conceivably feed the AI initiative, just to be safe. Neither response is wrong exactly, they are both just guesses standing in for a scope that was never actually set.

Gartner’s own guidance on data quality is direct about this: setting a program’s scope too wide taxes resources without producing business benefit, since not all data carries equal importance to your use case. Scoping determines whether your fix stays fast or becomes its own multi-quarter initiative, not something to settle informally before the real work starts.

Where This Fix Fits

Before scoping can start, it helps to be clear about where the diagnosis itself came from, since that shapes how much of this piece applies directly. Whether the distinction between data that exists but cannot be trusted and data that was never captured came from a structured set of diagnostic questions built for exactly this purpose, or from a different assessment entirely, a gut read, a retailer rejection that made the pattern obvious, the starting point from here is the same: a confirmed quality bottleneck, and a second question most teams skip, which of the records actually need attention, and which ones are simply sitting nearby the problem without being part of it. That second question is what this piece answers.

Why Fixing Everything Is the Wrong Default

The instinct to widen your fix comes from a reasonable place. If the customer records feeding your AI initiative are inconsistent, you can probably find that same inconsistency somewhere else in your organization too, so why not fix it everywhere while you are already looking.

That instinct produces a specific, predictable outcome: the fix stops being fundable as a fast, contained project and starts requiring the budget, timeline, and cross-functional buy-in a genuine organization-wide data quality initiative needs, the sustained, multi-year kind that changes how records get created in the first place, not just how the existing ones get corrected. Those are not the same project, and treating them as one guarantees your fast fix never actually finishes fast.

If your real goal is building lasting, organization-wide product data quality, system enforcement paired with genuine cultural ownership across every team touching the data is a real and worthwhile undertaking, and it deserves its own dedicated plan rather than becoming an accidental side effect of fixing one AI initiative’s data.

Mapping the Fix by Value and Risk

Once you decide to stay bounded to your use case, your next question is which records, inside that use case, actually need attention first, since even a scoped fix usually touches more data than you have time to fix all at once.

Gartner’s guidance gives you a direct way to sort this: map the data your use case touches along two dimensions, the value you get from getting it right, and the risk you take on from getting it wrong. A field that barely affects your model’s output but would cause real damage if wrong deserves your attention before a field that affects the output constantly but carries little consequence either way.

Applied to your quality-bottlenecked AI use case specifically, this looks like asking, for each data element your model actually consumes, what happens if this value is wrong when the model uses it. A wrong customer name might produce an awkward but harmless output. A wrong price or a wrong compliance attribute might produce a costly or even a legally risky one. Those two fields do not deserve equal priority from you, even if both currently show the same inconsistency rate.

How Widely Shared Is the Data You Are Fixing

Value and risk tell you what to prioritize, while a second question, how widely the data is actually shared, tells you how large the fix itself needs to be, a distinction Gartner draws between three categories.

Centralized Data

Shared master records used across many teams and systems fall into this category, and they hand you an inherently larger fix. Correcting centralized data well means coordinating with everyone else who also depends on that data being right, since a change made without their knowledge can break something downstream that has nothing to do with your AI initiative. This is the category that most often turns a fast fix into a slower one, not because the correction itself is harder, but because the coordination is.

Regional Data

Data shared within one business unit sits in the middle. The fix is smaller and more contained than centralized data requires, and it is usually one you can lead yourself if you already own that team’s data, without needing sign-off from stakeholders outside your immediate group.

Local Data

Data used by a single process or a single team is the smallest and fastest category to fix. One person can usually own the correction from start to finish, since nothing outside that one process depends on the data staying a particular way while the fix is underway.

If your quality-bottlenecked use case turns out to depend on centralized master data, you are looking at a genuinely bigger undertaking than one depending on a single team’s local records, even if the inconsistency itself looks identical on paper. Knowing which category you are in before you start is what keeps your estimate honest.

What the Fix Actually Involves Day to Day

With priority and scale set, the actual work in front of you is more concrete than it sounds standing outside it. Gartner’s own methodology names two practical steps worth borrowing directly: profiling and dimension selection.

Column-Based Profiling

This gives you a statistical read on the data as it currently stands, patterns of missing values, formatting inconsistencies, and outliers across a given field. It tells you what the data looks like, without necessarily telling you whether it is correct against any specific business rule.

Rule-Based Profiling

This checks your records against the specific business logic your use case actually depends on, rather than against general statistical patterns. It is usually the more useful of the two for a scoped fix, since it tests the exact thing your AI initiative needs to be true, not just whether the data looks internally consistent.

Dimension selection means resisting the urge to fix every possible kind of data problem you find. Out of the nine recognized data quality dimensions, accuracy, completeness, consistency, and the rest, your use case genuinely only needs two or three addressed to get unblocked. If your use case is bottlenecked by conflicting customer names, you need consistency and accuracy fixed. You do not need a full audit of timeliness or precision unless those are also demonstrably part of what is breaking your model’s output.

Scoping One Fix, Start to Finish

Take the retailer whose return-prediction model was struggling because customer records disagreed across three systems and product listings carried duplicate SKUs with conflicting prices. The diagnosis already confirmed this as quality-bottlenecked. Scoping it starts with the value-and-risk question: a wrong customer name is awkward but low-stakes, while a wrong price feeding into a return-prediction model risks the model justifying refunds based on figures that were never accurate to begin with. The price and SKU inconsistencies get priority. The customer-name variants can wait.

Next comes the data-expanse question. Product pricing at this retailer lives in a system shared across the catalog, e-commerce, and returns teams, centralized data, not something one team can correct alone. That single fact changes the shape of the fix: this is not a task one person finishes in an afternoon, it needs sign-off from whoever else depends on that pricing data staying stable while it gets corrected.

That leaves two dimensions worth actually working on, accuracy and consistency, not all nine. The scope, once written down, reads as something concrete: correct pricing and SKU records for the specific product lines feeding the returns model, coordinated with the catalog and e-commerce teams that also touch that data, timeline measured in weeks. Customer-name formatting stays out of scope entirely, it does not affect the model this fix exists to support.

That is what a properly scoped fix looks like once the frameworks have actually been applied to something real, rather than staying at the level of principle.

How to Know the Fix Is Actually Bounded, Not Creeping

Prioritizing by value and risk, sizing the fix by how widely the data is shared, and narrowing the work to two or three dimensions all point toward the same outcome, a fix that stays fast because it stayed small. Holding that shape once work is underway is its own separate discipline, since scope drift is quiet, it rarely announces itself as a decision, and instead shows up as a series of small, reasonable-sounding additions that each make sense on their own and add up to a different project than the one you started.

The Use Case Still Has a Name

You can still name the specific use case the fix serves, without needing to reference other initiatives to justify the work. The moment the justification shifts from “this fix supports X” to “this fix supports X and also helps with Y and Z,” the scope has already started moving.

The Records Match the Mapping

The records you are correcting are the ones your value-and-risk mapping actually flagged, not every record that happens to look messy to you along the way. Fixing an unrelated inconsistency just because it is visible while you are already in the data is scope creep, even when it feels efficient in the moment.

The Owners Have Not Multiplied

The people involved are still the ones who owned this data to begin with, not a growing list of stakeholders you are pulling in because the fix started touching their systems too. A widening circle of people needing to sign off is one of the clearest early signs that a bounded fix has stopped being bounded.

The moment any of those three starts slipping for you, your fix has stopped being the bounded project this piece describes and has started becoming the larger, organization-wide undertaking that deserves its own separate plan, its own budget, and its own timeline.

Key Takeaways

• Setting a data quality effort’s scope too wide taxes resources without producing business benefit, a principle Gartner states directly in its own guidance.
• Mapping your affected data by value and risk determines what actually needs fixing first, not every inconsistent field carries equal priority.
• Whether your data is centralized, regional, or local to one team changes how large the fix needs to be and who needs to be involved.
• A bounded fix stays scoped to your diagnosed use case. A fix that starts touching unrelated systems or unrelated teams has quietly become a different, larger project.

Two organizations can have the exact same complaint, our AI initiative is not working, and be describing completely different problems. One has data that is wrong, the other has data that simply does not exist yet, and treating those as the same problem is why so many AI budgets get spent solving nothing.

The distinction matters because the fix is different in each case, and most teams never actually check which one they have before reaching for a solution. They assume, usually based on instinct or whichever problem they dealt with last time, and spend weeks or months acting on a guess.

There are six questions that get you there, and answering them honestly about your own initiative is usually enough to know which problem you are actually solving before you spend another dollar assuming.

In Brief

• A data quality problem means the data exists but cannot be trusted. A data availability problem means the data was never captured in the first place. The fix for each is different.
• Six direct questions determine which one applies to a specific AI initiative, based on what is actually happening in the organization’s own systems today.
• Quality problems and availability problems produce different symptoms in production, inconsistent outputs versus initiatives that succeed in testing and fail once they go live.
• The diagnosis takes under an hour and determines which of two entirely different next steps is the right one.

The Diagnosis Most Teams Skip Before Blaming the Model

Only 7% of organizations say their data is completely ready for AI, and 27% say it is not ready at all, a gap Harvard Business Review Analytic Services documented in a 2026 study conducted with Cloudera, surveying more than 230 data decision-makers. Seventy-three percent describe preparing data for AI as genuinely difficult.

Those numbers hide something the survey itself was not built to capture, that “not ready” describes two entirely different situations, and a team can spend a quarter cleaning up records that were never the actual problem, or spend that same quarter waiting on a data initiative when the real gap was somewhere else entirely. From the outside, these two mistakes look identical, and both come from skipping the same step, a real diagnosis before a real fix.

Two Kinds of Data Problems, Briefly

This distinction exists because most organizations skip a scoping step before either problem ever gets diagnosed, a precondition failure that plays out the same way across most AI initiatives, and the short version of the split is enough to work with here. A quality-bottlenecked problem means the data exists but cannot be trusted, duplicated records, conflicting values, inconsistent formats across systems. An availability-bottlenecked problem means the data a specific AI use case needs was never captured or structured in the first place, simply because nobody needed that information until now.

Treating these as degrees of the same problem, rather than as two separate ones, is what makes the mistake expensive, since the fix, the timeline, and the resourcing required are different for each.

The Diagnostic Questions That Separate the Two

Run your AI initiative against these six questions and answer plainly, based on what is actually happening in your systems today. Each question is designed to isolate one signal, and it is the overall pattern across all six that points toward the actual bottleneck.

Does the data your use case needs already exist somewhere in your systems today, in some form?

This question works as the starting fork, since answering yes puts you in quality territory, evaluating data that exists but needs to be trusted, and answering no shifts the entire conversation to availability territory, whether that data was ever tracked in the first place. Be precise here, “exists in some form” means a real system of record, not a spreadsheet someone built once for a different purpose.

If it exists, do different systems or records disagree with each other about the same fact?

Three systems giving three different addresses for the same customer is a clear quality signal, and not a formatting inconvenience. It means there is no single trustworthy version of that fact anywhere in the organization, and any AI model trained on it will learn whichever version appears most often, regardless of which one is actually correct.

If it exists and agrees, has anyone actually verified it is current and accurate, or is that assumed?

Systems agreeing with each other is no guarantee they are correct, since multiple systems can consistently share the same outdated or wrong value, especially when one system was the original source and the others simply copied from it years ago without anyone checking since. This question catches quality problems that consistency alone would hide.

If the data does not exist yet, is that because nobody has ever needed to track it, or because it was tracked once and lost?

If the data was simply never tracked, that is a build problem, new capture has to be designed from scratch. If it existed once and disappeared, through a deprecated system or an integration that quietly stopped working, that is closer to a recovery and quality problem, worth investigating before assuming a full rebuild is necessary.

Would fixing existing records solve your problem, or would you still be missing something afterward?

This question works as an honesty check on the earlier answers, since it is possible to describe something that sounds like quality trouble when the real gap is actually availability. If a team could clean every existing record perfectly and the use case would still lack a piece of information it needs, that missing piece is an availability problem no amount of cleanup will touch.

Could a data team start cleaning tomorrow and make real progress, or would they hit a wall where the information simply is not there to clean?

This question serves as the practical test. A quality problem is workable immediately, since there is something to correct. An availability problem hits a hard wall almost right away, because there is nothing yet to act on. A team that reports being stuck within days of starting is usually describing an availability problem, not a quality one.

A pattern of answers across questions 2, 3, and 5 pointing toward inconsistency and conflict signals a quality-bottlenecked problem. A pattern across questions 1, 4, and 6 pointing toward genuine absence rather than inconsistency signals an availability-bottlenecked problem.

What a Quality-Bottlenecked Answer Looks Like

A mid-sized retailer wants AI to flag which products are likely to be returned before they ship. The company has years of return data, along with three systems that each record customer addresses differently, a product catalog with duplicate SKUs carrying different attributes, and a returns database that has never been reconciled against the original order system.

Running the six questions: the data exists in the point-of-sale, catalog, and returns systems (yes to question one). Those systems disagree with each other constantly, the same customer, the same product, three different values depending on which system is pulled (yes to question two). Nobody has verified which version is correct in years, each system has simply been trusted on its own terms (yes to question three).

Nothing here suggests information was ever lost, the raw signal exists, it is just contradictory (this points away from question four’s concern). Cleaning and reconciling the records would plausibly resolve the inconsistency and give the model something trustworthy to learn from (yes to question five). A data team could start reconciling these systems immediately, there is real, existing work to do starting tomorrow (yes to question six).

Every signal here points toward a quality-bottlenecked problem, and the fix is a targeted reconciliation project scoped to this specific use case, smaller and faster than a new AI capability build or a company-wide governance overhaul.

What an Availability-Bottlenecked Answer Looks Like

A logistics company wants AI to predict which shipments are at risk of customs delays before they happen. The company has clean, trustworthy data on shipment volumes, routes, and delivery times going back years. It has never once recorded which customs documentation was submitted with which shipment, because until this initiative, nobody needed that information for anything.

Working through the same six questions: the specific data this use case needs, documentation submitted per shipment, does not exist anywhere in the company’s systems (no to question one). Because it does not exist, there is nothing to compare for disagreement, and nothing to verify for currency or accuracy either, since there is no record at all (questions two and three do not apply). Nobody ever needed to track this before, the field was never tracked, not lost, which confirms question four’s answer.

Cleaning the existing shipment data, however thoroughly, would not surface documentation that was never captured in the first place (no to question five). A data team assigned to this would hit a wall almost immediately, there is genuinely nothing to clean until new capture exists (this confirms question six).

The pattern here points to an availability-bottlenecked problem, and the fix is building new data capture, integrating with whatever system tracks customs documentation and connecting it to the shipment record, on the same timeline as the AI build instead of a strict sequence.

Why Each Bottleneck Produces the Symptoms It Does

A model trained on inconsistent data tends to perform well in one test and poorly in the next, because it is learning from a signal that disagrees with itself. The signal is present, just corrupted, so the model produces an answer, just not a reliable one. That inconsistency is the fingerprint of a quality-bottlenecked problem.

Availability leaves a different fingerprint. An initiative built on missing data either cannot get off the ground at all, or performs surprisingly well in testing and falls apart the moment it reaches production, because testing environments are often built on hand-prepared sample data that quietly fills a gap the real environment does not have. The model was never actually learning the missing signal, since that signal was never there to learn from.

Recognizing which fingerprint is showing up is often a faster shortcut than running all six questions from scratch, inconsistency pointing toward quality, and absence, especially absence that only becomes visible once a project reaches production, pointing toward availability.

What to Do Once You Know Which One You Have

A quality-bottlenecked diagnosis points to a specific, scoped next step, cleaning and reconciling the exact records this use case depends on, not a broad governance program that touches everything, and scoping that cleanup correctly is where most reconciliation projects actually go wrong (Cluster 2 link, pending publication).

An availability-bottlenecked diagnosis leads somewhere different entirely, building the specific new data capture this use case needs, run alongside the AI build rather than treated as something that has to finish first, and that parallel build carries its own sequencing decisions distinct from a data cleanup (Cluster 3 link, pending publication).

Either way, the diagnosis itself is the highest-leverage thirty minutes available before committing real budget to either path.

Key Takeaways

• Data quality and data availability are two distinct problems that produce the same surface complaint, “our AI initiative is not working,” and require different fixes.
• Only 7% of organizations report their data as completely ready for AI, per a 2026 Harvard Business Review Analytic Services and Cloudera study, and 27% report it as not ready at all.
• Six direct questions, answered honestly, are usually enough to determine which bottleneck actually applies to a given AI initiative.
• Quality-bottlenecked problems tend to leave inconsistent outputs. Availability-bottlenecked problems tend to succeed in testing and fail once they reach production.

Your CFO wants a straight answer to a simple-sounding question. Where does next quarter’s AI budget go, into cleaning up the data or into building the AI itself. You have maybe twenty minutes in that meeting, and the uncomfortable truth is that most people in the room have not actually agreed on what problem the AI is supposed to solve in the first place.

That gap gets papered over constantly. Someone says “fix the data first,” because it sounds responsible. Someone else says “just start building,” because leadership wants visible progress this quarter. Both answers can be defended in a slide, and both skip past the decision that actually determines whether this initiative works.

There is a real answer to which comes first, and most organizations are asking a different question entirely.

Why Data Readiness Is Not the First Question to Answer

That real question starts with an instinct almost everyone in the room already has. Ask ten data leaders whether to fix data readiness before starting an AI initiative, and most will say yes without hesitating. It is the responsible answer. It is also, in a meaningful number of cases, the wrong first move. Data readiness still matters. The problem is that jumping straight to it assumes a decision has already been made that usually has not.

RAND Corporation interviewed 65 experienced data scientists and machine learning engineers to understand why AI projects fail. Their finding cuts against the instinct in that CFO meeting. Eighty-four percent of interviewees named leadership-driven failure as the primary reason projects collapse, ahead of data quality itself. Business leaders and technical teams frequently disagree, sometimes without realizing it, about what problem the AI is actually meant to solve or how success will be measured.

That is a scoping problem, sitting upstream of the data-first-or-AI-first debate entirely. Skip it, and the sequencing decision you make next stops mattering, because you end up optimizing the wrong thing regardless of which path you pick.

What an Unscoped AI Problem Actually Looks Like

That wrong optimization has a shape to it, and it rarely announces itself. Leadership asks for a model that predicts customer churn. The technical team builds one, optimized for prediction accuracy. Three months later, leadership asks why churn has not improved, because what they actually needed was a model that identified which at-risk customers were worth the cost of retaining, a narrower and more useful target than simply predicting who was likely to leave.

Both sides did their jobs, each one correctly by their own definition. The project failed because the target metric and the business objective were never the same thing, and nobody caught the mismatch until the work was already done.

A simple test cuts through this before a single dollar gets spent on data or infrastructure. Can leadership and the technical lead each independently write down, in one sentence, what business outcome this AI initiative is meant to change. That alignment has to happen before the sequencing conversation starts.

Two Different Data Problems Once the Use Case Is Scoped

Once leadership and the technical team agree on what problem the AI is solving, the real sequencing question finally becomes answerable, and it is narrower than most people expect. It comes down to which of two situations you are actually in.

In the first, the data your use case needs already exists somewhere in the organization, but it cannot be trusted. It is inconsistent across systems, duplicated, ungoverned, or simply wrong in ways nobody has caught yet.

In the second, the data does not exist yet in usable form. The specific use case is simply new, and the organization has never needed to capture, structure, or retain that information before now.

These are two different problems, each calling for its own first move.

When Data Exists But Cannot Be Trusted

This is the quality-bottlenecked path, and it is the one most content on data readiness already addresses, for good reason. Picture a customer record that shows three different names for the same account, a product catalog with duplicate entries carrying different prices, or a sales figure that changes depending on which system you pull it from.

RAND’s interviews found this pattern repeatedly. Organizations believe they have good data because they get weekly reports, without realizing that the data behind those reports was never built to support a new purpose.

When this is the actual bottleneck, fixing the data first is the correct sequence. The reason has little to do with feeling responsible. Building AI on top of untrustworthy data produces a faster path to a model nobody trusts, and that is a more expensive failure than a delayed start.

When AI Needs Data That Does Not Exist Yet

The availability-bottlenecked path looks different, and it gets far less attention in most data readiness conversations, which is part of why organizations mishandle it. Here, the data is simply incomplete. It does not exist yet, because the use case is asking a question the organization has never needed to answer before.

Picture a manufacturer launching a new product line and wanting AI to flag supplier risk before a shipment gets delayed. The company has years of clean, trustworthy sales data. It has never once tracked supplier lead-time variability at the granularity this use case needs, because nobody needed that number before. Cleaning existing records will not surface a number that was never captured, so the only real fix is building the data collection itself.

This is a real and growing constraint, and a significant one. Stanford HAI’s 2026 AI Index flags a broader version of this same problem at industry scale, noting genuine concern among researchers that the supply of high-quality training data itself may be approaching structural limits within the next several years. Synthetic data has not proven a full substitute. If data availability is becoming a binding constraint even at the scale of the entire AI industry, it deserves equal weight to quality inside a single organization, as a different problem in its own right.

When this is the actual bottleneck, spending months on a data governance program before touching the AI initiative solves a problem you do not have. The right move is building the specific data capture and structure the use case needs, alongside building the AI capability itself, on the same timeline instead of a strict sequence.

The Real Cost of Sequencing Data Readiness and AI Wrong

Whichever path actually applies, guessing wrong in either direction carries a real cost, and it shows up differently depending on which default an organization reaches for. Organizations that default to “clean everything first” often spend on a broad governance initiative when the actual use case only needed a narrow, targeted fix, delaying value for months over a problem that was smaller than assumed.

Organizations that default to “build now, fix data later” run into the opposite cost. They discover the trust problem only after the model is in production, when a bad prediction has already reached a customer or a decision, and the fix now requires unwinding both the data and the deployed system at once.

A third pattern is just as common, and often the most expensive of all. Organizations split the budget, funding a partial data cleanup and a partial AI build at the same time, without ever diagnosing which one the use case actually needed.

Both efforts end up underfunded, and neither one finishes. The AI initiative stalls waiting on data that was never fully fixed, and the data initiative loses priority the moment the AI timeline slips, leaving the organization with the appearance of progress on two fronts and real progress on neither.

All three defaults carry real risk. Diagnosing which path actually applies costs far less than guessing wrong in any of them.

How to Know Which Path Applies to Your Organization

The scoping check comes first. Confirm that leadership and the technical team can each state the target business outcome in the same terms, and resolve any gap in that alignment before anything else.

Once scoped, the diagnostic question is direct. Does the data your use case needs already exist somewhere, just inconsistent or untrustworthy, or does it not exist yet in usable form at all. That single distinction determines whether the right next move is a data quality initiative or a parallel build.

This is the exact question a Data & AI Strategy engagement is built to answer, replacing the guesswork with a clear sequencing plan.

Key Takeaways

• RAND’s interviews with 65 experienced AI practitioners found leadership-driven misalignment was the most cited primary cause of AI project failure, named by 84% of interviewees, ahead of data quality itself.
• Confirming what problem the AI use case solves, in terms both leadership and the technical team agree on, has to happen before any sequencing decision is meaningful.
• Once scoped, sequencing splits into two distinct paths: fixing data that exists but is not trustworthy, or building toward data that does not exist yet for the specific use case.
• Stanford HAI’s 2026 AI Index confirms data availability is a serious, industry-recognized constraint carrying equal weight to quality.
• Splitting the budget between partial data cleanup and a partial AI build, without diagnosing which one the use case actually needs, is common in practice and often costs more than committing to either path deliberately.