Data readiness for AI is whether the specific data a piece of AI work needs is reachable, permissioned, current and accurate enough for that work to run - not a general score for how tidy an organisation's data is.
You test it by naming one use case, checking its data against five things in turn, and doing that checking inside a week rather than a quarter. A use case can be data-ready while the rest of the company is nowhere close, because readiness belongs to the use case, not to the business it sits inside.
"Your data is not ready" gets used for two different problems, and mistaking one for the other is expensive. One is real: this specific use case cannot reach what it needs, or what it reaches is stale or wrong. The other is a multi-year data programme proposed before anyone has named a use case at all, wearing a technical objection so nobody has to say no out loud. The test below tells you which one you are looking at, and it does not need a data engineer to run it.
This is written for an ops lead, COO or chief of staff who has been told the data is not ready and has one week to find out whether that is true. You need one thing before you start: a use case specific enough that someone could describe what it does in a sentence. "Improve how we use AI in operations" is not a use case. "Draft first-pass responses to supplier queries from the last 12 months of correspondence" is.
Why "your data is not ready" only means something once you have named a use case
Data readiness is a property of one named use case, not a property of a company, because reachable data for a chatbot answering supplier queries is a completely different bar from reachable data for a model forecasting demand off five years of transactions. Gartner makes this point directly: there is no way to make data AI-ready in general or in advance, because readiness depends entirely on how the data will be used.
That is why the objection needs pinning down before you can test it. Ask whoever raised it to name the use case the objection applies to. If they can, you have something to test this week. If the honest answer is "all of it, eventually", you are not looking at a data problem. You are looking at a decision nobody wants to make, using data as the reason it has not been made yet.
What AI-ready data actually means
AI-ready data satisfies five things at once for the use case in front of you: it is reachable by the tool, permissioned for the people who will use it, current enough to answer with, structured enough for the task, and correct. Miss any one and the use case does not work, whatever the other four look like. Data is also one of the four things a full readiness assessment measures, alongside tool access, governance and people - the test below is what a proper look at that one dimension involves.
Reachable. The tool can actually get to the file, table or system, technically, not just in principle.
Permissioned. The people who will use the tool are allowed to see this data, and the tool is allowed to process it under the terms it was collected on.
Current. The newest record is recent enough that an answer built on it would not be wrong.
Structured enough for the task. Not structured in general - structured enough for this one job, which is a lower bar than most people assume.
Correct. What is in the record matches reality, not just a plausible-looking number someone entered once.
The middle one is where most teams get the ambition wrong. "Structured enough for the task" is not the same target as "well governed", and confusing the two is how a one-week test turns into a data warehouse business case. A folder of PDFs with consistent formatting is structured enough for a tool answering questions from their content. It is nowhere near structured enough for a model reconciling numbers across them. Same folder, two different verdicts, because the task changed.
How to run the test in a week
Run one check per property, in order, against the single use case you named, and you will have an answer inside five working days without booking a single workshop.
Day 1, reachable. Open the actual source the use case would read from and try to get the tool, or a person standing in for it, to the specific record it needs. Time how long it takes. If nobody can find it by hand, no model will find it either.
Day 2, permissioned. Ask whoever holds the record of processing activities whether this source is covered, and check the access list against who would actually use the tool. Two separate questions, both answerable in an afternoon.
Day 3, current. Find the newest entry in the source and compare its date against how fresh the use case needs it to be. A pricing tool needs today's numbers; a policy lookup can run on last quarter's document.
Day 4, structured enough. Pull three real examples of the input the use case would see, not the tidiest three, and check whether the format is consistent across them. Inconsistent is fine if the tool can still parse it; unreadable is not.
Day 5, correct. Take ten records the use case would rely on and verify them against a source you trust more. A 90% hit rate on this sample is a different problem, and a smaller one, than a 40% hit rate.
Write down a pass or fail for each day before moving to the next one, with the specific evidence behind it. "Mostly fine" is not a result. "Seven of ten supplier records matched our accounts system" is.
Why document-retrieval and analytics use cases need different things
A tool answering questions from documents tolerates far messier data than a tool calculating a number, because the two fail differently when the data is imperfect. Retrieval-style work, where a tool searches a set of documents and answers from what it finds, degrades gracefully: an inconsistent heading style or a mixed date format slows it down but rarely produces a wrong answer, because the tool is reading for meaning rather than doing arithmetic on a column.
Analytics and forecasting work does not get that grace. A single wrong or duplicated row does not get filtered out by context, it gets averaged in, and the model reports a confident, wrong number. That is why the same folder of supplier invoices can be fully AI-ready for a tool that answers "what did we agree with this supplier" and nowhere near ready for a tool that forecasts next quarter's spend from the same files. Know which kind of use case you are testing before you set the bar, or you will fail a use case that would have worked, or pass one that will not.
How to tell a data problem from an access problem
A data problem is when the information does not exist in usable form; an access problem is when it exists but the tool or the person is not permitted to reach it, and the two need completely different fixes. Security blocking a sanctioned tool from an internal platform is not evidence the data is unready. It is evidence of a permissions decision, and permissions decisions are usually a conversation, not a rebuild.
This distinction matters because assistants embedded in existing software inherit whatever the signed-in user can already see. Microsoft states plainly that Microsoft 365 Copilot only surfaces organisational data to which the individual user already has at least view permissions, so a tool that appears blocked is frequently a permissions setting rather than a data gap. Check who can see the source manually before concluding the data itself is the obstacle.
Where personal data is involved, that permissions check has a paper trail. The ICO's guidance on accountability and governance in AI sets out when a data protection impact assessment is required, and processing personal data with a new tool usually triggers one. If nobody can point to that assessment, you have found a governance gap, not a data quality one, and the fix runs through legal rather than through data cleaning.
What usually goes wrong
The test fails most often on day 2 or day 5, not day 1: teams assume reachability is the hard part and discover permissions or accuracy is the real blocker, after already spending the week on the wrong worry. The second most common failure is skipping the use case entirely and running the five checks against "our data" in general, which produces a result nobody can act on, because a vague fail does not tell you what to fix.
A composite score makes this worse rather than better. Scoring each of the five from one to five and averaging them hides exactly the one that is blocking you, in the same way a single maturity number hides the one constraint holding an AI programme back. A use case that is a five on four properties and a one on the fifth does not average to a three. It fails, full stop, on the one property, and averaging it away is how teams spend a quarter on the wrong fix.
The formats that break this test most often - scanned PDFs, screenshots pasted into slides, spreadsheets with merged cells - are worth checking on their own terms, and ivee's AI readiness checklist has that check written out with a stated pass and fail. Not testing at all is the most expensive failure of the five, though. In ivee's survey of 500 UK AI decision makers conducted in August 2026, 96% cannot show the numbers on their organisation's AI spend, and a use case nobody tested before committing budget to it is a common reason why.
FAQs: data readiness for AI
How do you know if your data is ready for AI?
Name one use case, then check its data against five things: whether the tool can reach it, whether the right people and the tool are permitted to use it, whether it is current enough to answer with, whether it is structured enough for that specific task, and whether what it contains is correct. A pass on all five for that use case means the data is ready for it. It says nothing about any other use case.
What does AI-ready data actually mean?
It means data that is reachable, permissioned, current, structured enough and correct for one specific piece of AI work. It is not a fixed property of a dataset and it does not transfer automatically from one use case to the next, because a data source that is ready for a document-retrieval tool can still fail an analytics tool reading the same files.
Is data quality the same as data readiness?
No. Data quality describes whether a dataset is accurate and consistent on its own terms. Data readiness describes whether that dataset, plus the permissions and access around it, actually works for a named piece of AI work. A dataset can have excellent quality and still fail readiness, most often on permissions or currency rather than on the numbers themselves.
How long does testing data readiness take for one use case?
About a week, run as five roughly day-long checks: reachability, permissions, currency, structure and accuracy, in that order. Most of the week is not spent testing, it is spent waiting for someone else to answer a question, which is why running the checks in parallel with the right people booked in advance matters more than the checks themselves.
If the test comes back fine, you have a use case worth piloting. If it does not, the result tells you exactly what to fix and who owns fixing it, which is worth more than a general data programme nobody can finish. Sometimes the honest answer is that the remediation really is the size everyone feared, and in that case a second opinion is cheaper than finding out six months into a rebuild that was not needed. Talk to ivee about running the diagnostic properly.
