This article is for anyone who uses AI with personal data in their company and has concluded, rightly, that their system is not high-risk under the AI Act: a customer-service chatbot, a tool that scores customers for campaigns, a system that summarises calls. The conclusion is correct, and it does not answer another question, the GDPR one: does that processing need a data protection impact assessment, a DPIA? The two classifications follow different rules, and in Spain the second is made concrete by a list from the Spanish Data Protection Agency, the AEPD.
The figure sets the two instruments side by side. The FRIA, under Article 27 of the AI Act, is owed by the deployer that is a body governed by public law or a private entity providing public services, with an Annex III high-risk system other than point 2, or by any deployer of the systems in Annex III, point 5, points (b) and (c); it is carried out before first use and has six contents. The DPIA, under Article 35 GDPR, is owed by the controller where the processing is likely to result in a high risk to the rights and freedoms of natural persons; it is carried out prior to the processing and has a minimum content of four points. Between them runs a band: they are independent instruments, and Article 27(4) lets the FRIA reuse the evidence of the DPIA.
What the GDPR requires
Article 35(1) requires the controller to carry out an impact assessment "where a type of processing in particular using new technologies, and taking into account the nature, scope, context and purposes of the processing, is likely to result in a high risk to the rights and freedoms of natural persons". The test is high risk to people, not the label on the technology. And that general obligation does not depend on any list: if a high risk is likely, the assessment is needed even if the processing fits none of the criteria.
Article 35(3) lists three cases in which the assessment is required "in particular": a systematic and extensive evaluation of personal aspects, based on automated processing, on which decisions are based that produce legal effects or similarly significantly affect people; processing on a large scale of special categories of data or of criminal data; and systematic monitoring of a publicly accessible area on a large scale.
And Article 35(4) adds the piece that matters here: "The supervisory authority shall establish and make public a list of the kind of processing operations which are subject to the requirement for a data protection impact assessment".
The AEPD list
The list published by the AEPD, available in Spanish only, sets out eleven criteria and a rule for combining them: a DPIA (an EIPD, in its Spanish acronym) is needed in most cases where the processing meets two or more criteria, unless the processing is on the list of operations that do not require one (Article 35(5)). The more criteria it meets, the list says, the greater the risk and the more certain it is that the assessment is needed. And it presents itself as a non-exhaustive list.
Two of its criteria describe a good deal of the AI a company uses:
- Criterion 1: processing involving profiling or evaluation of individuals.
- Criterion 2: processing involving automated decision-making, or processing that contributes to a large extent to such decisions.
Others are more specific but just as common: special categories of data (criterion 4), biometric data used to identify a person uniquely (criterion 5), large-scale processing (criterion 7), data about vulnerable people (criterion 9) and new technologies or innovative uses of established ones (criterion 10).
Under that rule, a tool that scores customers to prioritise campaigns, and does so on a large scale, meets at least two criteria, 1 and 7, and the list says that in most such cases a DPIA is needed. The same system is not high-risk under the AI Act: scoring customers for marketing campaigns is not among the Annex III uses, which do include, for instance, evaluating the creditworthiness of natural persons. It still needs the assessment.
A DPIA is not only about security
The underlying confusion is usually a different one: thinking of the DPIA as an IT security analysis. Article 35(7) requires it to contain, at a minimum, "an assessment of the risks to the rights and freedoms of data subjects". Rights and freedoms, not only the confidentiality of the data.
That is why the DPIA for a candidate-screening filter, when one is carried out, has to assess discrimination: the risk that the system rejects people for reasons that should not count is a risk to their rights, and it falls within what the assessment covers. That filter is also high-risk under the AI Act, and once Article 26 applies to it — from 2 December 2027 for high-risk systems under Annex III and from 2 August 2028 for those under Annex I — its paragraph 9 will require the deployer to "use the information provided under Article 13 of this Regulation" for that assessment, the information the provider has to give it.
Two classifications that are not the same
None of the above depends on the AI Act. Whether a system is high-risk comes from the AI Regulation; whether a DPIA is needed comes from the GDPR and the AEPD list. A system can be minimal-risk under one and require an assessment under the other, and a high-risk system does not escape the DPIA by having a FRIA. Both terms have their glossary entry: DPIA and FRIA.
The Article 27 FRIA is a different instrument, with a different subject and a different date. For Annex III high-risk systems other than point 2, it is owed by deployers that are bodies governed by public law or private entities providing public services, and by those deploying the systems in Annex III, point 5, points (b) and (c); its only date of application is 2 December 2027. Where the two coincide, Article 27(4) lets the FRIA "include cross-references to the relevant sections of that data protection impact assessment or include relevant parts thereof". Reuse, not replacement.
In practice
- Run each AI processing operation through the list before it goes live. Count the criteria and record the result, including when it is "not needed".
- If it touches health data, read the private healthcare case carefully. Article 35(3)(b) requires large-scale processing, and not every centre reaches it.
- If it uses biometrics, the distinction between verifying and identifying settles a great deal. Criterion 5 of the list is about identifying a person uniquely.
- Revisit the DPIA when the processing changes. A system that starts out summarising calls and ends up scoring customers has changed criteria, and the assessment you made at the start no longer holds.
- Do not wait for 2027. The GDPR already applies, and so does the list.
This article is for informational purposes only and does not constitute legal advice.