EU AI Act: Real-Time Biometric Identification Ban (Article 5)
Article 5(1)(h) bans real-time remote biometric ID in public spaces for law enforcement. Three exceptions, prior authorisation required. Fine: €35M or 7%.
Since 2 February 2025, deploying a real-time remote biometric identification system in a publicly accessible space for law enforcement is, as a general rule, prohibited under EU law. Article 5(1)(h) of Regulation (EU) 2024/1689 — the EU AI Act — sets out one of the Act's most closely watched prohibitions. Get it wrong and the fine ceiling is €35 million or 7% of worldwide annual turnover under Article 99(3), whichever is higher.
This article explains exactly what the prohibition covers, the three exhaustively listed exceptions, the procedural safeguards that govern every lawful deployment, and what the rules mean for organisations that are not law enforcement agencies but still use facial recognition or related biometric technology.
What Article 5(1)(h) Prohibits
Article 5(1)(h) bans the use — not merely the development or supply — of real-time remote biometric identification (RBI) systems in publicly accessible spaces for the purposes of law enforcement. Three elements combine to trigger the prohibition; each requires precise reading.
Real-time means identification is performed during or immediately after the capture of biometric data, leaving no meaningful opportunity for human review before the system acts or alerts. Post-hoc analysis of recorded footage is not real-time and falls outside Article 5(1)(h) — though it is high-risk AI under Annex III, point 1, and carries the full Annex III obligation stack under Articles 9–15 and 26 once the relevant deadlines apply.
Remote means identification without the active cooperation or knowledge of the data subject — systems that scan a crowd or a public street, not a border kiosk where the traveller looks at a camera. The distinction matters operationally: cooperative biometric verification at an EU border crossing is not the same legal object as a facial recognition system sweeping a train station concourse.
Publicly accessible spaces covers streets, squares, transport hubs, shopping centres, stadiums, and any space to which the general public has access — regardless of whether it is publicly or privately owned. A privately-run shopping mall is a publicly accessible space for this purpose. Private premises with controlled-access entry (a factory floor, a closed server room) fall outside the scope of this prohibition, though GDPR and other obligations may still apply.
For the purposes of law enforcement is the limiting purpose condition. This is why Article 5(1)(h) does not, on its own terms, directly prohibit a retailer using facial recognition at its own entrance to verify employee access or identify known shoplifters in its own store. Those deployments face different legal constraints — Annex III biometric systems, GDPR's Article 9 special-category data rules, and Article 5(1)(a)/(b) manipulative-technique prohibitions may all apply — but the Article 5(1)(h) prohibition is aimed squarely at law enforcement use.
The Three Exceptions: Exhaustive, Not Illustrative
Article 5(1)(h) contains three exhaustively listed situations in which a law enforcement authority may deploy real-time RBI in publicly accessible spaces, provided additional procedural safeguards are met (see below). These exceptions are exhaustive: if a deployment does not fit one of the three, it is prohibited regardless of the sensitivity of the law enforcement objective.
Exception (i): Targeted search for specific victims
Real-time RBI is permitted for the targeted search for a specific victim of abduction, trafficking in human beings, or sexual exploitation, and for the search for missing persons. The word "specific" is load-bearing: this exception permits finding a named individual, not scanning a crowd to identify any person who might be a trafficking victim. A deployment must be tied to an identified person and an identified crime category.
Exception (ii): Imminent threat to life, physical safety, or terrorist attack
The second exception permits deployment to prevent a specific, substantial and imminent threat to the life or physical safety of natural persons, or a genuine and present or genuine and foreseeable threat of a terrorist attack. Three adjectives — specific, substantial, imminent — constrain how authorities can invoke this exception. A general elevated threat level is not enough. The threat must be directed and temporally urgent.
Exception (iii): Localisation or identification for serious criminal offences
The third exception permits localisation or identification of a person suspected of having committed a criminal offence, for the purposes of a criminal investigation or prosecution or the execution of a criminal penalty. Crucially, the offence must appear in Annex II of the Regulation and must be punishable by a custodial sentence of at least four years in the member state concerned. Annex II covers offences including terrorism, trafficking in human beings, sexual exploitation of children, murder, kidnapping, rape, organised crime, corruption, and cybercrime — not traffic violations, petty theft, or minor administrative offences.
This is a deliberate departure from the original Commission proposal, which referenced the Framework Decision 2002/584/JHA list with a three-year threshold. The final text raised the custodial-sentence floor to four years and embedded the Annex II offence list directly in the Regulation, making it harder for member states to expand the exception without amending the Regulation itself.
Prior Authorisation: The Default Rule
Every lawful deployment under exceptions (i), (ii), or (iii) requires prior authorisation from a judicial authority or another independent administrative authority of the member state concerned. That authorisation must be granted before the deployment begins. It must constitute a binding decision — a soft approval or informal sign-off is insufficient.
The authorisation must specify the particular deployment: the system, the location, the duration, and the exception being invoked. Open-ended, standing authorisations that allow ongoing real-time RBI scanning without temporal or geographic limits do not satisfy Article 5(1)(h).
The urgency procedure
One narrow escape from the prior-authorisation requirement exists. In duly justified situations of urgency — where it is not possible to obtain prior authorisation before starting the use — deployment may begin without authorisation, provided the authority requests authorisation without delay and in any event within 24 hours of the deployment beginning. If the authorisation is refused, use must stop immediately and all data collected must be deleted promptly.
The urgency procedure is not a general workaround. The threshold is genuine impossibility of prior authorisation, not mere inconvenience. Recital 55 of the Regulation makes clear that this is meant for acute operational emergencies, not routine situations where authorities have simply not applied for authorisation.
The Safeguard Package
Lawful use under an exception does not mean unconstrained use. Article 5(1)(h) and associated provisions impose a cluster of safeguards on every authorised deployment:
Necessity and proportionality: Use must be strictly necessary for the specific objective, proportionate to the seriousness of the situation, and limited in time, geographic scope, and the population of data subjects affected.
Fundamental rights impact assessment (FRIA): Before deploying a real-time RBI system (or at the earliest feasible moment in an urgent deployment), the deploying authority must carry out an assessment of the fundamental rights impact. Article 27 of the Regulation sets out the FRIA requirements for deployers of high-risk systems; for law enforcement authorities, the obligations run in parallel with the requirements of the Law Enforcement Directive (Directive 2016/680).
Registration in the EU database: The system must be registered in the EU database established under Article 49 of the Regulation before it is deployed.
Notification: The relevant national market surveillance authority and the data protection authority must be notified of each deployment.
Audit log retention: The system must generate and retain logs sufficient to allow ex-post review of the deployment.
These safeguards are minimum requirements. Member states may impose additional constraints in national implementing legislation.
Member State Optionality
Article 5(1)(h) leaves member states room to manoeuvre in two directions. They may choose not to enable the exceptions at all — a member state can simply leave the general prohibition intact and prohibit all real-time RBI for law enforcement in public spaces on its territory. Several member states may take this approach for constitutional or political reasons.
Conversely, member states that do enable the exceptions must do so through domestic legislation that specifies the applicable exceptions, the authorisation procedure, the competent authority, the safeguards, and the accountability mechanisms. A law enforcement authority cannot invoke Article 5(1)(h) exceptions in the absence of enabling national legislation — the Regulation does not self-execute the exceptions.
This creates uneven rules across the EU. A deployment lawful in one member state may not be authorised in another. For any organisation deploying or supplying real-time RBI to European law enforcement agencies, the starting point is the national legislation of the relevant member state, not the Regulation alone.
Real-Time vs Post-RBI: A Distinction That Matters
The Article 5(1)(h) prohibition applies only to real-time remote biometric identification in publicly accessible spaces for law enforcement purposes. Post-deployment, retrospective analysis of recorded footage — sometimes called "post-RBI" or "non-real-time RBI" — is not caught by this prohibition.
Post-RBI is, however, an Annex III high-risk AI system (heading 1: biometrics, point 1(a)). It inherits the full high-risk obligation stack: a risk management system under Article 9, technical documentation under Article 11 and Annex IV, logging under Article 12, transparency and information to deployers under Article 13, human oversight under Article 14, accuracy and robustness requirements under Article 15, a conformity assessment under Article 43, registration under Article 49, and — for law enforcement deployers — the deployer obligations under Article 26, including human oversight requirements and a prior fundamental rights impact assessment under Article 27.
Under the Digital Omnibus agreed in May 2026, the Annex III obligations for stand-alone high-risk AI systems apply from 2 December 2027 (pushed back from the original 2 August 2026 date). The real-time prohibition, by contrast, has already applied since 2 February 2025.
The practical implication: a police force that abandons real-time facial recognition scanning and instead uses overnight batch analysis of recorded CCTV footage with a biometric identification system has moved out of the Article 5(1)(h) prohibition zone — but into the Annex III high-risk compliance zone, with a documentation, assessment, and registration burden that arrives in December 2027.
What This Means for Non-Law-Enforcement Organisations
Most companies will never deploy a real-time RBI system for law enforcement. But Article 5(1)(h) has indirect relevance for a wider set of organisations.
Facial recognition for physical access control at an office or factory does not, by its terms, engage Article 5(1)(h) — it is not for law enforcement and may not be in a "publicly accessible space." But it is a biometric identification system. If it scans people in a space accessible to the public, it will likely be Annex III high-risk. If it identifies people without their knowledge in a genuinely public space (not a controlled lobby), the Article 5(1)(a) manipulative-technique prohibition and Article 5(1)(c) social-scoring ban may come into play. GDPR Article 9 applies regardless.
Public-space monitoring with analytics — crowd-flow cameras with demographic classification — sits in a different risk tier from real-time individual identification, but it still engages biometric data processing under Annex III (emotion recognition systems under heading 1(c); biometric categorisation under heading 1(b) if the system categorises individuals by race, political opinion, religion, or other sensitive attributes).
Supplying real-time RBI systems to law enforcement makes the supplier a provider. The Article 5(1)(h) prohibition applies to use, but a provider that knowingly places a real-time RBI system on the market for law enforcement use in public spaces — without any mechanism ensuring it is deployed only under the conditions of Articles 5(1)(h)(i)–(iii) — faces significant legal exposure. Article 16 provider obligations and Article 25's role-shift provisions are relevant here.
The short version: if your organisation's AI system captures biometric data, processes it to identify natural persons, and operates in or near publicly accessible spaces, you need a clear-eyed legal analysis — not a quick assumption that Article 5(1)(h) does not apply.
The Penalty Picture
Breach of the Article 5 prohibitions — including Article 5(1)(h) — attracts the top-tier fine under Article 99(3) of the Regulation: up to €35 million or 7% of total worldwide annual turnover of the preceding financial year, whichever is higher. There is no lower "unintentional breach" category within Article 5; the tier is flat.
The SME and start-up cap under Article 99(6) applies: for smaller organisations, the applicable fine is the lower of the fixed amount or the turnover percentage. That provides some proportionality, but €35 million is still a hard ceiling, not a floor.
Beyond administrative fines, member states retain the power to impose criminal sanctions under national law for Article 5 violations. Several member states are expected to use this power, particularly for egregious or deliberate breaches.
Enforcement of Article 99 has applied since 2 August 2025. The combination of a February 2025 prohibition date and an August 2025 enforcement date means that from August 2025 onward, the full sanction package is live.
How Confir Helps
Confir's Article 5 prohibited-practice checklist uses deterministic, rule-based logic to identify whether a system's characteristics and intended purpose match any of the Article 5 prohibitions — including the real-time RBI ban. The same intake flags the relevant exception criteria and, where a system is not prohibited but is Annex III biometric AI, routes it into the high-risk workflow for classification and scoping.
The checklist is designed to be audit-defensible: the rule that fires is human-readable, and every finding maps to a specific Article and sub-paragraph. Because the engine is rule-based rather than probabilistic, the output is reproducible — run the same intake twice and get the same classification.
If your organisation uses biometric technology in any context — access control, public-space monitoring, identity verification — the Article 5 and Annex III screening in Confir is the starting point for understanding your compliance position under the EU AI Act.
Practical Steps for Affected Organisations
Law enforcement agencies and their suppliers:
- Map all existing and planned biometric identification deployments against the Article 5(1)(h) criteria: real-time, remote, publicly accessible space, law enforcement purpose.
- If a deployment matches, identify whether it falls within exceptions (i), (ii), or (iii). If not, it must stop.
- Verify that national enabling legislation exists in each relevant member state.
- For each exception-based deployment: obtain prior judicial or independent administrative authorisation; conduct a fundamental rights impact assessment; register the system in the EU database under Article 49; notify the relevant authorities.
- Establish an urgency protocol that documents the conditions for invoking the 24-hour post-deployment authorisation window.
Non-law-enforcement companies using biometric AI in or near public spaces:
- Confirm whether your system operates in a publicly accessible space and whether it identifies natural persons remotely.
- If yes, conduct an Annex III classification analysis: biometric identification systems (Annex III, point 1(a)) are high-risk. Biometric categorisation (point 1(b)) and emotion recognition (point 1(c)) are separately high-risk.
- Check GDPR Article 9 compliance for biometric data as special-category data: a lawful basis and a Data Protection Impact Assessment are required.
- Document the legal analysis. If Article 5(1)(h) does not apply because your purpose is not law enforcement, record that conclusion and the reasoning.
A note on supply-chain exposure: if your company develops or sells biometric identification software to customers who may use it for law enforcement, you carry provider obligations under Article 16. That includes checking — through contractual means and technical design — that the system is not placed on the market for uses that are prohibited. Supplying a general-purpose facial recognition API to a police force that then uses it for real-time public-space identification without exception authority is not a safe position. Article 25's role-shift provision means your legal exposure depends on how the system is presented, packaged, and sold, not just what you intended.
Related guides
- six prohibited AI practices
- unacceptable risk category
- EU AI Act risk levels
- Article 5 enforcement deadlines
- subliminal manipulation techniques
- EU AI Act overview
Manage your EU AI Act compliance in one place
Confir automates risk classification, technical documentation, and audit trails for any company. No consultants. No 6-month projects. 7-day free trial.
Start free trial →