How to prepare your data for AI: a step-by-step data readiness guide

S&P Global Market Intelligence's 2025 survey of 1,006 IT and business professionals in North America and Europe found that the share of companies abandoning most of their AI initiatives had jumped from 17% to 42% year over year (S&P Global Market Intelligence, 2025). Gartner predicts that through 2026 organizations will abandon 60% of AI projects unsupported by AI-ready data (Gartner).

Preparing data for AI means identifying exactly what a given AI use case depends on, then making that data accurate, governed, accessible, and continuously monitored — not cleaning an entire enterprise data estate before you start. This guide walks through the process in seven steps, covers what changes for generative AI and RAG systems, and ends with a short self-assessment to find your biggest gap.

What "AI-ready" data actually means

Gartner defines AI-ready data as data that is representative of the use case — including its patterns, outliers, and errors — and prepared through three ongoing practices: align, qualify, and govern it against metadata (Gartner). The detail readers often miss: there is no single "AI-ready" state that applies to an entire company. A business can have production-ready customer-support data, poorly governed HR records, and inaccessible legacy manufacturing data at the same time. Readiness is a property of a specific use case, not a company-wide checkbox.

The important distinction is purpose, not a universal rule about analytics. Some analytics pipelines remove or down-weight outliers when they are errors or would distort a specific summary. AI training data must remain representative of production, which can require preserving valid rare cases that a fraud, defect, or risk model needs to detect.

McKinsey frames the goal as building a governed, traceable, and reusable foundation that connects structured and unstructured data (McKinsey, 2026). That foundation shows up in the numbers: only 7% of companies report having fully scaled AI, and more than two-thirds of high-performing companies name data as their primary obstacle.

Why AI projects fail without it

Poor data readiness is a leading fixable technical cause of AI project failure — though it isn't the only one. RAND's 2024 report cited earlier estimates that more than 80% of AI projects fail, roughly twice the failure rate of non-AI IT projects. RAND did not measure that rate itself; it interviewed 65 experienced data scientists and engineers to investigate why projects fail (RAND Corporation, 2024). Those interviews identified misunderstanding or miscommunicating the problem as the leading root cause, ahead of inadequate data. The practical sequence is therefore: get the use case right, then prepare the data it needs.

The scale of the problem keeps growing. Gartner reported in January 2026 that by the end of 2025 at least 50% of generative AI projects had been abandoned after proof of concept because of poor data quality, inadequate risk controls, escalating costs, or unclear business value (Gartner, 2026). A separate Gartner survey of data management leaders found that 63% of organizations either lacked the data management practices AI requires or were unsure whether they had them (Gartner, 2025). And only 29% of technology leaders strongly agree their enterprise data meets the quality, accessibility, and security bar generative AI needs (IBM Institute for Business Value, 2024).

None of this means data has to be perfect. McKinsey's practical framing is to define what "good enough" means for each use case, based on its business need and risk profile — not to chase a universal standard of clean.

The 7-step data readiness process

The following sequence synthesizes recommendations from Gartner, McKinsey, and Google Cloud into a repeatable process, grounded in the lifecycle approach of ISO/IEC 5259-1:2024 and the risk-management structure of the NIST AI Risk Management Framework. Each step below answers its question in one sentence, then explains how to execute it.

1. 01

   Define the AI use case first

   Start with the decision, prediction, search, or workflow the AI will support — not with a data lake. You can't know which data is critical until you know what the AI needs to do, who owns the business outcome, and which errors are acceptable. Skipping this step is the most common cause of scope creep: teams end up trying to clean "all the data" instead of the specific fields one AI workflow actually depends on.

2. 02

   Inventory and classify your data

   Map what data exists, where it lives, and who owns it — across structured systems and unstructured sources like documents, emails, and call transcripts. Include an audit of "dark data" that the organization stores but no longer uses for analytics or decisions, then identify redundant, obsolete, or trivial records within it. Classify each source by sensitivity and confirm the purpose for which the AI may use it. This step usually surfaces legacy systems the project didn't expect to need; a governed extraction layer can make legacy data AI-ready without migrating the source system.

3. 03

   Consolidate and break down silos

   Centralize the data you've inventoried into a governed repository and automate its ingestion — manual exports go stale within weeks and quietly reintroduce the silos you just mapped. Profile and validate data where it already lives whenever practical, using connectors rather than copying entire tables. Moving terabytes of data solely to calculate quality statistics adds cost and delay without adding readiness.

4. 04

   Clean and validate data quality

   Run each critical dataset against seven practical quality dimensions. The first six are standard database hygiene; the seventh is what AI adds — a dataset can pass every null-check and still be unrepresentative of what the model will see in production. Convert these checks into executable rules (SQL, dbt tests, or a tool like Great Expectations) rather than one-time manual reviews, and assign a clear owner to every rule that fails.

   Completeness Accuracy Validity Consistency Uniqueness Freshness Representativeness
5. 05

   Structure, label, and add metadata

   Add the context an AI system can't infer on its own: consistent schemas, a shared taxonomy, and metadata recording what each field means, who owns it, and where it came from. For unstructured content, extract text and tables, then chunk documents with their source, timestamp, and permissions attached — not just the raw text. Metadata is no longer optional documentation; both people and AI agents need it at run time to interpret data correctly instead of guessing from a raw column name.

6. 06

   Lock down governance, security, and access

   Apply role-based permissions, classify personal and sensitive data, and confirm the intended use is legally permitted before the AI system goes live — not after a prototype has already copied confidential data somewhere it shouldn't be. Establish a single source of truth for each critical entity (customer, product, transaction) so the model isn't reconciling conflicting definitions across systems. For high-risk use cases, this is also where EU AI Act Article 10 obligations apply.

7. 07

   Validate against the real workflow, then monitor continuously

   Test the prepared data against the actual use case, not in isolation, and treat readiness as an operating capability rather than a one-time project. Once data enters production, schema changes, source delays, distribution shifts, and access-policy changes can degrade an AI system without anyone touching the model. Automated validation, dataset versioning, lineage that traces outputs back to source, and a named incident owner turn readiness from a launch gate into something you maintain.

What changes for RAG and AI agents

Predictive machine learning and generative AI diverge after this shared foundation. Predictive models need labeled training data, point-in-time datasets that avoid leaking future information into historical examples, and sometimes a feature store for reusable structured features — Feast is one widely used open-source implementation of that pattern. None of this is universal; a feature store adds real infrastructure for models retrained on structured data, and little value for a system that mostly retrieves documents.

RAG and agent systems need something different: document quality, chunking, provenance, and permissions enforced before the model ever sees the content. Access control has to run in the retrieval layer, not as an afterthought — a system that can retrieve a document doesn't mean it should surface it to every user. Preserve each chunk's source, timestamp, and owner so retrieved answers can be traced and cited rather than presented as unattributed fact.

A lightweight semantic layer or knowledge graph helps too: it defines what business terms actually mean so an AI agent doesn't guess from a raw column name. Evaluate retrieval quality the same way you'd evaluate a model — with a fixed set of test questions and a minimum accuracy threshold — before it reaches production, and re-run that evaluation as the underlying documents change.

A quick data-readiness self-assessment

Score each of the six pillars below from 1 (not started) to 5 (fully operational) for the specific use case you're evaluating — not for the company as a whole:

1. Data quality and reliability — is critical data accurate, complete, and fresh enough for this use case?
2. Governance, security, and privacy — is the intended use authorized, with an accountable owner?
3. Metadata, semantics, and lineage — can people and systems explain what the data means and where it came from?
4. Access and integration — can production systems reliably get this data at the latency the use case needs?
5. AI-specific preparation — are labels/features or documents/retrieval quality already evaluated?
6. Operations and monitoring — will quality, schema, and drift failures be detected after launch?

Don't average the six scores. Your lowest pillar is your real ceiling: a use case with excellent data quality but no named owner for access decisions isn't close to production, no matter how the other five pillars score.

This six-pillar version is a fast gut-check. Liorant's own audit for this exact work grades a more granular 17-component model, grouped into four areas, on a four-level maturity scale — because "governance" or "metadata" each split into several separately-buildable pieces once you're scoping real work rather than doing a quick self-check.

Data readiness and the EU AI Act

For high-risk AI systems under the EU AI Act, data governance becomes a legal requirement when the applicable high-risk provisions take effect. Article 10 requires training, validation, and testing datasets to be governed for their origin, preparation, labeling, and known gaps, and to be relevant, representative, and, to the best extent possible, free of errors. Under the AI Omnibus, those rules apply from 2 December 2027 for Annex III high-risk systems and from 2 August 2028 for high-risk systems embedded in regulated products. Breaches of provider obligations can carry fines of up to €15 million or 3% of worldwide annual turnover, subject to the Act's conditions and special rules for smaller companies. Where personal data is involved, GDPR's purpose-limitation and data-protection-by-design principles apply alongside it. Most business knowledge systems won't count as high-risk, but the underlying discipline is useful either way: traceable sources make it possible to explain and control system outputs.

The same artifacts matter outside the EU, too. El Salvador's Decreto Legislativo 234 created ANIA and the National Registry for AI Development, Innovation, and Application. ANIA Resolution 0001/2025 later made registration mandatory for operators deploying AI for specified consequential decisions, including health, credit and insurance, public-space biometrics, access to government services, employment, education, and professional licensing. The registration rules do not explicitly require data lineage, but documented sources and controls can support compliance. In the US, the voluntary NIST AI Risk Management Framework's Map and Measure functions cover system context, data suitability, and documented testing. Some state laws, including Colorado's AI law, make compliance with a recognized AI risk framework one condition of an affirmative defense; framework alignment alone is not enough. See Liorant's EU AI Act business guide for the full risk tiers, timeline, and obligations by sector.

Frequently asked questions

How Liorant gets you there

In Liorant's experience, organizations rarely need to fix their entire data estate before running a useful AI pilot. They need to identify the component capping their highest-value use case, then close that gap well enough to launch. Liorant's Data Readiness for AI service runs this playbook as two fixed-scope, fixed-price products rather than open-ended advisory.

In Liorant's experience, a first use case usually depends on three to six priority components rather than all 17 — the Audit identifies which ones. Nothing here locks you into a platform: the deliverables work with Copilot Studio, Google Gemini, Claude, or a custom build, and if you move into a Rapid AI Activation afterward, the same artifacts carry forward.