AI Readiness vs Data Readiness

Data readiness concerns whether specified information can support an intended use: it is understandable, appropriately available, sufficiently reliable and usable under the relevant conditions. AI readiness concerns the whole proposed activity, including the information, technical approach, evaluation, action authority, people and operating arrangements. A favourable finding about the data answers only part of the wider question.

This distinction helps a CIO and a business owner avoid talking past each other. The data team may have delivered a well-controlled dataset. Operations may still lack a way to review ambiguous outputs or prevent an unapproved customer commitment. Both statements can be correct. The useful response is to identify the missing dependency and its owner, rather than asking one team to accept responsibility for every remaining condition.

Define the intended use before calling data ready

Data has no single universal readiness state. The same records can be adequate for summarising historical workload and inadequate for training a predictor. A document collection can support internal discovery while lacking the authority needed to answer a customer's contractual question. The assessment must identify the task and the decision consequence before choosing quality measures.

The W3C Data Quality Vocabulary Working Group Note provides a way to describe quality information so users can judge fitness for purpose; it does not provide a complete universal definition of quality. That distinction is useful here. The practical comparison below is an original assessment method, not a W3C AI-readiness standard or a required certification.

Specify the relevant population, source versions, time window, permitted users and proposed transformations. For predictive work, identify when each input would have been available. For retrieval, identify which source is authoritative for which question. For an action workflow, identify whether the information is current enough to support the action and whether the destination can enforce the decision.

A data team should be able to state the limits of its conclusion. “These order lines can be interpreted against this catalogue snapshot for this offline matching exercise” is more useful than “the catalogue is AI-ready”. The first statement can be examined. The second invites every later project to assume that its own questions have already been answered.

A bookseller's purchase orders show the difference

Consider a hypothetical wholesale bookseller receiving purchase orders from schools and retailers. It wants an assistant to extract order lines and propose matches to approved catalogue records. The proposal retains human approval for uncertain editions, languages, bindings and quantities. The assistant is not authorised to substitute a title, change a commercial term or place an order with a publisher.

The source documents contain mixed Arabic and English descriptions. Some customers quote the bookseller's internal item code; others quote a publisher reference; some provide only a title and an edition year. A matching result must preserve the customer's requested variant. Finding a similar title is not enough if it identifies a different language edition or a different pack size.

Suppose a deliberately constructed diagnostic batch contains 240 order lines. A deterministic lookup finds one catalogue candidate for 180 lines, several candidates for forty, and no candidate for twenty. These are illustrative counts, not measured business results. They describe lookup outcomes in this batch; a single candidate has not yet been shown to be the correct match.

All 240 lines might contain a non-empty item-description field, giving complete field presence under that definition. Yet only 180 have a unique lookup candidate, which is 75 per cent of the batch. Neither measure proves semantic correctness. The difference shows why an attractive completeness percentage can coexist with unresolved work that matters to the proposed AI task.

The data-readiness question is whether the inputs, catalogue meaning and evaluation evidence are suitable for the proposed matching test. The wider AI-readiness question includes whether reviewers can resolve uncertainty, how the interface presents alternatives, which actions remain prohibited, and whether the workflow has enough capacity to handle the unresolved lines.

Follow the boundary from information to work

Data evidence and wider AI prerequisites for the bookseller

Boundary	Data-readiness evidence	Additional AI-readiness evidence
Interpret the request	Readable order lines with preserved language, edition and quantity context	A task definition that requires clarification when the request is ambiguous
Find a candidate	Catalogue identifiers, variant relationships and current source ownership	A matching approach evaluated against suitable reference decisions
Judge the proposal	Evidence explaining which source supports each proposed match	Reviewers with relevant knowledge, available time and a usable interface
Use the result	Correct destination identifiers and data-field meanings	Authority limits, approval conditions and a controlled handoff
Maintain the service	Update and correction history for the relevant records	Operating ownership, support, change review and a fallback process

The columns overlap because information and work are connected. The purpose of separating them is accountability. A catalogue steward can correct an edition relationship but cannot, merely by doing so, authorise automated substitutions. A process owner can approve a workflow but cannot declare a missing historical source available. The assessment should make the relationship explicit.

For questions about which record should prevail, source authority and business meaning provides a deeper method. For what a proposed interface must actually permit and confirm, use integration and action readiness. Those investigations support the wider decision without turning a data-quality report into a blanket deployment approval.

Clean data can still leave the workflow unready

Assume the bookseller resolves every ambiguity in a small authorised test set. Each order line now has a defensible reference match. The dataset may be ready for a controlled experiment. The business may nevertheless be unable to run a live pilot because the proposed reviewer cannot see the original request or because the application writes directly into a purchase-order system before review.

These are not defects that can be solved by increasing the dataset's completeness score. They concern how evidence is presented and how authority is enforced. The response may require a different interface, a draft-only destination or an explicit review queue. Until those conditions are demonstrated, keep the conclusion limited to the data or offline experiment.

Evaluation is another independent dependency. Correct catalogue records do not establish that the proposed matching approach uses them correctly. Define acceptable matches, unacceptable substitutions, appropriate clarification and cases that should remain unresolved. Use held-out examples suited to the intended conditions; do not repeatedly tune against the same cases and then describe the resulting score as independent evidence.

Human review also needs a task-specific standard. A reviewer who checks only that the title looks familiar may miss a different edition or language. The proposed workflow must make those distinctions visible and give the reviewer enough information to reject an attractive but unsupported match. Training attendance alone does not establish that this can be done.

An imperfect archive does not rule out every useful experiment

The opposite mistake is to insist that all corporate information must be repaired before any AI investigation can begin. A bounded, authorised subset may be sufficient to examine a defined question. The important conditions are that the subset is suitable for that question, its exclusions are explicit, and the conclusions are not extended to unexamined records.

For the bookseller, an experiment might initially cover a particular catalogue family with interpretable identifiers and complete reference decisions. It can investigate how well the approach handles the selected input variations. It cannot establish readiness for every publisher, historical edition or customer document merely because the restricted test worked.

Keep deliberate exclusions visible in the experiment record. If poor scans, handwritten amendments or mixed-language titles are removed, state why and explain what remains unknown. Excluding those cases may be sensible for a narrow question. Concealing the exclusion would make the result misleading when someone later uses it to approve broader operation.

The representative data-quality samples guide explains how selection changes what can be inferred. A diagnostic set can be excellent for discovering failure mechanisms while being unsuitable for estimating their frequency. Readiness depends on whether the evidence matches the claim being made, not on whether every sample has the same design.

Write two admission statements

An admission statement describes the conditions under which a dataset or activity may enter the next stage. Two short statements can prevent a common handoff error: the receiving team hears “data accepted” and assumes “system approved”. The statements should name the scope, unresolved conditions and person authorised to accept the next step.

A dataset statement for the illustrative case might read: “The specified catalogue snapshot and selected order lines may be used for the offline matching experiment. Reference decisions have been reviewed for the selected variants. Other catalogue families and unresolved source interpretations remain excluded.” This states information fitness for one purpose without granting action rights.

A workflow statement might read: “The proposed assistant may produce reviewable match suggestions in the test environment. It may not substitute products or modify orders. A live pilot requires demonstrated reviewer access to the original request, accepted ambiguity handling and an approved destination handoff.” The additional conditions make clear why the data decision and workflow decision are not interchangeable.

These are original specimen statements, not legal forms or official readiness declarations. Adapt them to the actual decision and retain links to evidence. A signed statement with vague scope is weaker than a clear, reviewable statement whose unresolved conditions are understood. The gate-versus-score guide explains how to keep essential conditions outside a compensating average.

Interpret quality measures at the right level

Choose the unit of measurement before reporting a number. A purchase order can contain many lines; a line can contain several quantities or variants; a catalogue title can exist in multiple editions. Counting documents, lines and unique titles answers different questions. Do not switch between them when presenting completeness or matching results.

Illustrative measures that should remain separate

Measure	Illustrative result	Permitted interpretation
Non-empty descriptions	240 of 240 order lines	The selected field is populated in this batch
Unique lookup candidates	180 of 240 order lines	75 per cent return one candidate under the lookup rule
Multiple candidates	40 of 240 order lines	These lines need disambiguation under the proposed workflow
No candidate	20 of 240 order lines	The lookup rule finds no match; the cause still requires investigation
Correct accepted matches	Not established by these counts	Requires reference judgement and evaluation of the proposed approach

A no-candidate result may reflect a missing catalogue item, a source error, a different identifier system or a genuinely unavailable title. Those causes imply different remedies. Automatically treating every unmatched line as bad source data can waste remediation effort and conceal a limitation of the matching method.

Similarly, a correct match rate needs a defined reference process. If reviewers disagree about acceptable editions, resolve the decision rule before using their labels as an evaluation standard. Preserve unresolved cases rather than silently assigning a convenient answer. The work may reveal that the business needs a clarification workflow more than a more confident matcher.

Inspect the namespace of an identifier as well as its value. In an illustrative extension, supplier code B-31 belongs to one edition in one publisher file and another edition in a different file. A lookup that drops the publisher identifier may still return a single row because it keeps the last imported record. The result is technically unique but cannot support the intended match. Preserve the compound business key and the rule that establishes its meaning.

Also inspect the transformation that produced a quality measure. Trimming spaces may be harmless for one identifier and alter another. Combining duplicate-looking records may remove a meaningful variant. Ask the source owner to explain the transformation and retain examples of its effect. The assessment should be able to distinguish a genuinely improved source from a cleaner-looking table whose processing has concealed information required by the task.

Include the effort required to handle uncertainty

The batch contains sixty lines without a unique candidate. Suppose, solely for planning, each requires six minutes of human investigation. That is 360 minutes, or six hours, before considering review of the uniquely matched lines. If only three reviewer-hours are available during the relevant daily window, the assumed workflow cannot clear that exception workload in the window.

This arithmetic is not a forecast of the bookseller's real operations. The batch was diagnostic, and the six-minute assumption needs measurement. It illustrates a separate readiness question: can the intended process absorb the uncertainty that the data and model leave unresolved? A data team can reveal the cases; a business owner must decide how the work will be handled.

Possible responses include narrowing the pilot, arranging additional review time, improving source collection or changing the outcome expected from the assistant. Removing uncertain cases from a performance denominator does not remove their operational cost. Keep them in the workload analysis even when they are legitimately excluded from a particular model metric.

Check updates, rights and the actual access path

A static extract may be fit for an offline experiment while the live update path remains unsuitable. Catalogue changes can introduce new editions, withdrawn items or corrected relationships. Establish which changes matter to the task, who maintains them and how a later assessment will identify the version used in a recommendation.

Availability is also specific to a role and purpose. An administrator's ability to export a catalogue does not establish that every intended application user should receive every field. Review licensed content, supplier restrictions and any personal information with the appropriate owners. The assessment records the permitted-use decision; it should not infer permission from technical accessibility.

Test the path the proposed service will use. A spreadsheet prepared by an expert may contain repaired identifiers that the live interface does not supply. An internal search screen may show context that an API omits. Document those differences so a positive finding about the prepared dataset is not transferred to a materially different input path.

Give each unresolved condition an owner who can change it

Assign source interpretation to the people who understand and maintain the records. Assign workflow acceptance to the business owner who is responsible for the consequences. Assign technical feasibility and access verification to the appropriate system owners. Some conditions require a joint decision, but joint involvement should not mean that no one is accountable for obtaining the evidence.

Write remediation items as observable changes. “Improve catalogue quality” does not identify a completion point. “Clarify the relationship between the two identifier systems for the selected publisher family and verify the agreed examples” is more actionable. Record which experiment or pilot remains blocked and what evidence will allow the decision to be revisited.

The data remediation backlog guide develops that handoff. It also helps distinguish a local correction from a recurring source-management issue. A successful one-off cleanup may support an experiment while still leaving the long-term maintenance process unresolved. Both facts belong in the readiness record.

Choose the assessment boundary that answers the real question

If the immediate uncertainty concerns data meaning, access, quality or history, commission a focused data-readiness investigation with a defined intended use. If leadership must decide whether an AI workflow can enter a controlled pilot, include the wider prerequisites. Specify the output expected from each workstream so procurement does not compare an extraction review with an end-to-end readiness engagement.

Before accepting a broad “AI-ready” claim, ask what the evidence covers and what remains to be demonstrated. The definition of an AI readiness assessment provides questions for interpreting that conclusion. A clear boundary allows the organisation to proceed where evidence supports it while directing effort toward the conditions that genuinely remain unresolved.

Open for AI's enterprise data and AI readiness assessment connects source-level findings to the proposed business step. For a readiness assessment discussion, bring a permitted sample, the decision the information must support, and a description of the intended user and action. Together these make it possible to distinguish a data problem from a wider readiness dependency.