Most companies start preparing for AI by cleaning up their data. They remove duplicates, fill in missing values, and connect systems that never talked to each other. The work is real and the dashboards show progress. Then the first AI task runs on that data and misses the one exception the process owner cared about, and nobody can say whether the cleanup helped.
AI readiness, for one business process, means the data behind it can hand an AI task reliable inputs, clear decision rules, and a way to check the result. How tidy the data looks matters less than whether it produces the result a specific AI task needs. So the question for a data team is not “is the data clean” but “by what standard do we say the data is fixed for this task”. This post answers that in four checks, and then shows how CUBIG defines the standard.
Key takeaways
- “Fix the data” hides three different jobs: clean it, connect it, and prepare it for the task. The third step determines whether the data fits the actual AI task, building on the cleaning and connection work before it, and it usually gets the least time.
- Fixed means measurable: the same cases, run before and after preparation under the same conditions, with the difference reported in the process owner’s units. A result that cannot be attributed cannot be defended.
- AI readiness expires. When a source, a rule, or a model changes, the record of which data version, which cases, and which conditions produced the result tells you what to recheck.
Does cleaning the data finish AI readiness?
No. Cleaning is one part of AI readiness, and the reason it is not the whole of it is that “fix the data” is one phrase for three different projects. They look the same on a status slide and prove very different things.
| What “fix” usually means | What it proves | What it leaves open |
|---|---|---|
| Clean it: dedupe, fill nulls, standardize formats | Records pass quality rules | Whether the fields the task relies on carry the meaning the task assumes |
| Connect it: locate sources, assign owners, open access | An AI system can reach the data | Whether what it reaches is complete and current for this process |
| Prepare it for the task: define units, relations, exceptions, and the cases the process must handle | The task has the inputs and the rules it needs | Whether results hold when the data changes next quarter |
Most AI readiness budgets go to the first row, because cleaning has a visible finish line and the quality score goes up. The trouble is that a table can pass every quality rule and still miss the exception that drives half the escalations in the process you chose. We covered why clean data and AI-ready data are different states in an earlier piece; this one is about the third row, which is where readiness is decided and where the calendar leaves the least time.
How do you know which data a specific AI task needs?
A general data readiness check is useful on its own, but verifying AI readiness for a specific task starts with that task, not with the dataset. Pick the one process the AI will touch first, and write down the cases it must handle: the routine ones, and the exceptions that the process owner escalates today. For each case, name the fields the decision depends on, the unit each field is in, how records relate across systems, and what a correct outcome looks like.
That list is the specification for “fixed”. A field that no case depends on does not need cleaning this quarter. A field that three cases depend on, and that a regional team leaves blank, is the actual problem, even if the quality dashboard never flags it. Teams that do data onboarding for many customers rediscover this every time: the hard part is not the cleaning, it is finding which exceptions the customer’s process actually runs on. We go deeper on this in AI data preparation starts with the task.
How do you verify that the preparation helped?
Measure AI readiness the same way you would measure any other change. Run the task on the cases before you prepare the data, prepare it, and run the same cases again with the same model and the same evaluation conditions. The difference between the two runs is the value of the preparation, expressed in the units the process owner cares about: cases handled correctly, rework avoided, time to a decision.
Without that comparison, a good pilot result cannot be attributed. Was it the data, the prompt, or a friendly sample? Nobody can say, and a result nobody can attribute is hard to defend in the budget meeting that follows the pilot. The wider context makes that meeting harder: a preliminary MIT NANDA report from July 2025, as reported by Fortune, found that about 95% of the organizations it surveyed saw no measurable financial return from their generative AI pilots. That study looked at financial return and at how organizations integrated the models, not at data preparation, so it does not show that missing comparisons caused the gap. It does show why AI results now have to be verified at the level of a single task rather than claimed at the level of a program.
The comparison only works if four elements are controlled. First, the cases: the same records, including the exceptions, in both runs. Second, the data version: the pre-preparation run uses a frozen copy and the post-preparation run uses the new version, so the two are never mixed. Third, the model and its settings: the same model, prompt, and parameters, so the difference cannot come from a tuned prompt. Fourth, the scoring rule: the process owner’s definition of a correct outcome, written down before either run. Recording these four conditions with the result makes it possible to estimate the effect of the preparation and to examine any variation that remains. Researchers are asking for this kind of assessment as well; Christine Legner of the University of Lausanne put it as a question: without AI-ready data there is no agentic AI, so how do you assess it?
What has to be rechecked when the data or the model changes?
AI readiness checked once is readiness that expires. Suppose the comparison ran on an extract pulled in March. By the time the workflow rolls out in June, a source system has added a status code, a regional team has started leaving a field blank, and the exception the pilot handled well now arrives in a format nobody tested. The code did not change. The data did, and the preparation that was correct in March is now out of date.
This is why an AI readiness assessment cannot be a one-time gate. The useful version keeps three things together: which version of the data a result came from, which cases it was checked against, and which evaluation conditions applied. When something drifts, that record narrows the recheck to the cases and fields that were affected, instead of sending the team back to a full cleanup. The same applies when the model changes: rerun the same cases on the same data version, and the difference is the model’s, not the data’s.
How CUBIG defines “fixed”
CUBIG separates three AI readiness questions that “fix the data” usually blurs, and answers each with evidence that can be rerun. The first is the common readiness state of the data itself: in Syntitan, Ready for Raw Data diagnoses a dataset across six axes (usability, integrity, context, consistency, reproducibility, and traceability), flags the axes to review first, and applies only the preparation steps the team chooses. Each applied step creates a new project Version, and the original dataset stays untouched. The second is fit for a specific AI task: Ready for Model takes the task type and the target column, prepares the data for that task, fills in the cases the task lacks, and compares performance before and after on the same model under the same evaluation conditions, so the improvement, if there is one, can be attributed. Ready for Agent does the same for an agent’s work: it finds the exception situations an agent is likely to miss, turns them into test cases, and compares the agent’s answers before and after the data is supplemented; connecting live agent runs to those cases is planned for December. The third is what happens after change: when the source dataset is updated, Execution Trace shows which project Versions each update produced and keeps every run tied to the Version, settings, and evaluation conditions it ran under. The same preparation steps can be reapplied to the updated data and the same comparison rerun, so the team sees whether the earlier result still holds instead of starting the cleanup over.
Under that definition, “fixed” is not a score of 100 on a quality dashboard. It is a data version that a named task was checked against, with the before-and-after result on record and the exceptions preserved rather than cleaned away. The longer definition is in What Is AI-Ready Data?
An AI readiness check before you call the data fixed
Five questions, drawn from the teams we work with. If any answer is “not yet”, the data is cleaner but AI readiness is not there yet.
- Can you name the cases the first AI task must handle, including the exceptions, and are they written down with expected outcomes?
- Did you run the task on those cases before and after preparation, with the same model and under the same conditions?
- Can the process owner read the difference in their own units, such as cases resolved correctly or hours of rework avoided?
- Do you know which data version, which rules, and which conditions produced the result?
- When a source or a model changes next quarter, do you know which cases to recheck, or does the cleanup start over?
These five are the checks we use before calling data fixed. They do not replace the task’s own success criteria: whether the data is ready for a given AI task is decided by that task’s criteria and the verification result, with the five answers as the evidence behind the decision. Try it on your data, free.
Related product: Syntitan
For structured data, CUBIG’s Syntitan keeps this evidence next to the data. A Project starts from a copy of the original dataset for one use case, and each preparation run creates a new Version. Ready for Raw Data diagnoses the data’s state across six axes before any model runs. Ready for Model compares performance before and after preparation on the same model and evaluation conditions, and can fill in the cases the task lacks. Ready for Agent builds test cases from the exceptions an agent tends to miss and compares its answers before and after; connecting live agent runs to those cases is planned for December. Execution Trace ties each run and each source update to the Versions involved, and Applied Status shows which Version is connected to which downstream system, delivered as a file, through an API, or over MCP. Sensitive fields can be masked before any of this runs. Syntitan works alongside the data platforms a team already uses rather than replacing them.
