The AEPD says the GDPR accuracy principle asks whether data fit the purpose, not whether every record is true

Why we are covering a July document in late August

This is not news and we are not dressing it as news. The AEPD published the note in July 2026 and the press note carries 21 July 2026. We picked it up now because it is substantive, it has gone largely uncovered in English, and the position it takes is more useful to a working DPO than most of what has been written about AI and the GDPR this year.

One housekeeping point that matters if you go looking. The file is served as calidad-datos-inteligencia-artificial.pdf, but the document on its own cover page is titled Exactitud, idoneidad y calidad de los datos en tratamientos de datos personales con Inteligencia Artificial. Search on the filename and you may conclude the note is only about data quality. It is mostly about what accuracy means.

Nothing here is enforcement. The note announces no investigation, names no controller, and states no sanction. It is the AEPD explaining how it reads two principles it supervises.

The relaxation: accuracy is measured against the purpose

The AEPD's own summary of the point, in the press note: "el principio de exactitud recogido en el RGPD no exige que los datos sean siempre plenamente veraces o esten completamente actualizados, sino que sean adecuados para cumplir el objetivo del tratamiento en el que se utilizan". Roughly: the GDPR accuracy principle does not require that data always be fully truthful or completely up to date, but that they be adequate to meet the objective of the processing in which they are used.

The note carries the same position at more length and with a piece of terminology worth borrowing. It coins "exactitud-RGPD" to separate the GDPR principle from "exactitud-ISO", the standards concept of a value correctly representing the true value of an attribute. It says explicitly that pairing the two would be an error, and that ISO-accuracy might be one necessary condition for GDPR-accuracy but is not necessarily so.

It follows that techniques which put values in the file that are not literally true about a given individual are not automatically a problem. The note works through imputing a missing salary field from a group mean, which it describes as sacrificing exactitud-ISO for completeness, and through normalising a group-level bias out of a credit history column. It also lists synthetic data generation, anonymisation and differential privacy in the same breath, on the same reasoning: the resulting dataset may still carry enough quality for the purpose.

There is a limit attached in the same passage, and it is not decorative. The use of data that do not reflect reality has to be analysed by its effect on decision-making, on profiling, and on any other significant effect on the natural person, and it has to be justified and documented. The note is also explicit that in processing operations producing effects on specific people, the demand for truthfulness and currency in the result must be stricter.

The tightening, in the same 23 pages

Having widened what counts as accurate, the note narrows how loosely you may assert it. Its final reflections ask that data quality requirements be defined objectively, that they guarantee compliance with accuracy and minimisation, that governance processes state clearly who determines them and how, and that documenting those requirements is an essential element of the accountability principle.

Two of the asks go further than most controllers currently reach. First, output metrics. The note says that ignoring metrics on the quality of the output prevents a controller from guaranteeing and demonstrating whether the purposes are being met effectively and suitably. Second, continuity: data quality is described not as a static design-phase requirement but as a continuous management process across the lifecycle of the model and of the processing, with periodic review and adaptation to changes in context, purpose, scope, risk and system behaviour.

Scope is wider than the personal data you would normally scope. Non-personal data used inside a personal data processing operation must also meet appropriate quality requirements where they can affect the suitability of the processing or its results. The note illustrates it with a student whose relative evaluation flips between mediocre and brilliant depending on a school average, a non-personal input, while the personal input stays constant.

There is a traceability line too. Under accuracy and accountability, the note says the controller will have to guarantee and document the traceability of the dataset used, including the origin of the data, the transformations applied, and the selection and exclusion criteria. On our reading that is the single most demanding sentence in the document for anyone who acquired a training set rather than built one.

Minimisation is the other blade

The note treats accuracy and minimisation as jointly defining a band. Set quality requirements too low and you compromise the suitability of the development processing. Set them too high and, in the AEPD's account, you contradict the minimisation principle by pulling in more data, or more granular, more precise or more frequent data, than needed, while raising acquisition and governance cost and, at worst, causing initiatives or research projects to be cancelled.

One consequence lands harder than the rest. The note states that datasets which do not meet the quality needed to develop or evolve an AI system are not necessary for that processing, so access to them is not justified except to the strictly necessary extent to assess their quality. That is a minimisation argument used as a gate on data acquisition, and it points at the common practice of hoovering up a corpus first and deciding later whether it is usable.

Alongside it sits an ordering claim: input quality requirements can only be defined once the suitability conditions of the processing are known. The note repeats it for AI development, where the quality needed in the training set derives from the performance the system must deliver once deployed. Practically, that means the data acquisition decision is downstream of the deployment specification, not upstream of it.

Inferences, and what a controller should have on file

On inferences the note is direct. Where the result of a processing operation is a decision, a profile, an inference or an enrichment of information relating to an identified or identifiable natural person, that result has the status of personal data, and so must satisfy accuracy and minimisation in relation to the purpose. Output is in scope, not just input.

It adds a warning that model governance functions will recognise. Aggregate performance of an AI system can hide errors or inaccuracies in individual inferences, particularly when measured with global metrics, which the note says requires additional control mechanisms where results can affect specific people. Development and deployment are separate processing operations on its account, and the quality of the data used to build a system is to be assessed separately from the quality of what it emits in use.

Reading the final reflections as a checklist, a controller shipping a model into a personal data processing operation would want, on file: the stated purpose and the suitability conditions derived from it; the quality requirements chosen for inputs and for outputs, with the objective criteria behind them; metrics for output quality and the minimum acceptable level; traceability of the dataset covering origin, transformations and selection and exclusion criteria; the safeguards designed to manage the known weaknesses of the system; the supplier's documented data quality requirements where the system was bought in; and a monitoring and review cadence. That list is our compilation from the note, not a form the AEPD publishes.

The note also says who should be doing it. It asks for a team including, at minimum, data scientists and data protection specialists, working to objective criteria and verifiable evidence, and it says a DPO or data protection adviser needs to understand the data flows and operations in AI development and in AI-bearing processing. That is a staffing statement as much as a legal one.

What we did not verify

What we opened: the full 23-page Spanish PDF at aepd.es/guias/calidad-datos-inteligencia-artificial.pdf, read end to end including the executive summary, the final reflections and the annex on how the accuracy concept evolved through Directive 95/46/EC, LO 15/1999 and the LOPDGDD; and the AEPD press note of 21 July 2026. The quoted Spanish sentence was character-matched against the press note text, with diacritics folded to ASCII for this page.

What we did not open: any official English translation, which we did not find and do not assume exists; the three earlier AEPD AI publications the note cross-references, on agentic AI (February 2026), audit requirements for processing involving AI (January 2021) and GDPR compliance for processing incorporating AI (February 2020); the ISO, UNE and DGA instruments the note cites, including ISO 25012, ISO 22989, ISO 5338, UNE 0079 and UNE 0080:2023; and any AEPD enforcement file applying this reading.

What we refuse to claim: that the AEPD changed the law, that the note is binding on anyone, or that it amends Article 5 GDPR. It does none of those. We make no claim about enforcement consequences, because the note states none. We do not extend the note beyond Spain; the accuracy principle it interprets is the GDPR's and therefore common across the EEA, which is our observation and not a statement that other supervisory authorities or the EDPB share this reading. We also do not claim the note says synthetic data is personal data. It says results that are inferences or profiles about an identifiable person are personal data, and separately that synthetic generation may be compatible with accuracy. Those are two different statements and we have kept them apart. Figures and page counts here come from the PDF we extracted; the extraction rendered several diagrams as loose text, so we have not relied on any figure for a substantive claim.

Related briefings

• AEPD fine over facial recognition at Aena
• AEPD on deepfakes as unlawful processing
• AEPD on biometric facial recognition in exams
• Spain's AI organic law and AESIA fines
• AI Regulation News hub