Data Readiness for AI: The Checklist to Run Before You Build

Data readiness for AI means five things are true: the data exists at the grain the model needs, code can reach it without a human exporting a file, its meaning has been stable long enough to learn from, you have ground truth for whatever you are asking the model to predict, and you are legally allowed to use it that way. Most stalled AI projects fail on the second and fourth, not on volume. Last updated July 2026.

The pattern repeats in almost every AI project that goes badly. The idea is sound, the vendor is competent, the budget is approved, and then eight weeks disappear into finding out that the field everyone assumed existed is populated on about 40 percent of records, or that the only way to get last quarter's data is for someone in operations to run a report and email a spreadsheet. Nobody lied. It is just that no one checked before the statement of work was signed.

This checklist is the pre-work. Run it before you scope the build, and it either de-risks the project or tells you the first thing to fix is the data, which is a much cheaper lesson to learn now.

What does data readiness for AI mean?

Data readiness is the state where a model can be trained, evaluated and served from your data without a person in the loop moving files around. That means the data is accessible by code, documented well enough that someone can tell what a column means, complete enough at the grain you care about, and governed clearly enough that you know who may see what. It is an engineering condition, not a data volume threshold.

The useful distinction is between data you have and data you can use. A company with nine years of transaction history in a warehouse nobody can query without a ticket has plenty of the first and none of the second.

The data readiness checklist

1. Does the data exist at the grain the model needs?

Grain is the level of detail of one row. A churn model needs one row per customer per month, not a rolled-up quarterly total. A demand forecast needs sales by SKU by location by day, not the monthly summary finance reports on. Aggregated data cannot be un-aggregated. If the only surviving record is the summary, that history is gone for modeling purposes, and you start collecting the detail from today.

2. Can code reach it, or only a human?

This is the most common blocker and the least discussed. Ask a blunt question: can a service account run a query against this data on a schedule, today, without asking anyone? If the answer involves someone logging into a vendor portal and clicking export, you do not have a data source, you have a manual process that will break the first week the person is on vacation. Fixing this is straight AI data engineering work: pipelines, credentials and a landing table, usually a few weeks and worth doing regardless of the AI project.

3. Has the meaning of the data been stable?

Definition drift kills more models than dirty data. A field called status that meant one thing before a CRM migration and something different after it looks perfectly clean, and it teaches the model a relationship that no longer holds. Ask when the last system migration was, when the pipeline was last rewritten, and whether anybody changed how a key field is populated. Then be honest about which slice of history is actually usable, which is often shorter than the full archive.

4. Do you have ground truth?

If you want a model to predict something, you need historical examples of that thing having happened, recorded reliably. This sounds obvious and it is where projects quietly die. Teams want to predict which deals will close but only record wins, never a clean reason for losses. They want to flag fraudulent invoices but never labeled the fraudulent ones. Without labels you are not building a prediction model, you are building an anomaly detector, which is a different project with a different accuracy conversation. Decide which one you are funding before you start.

5. Is it complete and consistent enough?

Check three numbers per critical field: what percentage is populated, how many duplicate entities exist, and how many values fall outside the plausible range. You do not need perfection. You need to know the numbers, because a field that is 55 percent populated is not usable as a primary signal and pretending otherwise costs you a month. Missing data is only fatal when it is missing for a reason correlated with what you are predicting, which is worth checking directly.

6. How much of it is locked in documents?

A large share of the information an AI project wants is not in a table at all. It is in contracts, PDFs, scanned forms and email attachments. Treat that as its own workstream with its own budget, because pulling structured terms out of a stack of commercial leases is a genuinely different engineering problem from querying a warehouse. If your use case is answering questions over those documents rather than predicting from them, you probably want retrieval-augmented generation instead of a trained model, which changes the readiness bar considerably: retrieval needs good documents and good chunking, not labels.

7. Are you allowed to use it this way?

Consent, contracts and retention policy all constrain what can go into a model. The specific questions that matter: does any of this contain personal data, does your customer contract or privacy notice cover this use, is there a retention limit that means you must delete records you were planning to train on, and does the data have to stay in a particular region. Get this answered by whoever owns compliance in week one, not after the model works.

How much data do you need for an AI project?

Far less than most teams assume, and the number depends entirely on the approach. If you are building on a large language model with retrieval, a few hundred good documents is often enough to be useful because the model already has language and reasoning. If you are training a classifier from scratch, a common working floor is a few thousand labeled examples per class, and rare events need proportionally more. Quality of labels beats quantity of rows almost every time.

What if my data is not ready?

Do not stop the project and do not start a two-year data platform program either. Both are expensive mistakes. The practical middle path is to narrow the scope to one use case, fix the data for that use case only, and ship it. A pipeline built to serve one working model is concrete, testable and paid for by an outcome, which is why it tends to survive. A generic data cleanup with no consumer is the kind of initiative that gets cancelled at the next budget review.

This is also the argument for a tightly scoped proof of concept before a full build. A good POC surfaces the data problems in two weeks for a few thousand dollars instead of five months into a fixed-price contract. Most of the reasons pilots never ship are data reasons, which is covered in more detail in why most AI proofs of concept stall.

Who actually fixes data readiness?

A data engineer, not a data scientist, and this mismatch wastes a lot of money. Teams hire an expensive ML specialist who then spends 70 percent of their time building pipelines they are not the cheapest person to build. If your checklist came back mostly red on items two and five, hire for data engineering first and bring the modeling in after. If the model is already built and the worry is what happens after launch, that is MLOps territory instead.

The short version

Before you sign anything, get written answers to five questions: what is the grain, can a service account query it, when did the definitions last change, where is the ground truth, and who says we are allowed to use it. If all five have real answers, your project is a normal engineering project. If two or more are vague, the first phase of your AI project is a data project, and the honest move is to budget it that way rather than discovering it in month three.

If you want a second opinion on whether your data supports the thing you have in mind, describe the project in the hire brief above. It scopes the build and the data work separately, so you can see which one is the real cost before you commit to either. You can also compare the routes for getting it built in the Toptal alternatives comparison, or go straight to hiring a vetted AI engineer.