Data Readiness: Are You Actually Ready for AI?

“Are we ready for AI?” has no answer. “Is the data for this task good enough that a competent person could do the task from it?” has an answer, you can get it in a week, and it is the only readiness question that predicts anything.

Readiness is not a company property

Company-wide data maturity assessments produce a score, a heat map and a two-year programme. They are not wrong, exactly; they are answering a question that no upcoming decision depends on. Meanwhile the same company usually has one specific corpus that is entirely adequate for one specific task, and one that is a disaster for a task that looks superficially similar.

So the unit of assessment is the use case. Scope it precisely before starting: the task, the inputs the system would need, and the systems those inputs live in. Half the value of the week comes from writing that sentence down, because a surprising number of proposals do not survive it.

The five checks

1 — Can you actually produce the corpus?

Not “does it exist”. Can a named person export it, this week, without a new procurement or a new integration? Count the items, count the systems, and record who owns each system. A corpus spread across four systems where one is owned by a team with other priorities is not a two-week project regardless of how good the data is.

2 — How stale is it?

Pull the distribution of last-modified dates rather than the average age. What you are looking for is the fraction that is old enough to be wrong: policies superseded, prices changed, people who left. A corpus where a fifth of the documents contradict current reality will produce confident wrong answers, and the model will have no way to prefer the new one over the old one, because bad content in the context beats good training every time.

3 — Do the permissions travel with the content?

If two users must see different things, ask where the access rule lives and whether it can be retrieved alongside the content as a filter. A permission model that exists only in the source application and cannot be projected into an index is the single most common reason a promising retrieval project stalls — the patterns for doing it properly are namespace and filter designs, and they need the ACL to be a queryable field.

4 — The human baseline

The check that decides most outcomes, and the one usually skipped. Take 50 real examples of the task. For each, assemble only what the system would retrieve, hand it to a competent person who does not already know the answer, and ask them to do the task from that alone.

Their success rate is a ceiling on the system’s. If a person cannot answer the question from the retrieved material, the information is not in the corpus, and no model, prompt or retrieval improvement changes that — it is a data problem wearing an AI costume. This is also the exercise that tells you why: the answer lives in an email, in someone’s head, in a system you did not include, or in the gap between two documents that each say half of it.

5 — May you use it for this?

Three sub-questions with three different owners: is there a lawful basis for this purpose, does any customer contract restrict sub-processing of this data, and does the corpus contain personal or special-category data you have not accounted for. Sample the free-text fields before answering the last one — free text always contains more than the schema suggests, and detecting it needs more than a regex.

The week

MON   Scope. One sentence for the task. List the inputs and the
      systems. Identify the owner of each system and message them
      today, because their reply is the week's critical path.

TUE   Extract. Pull a real sample — 200 items if you can, 50 at
      minimum. Compute the last-modified distribution while you
      are there. Note anything you could not get and why.

WED   Human baseline. 50 examples, assembled context only, one
      reviewer who does not already know the answers. Record the
      success rate and, for each failure, where the missing
      information actually lives.

THU   Permissions and legal. Where the ACL lives and whether it
      is queryable. Lawful basis, contract restrictions, and a
      scan of free text for personal data.

FRI   Score, write one page, and name the decision: proceed,
      narrow, or pick a different use case.

Wednesday is the day that produces the finding. Book the reviewer in advance and do not let the exercise slip, because every other day produces facts and this one produces the answer.

The scorecard

Each check scored 0, 1 or 2.

  0  blocking as it stands
  1  workable with a named piece of work
  2  fine today

  1  producible corpus
  2  freshness
  3  permissions travel
  4  human baseline           <- weight this one double
  5  lawful to use            <- a 0 here is a stop, not a score

Total out of 12 (with check 4 doubled):

  10-12  proceed
   7-9   proceed on a narrowed corpus, and say which part
   4-6   the data work is the project; re-scope or re-pick
   0-3   pick a different use case

Check 4 is doubled because it subsumes several things a separate check would measure badly: coverage, quality, structure and whether the task is even well posed. Check 5 is a gate rather than a score because no amount of strength elsewhere compensates for not being allowed to use the data.

What a failure actually means

A low score is not a mandate for a data programme. It is one of three much cheaper conclusions, and picking the right one is most of the value of having run the assessment.

• Narrow the corpus. Very often one subset is clean, current and permissioned while the whole is not. A system that answers confidently about the newest product line and abstains elsewhere is more useful than one that is unreliable everywhere.
• Change the task. If the human baseline failed because answers require judgement that is not written down anywhere, the model cannot supply it either — but drafting, summarising or routing the same material may be well within reach. Move down the ambition ladder rather than up the data ladder.
• Pick a different first use case. Feed the scores back into the selection rubric — this assessment is precisely how the data-readiness axis gets an honest number rather than an optimistic one.

The one conclusion to resist is “fix the data first, then do the AI project”. Data quality work with no consumer has no acceptance criteria and no end, and it tends to outlive the enthusiasm that funded it. If the data must be improved, improve exactly the slice this use case needs, with the human baseline as the test that says when you are done.