How Much Data Preparation Do You Really Need Before Starting an AI Project?

One of the easiest ways to delay an AI project is to decide the data has to be perfect before anything can begin.

That sounds responsible, but in practice it can turn into months of cleaning, cataloging and infrastructure work without proving whether the AI use case is valuable in the first place.

The opposite approach is just as risky. If teams push ahead with fragmented, outdated or poorly governed data, the project may work in a demo and then fall apart when people try to use it in a real workflow.

The better question is not whether your data is “AI-ready” in the abstract. Rather, you should be asking whether the data required for a specific use case is good enough to support the decision, recommendation or action the AI system is expected to make.

This is important especially as more companies try to move beyond pilots. McKinsey’s 2026 research found that more than two-thirds of high-performing companies identify data as the main obstacle to enabling AI.

However, the same research makes an important point: the goal is not perfect data. Companies need to define what “good enough” means based on the business use case and the risk attached to getting the answer wrong.

That is a much more practical standard for deciding how much preparation should happen before a project starts.

Perfect Data Is the Wrong Starting Point

Most organizations are working with data that has evolved over time rather than data that was designed for AI. It may sit across several systems, follow different definitions and include information that is incomplete, duplicated or out of date.

If every one of those problems had to be fixed before AI work could start, very few organizations would ever leave the planning stage. The better approach is to narrow the problem to the data the AI system actually needs.

For example, an internal assistant answering questions about HR policy does not need every enterprise dataset cleaned. It does need the correct policy documents, clear versioning and enough metadata to avoid returning outdated guidance. A forecasting model may care much more about historical consistency and missing values. An AI agent that can change customer records raises a different set of concerns around ownership, permissions and auditability.

Readiness therefore depends on what the system will do with the data. As we argue in another piece, companies do not need flawless data infrastructure before getting started. They do, however, need clear ownership, usable access and enough governance to keep fragmented data from undermining the use case.

Which Data Issues Matter Before You Start?

Not every data issue deserves the same level of attention before a project starts. Some problems directly affect whether the AI system can produce a reliable result, while others can be fixed later without blocking the initial use case.

The table below helps separate the two:

That distinction prevents “data preparation” from turning into a company-wide cleanup exercise.

The threshold should also rise with the consequences of failure. A low-risk internal summarization tool can tolerate more ambiguity than an AI system recommending credit decisions, modifying financial records or taking autonomous actions.

This is why data readiness should be evaluated alongside the use case rather than as a separate infrastructure project.

Searchable Data Is Not Necessarily Usable Data

Simply giving an AI system access to information does not mean that information is structured, current or reliable enough to use well.

Enterprise AI increasingly depends on unstructured information such as contracts, emails, call transcripts, PDFs and internal documentation. Those files may be perfectly readable by a person but still lack the structure, context or lineage an AI system needs to use them reliably.

This is why simply digitizing information or making it searchable does not solve the problem. AI systems need clear versioning, context and links between unstructured content and the structured enterprise data that gives it meaning.

For example, a contract may be accurate as a complete document. But if the retrieval system surfaces an outdated clause without the surrounding context, the model can still produce a wrong answer.

That changes what data quality means for AI. Teams need to think not only about whether the source data is correct, but also whether the system retrieves the right version, preserves enough context and can trace the answer back to its source.

Use the Pilot to Discover What the Data Actually Needs

Teams will not uncover every data problem before an AI project starts. A controlled pilot can surface the issues that actually affect the use case, whether that is missing information, poor retrieval, conflicting documents or access restrictions.

That makes the pilot useful for more than testing the model. It also shows where the underlying data needs work. Instead of trying to clean and prepare everything upfront, teams can focus on the problems that show up in the real workflow and improve the data from there.

That approach also gives organizations a clearer reason for each data investment. A new metadata field, pipeline or governance control exists because it improved a real workflow, not simply because it was included on a generic AI-readiness checklist.

The Data Foundation Has to Grow When the AI Does

The amount of preparation required for one pilot is not the same as what is required to support dozens of AI applications across an organization.

As more teams reuse the same documents, customer records and operational data, inconsistencies that were manageable in one use case can spread quickly. Data ownership becomes more important, lineage becomes harder to track and the same source may be processed differently by multiple systems.

Deloitte’s State of AI in the Enterprise report found that 81% of organizations are making faster decisions with AI, but only 25% are using it to deeply transform their businesses. The gap highlights a broader challenge as companies adopt AI faster than they redesign the processes, governance and operating models needed to support it at scale.

That is the point where preparation starts moving from use-case-specific fixes toward reusable infrastructure, including common pipelines, shared metadata, consistent permissions, lineage and monitoring that several AI applications can depend on.

Start With the Data the Use Case Actually Needs

Companies should not wait until every data problem has been solved before starting an AI project. They also should not treat data preparation as something that can be postponed until after the model has been selected.

The middle ground is to start with the use case and work backward.

Identify the data it depends on, determine which quality or access problems would make the result unreliable, fix those first and use the pilot to expose what needs to improve next.

As the number and risk of AI use cases grow, the data foundation should grow with them.

That is also where GAP’s broader AI and data services fit. GAP works across AI validation, data engineering, pipelines and production deployment, allowing teams to address the data constraints that matter to a specific use case without turning every AI initiative into a full enterprise data transformation.

The objective is not perfect data. It is data that is reliable enough, governed enough and accessible enough for the AI system you are actually trying to build.