AI Data Readiness: 9 Questions to Ask Before Any AI Project

An AI project fails, and the postmortem almost always focuses on the model: it wasn't accurate enough, it hallucinated too often, it wasn't the right tool. The quieter, more common truth is that a meaningful share of failed AI projects were doomed by their data long before the model ever entered the picture, and nobody checked the data carefully enough to notice in time.

Vendor names spelled six different ways across one export. A category field that is empty for a third of all rows. A spend file nobody can confirm is actually current. Feed any of this into even the most capable model, and the result is confident sounding, fluent, and unreliable, not because the model failed, but because the data it was given was never actually ready.

This guide gives you nine specific questions, grouped into quality, access, and trust, that reveal whether a dataset is actually ready for an AI project, before anyone spends time building anything on top of it.

Why data judgment matters as much as AI skill itself

Someone eager to build with AI, without pausing to check whether the underlying data is actually ready, is a genuine risk to a real project, not because of any lack of enthusiasm, but because enthusiasm applied to bad data produces confident, fluent, wrong results faster than caution would have. This is a specific, learnable form of judgment, distinct from prompt skill or tool fluency, and employers building real AI features have learned to screen for it directly.

This matters with particular weight in procurement and finance adjacent roles, where the underlying data, ERP exports, spend files, supplier records, is often genuinely messy in ways that are easy to underestimate until you look closely: the same vendor spelled six different ways, a category field left blank on a meaningful share of rows, records nobody has actually confirmed are current. An AI project built on top of this without pausing to check will faithfully, confidently, and incorrectly process the mess, and the resulting errors can be harder to catch than an obvious manual mistake would have been, precisely because AI output tends to look clean and authoritative regardless of what it was built on.

This is precisely why a candidate who asks careful questions about data before proposing an AI solution reads as more senior, not more cautious, to an experienced interviewer. Enthusiasm for AI is common and cheap to demonstrate. The discipline to check the actual data before building on it is rarer and considerably harder to fake, since it shows up specifically in the questions someone asks before, not after, things go wrong.

Three data quality dimensions worth checking first

Before any AI project, three specific data quality properties predict a large share of what will go wrong if they are ignored.

Completeness. Are the fields the project actually depends on filled in, consistently, across the dataset, or are there meaningful gaps that will quietly become missing information, or worse, incorrect guesses, once an AI tool encounters them.

Consistency. Does the same real world thing get labeled the same way throughout the dataset, or does one vendor appear under six slightly different spellings, one category get called three different names depending on who entered the data. Inconsistency like this quietly fragments what should be one clear pattern into several confusing ones.

Freshness. Is the data actually current, or is it a snapshot from months or years ago being treated as if it reflects today's reality. This connects directly to the earlier guide on RAG: retrieval only helps if what gets retrieved is actually current.

Access and privacy: the questions that come before quality

Before any quality check, a more basic question needs an honest answer: are you actually allowed to use this data this way. Who has permission to see it, does it contain personal or sensitive information that needs special handling, and is there a clear, documented rule governing how it can be used, stored, and shared. Skipping this step is not a technical risk, it is a real compliance and trust risk, and it is far easier to answer honestly before a project starts than to untangle after AI generated outputs have already been shared based on data that should have been restricted.

This is the real checklist promised for this guide.

The trust group is the one most often skipped, usually because it feels like a formality rather than a real risk. In practice, it is often the most predictive of the three groups: a dataset with no known owner and no clear origin is a dataset nobody can actually be held accountable for, which means any error it introduces has nowhere useful to go when someone finally asks "wait, is this actually right?"

A worked example: auditing a real ERP export

A team receives an ERP export of vendor purchase records and wants to build an AI powered spend categorization tool on top of it. Running the nine question audit before building anything reveals two immediate problems.

On quality: the vendor name field contains six different spellings of what is clearly the same supplier, "Crate Systems," "Crate Systems Inc," "CrateSystems," and three more variants, which would cause an AI tool to treat one real vendor as six different ones unless corrected first. The category field is empty for roughly 30 percent of rows, which would force the tool to guess a category for nearly a third of all spend with no real basis for the guess.

On access: the export includes an internal notes field that occasionally contains employee names attached to purchasing decisions, which raises a real access question worth resolving, who should be able to see this field, before building anything that might surface it.

None of these problems are difficult to fix, standardizing the vendor field and filling or flagging the empty categories is a straightforward cleanup task, and restricting the notes field is a simple access decision. But fixing them before building the AI tool, rather than discovering them after the tool has already produced a quarter's worth of unreliable categorizations, is the entire difference this guide is trying to teach.

Practice these interview questions

Data readiness questions test whether you think about the unglamorous groundwork before an AI project, the part that actually determines whether it succeeds. Work through your own answer first, then compare with the sample.