A team can spend weeks preparing an export for an AI pilot and still be unable to answer a basic question: which record is authoritative? The file may be complete and technically accessible while containing duplicate customers, expired policies, inconsistent labels and information that the project has no permission to use.
“Is our data ready for AI?” is therefore not a database question. It means: ready for a defined task, used for an agreed purpose, by authorised people and systems, with known limitations and an owner who can keep it fit after launch.
Most organisations do not need to clean the whole data estate before starting. They need the minimum trustworthy evidence for one bounded use case and a clear account of what that evidence cannot support.
1. Purpose: define the decision or task
Write the intended use in operational language. “Use customer data with AI” provides no test for relevance. “Summarise the last three approved service interactions for an adviser before a call” identifies a user, task, source boundary and output.
The Government Digital Service: Artificial Intelligence Playbook for the UK Government starts AI delivery with the goal and user need, then asks whether AI is the right tool. This sequence prevents a common readiness error: collecting every available field before establishing which information the task requires.
For the proposed use, record:
- The trigger: what starts the task and how frequently it occurs.
- The user: who receives or acts on the output.
- The decision: what judgement or action the information supports.
- The consequence: what happens if the data or output is wrong.
- The alternative: how the work is completed without this system.
If the use cannot be framed this precisely, data assessment will expand without a finish line.
2. Inventory: trace the real data path
Map what the first release will actually touch: systems of record, document stores, exported files, knowledge bases, prompts, retrieved passages, model outputs, feedback and logs. Include the spreadsheets and manual notes that operations rely on but architecture diagrams omit.
For each source, name the owner, format, update cycle, retention, access method and authoritative status. Record how information moves from source to model and from output to user or downstream system. A simple lineage map often reveals that the “single source of truth” is supplemented by local corrections or that an approved policy is copied into uncontrolled folders.
Do not confuse connectivity with readiness. An application programming interface can make poor or ambiguous information easier to retrieve. It cannot resolve which record should prevail.
3. Permission: distinguish possible from permitted
A project team may be technically able to access data without being permitted to reuse it for model development, evaluation or a new operational purpose. Check confidentiality, contracts, intellectual property, personal-data responsibilities, sector restrictions, retention and cross-border processing.
Where personal data is involved, the Information Commissioner’s Office: accountability and governance implications of AI recommends clarifying controller and processor relationships and using DPIAs to identify and control risks where required. Permission should cover the full route, including test environments, model providers, observability tools and human review queues.
Apply least privilege by role and purpose. A knowledge assistant for one team should not inherit access to every repository available to its service account. Retrieval should enforce the user’s current permissions, and revocation should remove access without waiting for a full re-index.
4. Necessity: use the minimum data that can do the job
More data can increase coverage while also increasing noise, exposure and evaluation difficulty. The Information Commissioner’s Office: data minimisation principle describes personal data as needing to be adequate, relevant and limited to what is necessary. The AI-specific Information Commissioner’s Office: security and data minimisation in AI makes the practical point that necessity depends on the specific purpose.
Test whether the outcome can be achieved with fewer fields, shorter history, selected document sections or de-identified data. Separate development, evaluation and production. Synthetic data can help test plumbing and rare scenarios, but it is not evidence that the system will behave correctly on real distributions.
5. Quality: define fitness for this use
Quality is contextual. A stale address may be irrelevant to topic classification and critical to customer communication. Review accuracy, completeness, consistency, timeliness, uniqueness and coverage in relation to the chosen task.
Distinguish source-data accuracy from model performance. The Information Commissioner’s Office: accuracy and statistical accuracy in AI explains that factual accuracy of personal data is different from how often a model predicts the expected answer. Both matter, but they need different controls.
Create a defect profile rather than one quality score. Record missing mandatory fields, invalid formats, duplicate entities, conflicting values, stale records and unreliable labels. Identify which defects block the use, which can be handled as exceptions and which are acceptable because they do not affect the outcome.
Historical labels deserve special attention. They may reflect inconsistent human practice, policy changes or outcomes that the organisation does not want a model to reproduce. A large labelled dataset can be a precise record of yesterday’s process rather than a suitable target for tomorrow’s one.
6. Representation: know who and what is missing
Ask whether the data covers the people, document types, languages, products, channels and operating conditions in which the system will be used. Overall volume does not guarantee representative coverage. A classification model may appear accurate while failing on a small but consequential case type.
The NIST: AI Risk Management Framework places context in the Map function and measurement in the Measure function. Use that discipline to document the target population and conditions, then compare them with the available development and evaluation data.
Do not fill a missing group with invented assumptions. Narrow the intended use, collect evidence lawfully or retain a human route until performance can be assessed. Where personal data is used to address bias, check that the collection and processing itself has a valid basis and suitable controls.
7. Provenance: keep every material output traceable
For documents and retrieval systems, preserve source identity, version, owner, approval status and effective date. Users should be able to reach the record or passage supporting an answer. If sources conflict, the system needs a hierarchy or an exception; the model should not silently choose.
For structured data, record origin, transformations, joins and corrections. For inferred fields, label them as inferences rather than facts. For model outputs, retain the relevant model, prompt, retrieval and policy versions so an incident can be reconstructed.
The European Data Protection Board: Opinion 28/2024 on personal data in AI models addresses anonymity, legitimate interest and consequences related to unlawfully processed personal data. For European operations, it is a useful reminder that questions about training data and deployed processing cannot be reduced to whether a user can see a name in the output.
8. Evaluation: create a test asset that can be reused
A demo set proves that selected examples work. A decision-grade evaluation set represents normal cases, difficult cases, important minorities, missing information and unsafe requests. It has expected outcomes or review criteria agreed by people who understand the workflow.
Measure what matters for the task:
- Retrieval: whether the correct current source appears and unsupported sources are excluded.
- Generation: whether claims are supported, qualifications are preserved and uncertainty is visible.
- Classification: errors by important class, including false acceptance and false rejection.
- Decision support: whether a reviewer can understand, challenge and override the recommendation.
- Operations: exception volume, review effort, latency, cost and recovery when a dependency fails.
The NIST: Generative AI Profile can help teams identify generative-system risks to include in testing. Keep the set versioned and rerun it after material changes to data, prompts, models, tools or policies.
9. Ownership: make readiness continuous
Readiness decays. Policies expire, product structures change, permissions move and users alter their behaviour. Name owners for source quality, access approval, lineage, evaluation, change control and incidents. Define how they will detect stale data, failed ingestion and degraded system behaviour.
ISO: ISO/IEC 42001 AI management systems provides a management-system structure for objectives, responsibilities, risk and continual improvement. The standard cannot clean a dataset or validate a particular use; its value here is the insistence that ownership and review continue beyond the pilot.
A one-page readiness decision
A manager should be able to summarise:
- Use: the exact task, user, decision and consequence.
- Sources: what is necessary, authoritative and available.
- Permission: who approved each use and which restrictions apply.
- Limits: known quality, coverage, freshness and representation gaps.
- Evidence: the evaluation set, measures and decision thresholds.
- Ownership: who maintains the sources and who can stop the system.
The outcome need not be “ready” or “not ready”. It may be ready for a read-only prototype using approved documents, but not ready to write back to a customer record. It may be ready for one team and language, but not for enterprise deployment. Scope is a control.
The right answer is to stop when the purpose remains vague, necessary data cannot be used lawfully, critical defects cannot be measured, material groups are absent, or no owner can maintain the source after release. A larger model cannot repair contradictory source records, create missing permission or make an unobservable decision safe.
If the answers are clear, an organisation may be ready to test even when its wider data estate is imperfect. Data readiness is enough trustworthy evidence for the next bounded decision—not a promise that every dataset is clean.
Further reading: NIST: AI Risk Management Framework; Information Commissioner’s Office: guidance on AI and data protection; European Data Protection Board: Opinion 28/2024; ISO: ISO/IEC 42001 AI management systems.
