The kickoff meeting for the invoice-audit pilot is going beautifully until someone asks about the data. The VP of operations waves the question away with the sentence that has buried more AI projects than any budget cut: "Data won't be a problem, we have tons of it." Week one, an analyst is asked to pull fifty real invoices to feed the vendor's sandbox. She finds that a fifth of the rate cards they would be checked against were quietly superseded by email amendments nobody entered, that three carriers still submit scanned faxes, and that the database she needs sits behind an access request another team filed four months ago and is still waiting on. Nothing about this company is unusual. In February 2025, Gartner put numbers on it: 63 percent of organizations either lack AI-ready data practices or are not sure they have them, and through 2026, organizations will abandon 60 percent of AI projects that are not supported by AI-ready data. This lesson takes those two numbers and makes them local: what "AI-ready data" actually means for one specific use case, and the five-question pre-check that predicts a project's fate in week one, before a single license is signed.

Two Numbers That Travel Together

Read the pair of Gartner findings the way you learned to read the MIT 95 percent in Chapter 1: precisely, asking what was measured. The first number is a confession. When organizations were asked whether they had AI-ready data practices, 63 percent said no or said they were not sure, and in data terms "not sure" is a polite no, because readiness you cannot demonstrate is readiness you do not have. The second number is the consequence arriving on schedule: Gartner predicts that through 2026, 60 percent of AI projects unsupported by AI-ready data will be abandoned. Not descoped, not delayed. Abandoned, which in the language of this program means a burned budget, a spent sponsor, and a named owner explaining a line-item deletion.

Notice what the prediction does not say. It does not say 60 percent of AI projects will fail. It says 60 percent of the projects without AI-ready data will be abandoned. That conditional is the entire opportunity. The abandonment is not a lottery; it is a queue, and the projects standing in it can be identified in advance by anyone willing to look at the actual inputs before looking at the demo. Most organizations run the sequence backwards: pick the vendor, schedule the pilot, and discover the data in week three, when the sandbox needs feeding and the feeding reveals the famine. The entire discipline of this lesson is moving the discovery from week three of a funded pilot to week one of an unfunded idea, where it costs a few days instead of a few hundred thousand dollars.

And notice one more thing about the 63 percent: it measures practices, not databases. Gartner did not audit anyone's tables. Organizations were reporting on their own ability to know whether their data was ready, and most could not answer. That is the real finding. The problem is not that enterprise data is messy; all enterprise data is messy. The problem is that most organizations have no routine instrument for checking whether the specific data a specific use case needs clears the bar that use case sets. This lesson hands you that instrument.

"Ready" Is Relative to the Use Case, Not the Enterprise

Here is the reframe that separates people who quote the 63 percent from people who act on it: data readiness is use-case-relative, not absolute. The phrase "AI-ready data" tempts everyone toward the wrong project, the enterprise-wide one: the master data program, the single source of truth, the three-year data lake migration that will make the company "ready for AI" in general. That project is a mirage with a budget. You do not need perfect enterprise data to run one AI use case any more than you need to repave every road in the county to drive to one address. You need the specific inputs of this one workflow, the fields this process actually consumes, to clear the bar that this use case sets. A company with a chaotic data estate can be fully ready for an invoice-audit use case whose three inputs happen to be clean, and a company with a celebrated data platform can be hopelessly unready for a forecasting use case whose one critical field was never captured.

The bar itself is set by the species of AI you chose, which is why Chapter 1.2's taxonomy matters here in one line: prediction needs labeled historical outcomes in volume, generation needs source material and exemplars rather than a large dataset, extraction needs document samples spanning the real variance, and agents need all of it plus permissions and logs. The same rate-card table can be abundantly sufficient for a generation use case (draft the dispute email) and catastrophically insufficient for a prediction use case (forecast which invoices will be disputed), because the second requires years of labeled outcomes the first never asks for. So the question is never "is our data good?" It is "are the named inputs of this workflow good enough for the species this proposal chose?" That question has six dimensions, and they are checkable in days.

Data readiness is a property of one use case's inputs measured against one species' bar, never a property of your company.

The Six Dimensions That Decide a Use Case's Fate

Six dimensions determine whether a specific use case's data clears its bar. Each one is a distinct way projects die, each has a distinct week-one test, and each prices a distinct remediation. Learn them as a set, because a use case must clear all six; five out of six is a delayed failure, not a partial success.

Three of these deserve a slow second look, because they are the ones week-one optimism hides best. Representativeness is the quiet killer of extraction and generation projects. Chapter 1.2 gave you the rule in five words: the worst 50, not the best 20. Any sample assembled to make a demo succeed will be drawn from the clean end of the distribution, and the gap between demo accuracy and production accuracy is exactly the variance the sample skipped. Rights is the dimension operations people check last because it never mattered before AI: the data was collected legitimately, sits in your systems legitimately, and has been used internally for years. But "use it to run our business" and "send it to a third-party model for automated processing" are different acts under privacy law, under many customer contracts, and across jurisdictions, and the difference surfaces late precisely because nobody thinks to ask early. Existence sounds too basic to fail until you meet its subtle form: the data everyone assumes exists because the humans doing the work clearly know it. The audit rules, the exception logic, the tribal thresholds live in practitioners' heads and nowhere else, which means the AI's most important input has an existence problem wearing an expertise costume.

The Three Week-One Illusions

Every unready use case is defended in week one by one of three sentences. Learn to hear them as alarms, not reassurances, because each one has a predictable translation.

"We have tons of data." Volume is the cheapest of the six dimensions and the only one this sentence addresses. What it usually describes is a data lake of unlabeled exhaust: years of logs, dumps, and attachments that were stored because storage is cheap, not captured because anyone designed them for reuse. Tons of data with no labels, no consistent fields, and no known lineage is not an asset for your use case; it is a landfill with a dashboard. The test is never "how much do we have?" It is "can you show me fifty rows of the specific inputs this workflow consumes, and are they complete?" Watch how fast tons becomes teaspoons.

"It's all in the system." Translation: the records exist, and 40 percent of the decisive information sits inside free-text note fields where a human typed what actually happened. "In the system" and "in structured, extractable fields" are separated by months of remediation. The order table is pristine; the reason the order was expedited, the concession the account manager made, the exception the warehouse applied all live in a comments box in eleven different personal shorthands. For a human reader that is fine. For a use case that needs those facts as inputs, that is an existence-and-quality problem announcing itself politely.

"IT says two weeks." The access estimate is the most reliably optimistic number in the building, because the person giving it is quoting the happy path: the ticket, the approval, the export. The actual path runs through a security review, a data-owner sign-off from a team with its own backlog, a compliance question nobody can answer quickly, and a export format that turns out to need rework. The test is empirical, not rhetorical: find the last comparable access request and ask how long it actually took, ticket opened to data delivered. If the last one took a quarter, your estimate is a quarter, whatever the SLA document says. Chapter 2's lesson on demo-to-production death taught you to distrust the demo's staging; this is the same discipline pointed at the calendar.

The Artifact: The Five-Question Data Pre-Check

Here is this lesson's named artifact, the instrument that converts the six dimensions into a week-one routine. It costs two to four working days, requires no vendor, no license, and no committee, and it prices the gap between the use case you imagined and the one your data will actually support. Run it before any vendor demo is scheduled, and record the answers in writing, because the written answers become the remediation backlog and, later, the receipt that you checked.

Question 1: Name the exact inputs this workflow consumes

Not "our logistics data." The named inputs: which documents, which tables, which fields, at what refresh frequency, from which systems. If the process map from your baseline work exists, this is a twenty-minute exercise; if nobody can produce the list, that fact is itself the finding, because a use case whose inputs cannot be named cannot be checked, priced, or piloted. A failing answer looks like: a category noun ("customer data," "the documents") instead of a list. What it prices: a half-day workshop with the people who do the work today, walking one real transaction end to end and writing down everything it touched. Cheap, and everything downstream depends on it.

Question 2: Pull 50 real examples, including the ugly ones. What fraction is complete and current?

Fifty, pulled by someone with no incentive to flatter the sample: a random week, not a curated folder, and deliberately including the cases the team dreads. Then count, field by field: what fraction is complete, what fraction is current, what fraction is in a format a machine can consume. This single question tests quality, representativeness, and the subtle form of existence at once, and it produces the lesson's most valuable number: the honest defect rate of your inputs. A failing answer looks like: "we looked at a few and they seemed fine," or a sample assembled by the person championing the pilot. What it prices: the cleanup. If 20 percent of a critical field is stale, you now know the remediation is a refresh project with a measurable scope, and you can cost it in analyst-weeks instead of discovering it as a production accuracy collapse.

Question 3: Who grants access, and how long did the last such request actually take?

Name the owning team for each input, the approval chain, and then anchor the estimate in evidence: the most recent comparable request, elapsed time from ticket to delivered data. Ask for the SLA and the actuals, and believe the actuals. A failing answer looks like: "IT says two weeks" with no reference case, or an owner who turns out to be a vendor with an export fee and a queue. What it prices: the calendar. If access historically takes twelve weeks, the pre-check just moved your pilot start date twelve weeks, for free, in week one, instead of letting a funded team burn that quarter idling.

Question 4: What law, contract, or policy touches this data?

One hour with legal or compliance, three specific prompts: does any of this include personal data and in which jurisdictions; do any customer or supplier contracts restrict processing, sharing, or third parties; does any internal policy or regulator care about this category? You are not asking for a legal opinion on the whole project; you are asking which inputs carry conditions. A failing answer looks like: "nobody's ever complained," which means nobody has ever asked. What it prices: either a scope cut (exclude the restricted slice and size what remains) or a remediation with a real timeline (contract amendments, consent, anonymization), both of which are radically cheaper in week one than in month four, when the rights problem otherwise surfaces as an unwind order.

Question 5: What is missing that the AI is supposed to produce anyway?

The strangest and most predictive question. Every AI use case has an implied teacher: the examples, rules, or outcomes the system is supposed to learn from or apply. Ask where that teacher lives. If the pilot will "apply our audit rules" and the audit rules exist only in one analyst's judgment, or "learn from past decisions" that were never recorded with their reasons, the use case is asking the AI to produce its own missing input. A failing answer looks like: "Marta knows all of that," delivered as reassurance. What it prices: a knowledge-capture project, workshops that turn tribal judgment into a written decision table, which is unglamorous, weeks-long, and the single highest-leverage remediation on this list, because it is also the only insurance against Marta's resignation.

Score it simply: each question earns a pass (evidenced, written answer that clears the bar), a flag (clears the bar after a priced remediation), or a fail (no credible path at reasonable cost). Any fail stops the use case in its current form. Flags do not stop anything; they become a priced, scheduled data-readiness sprint that runs before the vendor demo, not after the license. That sequencing, remediation before commitment, is the whole trick, and the worked example shows what it looks like with money attached.

Worked Example: Bramwell Logistics Runs the Pre-Check

Bramwell Logistics is a fictional 1,100-person freight and warehousing company, a composite built to carry realistic numbers. Bramwell spends about $38 million a year on outside carriers across 140 of them, receiving roughly 5,200 carrier invoices a month. Today a two-person team manually audits about 7 percent of invoices against rate cards and contracts; sampling suggests an overbilling rate around 1.4 percent of spend, roughly $530,000 a year leaking out through misapplied rates, duplicate accessorial charges, and fuel-surcharge errors. A vendor proposes an AI-assisted audit: extraction plus rules, 100 percent invoice coverage, $95,000 a year, with a further $35,000 integration estimate. The ROI slide writes itself. The operations lead, recently through this program, refuses to schedule the demo until the pre-check is done. It takes four working days.

Question 1, inputs: pass. Three inputs named in a half-day workshop: carrier invoices (PDF and EDI), the rate-card database, and 140 carrier contracts. Written down, with owning systems.

Question 2, the 50-sample: flag, twice. A random week's pull of 50 invoices and their matching rate cards shows 22 percent of rate cards outdated: superseded by email-negotiated amendments that never made it into the database, meaning the "current rate" the AI would audit against is wrong more than a fifth of the time. And three carriers, together 11 percent of invoice volume, submit scanned faxes that no extraction step will read reliably. Priced remediation: a rate-card refresh (one pricing analyst, half-time, three weeks, about $9,000 of loaded cost) and carrier outreach that moves two of the three fax carriers to portal PDF, routing the holdout's 3 percent of volume to the existing manual queue.

Question 3, access: flag. The rate database is owned by the pricing operations team, which quotes a six-week SLA for a recurring export feed. The last comparable request, pulled from the ticket system, actually took thirteen weeks. Priced remediation: file the request in week one so the real clock runs during the sprint instead of during a funded pilot.

Question 4, rights: flag, nearly a fail. Legal's one-hour review finds two customer contracts that prohibit third-party processing of shipment data; those customers are 18 percent of volume. Options priced: amend the contracts (legal estimates eight weeks, uncertain outcome) or scope them out and audit the remaining 82 percent, which still protects roughly $434,000 of the annual leakage. Bramwell scopes them out and starts the amendment conversation in parallel.

Question 5, the missing input: the big one. The vendor's tool applies "your audit rules." Bramwell's audit rules, the accessorial-charge exceptions, the surcharge interactions, the carrier-specific tolerances, exist in exactly one place: the head of the senior analyst who built the manual audit. Nothing is written down. Priced remediation: a four-week knowledge-capture effort, about 60 hours of the analyst's time plus a process analyst, producing a written decision table of 61 rules, roughly $14,000 of loaded cost, and incidentally the first time Bramwell has ever been insured against that analyst leaving.

The pre-check verdict: one pass, four flags, zero fails, and a remediation plan that runs as a ten-week data-readiness sprint costing about $40,000 of internal time, after which the vendor demo happens against real, representative, rights-cleared data with written rules. Now run the counterfactual, the timeline Bramwell did not buy. Sign in week one: $95,000 license, $35,000 integration. Month two, the tool flags nearly 40 percent of invoices as exceptions, because it is faithfully auditing against rate cards that are 22 percent stale; the two analysts drown in false positives and start ignoring the queue. Month four, legal discovers the two contracts and forces an emergency descope. Month six, the exception backlog and the credibility damage put the pilot "under review," which Chapter 1 taught you is where pilots go to become zombies. Cost of the counterfactual: roughly $180,000 in direct spend, nine months, and the next AI proposal at Bramwell greeted with folded arms. The pre-check bought the same destination, a working audit on clean data, for $40,000 and ten weeks, by doing the discovery before the commitment instead of after. That is what it means to be in Gartner's 40 percent instead of the 60: not better luck, earlier questions.

What to Do Monday Morning

The pre-check is a week-one instrument, and some week one is always available: a live proposal, a running pilot, or the use case your own team keeps discussing.

1. Pick one AI use case with a name and a sponsor, ideally one currently heading toward a vendor demo. The pre-check works best exactly where the enthusiasm is highest.
2. Run Question 1 as a half-day workshop with the people who do the work today: one real transaction, end to end, every input written down with its source system and owner. Refuse category nouns.
3. Pull the 50-sample yourself or assign it to a neutral party, random week, ugly cases included, and count completeness and currency field by field. Publish the defect rate as a number, not an adjective.
4. Anchor the access estimate in one historical fact: find the last comparable data request in the ticket system and record ticket-to-delivery elapsed time. Put that number, not the SLA, in the plan.
5. Book one hour with legal or compliance and ask the three rights prompts: personal data and jurisdictions, contract restrictions, applicable policy. Write down the answer even if it is "nothing applies."
6. Ask Question 5 out loud in the next steering discussion: "what is missing that the AI is supposed to produce anyway?" Then score the whole pre-check pass/flag/fail, price the flags, and present the remediation sprint as the pilot's real start date.

Key Takeaways

• Quote Gartner's pair precisely: 63 percent of organizations lack or are unsure of AI-ready data practices, and through 2026, 60 percent of AI projects without AI-ready data will be abandoned; the second number is a conditional, which makes it a queue you can exit in advance.
• Treat data readiness as use-case-relative, never absolute: the question is whether the named inputs of one workflow clear the bar of the chosen species, not whether the enterprise has achieved data nirvana.
• Check all six dimensions, because five of six is a delayed failure: existence, accessibility, quality, representativeness, volume and history, and rights each kill projects in a distinct way on a distinct schedule.
• Translate the three week-one illusions on sight: "tons of data" usually means unlabeled exhaust, "it's all in the system" usually means free-text notes, and "IT says two weeks" usually means the last comparable request took a quarter.
• Run the Five-Question Data Pre-Check before any vendor demo: name the exact inputs, pull 50 real examples including the ugly ones, anchor access in the last request's actual elapsed time, ask what law or contract touches the data, and ask what is missing that the AI is supposed to produce anyway.
• Score pass/flag/fail and price every flag: flags become a scheduled data-readiness sprint that runs before commitment, which is how Bramwell traded a $180,000, nine-month zombie for a $40,000, ten-week sprint and a pilot that starts on clean data.
• Hunt the missing-input problem hardest: rules and judgment that live in one expert's head are an existence failure disguised as expertise, and capturing them is both the pilot's prerequisite and the organization's insurance.
• Carry this forward: L2's Chapter 3 turns this manual pre-check into full AI-assisted data audits, but the habit starts here, with fifty ugly examples and five questions asked in week one.