Data Readiness

What Data Readiness means

Data readiness is whether the data an AI project depends on is governed, reachable and good enough to use. Those are three tests, and data has to pass all of them. Data that is good but locked in a system a tool cannot reach fails. Data that is reachable but full of gaps fails. Data that is complete and reachable but ungoverned, so that nobody can say which copy is current, also fails.

The word “ready” matters. The term does not describe how much data a business has, or how modern its systems are. It describes the state of the specific data one specific piece of work needs, at the moment someone wants to start. A business can be data-rich and still not ready for a particular workflow, and a small business with one tidy shared folder can be ready for a task a large one is not.

The site’s production article calls it one of the most common weaknesses in an AI project, and one of the most directly fixable once it has been identified. Both halves of that sentence carry weight. The first says to expect the problem. The second says the problem is not a reason to stop.

What properly governed Data means

The production article uses the phrase “properly governed data” and defines it plainly: data whose quality, accessibility and structure have actually been addressed rather than assumed. The last word is the important one. Most businesses assume their data is fine because people get through the day with it. People are good at compensating. A person knows that the third column of the spreadsheet is out of date, that one client is entered under two names, and that the signed copy is the one in the email and not the one in the folder.

A tool knows none of that. It reads what it is given. If the quality, the access and the structure have only ever been held together by the memory of whoever does the job, then the data is not governed, however well it works in practice. Governing it means turning the knowledge that people carry in their heads into something written down and checkable.

The same article reports that organisations with properly governed data deploy AI roughly 2.4 times faster than those without it. That is the one figure on this page, and it is the production article’s, not ours. It does not promise any particular result for any particular business. It shows which way the difference runs.

Where an Audit looks for it

Data is the first of the five things an AI audit checks for a small or mid-sized business, alongside tools, workflows, people and risk. The audit article puts the first question this way: not how much data a business holds, but where that data actually sits and whether the tool under consideration could reach it at all.

The audit is looking at the physical reality of information. Where does a specific piece of information live, and who or what is able to open it? The article gives three pictures of what that turns up:

• a lead captured in one system and re-typed into another;
• a contract signed over email and never logged anywhere else;
• a report built by hand from three exports every Friday morning.

None of these appears if the audit only asks how much data the business holds. They appear when it asks where each input comes from. The article also names the clearest case: a process that runs on scattered spreadsheets, a shared inbox and one person’s memory has a data problem no model fixes, and the audit names that problem rather than recommending a tool on top of it.

The two Audit steps that touch Data

The five-step method looks at data twice, and the two looks ask different questions.

Step two is called “Follow your data”. With the processes mapped, the audit follows the data through them: where it comes from, where it goes and where it gets stuck. The step writes down inputs, decision rules, exceptions, handoffs and volumes in enough detail that the process could be rebuilt. It also records what is written down nowhere. Where a process runs only because one person knows something they have never had to explain, that is logged as a knowledge gap and a key-person dependency, by name of process and never by name of person.

That register is a data readiness finding in its own right. Knowledge that sits in one head is data that is not reachable, and a tool cannot read it.

Step three is “Identify the opportunities”. Here each candidate is weighed on how often it repeats, what the manual version costs in effort, whether the data it needs exists in a usable state, and what regulatory exposure attaches to it. A candidate that is technically possible but not worth doing is named and set aside, with the reason recorded. Data readiness is one of the reasons that can put a candidate low on the list. The opportunity identification page covers the ranking in full.

The audit page also lists real constraints a client sets, and one of them is a data one: data that cannot leave a jurisdiction. A constraint like that is part of readiness. Data that is good and reachable, but not allowed to go where a particular tool would send it, is not ready for that tool.

An illustration of Readiness deciding the order

The AI audit page walks through an illustration, labelled there as an illustration and not a real client. A small firm has a monthly report built by hand from three exports. The audit ranks that report first, and one of the stated reasons is that it repeats every month and the data exists in a usable state.

The same illustration shows the other side. The report is also built from three exports and one person’s memory, which the second step logs as a key-person dependency. Readiness is rarely a yes or a no. The data is usable, and one part of the process is still held in a head. Both facts go into the record, and the second one becomes something to fix.

The point of the illustration is the order. A task whose data is already in a usable state can be built soon. A task whose data is scattered has a step to take first. Readiness sets the sequence.

Why it behaves differently from other Gaps

The production article makes a distinction worth keeping. Skills gaps and process gaps tend to close gradually, through training, hiring and iteration over the course of a project. Data gaps behave more like a threshold. A workflow either has data clean and structured enough to build on or it does not, and no amount of downstream process improvement compensates for source data that was never assessed properly.

The article also says that this is why data carries the largest single weighting in most structured readiness scoring frameworks, and why it is usually the first dimension worth examining closely. For an organisation whose core workflows start from inconsistent or scattered source documents, the first step is usually improving data intake and governance, not trying to optimise decisions built on top of data that was never assessed.

The cost argument is the same one the article makes for any readiness gap. Finding the problem during a scoping exercise costs a conversation. Finding the same problem six weeks into a build costs a redesign. Data is where that difference is most likely to show up, because the gap often only becomes visible once a tool tries to read the real thing.

One more point from the article applies here. A headline readiness score can hide which dimension is doing the damage. Two organisations can land on the same overall number, one with weakness spread evenly and one with a single badly underweight dimension. Only the breakdown shows which is which. If data is the low dimension, that is the fix to make first.

Data Readiness and Grounding

Data readiness matters most visibly when an assistant is asked to answer from a business’s own documents. The grounding page describes the pattern: a person asks a question, the assistant answers from a named document, and the answer can be checked against it. The advanced ChatGPT programme builds document-grounded question and answer on an organisation’s own files, and the Copilot Chat course builds an HR policy assistant grounded in the handbook.

All of that depends on the documents being worth grounding on. An assistant pointed at a handbook that has three conflicting versions will answer from one of them, and the answer will still be traceable to a document. Traceable is not the same as right. Grounding makes a wrong source easy to find, which is useful, but it does not make the source correct. Whether the right version exists, is named, and is the one the tool reads is a data readiness question.

The grounding page also notes that which content a tool is grounded in is a decision, and a decision about data. That decision is made far more easily when the documents were already organised.

Data Readiness and Data Protection

The two terms sit next to each other and are easy to merge. They are different questions about the same material.

Readiness asks whether the data is governed, reachable and good enough to use. Data protection asks how personal data may be collected, used and stored wherever an AI system touches it. The first is about whether the work can be done. The second is about whether it may be done, and how.

They meet at the audit. Where a tool would touch personal data, the audit checks it under data protection rules before the tool is recommended, not after it is already in use, because a data protection problem found after roll-out costs far more to unwind than one flagged at the scoping stage. The data protection page adds that obligations attach to what a system does with data, not to where it is hosted. So the question of where data goes belongs in the same conversation as the question of whether it is usable.

What to do first

Pick one workflow, not the whole business. Then ask four plain questions about the data it runs on:

1. Where does each input actually sit, and in which system or inbox?
2. Who or what can open it, and could the tool under consideration?
3. Is there one agreed version, or several, and who says which is current?
4. Does the knowledge that makes the process work exist anywhere except one person’s memory?

If the answers are clear, the data is probably ready for a first narrow prototype. If they are not, the work to do is on the data, and the production article says exactly that: improve intake and governance first, then build. An audit is where those questions get asked in a fixed order, and the AI governance page covers the rules that keep the answers true afterwards.

Readiness is not a one-off. A business that fixes its data for one workflow has a method for the next, and the written process record from step two of an audit keeps its value even if nothing further is commissioned.

See what predicts whether an AI project reaches production and what an AI audit actually checks for the full arguments.