Article 5(1)(h) biometric identification ban: requirements

What Article 5(1)(h) asks law enforcement to prove before any live facial recognition

A law enforcement compliance lead receives a request to deploy live biometric matching in a public square. The first answer is that the default is prohibited. Article 5(1)(h) bans real-time remote biometric identification in publicly accessible spaces for law enforcement, and the Act allows it only in three narrow situations: searching for specific victims or missing persons, preventing a specific and imminent threat to life or a terrorist attack, and locating suspects of Annex II offenses punishable by at least four years' custody. Each exception is a set of conditions the authority must satisfy for each use, not a general permission to run the system. The risk the prohibition targets is mass surveillance of people who are not suspected of anything, captured as they walk through a public space. That is why the burden falls on proof rather than intent: the authority must be able to show, for every single deployment, which exception applies and why.

Before any use, the authority must have completed a fundamental rights impact assessment under Article 27 and registered the system under Article 49. Each use also needs prior authorization from a judicial authority or a binding independent administrative authority, and each use must be notified to the market surveillance authority and the national data protection authority. In urgent cases, use may begin if authorization is requested within 24 hours, but if authorization is refused, use must stop and all data and outputs must be deleted. The Act also bars any decision with an adverse legal effect on a person based solely on the system's output. Confirm with your national legislation whether the exceptions are provided for at all, since they are available only where national law creates them and that law must be notified to the Commission within 30 days of adoption.

The hard part is evidence for each use, not the existence of a policy. A practical file for one deployment would link the authorization, the impact assessment version, the registration record, the notifications, the operator's log of the specific event and the record of how the output was reviewed by a human before any action. Ask the vendor or integrator for logs that tie each match request to its legal basis and retention period, and confirm they can be exported for an authority. Breaching the prohibition carries fines of up to EUR 35 million or 7% of total worldwide annual turnover for the preceding financial year, whichever is higher, under Article 99(3). The consolidated Article 5 text and the Commission's guidelines on prohibited practices should be read together with national law before any request is approved.

Which systems, authorities and deployments does Article 5(1)(h) reach?

Article 5(1)(h) applies only when several conditions line up: the matching is live, the space is publicly accessible, and the user is law enforcement. Each card below is a scoping decision or a party that changes the work, so settle them before anyone designs a camera feed or signs a vendor contract.

Live versus post-event matching

The prohibition targets real-time remote biometric identification, so the question is whether matching happens while the person is in view or after recording. Post-event analysis of stored footage falls under different rules and is generally treated as a separate high-risk use. Check the pipeline for any path where a live feed is matched within moments, because a short delay does not automatically move a system outside the ban. Document the timing design and the exact point at which a match is generated.

Publicly accessible spaces

The ban covers identification in publicly accessible spaces, so the physical location of each camera or access point is a legal input. Streets, transit hubs, stadiums and shopping areas are typical examples, while private premises may fall outside this specific ban. Map every camera and sensor to a location category and record the reasoning. Where a space is mixed, such as a building lobby open to the public, treat it as in scope until counsel confirms otherwise.

Use by or for law enforcement

The prohibition is aimed at use by law enforcement authorities or on their behalf, which makes the identity of the operator and the customer decisive. A system run by a private security firm with no law enforcement mandate may face different obligations, while a vendor deploying a system for a police force does. Confirm in writing who the deploying authority is, who sets the search purpose, and who receives the output. Map each of these roles to the Act's provider and deployer definitions before the design is fixed.

National law and exceptions

The three exceptions in Article 5(1)(h) are available only where the member state's national law expressly provides for them and sets out the detailed rules. Some member states may not provide for the exceptions at all, which removes the lawful route for live use in that country. Ask the competent ministry or counsel which national statute applies, whether it has been notified to the Commission within the required period, and whether it limits the purposes or locations further.

Watchlist and reference data sources

Any system that compares live faces against a reference set depends on the source of that set. Watchlists built from untargeted internet or CCTV scraping raise a separate prohibition, and a list compiled without a documented legal basis creates a problem regardless of the matching engine. Inventory each watchlist, its origin, the legal authority for it, its update cadence and its deletion rules. Include any list shared with another agency or vendor in the scope.

Biometric matching component and operators

The biometric matching component is the technical core that converts faces into templates and compares them, and the operators are the people who start a search and act on results. Both are in scope because the Act requires prior authorization for each use and prohibits adverse decisions based solely on system output. Record which component performs matching, where templates are stored, and which trained operators can trigger a search. Assign an accountable owner for each search request and keep the logs that tie it to an authorization.

How authorization, impact assessment and registration gate each use

Article 5(1)(h) treats every live use as a separate event that needs its own prior authorization. Before a law enforcement authority deploys real-time remote biometric identification in a publicly accessible space, a judicial authority or a binding independent administrative authority must approve that specific use. Approval is not a standing licence for the system or the location. For each use, the authority needs to see the purpose, the target, the place, the time window and the reason the exception applies. Operators should treat the authorization record as the first document in every use file, and should confirm with their national authority which body is competent and what form the request must take.

Authorization is only one gate. Under Article 5(2), the law enforcement authority must also complete a fundamental rights impact assessment under Article 27 and register the system under Article 49 before use is authorised. Teams running the process should keep the impact assessment, the registration reference and the authorization decision linked in one case record, so an inspector can trace each use from request to outcome. In urgent cases, registration may follow without undue delay, which means the file must be completed afterwards rather than skipped. Confirm with the relevant authority what documentation it expects at each stage, because the Act sets the outline and national practice fills in the detail.

The urgency route in Article 5(3) is the most time-sensitive part of the process. Use may begin before authorization if the request is made within 24 hours. If the authority refuses, use must stop and all data and outputs obtained must be deleted. Notification duties also apply to each use: the authority must notify the market surveillance authority and the national data protection authority, and any member state that adopts these exceptions must notify the Commission within 30 days of adoption. Finally, Article 5(3) bars any decision with an adverse legal effect on a person based solely on the system's output, so the operational procedure should require documented human review before anyone is affected by a match.

How an assessor tests Article 5(1)(h) and which evidence passes

This table sets out each test an assessor is likely to run against Article 5(1)(h) use of live biometric identification, the evidence requested and the findings that most often fail. Read it as a checklist for building a per-use evidence file before any deployment, since the assessor will ask for proof that each individual use met every condition.

Test	Test approach and evidence requested	Common finding
Exception coverage per use	Document review of the legal basis for each logged use, matched to one of the three exceptions (victim or missing person search, imminent threat or terrorist attack, Annex II suspect). Request the case record showing which exception applied.	Use logged without a stated exception, or the case fits none of the three exceptions.
Authorization before use	Sample of logged uses compared against authorization decisions from a judicial or binding independent administrative authority. Evidence: signed decision with date and scope, timestamped before the first match.	Authorization dated after the match, or scope of the authorization does not cover the location or purpose used.
24-hour urgency path	Walkthrough of the urgent procedure, then sample of urgent uses. Evidence: time of start, time authorization was requested, and the outcome.	Authorization request filed later than 24 hours after the urgent use began, or no record of the request.
Refused urgent use	Check that use stopped on refusal and that data and outputs were deleted. Evidence: deletion logs, storage and backup checks, and confirmation from the authority.	Outputs retained in backups, analyst notes or exports after refusal.
Fundamental rights impact assessment	Document review confirming the Article 27 assessment was completed before authorization. Evidence: approved assessment, version history and date.	Assessment still in draft, or completed after the first use.
Registration	Check the system is registered under Article 49 before use. For urgent cases, confirm registration followed without undue delay. Evidence: registration record and dates.	Registration missing for the system, or urgent-case registration with no documented follow-up.
Notification to the two authorities	Sample of uses checked against notices to the market surveillance authority and the national data protection authority. Evidence: dated notices referencing each use.	Notifications missing for urgent uses, or sent only for some uses in the period.
Commission notice where national law adopts the exceptions	Confirm national law provides for the exceptions and that the Commission was notified within 30 days of adoption. Evidence: national legal text and the notification record.	Exceptions relied on without a national legal basis, or notice to the Commission not filed or filed late.
No sole reliance on the output for adverse decisions	Walkthrough of decision workflows and sample of adverse decisions. Evidence: documented human review and records showing other grounds beyond the system output.	Adverse decisions traceable only to the system output, with no independent review recorded.

Implementing the Article 5(1)(h) controls step by step

This sequence turns the Article 5(1)(h) conditions into a working control set, from the national legal basis through per-use logging, deletion and notification, so that each live use can be shown to meet the prohibition's exceptions and safeguards.

Confirm the national legal basis for each exception
Counsel for the law enforcement authority reviews the national law that would allow each of the three exceptions: victim and missing person searches, prevention of a specific and imminent threat to life or a terrorist attack, and location of suspects of Annex II offenses punishable by at least four years' custody. Exceptions are available only where national law provides for them, so the team must confirm which exceptions the law covers and which it does not. The output is a signed legal basis memo that lists each permitted purpose, the authority that may approve it, and the national provisions relied on. Confirm the final text with the competent ministry and your own legal advisers.
Define the request workflow and authorization record
The team maps every step from a field request to a decision: who may ask, what the request must state, which judicial or binding independent administrative authority decides, and how urgent requests are routed. Each use needs prior authorization, and the urgency path requires the request within 24 hours, so the workflow must show the timing controls. The output is an authorization log schema with fields for the purpose, the individual searched for or threat relied on, the authorizing body, the decision, the time window, and the link to the request. Done when a reviewer can trace any use back to a single authorization record.
Complete and file the fundamental rights impact assessment
The law enforcement authority completes the fundamental rights impact assessment required under Article 27 before any authorized use. The assessment covers the rights affected, the necessity and proportionality of each purpose, the safeguards, and the governance measures. Legal, data protection and operational staff sign off, and the assessment is kept with the authorization records. The output is a dated, signed assessment that is referenced in every authorization request. The team should confirm the template and filing route with the market surveillance authority before use.
Register the system before authorized use
Use is authorized only after the system is registered under Article 49, and the registration must reflect the deployment as it will run. The team prepares the registration entry from the system description, the purposes, the watchlist and data sources, the operating locations and the named responsible roles, then checks it against the impact assessment. In urgent cases, Article 5(2) allows registration to follow without undue delay, so the team should record the reason for that path. The output is a registration record with a reference number and a change log that is updated whenever the configuration changes.
Build per-use logging and deletion
Engineers configure the system to log each use as a discrete event: the authorization reference, the time and place, the purpose, the operator, and the outputs produced. Logs must not themselves hold more biometric data than needed. If a request is refused, all data and outputs from that use must be deleted, so the deletion procedure is scripted, scoped to a single use, and verified with a record. Self-hosted platforms can help with the audit trail. For example, Nextcloud's admin_audit app writes to audit.log, and OpenBao audit devices record API requests with sensitive values hashed. Confirm that each component meets the authority's logging rules. The output is a tested deletion procedure with evidence from a rehearsal run.
Wire the notification steps
The team sets up notifications for each use to the market surveillance authority and to the national data protection authority. The notification must reference the authorization record and carry the facts the two authorities need to review the use. The process owner tracks timing against the rules in Article 5(4) and (5) and confirms that the national law provides for the exception. The output is a notification template, a sending procedure with named owners, and a register of sent notifications that matches the authorization log.
Rehearse the urgency path
The team runs a tabletop exercise of an urgent use: the request is made, use begins while authorization is pending, the 24-hour window is tracked, and the outcome is either approval or refusal. A refusal triggers stop, deletion and notification. The exercise also tests whether the rule that no adverse legal decision may rest solely on system output is applied in the workflow. The output is an exercise report listing gaps, owners and fixes, and a rerun after changes. Independent auditors and assessors review the evidence but do not perform the rehearsal or certify the controls.

Evidence that shows each use was lawful and how to keep it current

Article 5(1)(h) exceptions are only lawful when each use can be traced back to a prior authorization, a completed impact assessment and a registration, followed by notifications and a record of what the system output and what happened to it. The cards below cover the artifacts an assessor or authority is likely to ask for, which sources can produce parts of them, and what to confirm in your own environment.

Authorization decisions with timestamps

Each use needs prior authorization from a judicial authority or a binding independent administrative authority, and urgent use may start only if authorization is requested within 24 hours. Keep the signed decision, the scope it grants, the time it was issued and the time any urgent request was filed. Confirm that the decision record links to the specific deployment and use it covers, because a general approval does not show that each use was authorized. Where the authority is a court, store the decision in the controlled case system rather than a shared drive.

Impact assessment versions

Use is authorized only after the law enforcement authority has completed a fundamental rights impact assessment under Article 27. Keep every version of the assessment with its approval date, the system configuration it describes and the reviewer who signed off. An assessment that predates a model update or a change in watchlist scope will not cover the later use. Record which version was in force for each authorized use so the link between assessment and use can be shown.

Registration records

The system must be registered under Article 49 before authorized use, and in urgent cases registration may follow without undue delay. Keep the registration reference, the date of registration and the date of any urgent-case registration, and compare them against the first use date for each deployment. Check that the registration was filed before the first live use, or that the urgent-case record explains why it could not be. Retain the registration history even after a system is retired.

Notification receipts

Each use must be notified to the market surveillance authority and the national data protection authority. Keep the notification itself, the transmission record and the acknowledgment for each use, linked to the authorization it relies on. Confirm with your national authorities which exceptions their law provides for and whether the Commission notification within 30 days of adoption has been made, since the exceptions are available only where national law provides for them.

Per-use request logs and output records

Logs should show which operator started each use, the authorization reference, the time window, the watchlist or search parameters, and the outcome. Nextcloud's admin_audit app can write its additional event information to audit.log in the data directory, or to a path set with logfile_audit, which helps for case documents held there. OpenBao audit devices keep a JSON log of every API request and response, including errors, with most sensitive values hashed with HMAC-SHA256, which helps prove access to keys and secrets. Confirm what each tool logs in your version and whether those logs cover the biometric system itself.

Deletion certificates after refusal

If authorization is refused, use stops and all data and outputs must be deleted, so keep a deletion record for each refused request. The record should list what was deleted, from which stores and backups, when, and by whom, and should be signed by the responsible operator. Confirm that backups, caches and derived outputs are covered, and that any language-model components that processed case text were also cleared. Test this in an isolated environment before you rely on it.

Human review records for decisions

No decision with an adverse legal effect on a person may be taken based solely on the output of the system. Keep a record for each decision showing who reviewed the output, what independent facts they checked, and their conclusion, with the timestamp. For any language-model components, Langfuse traces capture LLM calls, retrieval steps, tool executions, timing, inputs, outputs, token usage and metadata, which can show what the model contributed to a review. Confirm that traces are retained for the period your legal obligations require and are access-controlled, because they may contain personal data.

What meeting Article 5(1)(h) costs in money and effort

This table lists the work an organization pays for when a law enforcement authority relies on the Article 5(1)(h) exceptions, with who is paid, whether each item is one-time or recurring, and what drives its size. The Act sets fines but does not price this work, so use the drivers column to scope quotes and ask for each item separately.

Cost component	One-time or recurring, and who is paid	What drives the cost
Legal analysis of national exceptions	One-time per member state, plus updates when national law changes. Paid to counsel or internal legal staff.	Number of member states and authorities involved, and whether national law provides for each exception (Article 5(5)).
Fundamental rights impact assessment drafting	One-time per system and per material change. Paid to the authority's internal team or an outside consultant it engages.	Number of matching systems, complexity of the deployment and how many use cases the assessment must cover (Article 27).
Independent review of the impact assessment	One-time per assessment, with review on material change. Paid to an independent reviewer the organization engages.	Depth of the assessment, the quality of prior documentation and the number of reviewer rounds needed.
Registration and notification administration	Recurring, as each use must be notified to the market surveillance and data protection authorities (Article 5(4)). Paid through internal staff time.	Volume of authorized uses, number of notifying authorities and the time allowed by national rules for each notice.
Authorization request handling	Recurring per use. Paid through internal staff time and on-call capacity for urgent requests.	Volume of requests, the 24-hour window for urgent authorization requests (Article 5(3)) and the number of judicial or administrative bodies involved.
Logging and audit engineering	One-time build, then recurring storage, review and retention. Paid to engineers and for infrastructure. Self-hosted open-source audit logging, such as Nextcloud's admin_audit app or OpenBao audit devices, can reduce license spend for these components.	Number of systems in the logging chain, event volume, retention requirements and how much log data must be hashed or protected.
Deletion and urgency-path testing	One-time test design, then recurring testing after changes. Paid to engineers and to any external tester engaged.	Number of data stores and outputs, the refusal path that requires deletion (Article 5(3)) and how often the system changes.
Auditor or authority review time	Recurring at each review cycle. Paid to the authority, its inspectors or an independent auditor the organization engages.	Number of inspections, the completeness of evidence packs and the number of authorities that request records.
Human oversight and decision controls	Recurring. Paid through internal staff time to confirm that no adverse decision rests solely on system output (Article 5(3)).	Number of decision types affected and how many staff must sign off on each output.

Who does what: the authority, the implementation partner and the auditor

The law enforcement authority that wants to use live remote biometric identification owns the legal decision to deploy it. Under Article 5, each use needs prior authorization from a judicial authority or a binding independent administrative authority, and the authority must complete a fundamental rights impact assessment under Article 27 and register the system under Article 49 before use. The authority also owns the notifications to the market surveillance authority and the national data protection authority. Vendors and integrators cannot grant any of these approvals.

Authorization: The judicial or independent administrative decision for each use, including the urgency route with a 24-hour request window.
Impact assessment: The Article 27 fundamental rights assessment, signed off by the authority and kept on file.
Registration and notification: Registration under Article 49 and per-use notices to the market surveillance and data protection authorities.
Use decisions: Confirmation that no adverse legal decision rests solely on system output.
Outsourcing limits: Technical support can be bought in, but the legal accountability and the decision to operate stay with the authority.

Before engaging any partner, confirm with the authority's legal team which national law provides the exceptions and what the notification timeline to the Commission requires.

Questions buyers ask about Article 5(1)(h) compliance

Can a private company be caught by the Article 5(1)(h) ban?

Article 5(1)(h) is aimed at law enforcement authorities. It prohibits real-time remote biometric identification in publicly accessible spaces for law enforcement purposes, subject to three narrow exceptions. A private company that runs live facial recognition for its own security, retail analytics or access control is not covered by this specific prohibition, but that does not mean the use is unregulated. Other biometric prohibitions, including the bans on untargeted scraping of facial images and on biometric categorisation by sensitive attributes, apply more broadly and are covered on their own pages. Private operators should confirm with counsel which prohibition or high-risk category, if any, their use falls under before deciding that the ban is irrelevant to them.

What are the fines for breaching the live facial recognition ban?

Breaching the prohibition in Article 5(1)(h) can carry fines of up to EUR 35 million or, for an undertaking, 7% of total worldwide annual turnover for the preceding financial year, whichever is higher, under Article 99(3) of the AI Act. The higher figure applies to large groups, so turnover matters more than the fixed amount for them. The fine is a ceiling set by the regulation, and national authorities decide the actual amount case by case. Fines are only one exposure. A non-compliant deployment can also lead to orders to stop use, deletion of data and outputs, and reputational damage with regulators and the public.

How long does it take to prepare for an authorised use?

No duration is supplied for this work, and the time depends on the case. The main drivers are how many distinct uses are planned, whether an authorisation request has already been prepared, how mature the fundamental rights impact assessment under Article 27 is, whether the system is already registered under Article 49, and how quickly the judicial or independent administrative authority can review the file. Systems that already have documented data flows, access logs and retention rules usually need less preparation than systems built without them. Ask any partner for a written scope and timeline before work starts, and ask your legal team to confirm the national procedure, because the authorising body and its process differ by Member State.

Can our team handle Article 5(1)(h) work in-house?

Engineering teams can usually prepare the technical side in-house: logging, access controls, retention settings, human review workflows and the records needed to show what was run and when. The legal and fundamental rights work is different. Writing the fundamental rights impact assessment, framing the authorisation request, and deciding whether a narrow exception such as locating a missing person applies require lawyers and people with fundamental rights expertise, working with the law enforcement authority's own legal function. Most organizations split the work: legal owns the justification and the authorisation file, while technical staff, or an implementation partner, supply the system evidence.

What does the law enforcement authority need to provide?

The authority must own the legal basis and the decision to seek each use. In practice it needs a named system owner who can describe the system's purpose, data sources, accuracy testing and operators, a legal lead who can confirm that a permitted exception and national law apply, and a data protection contact who can work through the data protection authority notification required under Article 5(4). It also needs documented records of each authorisation, the time and place of each use, and the outcome, since each use must be notified. Without these people and records, technical evidence cannot show that the conditions were met.

Can an outside partner prepare the evidence without giving a legal opinion?

Yes, an implementation partner can prepare the technical and documentary evidence without giving a legal opinion on lawfulness. DeployOpen plans, implements, hardens and documents self-hosted open-source platforms inside the client's own infrastructure, and can prepare system records, access and audit logging configuration, and evidence packs for review. DeployOpen does not issue legal opinions, audit reports or certifications. The authority remains responsible for deciding whether a use is lawful, and any statement on compliance must come from its own counsel or from an independent assessor where one applies. The scope of any engagement should say so in writing.

Which logs does a system need to show each use was controlled?

A system that may be used under Article 5(1)(h) should record who initiated each use, the authorisation reference, the time, the scope and the outcome, and it should keep those records separate from the operational data they describe. Open-source components can help produce this evidence. Nextcloud's admin_audit app, for example, logs additional event information to audit.log in the data directory or to a path set with logfile_audit, and OpenBao audit devices keep JSON logs of every API request and response with most sensitive values hashed. Confirm with your own engineers and counsel which logs satisfy the authority's requirements, and whether an alert on each use can be routed to the notification process.

How DeployOpen prepares systems and evidence for Article 5(1)(h)

DeployOpen plans, implements and documents self-hosted open-source platforms inside the client's own infrastructure, and prepares the logs, records and access controls that an Article 5(1)(h) assessment would examine. We do not issue authorizations, impact assessment conclusions or registrations, which remain the responsibility of the law enforcement authority and the competent authorities.

How we scope

Engagements are fixed-scope, with the systems, deliverables and timelines agreed in writing before work starts.
The written scope states which biometric platforms, logging paths and storage locations are in and out of the work.
We confirm with the client which authorities, legal reviewers and data protection officers own each decision.
Scope documents name who owns the Article 27 impact assessment inputs and the Article 49 registration record.

How we build

We configure audit logging for each platform so that every access, query and output has a timestamped record.
We set role-based access so that only authorized operators can start, review or stop a recognition session.
We design retention and deletion routines that support the requirement to delete data and outputs after a refused urgent use.
We test that logs are complete and tamper-evident before the system is handed over for review.

How we hand over

Handover includes configuration records, log schemas, access matrices and runbooks for each authorization step.
We provide a notification and evidence checklist mapped to the market surveillance and data protection authority duties.
Documentation states clearly which artifacts the client must produce and which an independent assessor will need to see.
Each deliverable is versioned so that auditors can see what changed between authorized uses.

How we support

Ongoing support, upgrades and continuous testing are available as retainers after the initial handover.
Retainers can cover periodic log reviews, configuration drift checks and updates to runbooks when national law changes.
Security testing of the recognition pipeline can be scoped separately, including AI system and API testing.
Ask us to confirm exactly which evidence we can prepare and which must come from your legal and oversight functions.

Article 5(1)(h) remote biometric identification for law enforcement