What is the AEPD’s guidance on GDPR accuracy rules for AI data?
Spain’s data protection authority says AI data quality and GDPR accuracy should be assessed against the processing purpose, not treated as an absolute demand for perfect data.
AI teams often treat data quality as a model performance problem and GDPR accuracy as a privacy problem. Spain’s data protection authority now connects the two, but it does not collapse them into the same rule.
On 21 July 2026, the Agencia Española de Protección de Datos (AEPD) published a technical note on data quality, accuracy, and minimisation in AI systems that process personal data. The note is guidance, not new legislation. Its practical message is still significant: organisations should define what “good enough” data means for each AI purpose, measure it, and monitor both inputs and outputs across the system lifecycle.
This article is legal information, not legal advice. Teams should ask counsel to review how the AEPD’s guidance applies to a specific AI system, especially where outputs affect individuals.
What the guidance covers
By the end, you should be able to:
- Explain why the AEPD separates data quality from the GDPR accuracy principle.
- Decide when veracity, precision, and currentness matter for an AI dataset.
- Treat output validation as part of GDPR accountability.
- Document data quality requirements in a way developers and privacy teams can review together.
The AEPD’s position starts from GDPR Article 5. The European Commission summarises the GDPR principles as including purpose limitation, data minimisation, accuracy, storage limitation, integrity and confidentiality, and accountability. Accuracy means personal data should be accurate and up to date, taking into account the purposes for which it is processed.
The AEPD applies that purpose-based framing to AI. It says data quality and GDPR accuracy should not be understood in absolute terms. The relevant question is whether the data is suitable for the purpose of the processing and whether that suitability matters for the people affected.
Data quality is wider than GDPR accuracy
The AEPD draws a line between data quality and the GDPR’s accuracy principle.
Data quality can include relevance, representativeness, bias controls, completeness, consistency, precision, timeliness, provenance, and other properties. Some of those properties apply to non-personal data. Some apply to whole datasets rather than individual records. Some matter for model development even when no single field is “false” in the ordinary sense.
GDPR accuracy is narrower. It applies to personal data and asks whether personal data is accurate and, where necessary, kept up to date in light of the processing purpose.
That distinction matters for AI systems because model behaviour often depends on dataset-level properties. A training dataset can contain many accurate records and still be unsuitable if it is unrepresentative, biased, stale for the task, or missing important cases. The reverse can also be true in limited contexts: synthetic or transformed data may support a valid purpose even if each value does not reflect a real individual event.
The AEPD’s summary says techniques such as synthetic data generation, anonymisation, and bias correction can be compatible with GDPR accuracy where they are justified by the purpose and do not create adverse effects for people. That is a narrow statement. It does not mean synthetic data removes GDPR risk in every case, and anonymisation remains fact-specific.
Accuracy depends on the purpose and impact
The AEPD’s guidance pushes teams away from a blanket rule that all data must always be fully true, precise, and current. Instead, teams should ask what level of quality the purpose requires.
A product analytics model that groups users into broad behavioural segments may need different quality controls from a credit, hiring, insurance, education, health, or fraud model that affects a named person. Aggregated or statistical uses may tolerate abstraction. Outputs that affect specific people need stronger checks.
This does not weaken the GDPR. It makes the analysis more precise.
A stale address may be irrelevant in a model that estimates regional traffic patterns from historical data. The same stale address may be serious if it affects a delivery decision, eligibility check, or fraud review about one person. The purpose changes the quality requirement.
That also connects accuracy to minimisation. If an AI team demands more data, richer data, or constant refreshing “for quality” without showing why those properties are necessary, the collection can conflict with data minimisation. The AEPD’s guidance gives privacy teams a way to challenge unnecessary data collection without forcing an unrealistic demand for perfect data in every dataset.
Poor-quality data may fail the necessity test
One of the most practical points is the link between quality and necessity.
The user-provided summary of the AEPD guidance states that data which does not meet the required quality standards cannot be considered necessary for processing. Access to that data may only be justified to assess its quality.
That is a useful operating rule for AI teams. If a dataset cannot meet the quality threshold for the stated purpose, the team should not treat it as necessary simply because it is available or may improve a metric. The first valid use may be a limited quality assessment, followed by a decision to exclude, transform, replace, or document the data with safeguards.
This point needs legal review before publication against the full technical note, because the AEPD press release confirms the general quality, accuracy, minimisation, and lifecycle themes, but the exact “necessity” phrasing should be checked against the PDF text.
Non-personal data can still matter
The AEPD also says quality requirements do not apply only to personal data. Non-personal data used in a process that handles personal data may affect the outcome.
For example, an eligibility model may combine personal data about an applicant with market data, location risk scores, product metadata, or reference tables. Those auxiliary datasets may not identify a person by themselves. They can still shape the output about a person.
Developers should bring those datasets into the quality review. Privacy teams should avoid a narrow inventory that only lists direct identifiers or user profile fields. If a non-personal input changes the inference, prediction, or decision about an identifiable person, it belongs in the system’s quality controls.
Output quality is part of the control set
The AEPD’s guidance does not stop at inputs. It points to AI outputs such as inferences, predictions, and decisions. Those outputs should not create incorrect or disproportionate representations of affected people.
That changes the compliance task. A team cannot show that an AI system is fit for purpose only by saying the training data passed checks. It also needs objective metrics for the outputs.
Useful output controls may include:
- Error rates split by relevant groups.
- False positive and false negative rates for decisions that affect people.
- Drift checks between development data and live data.
- Human review rules for uncertain or high-impact outputs.
- Appeal, correction, or override paths where people can challenge an output.
- Monitoring that detects when quality falls below the documented threshold.
The right metrics depend on the purpose. A support chatbot, fraud classifier, health triage tool, recommender system, and identity verification flow do not need the same quality thresholds.
A practical data quality record for AI systems
Developers can make the AEPD’s guidance easier to apply by turning legal and policy requirements into a versioned quality record. This does not replace a DPIA, legal basis assessment, AI Act review, or model card. It gives engineering, data science, and privacy teams a shared object to review.
type ProcessingPhase = "development" | "testing" | "deployment" | "monitoring";
type QualityDimension =
| "relevance"
| "representativeness"
| "accuracy"
| "currentness"
| "bias"
| "completeness"
| "provenance"
| "outputValidity";
type DataQualityRequirement = {
systemId: string;
purpose: string;
phase: ProcessingPhase;
dimension: QualityDimension;
appliesTo: "personal-data" | "non-personal-data" | "outputs";
metric: string;
threshold: string;
whyNecessary: string;
reviewOwner: string;
reviewFrequency: "per-release" | "monthly" | "quarterly";
fallbackIfFailed: string;
};
const hiringScreeningOutputCheck: DataQualityRequirement = {
systemId: "candidate-screening-v2",
purpose: "rank candidates for recruiter review",
phase: "deployment",
dimension: "outputValidity",
appliesTo: "outputs",
metric: "false negative rate by role family and protected-class proxy review",
threshold: "below approved risk threshold for each monitored group",
whyNecessary:
"The output affects whether a recruiter reviews a named candidate. The team must detect disproportionate or incorrect exclusion patterns.",
reviewOwner: "privacy-and-ml-governance",
reviewFrequency: "per-release",
fallbackIfFailed:
"pause automated ranking for affected roles and route candidates to manual review",
};The important field is whyNecessary. It forces the team to explain why a quality property is needed for the purpose. If the team cannot explain the necessity, it should not collect more personal data or keep low-quality data in the pipeline by default.
Teams can store this record beside model documentation, change approvals, or data catalog entries. The format is less important than the discipline: define the requirement before using the data, measure against it, and decide what happens when the requirement fails.
What teams should do next
For AI systems that process personal data, the AEPD guidance points to a simple review sequence.
First, state the processing purpose in plain language. Avoid broad labels such as “AI improvement” or “personalisation” unless the team can explain the concrete decision or service outcome.
Second, list the datasets that affect the result. Include personal data, synthetic or transformed data, reference tables, external scores, and non-personal inputs that can influence outputs about people.
Third, define quality requirements for each phase. Development, testing, deployment, and monitoring may need different thresholds.
Fourth, separate input quality from output quality. Record-level checks, dataset checks, and output validation answer different questions.
Fifth, connect quality to minimisation. If a dataset fails the quality threshold, limit access to quality assessment, remediation, or deletion decisions unless counsel approves another basis.
Sixth, document safeguards. This may include human review, appeal channels, correction paths, release gates, drift monitoring, data retention limits, and escalation rules.
Where legal review is needed
A few areas need careful review before applying the guidance to production systems:
- Whether the system makes automated decisions or supports decisions that have legal or similarly significant effects under GDPR Article 22.
- Whether a data protection impact assessment is required.
- Whether special-category data or inferred sensitive data is involved.
- Whether synthetic or anonymised data still carries re-identification or singling-out risk.
- Whether the EU AI Act creates separate data governance, transparency, or risk management duties.
- Whether another EU supervisory authority would take the same view outside Spain.
The AEPD note is not a shortcut around those questions. It helps frame one part of the analysis: how to define and evidence data quality, accuracy, and minimisation for AI systems.
Summary
You can now:
- Treat AI data quality as broader than GDPR accuracy.
- Define accuracy and currentness against the processing purpose.
- Include non-personal inputs when they influence outputs about people.
- Validate AI outputs, not only input datasets.
- Link quality failures to data minimisation and necessity.
Next, review your AI data inventory and add purpose-based quality requirements for each system that processes personal data. Start with systems that rank, classify, recommend, or decide something about named people.
Sources
- AEPD, “La AEPD analiza la calidad, exactitud y minimización de datos personales en tratamientos realizados con sistemas de IA,” 21 July 2026
- AEPD technical note PDF, “calidad-datos-inteligencia-artificial.pdf”
- European Commission, “Principles of personal data processing under the GDPR”