AI-Ready Data: What That Phrase Actually Demands
Gartner is cited projecting that 60% of AI projects will be abandoned through 2026 because the data was not AI-ready. It is the most specific of the widely quoted failure statistics because it names a cause, and it is nearly useless because the phrase it names is almost never defined.
Here is the definition worth using: data is ready when you can get it, trust it, join it, and see what happened next. Four conditions. Most organisations satisfy the first two for their main systems, struggle with the third, and have never attempted the fourth.
The fourth is the one that kills projects. You can nearly always obtain the inputs. Getting the outcomes, meaning which prediction was correct, which ticket was genuinely resolved and which recommendation was acted on, needs instrumentation nobody built, because until now nobody needed it. Without outcomes you cannot train a model, you cannot evaluate one, and you cannot prove the system works. Every one of those is fatal on its own.
The good news is that readiness is not a prerequisite, it is a scope. You do not need an enterprise data programme before you can do anything. You need enough data, for one decision, to be good enough, and that is a much smaller question than the one consultancies tend to ask.
Three questions get you to an answer in a day. Where does this data physically live and can a system read it on a schedule? Does the same real-world thing have one identifier across systems? And is there any record of what happened after the decision you want to automate?
Data is AI-ready when you can get it, trust it, join it, and see what happened next. Most organisations manage the first two and have never attempted the fourth. Access fails organisationally rather than technically: a pilot runs on an extract, while production needs credentialed, monitored access the system owner must approve.
The first failure is boringly organisational and consumes more calendar time than any engineering.
Pilots run on extracts. Production needs a connection. Someone exported a spreadsheet and emailed it. A live system needs credentialed, scheduled, monitored access to the source, which means the system's owner has to agree, and they were not in the room when the project was approved.
The owner has reasons to say no and they are usually good ones. Load on a production database, exposure of fields the project does not need, uncertainty about what you will do with it, and the fact that they will be asked about it if something goes wrong. Treating this as obstruction rather than as a legitimate position is how projects stall for months.
Ask for the narrowest thing that works. A read replica rather than the primary. A nightly extract rather than live access. The six fields you need rather than the whole table. Each reduces the objection and most projects do not need more.
Vendor systems are the hard case. If the data lives in software you license, you get whatever export or API the vendor provides, at whatever price, and sometimes the answer is a CSV download by hand. Find this out before scoping, because it can be the whole feasibility question.
Start the access conversation on day one of the project, in parallel with everything else, rather than when the model is ready and waiting. It is the only task here whose duration you do not control.
Budget weeks, not days, for access alone. It is the single most underestimated line in these projects and the one least improved by adding engineers.
The condition that quietly defeats more projects than quality does is whether the same real-world entity can be recognised across systems.
The customer in your billing system, your support tool and your product analytics is three records. If there is no shared identifier, joining them is a matching problem: fuzzy, probabilistic, and wrong a meaningful percentage of the time. Every downstream number inherits that error rate.
Matching errors are asymmetric and both directions hurt. Merging two different people creates a record that is nonsense. Failing to merge one person splits their history, so the model sees two shallow profiles instead of one useful one.
The fix is an identifier, and creating one is a project. Picking a system of record, assigning stable identifiers, propagating them, and maintaining them as records are created in multiple places. It is unglamorous, it benefits far more than the AI project, and it is frequently the right first investment.
Time is an identity problem too. The same event recorded in two systems with different timestamps, different timezones, or different definitions of when something counts as having happened. Joining on time without agreeing what time means produces plausible and wrong results.
Deduplication is the same problem pointed inward. One system frequently holds the same entity twice, created by two people on two days, and a model trained on that data learns from a world where some customers exist twice and others once. Counting duplicates in your largest table is a ten-minute query and the result is usually sobering.
Test this before anything else. Take fifty real entities and try to trace them across every system by hand. The hit rate from that exercise tells you more about feasibility than any data quality report.
This is the condition most organisations fail and the one they are least prepared to hear about.
Inputs describe the situation. Outcomes describe what happened. A model learns from the pairing. Without outcomes you have a description of the world and no signal about what was right.
Operational systems record decisions, not results. The ticket was assigned to a queue, but was it the correct queue? The lead was marked qualified, but did it close? The transaction was approved, but was it fraudulent? In most systems the first half is captured and the second is not, or is captured somewhere that cannot be joined back.
Delay makes it harder. Some outcomes are known in seconds and some in months. A model predicting churn learns from an outcome that takes a quarter to observe, which sets a floor on how fast you can iterate and is rarely in anyone's plan.
Negative examples are usually missing entirely. You know which applications you approved and how they performed. You know nothing about how the rejected ones would have performed, because you rejected them. This is a structural gap, not an oversight, and it changes what the model can be trusted to say.
Start collecting outcomes now, even if the project is a year away. It is a small instrumentation change, the data is worthless until it has accumulated, and starting late means waiting later.
Two organisations with identical data in different places face different projects, and the difference is usually invisible in a requirements document.
One warehouse is the easy case and the rare one. If the records you need already land in a single analytical store on a schedule, most of the access and joining work has been done by somebody else and you are starting from a good place.
Operational databases are the common case. The data is live, it is in the system that needs it for its day job, and reading it at volume affects that system. The usual answer is a replica or a scheduled extract, which introduces staleness you then have to reason about.
Spreadsheets are more common than anyone admits and are not disqualifying. A process run from a shared workbook has structure, however informal, and extracting it is tractable. What is not tractable is a workbook where the structure changes whenever someone adds a column.
Third-party systems set a hard ceiling. Whatever export, API or rate limit the vendor offers is what you have. Check it first, because an hourly rate limit can make a real-time feature impossible regardless of budget.
Paper and PDF are a different project. If the source is a scanned document, the first phase is extraction rather than modelling, with its own cost and its own error rate to design around.
Readiness work crosses organisational lines, which is why it stalls in companies that have the skills to do it.
The system owners hold the access decision, and they are usually in operations or IT rather than in the team running the project. Nobody can grant themselves what they need.
The business owns the definitions. What counts as a resolved ticket, a qualified lead, an active customer. These are not technical questions and a data team answering them alone will produce a model measuring something the business does not recognise.
Somebody has to own the identifier. Assigning and propagating a stable identity across systems is ongoing stewardship, not a migration, and without a named owner it degrades from the day it ships.
The project team owns the instrumentation. Capturing outcomes is usually a small change in an operational system, requested by the project and implemented by whoever maintains that system, which means it needs to be asked for early and politely.
Name all four before starting. The commonest shape of a stalled readiness project is four groups each waiting for one of the others, with no one person able to say the work is behind.
Teams assume clean data is the requirement. It is not, and the distinction saves a great deal of unnecessary work.
Models tolerate noise and do not tolerate inconsistency. A field that is missing 15% of the time, consistently, is workable. A field that meant one thing until a system migration in March and something else afterwards is poison, because the model learns a pattern that stopped being true.
Silent schema changes are the standard version of this. A dropdown gained an option, a free-text field was replaced by a picker, a category was renamed. None broke anything, all changed the meaning of history, and nobody recorded when.
So ask what changed, and when, before you ask what is wrong. A timeline of system changes over the period your data covers is more valuable than a completeness report.
Free text is usually richer than the structured fields beside it. The notes field contains what actually happened; the dropdown contains what someone picked to close the screen. Modern models handle free text well, which makes it an asset rather than the liability it was.
Document the known defects rather than fixing them all. A short written list of what is wrong with each field, and from when, lets whoever builds the model compensate deliberately. An undocumented defect is discovered by the model and expressed as a confident wrong prediction.
Resist the urge to clean everything first. Cleaning data without a specific use is unbounded work with no finish line. Pick the decision you want to improve, find the fields it needs, and fix those.
The question everyone asks first, and the answer is smaller than expected and depends on what you are doing.
For classification with a modern model, hundreds of good examples go a long way. Fine-tuning on a narrow task does not need the volumes that training from scratch once implied, and few-shot prompting needs fewer still.
For retrieval you need coverage, not volume. The question is whether the answer exists in your corpus, not how large it is. A thousand well-maintained documents beat a hundred thousand stale ones, and the deduplication and freshness work matters more than quantity.
For forecasting you need history, measured in cycles. Predicting something seasonal with eighteen months of data means one and a half examples of the pattern, which is not a dataset.
For rare events you need rare events. Fraud at 0.3% in ten thousand records is thirty examples. Volume requirements scale with how uncommon the thing you care about is, not with the table size.
Synthetic data fills gaps in shape, not in truth. It is useful for testing a pipeline and for balancing a class, and it cannot tell you something about the world that your real data does not already contain.
Count what you have of the thing that matters, not of rows. The useful number is examples of the specific outcome you are predicting, and it is usually a small fraction of the headline figure.
The questions a buyer, auditor or regulator will ask are predictable, and answering them later is more expensive than designing for them now.
Where did this data come from and may you use it this way? Data collected for one stated purpose may not be usable for another, and the answer differs by market. It is a question for whoever handles your contracts and privacy position, and the worst time to ask is after a model is in production.
Who may see what? If a model is trained on or retrieves from data with mixed permissions, it can surface to one user something another user's record contains. Permission-aware retrieval is a design decision, not a filter added afterwards.
Can you delete a person? Erasure obligations reach the data you hold about someone. If that data is inside a trained model or an embedding index, deletion is substantially harder than removing a row, which is an argument for retrieval over fine-tuning where the choice exists.
Can you explain a decision? Some decisions have to be explicable to the person affected, and the requirement is increasing in several markets.
Write the answers down once. Four paragraphs, reviewed by whoever owns your legal position, saves the same conversation repeating in every project.
You do not need a data strategy to answer the feasibility question. You need one focused day, and it is the highest-return day in the whole project.
Name the single decision you want to improve. Not "use AI in support" but "route an incoming ticket to the right queue". One decision, made many times, with a definition of correct.
List the fields that decision depends on, and find them. Which system, which table, who owns it, how to read it on a schedule. Stop when you cannot locate one, because that is your answer.
Trace fifty real entities by hand across those systems. The proportion you can follow end to end is your practical join rate, and it is always lower than anyone predicts.
Find the outcome. For those fifty, what happened next, and is it recorded anywhere you can reach? If not, the project starts with instrumentation rather than modelling, and that is useful to know before the budget is set.
Write down what changed in those systems over the period. Migrations, renames, new fields, process changes.
That is the audit. Four conditions, fifty records, one day. Our rate band is published, $40 to $100 an hour by role, blending to $60 to $70 for a mixed team, and this is the cheapest engagement we sell because it frequently ends with us saying the project is not ready and here is the smaller thing to do first.
Four conditions: you can get it, you can trust it, you can join it, and you can see what happened next. Access means a credentialed, scheduled, monitored connection rather than an emailed extract. Trust means consistency over time more than cleanliness. Joining means the same real-world entity is identifiable across systems. And outcome data means a record of what actually happened after the decision, which is the condition most organisations have never collected.
Gartner is cited projecting 60% of AI projects abandoned through 2026 for lack of AI-ready data. In practice the failures cluster: access takes weeks because the system owner was never consulted, entities cannot be joined across systems because no shared identifier exists, and there is no record of outcomes, which makes training, evaluation and proving value all impossible. None of these is a modelling problem and none is solved by better technology.
Less than most people expect, and it depends on the task. Classification with a modern model can work from hundreds of good examples. Retrieval needs coverage rather than volume, so a thousand maintained documents beat a hundred thousand stale ones. Forecasting needs history measured in cycles, so eighteen months of seasonal data is one and a half examples. For rare events you need examples of the rare event, so 0.3% fraud in ten thousand records is thirty cases, not ten thousand.
Less than you think. Models tolerate noise but not inconsistency: a field missing 15% of the time consistently is workable, while a field whose meaning changed at a system migration is actively harmful because the model learns a pattern that stopped being true. Ask what changed and when before asking what is wrong. Avoid cleaning everything first, which is unbounded work; pick one decision and fix the fields it depends on.
It is the record of what actually happened after a decision: whether the ticket was routed correctly, whether the lead closed, whether the transaction was fraudulent. Models learn from pairing inputs with outcomes, and most operational systems record the decision but not the result, or record it somewhere that cannot be joined back. Without outcomes you cannot train, cannot evaluate, and cannot prove value. Start collecting now even if the project is a year away.
Weeks rather than days, and it is the most underestimated line in these projects. The blocker is organisational: the system owner has legitimate concerns about load, exposure and accountability, and they were not in the room when the project was approved. Reduce the objection by asking for the narrowest thing that works — a read replica rather than the primary, a nightly extract rather than live access, six fields rather than the table. Vendor systems are the hard case and should be checked first.
One day and five steps. Name the single decision to improve, with a definition of correct. List the fields it depends on and locate each one, including who owns it and how to read it on a schedule. Trace fifty real entities by hand across those systems to get your practical join rate. Find whether the outcome for those fifty is recorded anywhere reachable. And write down what changed in those systems over the period the data covers.
Vikas has around fifteen years of experience building software and now builds generative AI systems at Zyneto. His work covers retrieval augmented generation, agentic AI, knowledge graphs, AI memory, and the evaluation and guardrails that decide whether any of it is safe to put in front of customers. He has shipped enterprise copilots, document AI, chatbots and predictive analytics for e-commerce, fintech and marketing teams, and works day to day in Python, JavaScript and SQL. He follows multimodal models, business process automation and enterprise AI security closely, and mentors engineers moving into AI. He writes about architecture, inference cost and the failure modes that only show up at production scale.
Share your details and we will talk soon.
Be the first to access expert strategies, actionable tips, and the trends actually shaping the digital world. No fluff - just practical insights delivered straight to your inbox.
Dive into our blog and stay ahead of the curve with expert perspectives, future-ready trends, and tech tips written for decision-makers and doers alike.
