What This Template Covers
The AI data requirements checklist covers six areas that together define whether your data position is strong enough to build a reliable AI product. The data inventory section establishes what data exists, where it lives, and what it represents. This is the starting point. Many teams discover during this section that the data they assumed existed is either missing, incomplete, or in a format that requires significant transformation before it can be used. The training data requirements section covers the volume and composition of data needed to train or fine-tune a model, or to build an evaluation benchmark. Volume requirements vary enormously by task type. Classification models may need a few hundred labelled examples per class. General-purpose LLM fine-tuning requires significantly more. RAG systems need a well-curated knowledge base rather than large volumes of raw data. The data quality standards section defines what constitutes acceptable data quality for each type. Accuracy, completeness, consistency, and timeliness are the core dimensions. For labelled datasets, inter-annotator agreement is an additional quality measure. The data pipeline section covers how data flows from source to model. Who is responsible for extraction, transformation, and loading? How frequently is the data updated? What happens when the source data changes structure? The GDPR and governance section covers lawful basis, data minimisation, retention limits, pseudonymisation requirements, and data subject rights that affect how data can be used in AI training and inference. The evaluation dataset section covers the hold-out data needed to measure whether the model is working correctly and improving over time.
How to Use This Template Step by Step
Step one: run a data inventory. For each AI capability your product requires, list the data types needed as inputs and the data types that will be generated as outputs. For each input data type, record: where it currently exists (internal systems, third-party sources, to be collected through the product), the current volume, the update frequency, the format, and the access method. Step two: assess data quality for each data type. Use the four-dimension quality assessment: accuracy (what percentage of records are correct?), completeness (what percentage of required fields are populated?), consistency (are the same concepts represented the same way across records?), and timeliness (how current is the data, and does staleness affect the AI task?). For each dimension, score current quality and set a minimum acceptable threshold. Step three: identify the labelling requirements. For supervised learning tasks, you need labelled data. For each label type, define: the labelling taxonomy (the full list of labels and their definitions), the labelling process (who does it, what tools, what quality control), the target volume (how many labelled examples are needed), and the inter-annotator agreement target (typically Cohen's kappa of 0.7 or higher for reliable labelling). Step four: design the data pipeline. Map the flow from source to model. For each step in the pipeline, document: the transformation applied, the tool or service that performs it, the expected failure modes, and the monitoring approach. Data pipelines that fail silently produce unreliable AI outputs without any obvious indication that something is wrong. Step five: complete the GDPR and governance checklist. For each data type that includes personal data, document: the lawful basis for processing under GDPR Article 6 (and Article 9 for special category data), whether the use of this data for AI training is covered by your current privacy notices, the pseudonymisation or anonymisation applied, the data retention period, and whether the data is transferred outside the UK or EU (which triggers transfer mechanism requirements under UK GDPR and the EU GDPR). Step six: build the evaluation dataset. Define a hold-out dataset that is representative of the real distribution of inputs the model will receive in production. Define the evaluation metrics and thresholds that constitute acceptable model performance. Set a schedule for regular evaluation runs (weekly or monthly depending on how frequently the data or model changes).
Section-by-Section Walkthrough
The data inventory section is best completed as a table with rows for each data type and columns for: data type name, source system, current volume, update frequency, format, access method, access owner, and current quality rating (high, medium, low, unknown). Add a notes column for anything that requires follow-up. Review this table in the first technical planning session. Any row with "unknown" in the quality column is a risk that needs investigation before the sprint starts. The training data requirements section should address both the minimum viable data position and the aspirational data position. The minimum viable position is what you need to build a product that is good enough to launch. The aspirational position is what you would need to build a product that is significantly better than the competition. Knowing both helps you make informed decisions about how much data preparation investment to make before the first launch. The data quality standards section should include examples of good and bad data for each type. Abstract quality standards ("accuracy must be high") are difficult to implement. Concrete examples of acceptable and unacceptable data records give the data preparation team a practical reference point. The data pipeline section should include a diagram showing data flow from source to model. For each stage, note the latency (how long the transformation takes), the error rate (what percentage of records fail processing), and the monitoring approach (how you know when the pipeline is failing). Unmonitored data pipelines are a common source of silent AI quality degradation. The GDPR section should be reviewed by someone with data protection knowledge, ideally your Data Protection Officer if you have one, or legal counsel with GDPR expertise. The ICO has published specific guidance on AI and data protection that is the reference standard for UK products. Key questions for AI-specific GDPR compliance: does using this data for AI training constitute a new purpose that requires a fresh lawful basis? Does the automated processing meet the requirements of Article 22 if it produces decisions that affect individuals? The evaluation dataset section should specify: size (how many examples), composition (is it representative of real usage patterns), update frequency (when does the evaluation dataset need to be refreshed), and ownership (who is responsible for maintaining it and running evaluations).
Common Mistakes This Template Prevents
The most common data mistake in AI projects is assuming that data which exists is data that can be used. Data in a CRM system may be governed by a privacy notice that does not cover AI training. Data from a third-party provider may have contractual restrictions on use for AI. Data that was collected for one purpose may not be legally usable for another under GDPR's purpose limitation principle. The GDPR section of this checklist surfaces these constraints before they become a blocker mid-project. The second common mistake is underestimating the volume of high-quality labelled data required. Teams often plan to label data during the build sprint and find that labelling takes far longer than expected. Building a taxonomy, setting up labelling tools, training annotators, and achieving acceptable inter-annotator agreement is a significant project in itself. If labelled data is required, plan a dedicated labelling phase before the main build sprint. The third mistake is building a data pipeline without monitoring. A pipeline that silently drops records, silently corrupts data types, or silently fails to update will produce an AI system that degrades over time without obvious explanation. Pipeline monitoring is not optional infrastructure. The fourth mistake is using the same dataset for training, validation, and evaluation. Models evaluated on the data they were trained on look artificially good. A genuine hold-out evaluation dataset that the model has never seen is the only reliable measure of real-world performance.
Customisation Tips for Different Project Types
For LLM-based products using retrieval-augmented generation, the data requirements checklist should be extended to cover knowledge base management: how documents are ingested, chunked, and embedded; what metadata is attached to each chunk; how stale or incorrect content is identified and removed; and who is responsible for ongoing knowledge base curation. The quality of a RAG system is directly tied to the quality of its knowledge base. For products that fine-tune a base language model, add sections covering the fine-tuning dataset format requirements, the specific task representation (instruction-following format, preference pairs, or completion format), and the evaluation benchmark design. Fine-tuning data quality requirements are significantly higher than RAG knowledge base requirements. For products in regulated sectors, the GDPR section should be extended with sector-specific requirements. Healthcare products processing patient data under NHS Digital data standards have additional requirements beyond standard GDPR. Financial services products using personal data for credit assessment must meet FCA expectations for data governance and fairness testing. The checklist should name the specific regulatory requirement alongside the GDPR requirement for each data type. For enterprise products that will use customer-provided data, add a data intake section covering: the data formats you will accept, the validation process applied to incoming data, the security controls during data transfer and storage, the GDPR controller-processor relationship (you will likely be a data processor for customer data), and the contractual terms in your data processing agreement.