Don't wait for clean data to start

There is a meeting that kills more AI programs than any technical failure. It is the one where someone says "before we do AI, we need to fix our data," everyone nods, and an eighteen-month data-quality program is born. The AI project is officially "phase two." Phase two rarely arrives, because enterprise data never sits still long enough to be finished - and eighteen months later the business case has moved, the sponsor has moved, or both.

The numbers say the quiet part: only about 14 percent of companies rate themselves fully data-ready, while 91 percent have adopted AI anyway. Readiness is not what separates winners from losers; the winners started before they felt ready and let the use case tell them what to clean. This post makes the practitioner's case for that sequencing - model first, clean second - and gives you the loop we use to do it without shipping garbage. Because the other half of the debate is right about one thing: AI does amplify whatever you feed it. The answer to both truths is the same loop.

Table of contents
1. Why cleanup-first stalls
2. What GIGO actually implies (and what it doesn't)
3. The model-first loop
4. Error analysis: let the model write the cleanup backlog
5. Quality gates that ship with v1
6. Where waiting IS correct
7. What this looks like in an engagement
8. Takeaways

1. Why cleanup-first stalls

The cleanup-first sequence feels responsible, which is exactly what makes it dangerous. Three structural problems:

• It has no natural end. "Clean" is not a state a living dataset reaches; new sources, schema changes, and upstream process drift arrive faster than the backlog burns down. As one analysis puts it, cleanup as a first step often becomes the reason initiatives stall, because the finish line moves.
• It cleans blind. Without a model consuming the data, you cannot rank defects by impact - so the program polishes everything equally, which means it polishes mostly things that do not matter. The 60-to-80-percent underestimation of data-prep cost that readiness advocates cite is partly an artifact of this: unscoped cleaning is unbounded cleaning.
• It burns the political capital the model needed. An AI initiative gets one honeymoon with its sponsor. Spend it on a data program with no visible product, and the model that eventually ships inherits fatigue instead of enthusiasm. Only 16 percent of AI initiatives scale enterprise-wide; the graveyard is full of projects that were still "getting the data ready."

Note what this argument is not: it is not that readiness doesn't matter. Gartner projects that through 2026, organizations will abandon 60 percent of AI projects not supported by AI-ready data. The dispute is about sequencing and scope - whether readiness is a gate you clear before modeling, or a property you build for one use case at a time, driven by evidence.

2. What GIGO actually implies (and what it doesn't)

"Garbage in, garbage out" is true and routinely misapplied. What it implies: a model trained on biased, mislabeled, or systematically broken data will produce confident, scaled versions of those defects. What it does not imply: that every field in every table must be pristine before any model may exist.

The refinement that matters, and that the AI-ready-data literature has converged on: readiness is contextual. Data is ready or not for a specific use case - and traditionally "high-quality" data is not the same as AI-ready data; the two can even pull in opposite directions (deduplicated, aggregated warehouse tables are "clean" by BI standards and lossy by ML standards, because the raw events the model wanted were tidied away). A churn model cares about label leakage and event timestamps; a support copilot cares about document freshness and coverage; neither cares about the malformed addresses that the readiness program would have spent a quarter fixing.

So the operative question is never "is our data clean?" It is: for this decision, which defects in which fields actually change the output? That question cannot be answered in the abstract. It is answered by building the first model and looking at where it fails - which is why the model comes first.

3. The model-first loop

The sequencing we use on every engagement where the data is allegedly not ready:

Week 1-2   Baseline on the data as it exists today.
           Simple model, honest eval set, no cleaning beyond
           what the pipeline needs to run at all.

Week 3     Error analysis. Slice failures by segment, source,
           field completeness. Rank: which data defect, if fixed,
           buys the most metric?

Week 4+    Fix the top defect ONLY. Re-run the eval.
           Repeat. Every cleanup item enters the backlog with
           an expected metric gain attached - or it doesn't enter.

Two properties make this loop work where the readiness gate fails. First, the baseline converts data quality from an opinion into a measurement. "Our data is a mess" becomes "duplicate customer records cost us 4 points of precision in the mid-market segment" - a sentence a sponsor will fund. Second, every cleaning dollar has a receipt. The data team stops being a cost center doing invisible hygiene and starts being the team that moved the model 6 points in March. In our experience the baseline itself routinely surprises in both directions: fields everyone swore were unusable carry most of the signal, and the "clean" table everyone trusted turns out to have a leaking label. You cannot know which until a model consumes it.

4. Error analysis: let the model write the cleanup backlog

The pivot of the whole approach is the error-analysis pass, so here is its concrete shape:

# For each failure in the eval set, tag the plausible cause:
#   LABEL     - target wrong/leaked/inconsistent definition
#   MISSING   - predictive field null/sparse for this segment
#   STALE     - feature computed from outdated snapshot
#   DUPE      - entity resolution failure (same customer, 3 ids)
#   DRIFT     - upstream process changed mid-history
#   MODEL     - data fine, model genuinely wrong
#
# Then: group by tag x segment, multiply frequency x business
# cost, sort descending. The top three rows ARE the data
# quality roadmap. Everything else waits.

This is the discipline that separates "start messy" from "ship garbage." You are not ignoring quality; you are ordering it by evidence. Typically the top of the list is boring and specific - one join key with two formats, one label definition that changed in 2024, one source system whose timestamps are local time - and fixing three such items moves the metric more than a year of generic profiling. The GIGO-era guidance is right that small inconsistencies compound; the loop finds the specific inconsistencies that are compounding, instead of insuring against all conceivable ones.

5. Quality gates that ship with v1

Starting before the data is clean does not mean starting without guardrails. The minimum harness that ships with the first model, not after it:

• Schema and freshness checks at the pipeline boundary - types, ranges, null-rate ceilings, arrival SLAs. Cheap assertions (dbt tests, Great Expectations, or twenty lines of SQL) that turn silent upstream drift into a loud failure.
• An eval set you actually trust. If you clean only one dataset perfectly, make it the evaluation data. A clean eval set over messy training data is a workable v1; the reverse is flying blind.
• Provenance on every training run - which snapshot, which filters, which known defects were present. When the model misbehaves later, this is the difference between a one-hour diagnosis and an archaeology project.
• A human checkpoint sized to the blast radius. Messy-data v1s earn their way into automation; they do not start there. Recommendations with human review first, autonomous writes later.

This harness is what makes the trust argument - that decision-makers must believe the data - compatible with starting now: trust is built by visible checks and honest error reporting, not by a certificate that the lake was audited eighteen months ago.

6. Where waiting IS correct

The honest boundaries of the start-now argument - cases where the readiness camp wins:

• Regulated and safety-critical decisions. Credit adjudication, clinical support, anything with a regulator in the loop: data lineage and quality evidence are legal prerequisites, not iteration targets. The loop still applies inside the compliance envelope, but the envelope comes first.
• Known systematic bias in the labels. If the historical outcomes encode a practice you are legally or ethically required not to replicate, modeling first means laundering the bias into software. Fix the label process before any training run.
• Foundational identity chaos. When the same customer exists as five entities across three systems and the use case is customer-level, minimal entity resolution is not "cleaning," it is the substrate. Scope it to the entities the use case touches - not the whole CRM.
• No eval data at all. If you cannot assemble even a few hundred trustworthy labeled examples to score against, you have a measurement problem before you have a modeling problem. Fix measurement first; it is usually days, not quarters.

7. What this looks like in an engagement

The pattern from a typical brownfield client - a B2B distributor wanting order-volume forecasting, convinced they needed a year of data remediation first:

• Week 2: baseline gradient-boosted model on the ERP extract as-is. MAPE 31 percent - not shippable, but now there is a number.
• Week 3: error analysis. Two findings dominate: a unit-of-measure inconsistency in one product family (cases vs. units, 40 percent of volume error) and returns processed as negative orders with a 3-week lag.
• Weeks 4-6: fix those two defects only - a mapping table and a returns-handling rule. MAPE 19 percent. The planned "address standardization" and "vendor master dedup" workstreams from the original readiness plan turn out to affect the forecast not at all; they are deferred indefinitely.
• Week 8: v1 feeds the weekly S&OP meeting with a human sign-off step. The data-quality backlog now has four items, each with an expected MAPE gain and an owner. Total elapsed time to value: two months, on data that "wasn't ready."

The counterfactual is the part worth pricing: the readiness-first plan had those two load-bearing defects scheduled behind two quarters of work the model never needed.

8. Takeaways

• The readiness gate fails structurally: no finish line, blind prioritization, and it spends the sponsor's patience on invisible work.
• GIGO is true and contextual. Readiness exists per use case, not per lake - and BI-clean is not ML-ready.
• Sequence: baseline on today's data, error-analyze, fix the top defect, repeat. Every cleanup item carries an expected metric gain or it waits.
• Ship the guardrails with v1: boundary checks, a trusted eval set, provenance, and a human checkpoint sized to the risk.
• Respect the real exceptions - regulated decisions, biased labels, identity chaos, no eval data - and scope even those to the use case.
• Your data will not be perfect this year. It is almost certainly good enough to learn from this month - and the model will tell you what to clean.

References

1. The data readiness myth: why you're more prepared for AI than you think (Bosio)
2. What is AI-ready data? Why "clean" data isn't enough (Alation)
3. Why AI data quality is key to AI success (IBM)
4. Your data is more AI-ready than you think (Kamiwaza)
5. Garbage in, garbage out: data quality in the AI age (Tasman Analytics)
6. The hidden cost of poor data readiness for AI (Medium)
7. Good data isn't good enough: AI readiness starts with trust (Syniti)

Hero image: Luke Caunt on Unsplash.

We help teams find the signal in the data they already have. Explore our other insights or get in touch if you would like to talk it through.