AI data quality and the GDPR accuracy principle — the Spanish DPA’s criteria for model governance
The AI Act’s data-governance duties have been pushed to 2027 and 2028. The GDPR accuracy principle applies to your models today. In July 2026 the Agencia Española de Protección de Datos published a technical note — Exactitud, idoneidad y calidad de los datos en tratamientos de datos personales con Inteligencia Artificial — that does something unusually useful for a supervisor: it explains why “accuracy” in a data-quality standard and “accuracy” in Article 5(1)(d) of Regulation (EU) 2016/679 are not the same test, and why demanding too much data quality is itself a compliance problem. For a payments firm running monitoring, screening and scoring models, it is the clearest statement yet of what a supervisor expects to see documented.
1. What the note is — and what it is not
It is a technical note: supervisory criteria, not binding law. Nothing in it creates an obligation that Regulation (EU) 2016/679 does not already contain, and it says so — the standards it cites “serve as technical orientation and neither replace nor modify the legal requirements derived from the GDPR”. Read it the way you would read a supervisor’s expectations paper: it tells you how the regulator will frame the question when it asks.
Its stated audience is controllers, processors and data protection officers, plus anyone involved in developing, testing and maintaining products or services that need access to personal-data sets — which in a regulated firm means the model owners as much as the privacy office. It also expressly extends to processing under Ley Orgánica 7/2021, the Spanish law covering personal data processed for the prevention, detection, investigation and prosecution of criminal offences. And it uses “AI system” more broadly than the AI Act does, explicitly including logistic regressions, mathematical optimisation and statistical methods. A rules-and-thresholds monitoring engine is inside the note’s scope even if it is nowhere near the AI Act’s.
2. Two principles, one quality band
The GDPR never uses the phrase “data quality” as a principle. What it has are two provisions in Article 5(1): letter (c), requiring personal data to be adequate, relevant and limited to what is necessary in relation to the purposes (“data minimisation”), and letter (d), requiring data to be accurate and, where necessary, kept up to date (“accuracy”). The note’s central move is to read them together as defining a band: quality high enough that the processing achieves its purpose, and no higher.
That reframes accuracy as purpose-relative rather than absolute. Truthfulness and being up to date are required where they are necessary for the purpose — particularly where their absence would affect the rights and freedoms of natural persons — and not as a universal requirement of every processing operation. Satisfying the principle may instead require precision, sufficient granularity, an adequate collection frequency, absence of bias or completeness of attributes, depending on what the processing is for. The right of rectification under Article 16 is expressly preserved: an individual can still have inaccurate data about them corrected regardless of how the quality band was set.
3. Why the standards vocabulary trips teams up
Data quality is defined in standards such as UNE 0079, ISO 25012, ISO 5259 and ISO 8000 as the degree to which data characteristics satisfy stated and implicit needs when used under specified conditions; ISO 22989 defines data-quality checking for AI systems as examining data for completeness, bias and other factors affecting usefulness. ISO 25012 lists fifteen characteristics — accuracy, completeness, consistency, credibility, currentness, accessibility, compliance, confidentiality, efficiency, precision, traceability, understandability, availability, portability and recoverability — and states that they must be evaluated against the specific context of use.
“Accuracy” appears in both vocabularies with different meanings, and the note warns against pairing them. The practical consequence for documentation: when a model risk assessment says “data accuracy: 98.4%”, that is a standards-flavoured metric, not evidence of compliance with Article 5(1)(d). The compliance statement has to say what purpose the data must serve, which characteristics that purpose requires, and at what level — and it must rest on objective criteria and verifiable evidence rather than on a target inherited from the model documentation.
The note also separates the quality of an individual record from the quality of a dataset. In machine-learning processing, quality has to be judged on the set as a whole: every record can be individually correct while the set fails to represent the population, or specific groups within it. And non-personal data used inside a personal-data processing operation — reference tables, scorecards, configuration parameters — must meet quality requirements too, because an error in a non-personal input can produce an output that is inaccurate about a person even when every personal input was correct.
4. The output is personal data
Where the result of a processing operation is a decision, a profile, an inference or an enrichment relating to an identified or identifiable person, that result is itself personal data — so the accuracy and minimisation principles apply to the output, not only to the inputs. Two operational consequences follow, and both are testable.
First, the minimum acceptable quality of the output has to be determined and measured. The note states that ignoring output-quality metrics makes it impossible to guarantee or demonstrate that the purposes are being achieved effectively — accountability language, aimed at Article 5(2) and Article 24. Second, aggregate performance can conceal individual error: the note warns that a system’s aggregate performance may hide errors or inaccuracies in individual inferences, especially when evaluated through global metrics, which requires additional control mechanisms where the results can affect specific people.
It also refuses the perfection standard in both directions. There is no perfect processing and no perfect system; what is required is a system that is adequate for the design of the processing — one whose strengths and weaknesses are known and documented, and whose weaknesses can be managed effectively through safeguards built into the processing. That is a governance test a firm can pass with an imperfect model and fail with a good one.
5. Worked example — the alert score is a personal datum
Facts: a payment institution scores every transaction for money-laundering risk and auto-escalates the top decile to an analyst queue. Model validation reports AUC and a false-positive rate at portfolio level. Nothing measures the quality of the individual output attached to a named customer.
Applicable rule: the score and the alert are inferences relating to an identifiable person, so they are personal data subject to Article 5(1)(c) and (d) in relation to the purpose. The note’s aggregate-performance warning applies directly: portfolio metrics do not evidence output quality for the individual, and the presence of downstream operations that modify or correct the model’s output is one of the factors that sets the required output quality.
What the analyst does: defines the minimum acceptable output quality for the decision that actually affects the customer — not for the score in the abstract — and records the human-review step as a designed safeguard rather than as workflow. Where the same score feeds a second use, such as a restriction or an offboarding recommendation, that use is assessed separately, because its impact on rights is different.
Outcome: the model documentation gains two things it did not have: an output-quality metric tied to the decision, and a written statement of which safeguards permit the input-quality requirement to sit where it does. Both are what an inspection asks for.
6. Worked example — the requirement that was set too high
Facts: to cut false positives in sanctions and PEP screening, a project proposes to collect and keep full address history and a complete date of birth for the entire customer base, including customers where a lighter identification set is sufficient.
Applicable rule: quality requirements must rest on objective criteria and verifiable evidence. Requirements set too high do not merely cost money — they contradict minimisation by requiring access to more data, or to data of greater extension, granularity, precision or frequency than needed, and they raise the cost of data access and governance.
What the analyst does: tests the requirement before adopting it. Measure what the additional attribute actually contributes to match precision on the firm’s own population; if the contribution is material for a defined segment, scope the collection to that segment and document the evidence; if it is not, the requirement fails minimisation and the false-positive problem is addressed in the processing design instead — tuning, secondary review, or a different matching strategy.
Outcome: a narrower collection with an evidence trail, which is both the defensible privacy position and the cheaper build. The failure mode the note describes is the opposite: an unevidenced quality target that expands the dataset and is then justified by pointing at the accuracy principle.
| Quality requirements set… | What it looks like in practice | Consequence the AEPD identifies |
|---|---|---|
| Too low | Datasets that are unrepresentative, stale for the purpose, or missing attributes the decision depends on | The development processing cannot be considered suitable — the resulting system does not reach the intended performance or design requirements |
| Too high | Excess volume, granularity, precision or collection frequency demanded without evidence that the purpose needs it | Contradicts minimisation, raises data-access and governance cost, and can lead to viable initiatives being abandoned |
| Measured only on inputs | No metric on the decision, inference or profile the processing produces | Impossible to guarantee or demonstrate that the purpose is being achieved effectively and suitably |
7. Worked example — evaluating a dataset you have not yet accessed
Facts: a fraud-model team wants bulk access to an external dataset to retrain a device-risk model. The plan is to ingest it, then assess whether it is any good.
Applicable rule: the note requires the legitimacy of the access to be evaluated before a mass access or collection begins, which means determining whether the datasets are necessary — adequate, relevant and limited to what is necessary for the purpose — and therefore assessing quality at source, alone or in combination with other sets. Where a dataset lacks the necessary quality, access can only be justified to the extent strictly necessary to evaluate its quality objectively and determine its possible suitability for the intended purpose. The note also uses the Data Governance Act definition of access in its Article 2(13): use of data in accordance with specific technical, legal or organisational requirements, without necessarily implying transmission or download.
What the analyst does: sequences it as evaluation first, ingestion second — a bounded assessment against the performance requirements defined for the intended use, documented as its own step. Where the source permits it, the evaluation runs under a compute-to-data arrangement rather than by copying the set, which the note identifies as an access model whose benefits go beyond data protection.
Outcome: the decision to ingest is evidenced by a quality assessment rather than justified after the fact — and if the set fails, the firm has processed the minimum necessary to find that out.
8. Development and deployment are different processings
Developing or evolving a machine-learning model using personal data is a distinct processing operation from using that model in production, with its own purpose, its own quality requirements and its own assessment. The note maps the lifecycle to ISO 5338 and lists what the resulting performance depends on: the quality of the training, test, validation and evolution datasets; how quality is altered by the data processes along the lifecycle; the development methodology; design decisions; the intended contexts and purposes; implementation factors at deployment such as model quantisation; context drift and data drift over time; and bias generated by feedback loops during model evolution.
Two governance points follow. Data governance has to coordinate the personal-data obligations with the requirements of developing, procuring, deploying and evolving the systems, keeping quality criteria coherent across the whole lifecycle — the note points to the twenty-two governance, management and data-quality processes developed in UNE 0080:2023 as an illustration of that overhead. And defining, evaluating and reviewing quality requirements needs a multidisciplinary approach: at minimum, data-science and data-protection specialists working together on objective criteria and verifiable evidence. In a payments firm, that is the model owner and the DPO signing the same document, which is rarer than it should be.
The contrast with the AI Act timetable is the reason to act now. The high-risk requirements in Chapter III of Regulation (EU) 2024/1689 — data governance among them — now apply from December 2027 for Annex III systems and August 2028 for Annex I systems following Regulation (EU) 2026/1744. Article 5(1)(c) and (d) of the GDPR have applied since 2018.
9. What to do, today
- Write the quality band down. For each model-driven processing: the purpose, the characteristics that purpose requires, the level required, and the evidence for that level.
- Add an output metric. If nothing measures the quality of the decision, inference or profile produced, accountability cannot be demonstrated — this is the note’s sharpest single point.
- Stop reporting aggregate performance as assurance. Where outputs affect individuals, add controls aimed at individual error, and say what they are.
- Challenge high quality requirements, not just low ones. An unevidenced demand for more granular data is a minimisation finding waiting to happen.
- Separate the development file from the deployment file. Different processing, different purpose, different quality requirements, different documentation.
- Assess datasets before you ingest them. Evaluate at source; where quality is unknown, limit access to what is strictly necessary to establish suitability.
- Include the non-personal inputs. Reference tables, thresholds and configuration parameters can make an output inaccurate about a person; scope them into the quality requirements.
10. Frequently asked questions
Is the AEPD note binding?
No. It is a technical note setting out supervisory criteria on how existing GDPR principles apply. The obligations come from Regulation (EU) 2016/679; the note explains how the AEPD reads them in AI-related processing, and the standards it cites are technical orientation only.
Does it apply to firms outside Spain?
The criteria are read off the GDPR, so the reasoning travels; the AEPD’s competence does not. For a group operating through branches, the practical value is that it is a written, citable articulation of an argument other EU supervisors are likely to make in similar terms.
Does a rules-based transaction-monitoring engine count as an “AI system” here?
For the purposes of this note, yes. It uses the term more broadly than the AI Act and the Commission’s guidance on the definition of an AI system, expressly including techniques such as logistic regressions, mathematical optimisation and statistical methods.
Can synthetic data or bias correction be used?
The note treats data-quality management, including modifying values, as compatible with the accuracy principle where the purpose justifies it and the result does not give an incorrect picture of the person or harm their rights. Document the justification and assess the outcome, not just the technique.
Where does this sit relative to a DPIA?
It feeds one. The quality band, the output metrics and the safeguards that manage a system’s documented weaknesses are exactly the material a data protection impact assessment needs in order to conclude that the processing is suitable for its purpose.
Related: EU AI Act deadlines for financial institutions · Mule-account reporting in Spain · DORA Article 30 and ICT contracts
