Data Readiness Before AI: A Practical Decision Framework

1. Begin with the decision the data will support

Define the output, its user, when it is needed, and the consequence of error. An assistant answering leave-policy questions needs authoritative current sources. Demand forecasting needs consistent history and factors that explain change. One universal quality checklist will not serve both.

Write a simple use-case contract: required inputs, intended output, update frequency, acceptable accuracy, and excluded cases. This prevents the team from collecting everything available and forces every data element to justify its role.

• What decision or task is being supported?
• What time horizon is required?
• What is the impact of error or delay?
• How will the result be verified?

2. Know the source, owner, and data path

Every important field has a history: where it originated, who entered it, how it changed, and where it was copied. Data lineage means being able to trace that history. A company does not need a complex platform to begin; it needs a clear map of sources, integrations, transformations, and owners.

If “total sales” comes from the order system and is then adjusted in a finance spreadsheet, decide which is authoritative and why. If product descriptions are copied among teams, name the owner of the final text. A source without an owner has no reliable route for correction.

3. Measure quality against the purpose

Test completeness, accuracy, freshness, consistency, and uniqueness, but do not treat them as cosmetic scores. Connect each defect to the outcome. A missing phone number may be irrelevant for inventory analysis and critical for customer contact. Week-old data may suit monthly planning and fail real-time routing.

Use a representative sample that includes ordinary and exceptional cases. Quantify missing fields, duplication, impossible values, and source conflicts, then review a sample with a business expert. Numbers expose patterns; experts explain what those patterns mean.

4. Align meaning before training or integration

Data can be complete while carrying different meanings. Is an active customer someone who bought in the last month or year? Does cancelled demand count as revenue? Does resolution time start at ticket creation or assignment? Semantic disagreement produces conflicting reports and models.

Create a compact glossary for consequential concepts, including definition, calculation, owner, and exceptions. Do not begin with hundreds of fields. Start with the terms used by the use case. Shared language makes AI output testable.

5. Design access and privacy from the start

Availability does not establish permission to use data. Define the purpose, minimum necessary data, authorized roles, retention, and whether the information is personal, sensitive, sector-regulated, or contractually restricted. Mask or aggregate when identity is not required.

An employee knowledge assistant may need general policies but not payroll records. Complaint-theme analysis may work on de-identified text. Minimization reduces risk and cost while making access review easier.

• A legitimate, specific purpose.
• The minimum data required.
• Role-based access.
• A record of use and change.

6. Use a readiness card and improvement plan

Rate each dimension visibly: relevance to purpose, source and ownership, quality, shared meaning, access and compliance, and the ability to update and monitor. Do not hide a critical blocker inside one combined score. Overall readiness may look high while lack of usage rights prevents the project.

Turn gaps into owned actions with dates: align an order state, repair an integration, archive an obsolete policy, or add a quality check. After critical blockers are addressed, run a prototype on a controlled sample and monitor change in production. Readiness is an operating condition, not a launch certificate.