The Data-Readiness Myth: Why "Fix the Data First" Is the Most Expensive Sentence in Enterprise AI
Everyone's data is a mess. The automation is processing it anyway. So what, exactly, has to be fixed first?
In 2014, Amazon set a small team to work on a system that would read résumés and rate candidates from one to five stars — the way shoppers rate products. It was trained on ten years of applications to the company. Most of them had come from men, because that's who had applied. By 2015 the team noticed the model had drawn its own conclusion: men were preferable. It penalised résumés containing the word "women's" — as in "women's chess club captain" — and downgraded graduates of two all-women's colleges. Engineers stripped those signals out. They couldn't be sure it wasn't finding others. The project was shut down in 2017; Amazon said recruiters never used its rankings to evaluate candidates.
Nobody would call that dirty data. Every résumé was real, complete and correctly stored. The data simply wasn't representative of the job the model was asked to do — and the model believed it anyway.
That story, and a handful like it, is why every consultancy, assessment vendor and maturity model now tells you the same thing before you automate anything: fix the data first.
Here's what that sentence costs. In the deals we see, it delays the first working process by a year or more. And when the data programme ends, the data still isn't fixed — because "the data" was never one thing. It was two, wearing the same word, and nobody said which.
The readiness industry took the right lesson from the wrong kind of AI. Gartner, of all people, says which kind: in the release predicting that, through 2026, 60% of AI projects that lack AI-ready data will be abandoned, its analyst defines the term as data representative of the specific use case. Amazon's résumés failed that definition word for word. Your invoices don't — and that distinction is the whole argument of this piece.
First, understand what "fix the data" actually means
In any back office, "the data" means two things with almost nothing in common.
The first is data your systems look up and believe: the vendor master, customer IDs, the chart of accounts, tax rates. A payment run doesn't wonder whether a vendor record is a duplicate. It pays it.
The second is data somebody has to read and check: invoices in a dozen layouts, a scanned bill of lading, a KYC pack with a handwritten field, a supplier spreadsheet whose columns move every quarter. Nobody believes these on sight. Someone extracts, checks, and reconciles them against the first kind.
The first kind has to be right before you start. The second is what automation is built to process — and what gets cleaner by being processed. Two kinds of data, one word: that's the whole problem with "fix the data first."
So let's name the line: the Readiness Line
A duplicate vendor record is above the line — the system will pay it twice. A rotated invoice scan is below it — the system will read it, check it, and flag what doesn't match.
Will the system look this data up and believe it — or read it and check it?Look-up-and-believe is above the line. Read-and-check is below it.
To be fair: sometimes readiness is real
This isn't an argument that data quality doesn't matter. Above the line it matters completely, and Amazon isn't the only proof.
IBM's Watson for Oncology, STAT showed in 2018 from IBM's own internal decks, had been trained on a handful of synthetic, hypothetical cases rather than real patient records, and had produced treatment recommendations the decks themselves called "unsafe and incorrect." No patient was harmed. The pattern is the one from the top of this piece: a system asked to believe data it never really had.
Zillow is the half-billion-dollar version, with a detail that matters here: it had the check, and switched it off. Its pricing experts used to adjust the algorithm's home valuations. In early 2021, under an internal push to catch up with Opendoor that staff called Project Ketchup, the company began using the Zestimate directly as its cash offer, stopped its pricing experts from modifying it, and asked them to stop questioning it — then, to win more homes, raised bids thousands of dollars above the algorithm's price, a practice it called "offer calibration." The human step between the model and the money was removed to hit volume targets. On 2 November 2021 Zillow shut Zillow Offers down: a $304 million write-down, another $240 to $265 million expected, a quarter of the workforce gone.
So here is the rule, without hedging: wherever a system's output will be believed without a check — a model trained on the data, a lookup taken as truth, a forecast acted on directly — readiness is a prerequisite. Fix the data first, or you automate your errors at scale. This is not a vendor's convenient exception. It is also not what most enterprise automation is: invoice processing, claims intake, customs filings, onboarding packs read data and check it, and for reading, the rule flips.
The first 90 days, as they actually go
We looked for an independently reported example of this pattern and found only vendor case studies. So what follows is ours, and we'll say so: the shape of the first ninety days across our document deployments — supplier invoices for manufacturers, customs packs for brokers, batch documentation for pharma. The numbers differ by customer; the pattern doesn't.
The intake looks the same everywhere: documents arriving by email, portal and scanner, and roughly a third of them the ugly kind — pages scanned sideways or skewed, a stamp across the total, three layouts from the same supplier, checkboxes flattened into unreadable marks, a purchase-order number handwritten in the margin. The plan before we arrive is usually a data project measured in months: standardise templates, digitise the archive, then automate.
The workflow goes live on the documents as they are. Each one is classified, extracted, then validated against the customer's own master data — and where something doesn't match, it goes to a person with the reason attached. Supplier name matches two vendor records. Total on page 1 disagrees with line items on page 3. PO number not found. In the first week the queue is long. That is the point: every exception is a data error that was flowing through the old process unseen.
By day 90 three things have changed, and none is a data project. The exception rate has fallen as the pipeline learned each supplier's layouts. Duplicate vendor records have surfaced — found by documents that matched two of them, not by a cleansing exercise. And fields the old process never captured — payment terms, tax by line — are structured, searchable data.
Nobody ran a data project. The data got better because the work got done.
The readiness list, sorted by the line
Put every data problem currently blocking your automation to the test above. Buyers tell us the same five, almost word for word. Two are above the line; three aren't. (Governance comes up in the same breath, but it's policy, not data — it gets its own piece.) Here's what happens to each when you stop treating it as a prerequisite.
Read it down the second column. Two of the five sit above the line — both data a system will look up and believe — and even those shrink when scoped to one process rather than the enterprise. Three are things the automation does as it goes, only for the documents that matter, rather than for the archive nobody will open. "Garbage in, garbage out" is true above the line; below it, the workflow is the filter.
The readiness list isn't wrong. It's just mostly a description of what the automation would have done anyway.
Three objections
"Our consultants say readiness first."
Ask them which kind of AI they mean. Readiness for a forecasting model and for invoice processing are different projects with different price tags. Gartner's release says both things: data with issues isn't ready for AI, and "ready" means representative of the use case. Those aren't in tension — the first is the rule above the line, the second is how you scope it. If the answer is "all of it, before anything," you're being sold the prerequisite, not the outcome.
"We tried OCR and it failed on our documents."
It probably did. OCR was never the hard part. Rotated pages, flattened checkboxes and stamps over totals break OCR-only tools, and those are everyday inputs, not edge cases. What failed was a tool that could read characters but couldn't read a document.
"A vendor would say this."
Yes. So don't take it on faith. Bring your five worst documents to the demo — ours included — and watch what happens in the first ten minutes. Which brings us to what we actually built.
How AutomatR handles below-the-line data
We built our document pipelines for the ugly third, because that's where the work and the errors live.
Concretely, "learns the layouts" means this. Each page is classified by type before extraction, so a multi-page pack is read as an invoice, a delivery note and a terms sheet rather than one blob. Fields are found by position and label, not a fixed template, so a new layout is a harder page, not a failed one. Corrections in the exception queue feed back into extraction for that supplier — but what the pipeline learns never escapes the check. A document is auto-approved only when its fields clear a confidence threshold, reconcile arithmetically, and match the master data exactly once; anything else goes to the queue with the reason attached. Learning changes how fast a document reaches that check. It never bypasses it. The number that tells you whether this works is the straight-through rate — documents that pass without a human touch — and we'd rather show it on your documents than quote someone else's.
Today our pipelines process customs, GST and pharmaceutical documentation in production for enterprise customers in India — the categories where scans, stamps and multi-page packs are the norm, not the exception. Where that data goes once it's read — and who controls it — is a separate question, and we've answered it separately in The Four Exits.
The Ugly-Document Test
Take these five to any vendor demo, including ours.
- 01The rotated oneA scan turned 90°, with a stamp over the total.
- 02The inconsistent oneThree invoices from one supplier in three different layouts.
- 03The handwritten oneA form with checkboxes and one field filled in by hand.
- 04The buried oneA 40-page pack where the data you need is on pages 3 and 37.
- 05The spreadsheet nobody trustsThe supplier file whose columns move every quarter.
Watch the first ten minutes. If the vendor asks to "clean these up first," you've learned which side of the Readiness Line they live on. If the documents go through and the exceptions come back with reasons, you've learned something too.
To run it against our stack, send the five through automatr.tech/contact; we'll process them next week — no cleaning first, no sample set of ours.
Of the data problems currently delaying your automation, how many are above the line — and how many would the automation itself have fixed by now?
Further reading: going deeper on data readiness
- →The Four Exits — where the data goes once the agent can read it: control, not readinessautomatr.tech/blog/four-exits-agent-data-leaks
- →AI Agents Have a Meter Runningautomatr.tech/blog/ai-agent-token-economics
- →Gartner, "Lack of AI-Ready Data Puts AI Projects at Risk"gartner.com/en/newsroom
- →STAT, "IBM's Watson recommended 'unsafe and incorrect' cancer treatments"statnews.com
- →Deloitte, "AI Agents are Only the Beginning" (Aug 2026)deloitte.com/us/en/about/press-room
- →Journal of Information Systems Education, "Exploring the Role of AI in the Closure of Zillow Offers" (2024)jise.org
- →Reuters, "Amazon scraps secret AI recruiting tool that showed bias against women" (Oct 2018)reuters.com
