An AI project can look promising in a workshop and struggle before anyone trains a model. The missing pieces are often ordinary: records cannot be joined, outcomes are not labeled consistently, or no team owns the decision the system is meant to improve.
A team proposes predicting service complaints but has only records of customers who contacted support. Silent dissatisfied customers are absent. Before training, ask whether the available labels represent the real problem or only the portion visible in a particular channel.
Inspect the data journey
Can the project obtain representative information legally and reliably? Are key fields complete, time-stamped and understandable? Would the available history have been known at the moment a real decision was made? That last question catches data leakage that can make a pilot look unrealistically strong.
Data readiness can be tested with a small manual exercise. Select a few past decisions and ask whether the project data would have been available at the time, whether the outcome is known and whether the decision owner agrees with the label. Disagreements reveal more than a generic “data quality is good” statement. Fix them before treating a model score as meaningful.
Check the labels and baseline
Ask how the outcome is recorded and whether it reflects the whole population. Investigated fraud cases, for example, are not a random sample of all transactions. Compare the proposed approach with a simple rule or current workflow.
Confirm the operating path
Name the user, intervention, review process and success measure. If a prediction arrives too late to change anything, better model training will not fix the business case. Data readiness is a practical go/no-go conversation, not an exercise in collecting every possible field.
