Is Your Data Ready for AI? A One-Page AI Data Readiness Checklist

Readiness is about fitness for a purpose

Data that is perfectly adequate for monthly reporting can be unfit for a model. Reporting tolerates late corrections, aggregated values and the odd gap. A model that scores individual records, or a retrieval system that answers staff questions from policy documents, does not. The standards community uses the same framing. The ISO/IEC 5259 series (data quality for analytics and machine learning) defines quality characteristics and measures relative to the intended use. Part 5 assigns oversight of data quality to governing bodies, not only to technical teams.

So start by writing the use case in one sentence: what decision or task the AI supports, for whom, and what a wrong answer costs. Every question below is asked against that sentence.

Quality: is the data accurate, complete and representative enough for this use?

The quality model in ISO/IEC 5259-2 builds on established data-quality standards and adds characteristics that matter for machine learning. In practice, leaders should ask:

• Accuracy. For the fields that matter most, what is the measured error rate? Has anyone sampled records against the source of truth?
• Completeness. What share of records is missing key fields? Are the gaps random, or concentrated in particular regions, products or customer groups?
• Timeliness. How old is the data when the AI uses it? Does that match how fast the real world changes for this use?
• Representativeness. Does the data cover the situations the system will actually meet, including unusual cases, outliers and recent changes? NIST SP 1270 explains how unrepresentative data introduces bias, and why that is partly a human and process problem rather than only a statistical one.
• Labels and ground truth. If the use case needs labelled outcomes (for example, "this invoice was fraudulent"), how were the labels produced, how consistent are they, and who checked them?
• Unstructured content. For document-based and generative uses: are documents current and de-duplicated? Is the authoritative version identifiable? Are superseded policies removed or marked? The NIST Generative AI Profile suggests verifying the provenance of training and test data, and checking that data used for fine-tuning or retrieval-augmented generation is grounded (action MS-2.5-005).

Access: may you use it, and can the system reach it safely?

Many pilots stall here, usually late, after the build has already started.

• Rights and purpose. Do contracts, privacy notices, consent terms or licenses allow this data to be used for this purpose? Customer contracts and third-party data licenses often restrict secondary use.
• Sensitivity. Does the data include personal, health, financial, export-controlled or Controlled Unclassified Information? If so, which environments and vendors are allowed to process it?
• Vendor handling. If an external AI service processes the data, what do its terms say about retention, use for training, processing location and sub-processors?
• Technical access. Is the data reachable through a supported interface such as an API, a warehouse or governed extracts? Or does it depend on one person's spreadsheet export?
• Least privilege. Will the AI system see only what the user of that system is allowed to see? Retrieval systems that ignore document permissions are a common way to leak data.

Lineage: can you trace where it came from and what was done to it?

The NIST AI RMF notes that maintaining the provenance of training data supports transparency and accountability, and its MEASURE function expects test sets and metrics to be documented. Federal agencies already face this in OMB M-25-21. Its impact assessments for high-impact AI must summarize the data used and its fitness for the intended purpose. Contractors selling AI to agencies should expect similar questions.

• Source systems. Which systems produced the data, and which one is authoritative when they disagree?
• Transformations. What joins, filters, de-duplication and enrichment steps were applied? Are they in version-controlled code, or in undocumented manual steps?
• Versioning. Can you reproduce the exact dataset used to train or evaluate a model, or to build an index, on a given date?
• Provenance metadata. For external or purchased datasets, do you know the origin, collection method, collection period and license? The Data Provenance Standards define a compact set of fields for exactly this. Open specifications such as OpenLineage capture pipeline lineage automatically in many data tools.
• Change detection. Will someone be alerted if an upstream system changes a field's meaning, format or fill rate?

Ownership: who answers for it?

Data without an owner degrades, and AI makes that faster to see.

• Data owner. Is there a named business owner for each critical dataset who can approve its use and settle questions about its meaning?
• Steward and maintenance. Who fixes quality issues when they are found, and how fast?
• Definitions. Are key terms ("active customer," "closed case," "on-time delivery") defined once and used the same way across sources?
• Feedback loop. When users of the AI system find wrong answers caused by bad data, where do they report it, and who acts on it?
• Funding. Is ongoing data maintenance in a budget, or only the pilot?

How to score the result

Rate each area ready, ready with conditions or not ready, and record the conditions:

• Ready in all four: fund the pilot.
• Conditions in one or two: fund the pilot with those conditions as tracked tasks that must be closed before production.
• Not ready on access or ownership: fix those first. Technical work cannot make up for missing rights or an absent owner.
• Not ready on quality or lineage: consider a short, separately funded data-preparation phase with its own success measure, before any model work.

The one-page checklist

Use case (one sentence): decision or task · users · cost of a wrong answer

Quality

• Error rate measured on the fields that matter
• Missing-data rate known, and its pattern understood
• Data is fresh enough for this use
• Coverage includes the cases the system will meet
• Label quality checked, if labels are needed
• Documents current, de-duplicated and authoritative, for generative uses

Access

• Contract, license and privacy terms allow this use
• Sensitive data classified, with approved processing locations
• Vendor retention, training and location terms reviewed
• Stable, supported technical access path
• The system enforces each user's existing permissions

Lineage

• Source systems and the authoritative source identified
• Transformations in version-controlled code
• Datasets reproducible by date
• Provenance recorded for external data
• Upstream change alerts in place

Ownership

• Named data owner who can approve use
• Steward with a fix-time expectation
• Shared definitions for key terms
• User feedback route for data errors
• Ongoing maintenance funded

Verdict: ready / ready with conditions / not ready · conditions and owners · review date

Getting help

If you are about to fund an AI pilot and want an independent read on whether the data will support it, tell us about the use case. We will reply with a short scope and a timeline, or tell you plainly if we are not the right fit.

All insights