Is Your Data Ready for AI? A Use-Case Data Readiness Assessment

Most AI programs find their data problem after the budget is approved. The pilot runs on a curated extract, the demo impresses, and the production build then meets the real estate: fields defined three ways, documents nobody owns, permissions that do not survive the copy, and no record of what a correct answer looks like. Gartner predicts that through 2026 organizations will abandon 60% of AI projects unsupported by AI-ready data.¹ The cheap moment to find the gap is before the money is committed, with a test that names the use case.

• 60%of AI projects unsupported by AI-ready data that Gartner expects organizations to abandon through 2026¹
• 63%of organizations lack, or are unsure they have, the right data management practices for AI (Gartner survey, Q3 2024)¹
• 26%of chief data officers are confident their data can support new AI-enabled revenue streams (IBM, 2025)²

What AI-ready data means

AI-ready data is data fit for one specific AI use case: it represents the situations the system will meet, the system can reach it under the right permissions, and the business may lawfully use it for that purpose. Gartner's definition makes the same point: the data must be representative of the use case, including the patterns, errors, outliers and unexpected cases needed to train or run the model.¹ Readiness belongs to a pair, one dataset and one decision, and no single score for a data estate can stand in for it.

In IBM's 2025 survey of 1,700 senior data leaders, 81% said their data strategy is integrated with the technology roadmap, and only 26% were confident their data could support new AI-enabled revenue streams.² Estate maturity scores cannot close that gap, because they rate a whole platform and say nothing about whether the claims-triage model in next year's plan will work. A use-case assessment tests only the data that system will read and write, and ends in one of three decisions: build, fix first, or choose a use case the data already supports.

Why data readiness is assessed per use case

Data readiness is assessed per use case because the same dataset routinely passes for one AI system and fails for another. A customer table refreshed nightly is fresh enough for a weekly churn model and stale for an agent answering a customer who changed plans an hour ago. A claims archive suits a reserving model and fails a triage assistant that needs the adjuster notes, which sit in scanned PDFs. A call-recording archive can be complete and still off-limits for training, because callers were told the recordings were for quality purposes.

Gartner's first recommendation in its February 2025 release is to align data sources with specific AI use cases.¹ In July 2024 it predicted that at least 30% of generative AI projects would be abandoned after proof of concept by the end of 2025, with poor data quality among four causes.³ Both are forecasts, and the 60% covers only projects without AI-ready data, so neither is a measured failure rate. They describe one mechanism: projects approved on the strength of a demo, with the data question left for the build.

The eight tests of AI data readiness

The eight tests are coverage, quality and consistency, freshness, lineage and ownership, access and permissions, labeled outcomes, the condition of unstructured content, and legal basis and retention. Run each one against the data a single use case will read and write, record the result as pass, fix or fail, and name the owner of every fix.

The quality test has a standard behind it: ISO/IEC 5259-2, published in 2024, specifies a data quality model, measures and reporting guidance for analytics and machine learning.⁴ IBM's 2025 study names the same barriers the table tests: data accessibility, completeness, integrity, accuracy and consistency.²

Coverage: compare the data with live traffic

Pilot data is usually the happy path, exported by someone who knew which records were clean. The coverage test sets the historical data beside a sample of recent production traffic and counts the rare cases: the disputed invoice, the claim with three claimants, the order placed in one currency and refunded in another. Where the system will serve a segment with no examples, it will be guessing, and the assessment should say so.

Labeled outcomes: build the answer key first

A labeled outcome is a historical case with a known-correct answer: the invoice coded to the right ledger, the ticket routed to the right team, the clause a lawyer marked as non-standard. Without them, nobody can show the system works, and every prompt or model change becomes an argument. In the systems we build, a graded set of a few hundred real cases per decision type, weighted toward the hard ones, is the floor for a first release, and we measure how often two reviewers agree before trusting the labels. The set then becomes the regression suite described in our guide to LLM and AI agent evaluation.

Legal basis: the purpose travels with the data

Under the GDPR, personal data is collected for specified purposes, may not be processed further in a way incompatible with them, and is kept in identifiable form no longer than those purposes require.⁸ A new AI use case is a new purpose, so the test checks what people were told at collection, what contracts allow and what the retention schedule says. The European Data Protection Board's December 2024 opinion accepts legitimate interest as a possible legal basis for developing and deploying AI models, subject to a necessity and balancing assessment, and warns that developing a model with unlawfully processed personal data can affect the lawfulness of deploying it unless the model has been anonymized.⁹

How to prepare unstructured documents for AI

To prepare unstructured documents for AI, make the current version of each one identifiable, make its text and tables extract reliably, and carry the access rights of its source system into the index. This is where most enterprises are weakest: in IBM's 2025 study, 26% of chief data officers were confident their organization could use unstructured data in a way that delivers business value.²

The defects are specific. A policy library holds two versions of the same procedure with nothing marking which one applies, so retrieval returns both and the model blends them. Scanned contracts extract with their tables flattened. The copy in the index has lost the access list of the original. OWASP files these failures under vector and embedding weaknesses (content exposed through weak access controls, leakage between users of a shared store, conflicts between sources that contradict each other) and recommends permission-aware vector stores with strict partitioning.⁵

Document preparation is a pipeline that reruns whenever a source changes:

• Index only the authoritative repository for each document type.
• Tag each document with an owner, an effective date, a status (current, superseded or draft) and its business scope.
• Test extraction on the hardest formats first: scans, tables and forms.
• Carry the source system's permissions into the index and apply them at query time.
• Remove superseded and duplicate documents from the index when the source changes.

Our guide to enterprise RAG in production covers the retrieval side, from chunking to permission filters.

Data readiness for AI agents

Data is ready for an AI agent when the agent can act through governed APIs, each fact it changes has one agreed system of record, every write is idempotent, and changes reach it as events. A read-only assistant can tolerate a stale copy. An agent that updates a customer record or issues a credit writes into the systems that run the business, and that is where its readiness is tested. IBM found that 80% of chief data officers have started developing datasets to train AI agents, and 79% say they are early in defining how to scale and govern them.²

• An API for every action The agent acts through the interfaces your applications use, under a scoped service identity, with its arguments validated. Screen automation breaks when a layout changes. The Model Context Protocol standardizes the exposure: a server offers resources, which are context and data, and tools, which are functions the model may execute.¹⁰
• One system of record per fact When a customer's address lives in Salesforce, SAP and the billing system, write down which one the agent reads and which one it writes, and let the others follow by synchronization. Otherwise the agent corrects one system and a nightly job overwrites the change from another.
• Idempotent writes Agents retry after timeouts. A key derived from the intent makes a repeated call to issue the same credit run once.
• Events as well as tables Change data capture or business events (order shipped, claim filed, payment failed) let the agent act when something happens instead of polling a table, and each event joins the audit trail.

What data RAG, machine learning and AI agents each need

Retrieval-augmented generation needs current, permissioned documents; a predictive model needs labeled history; an agent needs governed write access to systems of record; and all three need labeled outcomes to be evaluated against.

The minimum viable data foundation

The minimum viable data foundation is the smallest set of pipelines, contracts and controls that lets the first use case pass all eight tests, built so the second use case reuses it. Each of its five parts depends on the one before.

The foundation leaves out an enterprise-wide catalog, a platform migration and master data for every domain. Those are sound programs, and none has to finish before the first use case passes. The exception is a shared blocker: if the use cases the business most wants all fail on the same customer master or the same missing event feed, fix that first, or each use case pays for its own workaround. Our data engineering work is scoped this way: what the first use case needs, built in your environment so the next one reuses it.

What to fix first when the data is not ready

Fix first whatever makes the use case unlawful or unreachable, then whatever makes its results unmeasurable, then whatever makes them wrong. The order follows dependency: each fix is wasted while an earlier test still fails.

1. 1Legal basis and access No cleaning rescues data you may not use or cannot reach, and these fixes take longest to agree, so they start first.
2. 2Labeled outcomes Without a graded set, you cannot tell whether any later fix helped.
3. 3Coverage Missing segments cannot be cleaned into existence. Collect examples, narrow the scope, or route the rest to people.
4. 4Quality and freshness on critical fields Clean only the fields the use case reads, and check each fix against the graded set.
5. 5Lineage and ownership Assign owners and record lineage for what you fixed, so the fixes hold after the project team moves on.

Two decision rules keep the work proportionate. Clean only the columns the use case reads, because quality work elsewhere does not change its results. And if the fix that unblocks a use case is larger than the value it will return, pick another use case and put the fix on the platform plan.

Data governance that does not block AI delivery

Governance keeps pace with AI delivery when each dataset has a named owner and a data contract the pipeline checks automatically, so approval becomes a property of the data instead of a meeting before each project. The owner answers for the dataset's defects and approves new uses of it. A governance council sets policy and stays out of the release path.

The Open Data Contract Standard, from the Bitol project at the Linux Foundation, describes a dataset together with its expected behavior: the quality rules it must obey, its service levels, its stakeholders and their roles.¹¹ OpenLineage defines a standard API for capturing lineage events about datasets, jobs and runs.¹² With both in place, the evidence for tests 2, 3 and 4 comes from the pipeline, and nobody assembles it by hand for an audit.

For systems the EU AI Act classes as high-risk, this evidence is a legal requirement. Article 10 requires training, validation and testing data to be relevant, sufficiently representative and, to the best extent possible, free of errors and complete in view of the intended purpose, and subject to governance practices covering data origin, preparation and the examination of possible bias.⁶ Regulation (EU) 2026/1744 moved those obligations to December 2, 2027 for stand-alone high-risk systems and to August 2, 2028 for AI inside regulated products.⁷ Kept as records, the eight tests produce most of what Article 10 asks for.

The assessment is small beside the build it protects. It replaces a vague question about the data estate with eight answers about one decision, each with an owner.