Facial Recognition and the EU AI Act: What GDPR Compliance Requires

Europe ensured that the sanctity of the biometric data of its people even before its artificial intelligence law even existed. In the two years between 2022 and 2024, three separate data protection regulators fined ClearView AI. The Italian Garante, the French CNIL, and the Dutch Data Protection Authority (€ 30.5 million) also included incremental penalties of 5.1 million euros each. The reason behind such severe penalization was given by the Dutch regulator’s decision notice, the company had its database built on more than 30 billion scraped images, the unique biometric code it derived from each face is biometric data, and its collection is prohibited unless any statutory exception applies.  

The regulators determined which articles of the GDPR were breached by ClearView AI and made their decisions according to those breaches. The EU AI Act was not in application; it would not have been until February 2025. The breaches were found in Article 6 on lawfulness, also in Article 9, which was on special category data, and in Article 15 and Article 16.  That sequence rested entirely on the General Data Protection Regulation (GDPR). GDPR had already set a solid base for the EU AI Act to thrive. 

The EU AI Act determines whether a facial recognition system could even exist and under what circumstances. GDPR, on the other hand, decides whether a facial recognition system may exist and on what terms, while GDPR decides what that system may lawfully do with a face once it does. Compliance teams that read only the first, find a comfortable exclusion for identity verification, and stop there are answering the easier of the two questions.

Two rulebooks now govern one camera

The EU facial recognition laws sort into three tiers by what the system is used for, and GDPR then applies across all three tiers alike. That second half of the sentence is where most of the practical compliance work sits, and it is the half that the risk-tier framing tends to obscure.

Remote Identification and one-to-one verification are not the same thing

The distinction that carries the most commercial weight is the one between identifying an unknown person against a gallery and confirming a known person against a document they have just presented. The first is a one-to-many search, and it is what the phrase remote biometric identification describes in the Act. The second is a one-to-one match, which is what happens when a customer takes a selfie during onboarding, and the system compares it against the photograph on the passport they uploaded a moment earlier.

Regulators treat these differently because their risks differ. A one-to-many search can surface a person who never asked to be looked for, whereas a one-to-one match resolves a claim that the person has already made about themselves.

What Annex III actually excludes

Annex III lists remote biometric identification systems as high-risk and then adds an exclusion in the same breath. The text reads that the category “shall not include AI systems intended to be used for biometric verification the sole purpose of which is to confirm that a specific natural person is the person he or she claims to be.”

The narrow wording of the text holds significance here. The exclusion turns on the words sole purpose, which means a system that also runs a watchlist search, scores demographic attributes, or retains templates for later matching has arguably stepped outside it. Further, the exclusion removes a system from the high-risk tier only. It does not touch Article 5, it does not touch the transparency duties in Article 50, and it does not touch GDPR at all.

Which facial recognition practices are banned under Article 5?

Article 5 prohibits four biometric practices outright, and unlike the high-risk regime, these have been enforceable since 2 February 2025 with no deferral and no compliance pathway back. A prohibited practice cannot be documented, audited, or risk-assessed into legality, which is what separates this tier from every other rule in the Act.

1. Untargeted scraping of facial images: Article 5(1)(e) bans AI systems that create or expand facial recognition databases through the untargeted scraping of facial images from the internet or from CCTV footage. This is the provision that renders Clearview-style operations illegal under EU AI law and not only under GDPR.
2. Biometric categorisation by protected attributes: Article 5(1)(g) bans systems that categorise individual people by their biometric data in order to deduce or infer race, political opinions, trade union membership, religious or philosophical beliefs, or sexual orientation. Lawful labelling or filtering of legitimately acquired datasets remains outside the prohibition.
3. Emotion inference at work and in education: Article 5(1)(f) bans systems that infer the emotions of a natural person in workplaces and educational institutions, with an exception where the system is intended for medical or safety reasons.
4. Real-time remote identification in public spaces: Article 5(1)(h) prohibits live remote biometric identification in publicly accessible spaces for law enforcement purposes, unless the use is strictly necessary for one of three listed objectives such as the targeted search for a specific victim of trafficking or the prevention of an imminent terrorist threat.

Points two and three deserve more attention than they usually get in commercial settings, because both can be triggered without anyone intending to. A liveness or facial age estimation model that also outputs an inferred ethnicity attribute, or a customer-experience tool that scores applicant sentiment during a video interview, can drift into prohibited territory even though nobody set out to build a categorisation system.

The four cumulative conditions that trigger the scraping ban

The line between targeted and untargeted scraping is the most consequential definitional question in Article 5(1)(e), and the Commission’s guidelines on prohibited AI practices, published on 4 February 2025, set out how to draw it. As the Future of Privacy Forum’s analysis of the provision sets out, four conditions must be met at the same time, and where any one is absent the provision does not trigger.

1. The activity qualifies: Placing on the market, putting into service for this specific purpose, or use of the AI system.
2. The purpose qualifies: Creating or expanding a facial recognition database.
3. The method qualifies: AI tools used for untargeted scraping, meaning a technique that absorbs as much data as possible from different sources with no specific focus on a given individual or group.
4. The source qualifies: The internet or CCTV footage specifically.

The guidelines read databases broadly, covering any collection of data specially organised for rapid search and retrieval by a computer, whether temporary, centralised, or decentralised. It is enough that the collection can be used for facial recognition, and recognition does not have to be its sole purpose. Where a system combines targeted and untargeted searches, only the untargeted part is prohibited. One caveat is worth carrying forward, which is that these guidelines are expressly non-binding, with authoritative interpretation reserved to the Court of Justice of the European Union.

What falls outside the Scraping Prohibition

Four categories sit outside the scope of Article 5(1)(e). Targeted scraping of specific individuals or pre-defined groups for law enforcement purposes falls outside it, subject to the Law Enforcement Directive. Untargeted scraping of biometric data other than facial images, such as voice samples, is not covered. Non-AI scraping methods sit outside the provision altogether, because the prohibition attaches to AI systems. AI systems that harvest facial images to train models generating entirely fictitious persons are also excluded.

That last category remained the most contested, and the Digital Omnibus negotiations responded to it directly by adding a new prohibition on AI practices that generate non-consensual intimate or sexual content and child sexual abuse material. Even where the AI Act prohibition does not apply, scraping facial images to train generative models still triggers copyright obligations and GDPR requirements for special category data.

There is also a gap the provision leaves open. Article 5(1)(e) bans the creation or expansion of these databases, and it does not on its face prohibit the continued use of a database built before the prohibition applied. Unlike Article 5(1)(h), it admits no law enforcement exception, which suggests the blanket drafting was deliberate.

Which facial recognition systems are high-risk, and when do the rules become Restrictive?

Area 1 of Annex III makes three categories of biometric AI high-risk, being remote biometric identification systems, biometric categorisation according to sensitive or protected attributes, and emotion recognition. Facial recognition applied to recorded footage after an event rather than in real time is not prohibited, and it lands here instead, and it lands in the high-risk tier when it runs as a one-to-many search. Deployments that operate under degraded capture conditions, such as masked face recognition, sit in this tier too when they run as one-to-many searches.

What compliance obligations apply once the deferral ends?

From 2 December 2027, any facial recognition system classified as high-risk under the EU AI Act must meet strict requirements before it can be used in the EU. These responsibilities are divided between the company that creates the system (the provider) and the organisation that uses it (the deployer). The provider must ensure the system is safe, accurate and properly documented. This includes managing risks, using reliable training data, keeping technical records, enabling logging, and completing a conformity assessment before the system can be placed on the market. Buyers do not have to create this documentation themselves, but they should ask vendors for proof that these requirements have been met.

The organisation using the system also has responsibilities. It must use the system according to the provider’s instructions, assign people responsible for human oversight, keep required records, and inform individuals when AI has been used in decisions affecting them. If the organisation discovers that the system creates serious risks, it must notify the provider and relevant authorities and stop using it until the issue is addressed. The information provided by the AI system must also support the organisation’s GDPR Data Protection Impact Assessment (DPIA). In other words, businesses should not wait until 2027 to prepare because some privacy and risk assessment duties already apply today.

What fines apply for illegal facial recognition in the EU?

The AI Act sets a three-tier penalty structure under Article 99, and GDPR fines run on a separate track that can apply at the same time. The Clearview sequence is the clearest demonstration of the second point, because that enforcement was purely a data protection matter.

For most commercial deployments, the relevant row is the second rather than the first, because the realistic failure is a misclassification rather than a prohibited practice. That distinction is worth holding onto, since the headline €35 million figure describes a risk a legitimate onboarding flow will almost never run. The fourth row is the one that has actually been used against facial recognition operators in Europe so far.

How does the EU AI Act interact with GDPR for facial recognition?

The two regulations answer different questions about the same system, and neither answer substitutes for the other. The AI Act asks whether this kind of system may be placed on the market and under what controls. GDPR asks whether the processing of this particular person’s face is lawful, necessary, and proportionate. A deployment can clear the first test comfortably and fail the second.

A carve-out in one regulation is not a carve-out in the other

The Act says this in its own text rather than leaving it to interpretation. Article 5(1)(h) closes with the statement that the provision “is without prejudice to Article 9 of Regulation (EU) 2016/679 for the processing of biometric data for purposes other than law enforcement.”

The practical consequence is that a facial recognition system used for one-to-one identity verification, sitting outside the high-risk tier and outside every Article 5 prohibition, is still processing special category data under GDPR Article 9. That processing needs a lawful basis under Article 6 and, separately, a condition from the closed list in Article 9(2). The AI Act contributes nothing to either requirement.

The mistake compliance teams are making right now

The pattern showing up most often is a team that reads Annex III, finds the one-to-one verification exclusion, concludes the AI Act does not apply to their onboarding flow, and treats the file as closed. The conclusion is usually correct on its own terms and almost always incomplete, because the binding constraint was never the AI Act.

The cost of the mistake is rarely a fine, at least at first. It shows up at data protection impact assessment sign-off, after the vendor has been selected and the integration built, when someone asks where the biometric templates are stored and for how long. A storage architecture costs far more to retrofit than to choose correctly at the outset, and the regulator’s own warning in the Dutch case is worth remembering at this point, being that using a non-compliant facial recognition service is itself unlawful. An organisation that outsources the capability does not outsource the exposure.

What EU AI Act facial recognition compliance requires in practice

Compliance for a commercial facial recognition deployment in the EU comes down to three decisions, and all three are better made before a vendor is chosen than after.

Decide the Article 9 condition before you decide the vendor

Establish which condition in GDPR Article 9(2) your processing relies on, and confirm it holds in every member state you operate in, because the substantial public interest route depends on national law. Document the Article 6 basis alongside it. Where consent is the only condition available, treat that as a signal that the use case may not be defensible rather than as a completed step.

Decide where the template lives, and for how long

Settle three questions in writing. Whether the raw image is retained at all after the match, where the derived template is stored and who holds the key, and what the deletion trigger is. According to EDPB Opinion 11/2024, the architecture that keeps the template under the individual’s control is the one that survives scrutiny most comfortably, so the burden of justification rises with every step away from it. Data residency belongs in this decision too, particularly for organisations with on-premises or in-region deployment obligations.

Decide what a human reviewer can actually overturn

Human oversight is only meaningful where the reviewer can see the basis of the decision. Map which biometric outcomes a person can reverse, what evidence they see when they do, and how that review is logged. This work is required under Article 14 for high-risk systems, and it remains good practice for excluded ones, because GDPR Article 22 rights and the accountability principle do not depend on the AI Act’s classification. Consent capture and proof of consent should be logged with the same rigour, which is why consent verification is worth treating as a distinct control rather than a checkbox in the interface.

How Shufti handles facial recognition under EU rules

Compliance teams running biometric onboarding in the EU keep running into the same problem, which is that they can describe what their system decided but not why, and a reviewer who cannot explain a decision cannot defend it to a regulator or overturn it for a customer.

Shufti face verification layer addresses that directly through explainable decisioning. Every flagged image carries a colour-coded attention map showing natural, moderate, and high-anomaly zones, so a fraud or compliance reviewer can see where and why risk was raised rather than accepting a score. Shufti holds iBeta Level 3 conformance under ISO/IEC 30107-3 for passive liveness on both iOS and Android, which is the highest published independent standard for liveness attack detection.