EU AI Act Annex III Point 6: AI for Law Enforcement Risk Assessment

Annex III of the EU AI Act (Regulation (EU) 2024/1689) lists eight categories of high-risk AI systems. Point 6 covers law enforcement. If your system is intended for use by or on behalf of a law enforcement authority — or by a Union body supporting such authorities — and it performs one of the four functions listed below, it is high-risk. Full provider and deployer obligations apply from 2 December 2027 under the Digital Omnibus agreed in May 2026.

The stakes are concrete: non-compliance with high-risk requirements carries a maximum fine of €15 million or 3% of total worldwide annual turnover (whichever is higher) under Article 99(4). An Article 5 violation — for instance, deploying a system that the Act prohibits outright — goes to €35 million or 7% under Article 99(3).

What Annex III Point 6 Actually Covers

Four distinct functions trigger high-risk classification under point 6:

Victim-risk assessment. AI used to assess the risk that a natural person will become a victim of a criminal offence. This includes threat-assessment tools that score potential victims of domestic violence, organised crime, or repeat victimisation.

Polygraph and emotion-detection tools. AI used as polygraphs or similar tools to detect the emotional state of a person, or to test the reliability of a person's statements through physiological or behavioural signals — voice stress analysis, micro-expression recognition, pupil-dilation measurement.

Evidence reliability assessment. AI used to evaluate the reliability of evidence in the course of investigation or prosecution. Forensic facial-recognition systems that generate candidate match rankings, audio/video authenticity tools that flag potential manipulation, and fingerprint-matching algorithms that rank confidence scores all fall here because their output directly conditions what evidence reaches a court.

Recidivism and offending risk — with a critical boundary. AI used to assess the risk of a person re-offending, or to predict the risk that a person will commit a criminal offence. This is where the classification framework intersects with an outright prohibition that demands careful attention.

The Prohibition Boundary You Cannot Miss

Article 5(1)(d) of the EU AI Act — in force since 2 February 2025 — prohibits AI that makes risk assessments of individuals for the purpose of predicting the risk of a criminal offence based solely on profiling or on the assessment of personality traits and characteristics. This is a banned practice, not a high-risk one. A system that generates a recidivism score purely from a demographic profile, social-media behaviour, or inferred personality traits, without any grounding in objective, verified facts about the individual's circumstances, crosses into prohibited territory.

The high-risk Annex III point 6 use cases are the adjacent but lawful ones: systems that support human law enforcement assessment grounded in objective, individual-specific facts — verified criminal history, documented behaviour patterns, case-specific circumstances — where a human decision-maker reviews the output and bears accountability for the outcome. The line is between a tool that informs human judgment and one that replaces it with a statistical profile alone.

If you are unsure which side of the line your system sits on, that uncertainty is itself the signal to seek legal advice and document your analysis thoroughly before deployment.

Profiling in the course of detection or investigation. AI used for profiling natural persons in the course of detection, investigation, or prosecution of criminal offences is also high-risk under point 6. Unlike the above, the Act does not provide a profiling carve-out here — profiling for law enforcement purposes triggers high-risk obligations regardless of how the system is constructed.

The Art 6(3) Filter and Why It Rarely Applies Here

Article 6(3) allows a provider to conclude that an Annex III system is not high-risk if it poses no significant risk of harm to health, safety, or fundamental rights — for example, it performs a narrow procedural task or improves a previously completed human activity without influencing assessments about specific persons.

This filter is very difficult to apply to point 6 systems. Any system whose output conditions a law enforcement decision about a named individual — whether to detain, investigate, charge, or release — poses a significant risk to that person's fundamental rights by definition. Providers who claim the Art 6(3) exemption for a point 6 system must document that assessment and register it in the EU database under Article 49.

Who Does What: Provider and Deployer Roles

The Provider's Obligations (Articles 9–15, 43, 47, 49, 72–73)

The provider — the organisation that develops and places the system on the market, or puts it into service under its own name — carries the heaviest load.

Risk management system (Article 9). The provider must establish, document, and maintain a risk management system covering the entire lifecycle: hazard identification, risk evaluation, mitigation measures, and residual risk assessment. For law enforcement AI, this means explicit analysis of false-positive harms (an innocent person flagged as high-risk), false-negative harms (a genuine threat missed), and demographic disparate-impact (whether error rates differ across protected groups). Article 9 is a living document obligation — the assessment updates as the system evolves.

Data and data governance (Article 10). Training, validation, and test datasets must be relevant, representative, free of errors so far as possible, and complete for the system's intended purpose. For law enforcement AI, the historical data problem is acute: datasets drawn from past policing activity often carry biases from over-policing of particular communities. The provider must document known limitations and what steps were taken to address them.

Technical documentation (Article 11 / Annex IV). Before the system goes on the market, the provider must compile an Annex IV technical documentation pack: system design and architecture, training data characteristics, performance metrics disaggregated by relevant demographic groups, known limitations and failure modes, post-market monitoring procedures. This is the document a conformity assessor, market surveillance authority, or notified body would examine.

Transparency and information to deployers (Article 13). The system must be designed to allow deployers to understand what it does and does not do. Providers must supply instructions for use that cover the system's purpose, performance characteristics, limitations, human oversight requirements, and the data the system was trained on.

Human oversight (Article 14). Providers must design in the capability for human oversight — not merely document that it is desirable. The system must be capable of being overseen, corrected, and overridden by appropriately trained personnel.

Accuracy, robustness, cybersecurity (Article 15). Law enforcement AI systems must achieve levels of accuracy, robustness, and cybersecurity appropriate to their intended purpose and foreseeable misuse. Accuracy metrics must be documented in the technical documentation. Robustness covers behaviour under adversarial input or distribution shift. Cybersecurity is particularly relevant for systems handling sensitive criminal-justice data.

Conformity assessment (Article 43). The standard route for Annex III point 6 systems is internal conformity assessment — the provider reviews compliance against the Article 9–15 requirements and documents the findings. No mandatory third-party notified-body assessment is required unless the system is embedded in a regulated product listed in Annex I. However, "internal" does not mean cursory: regulators will scrutinise the quality of the provider's self-assessment.

EU Declaration of Conformity (Article 47) and CE marking (Article 48). Before the system is placed on the market, the provider issues a Declaration of Conformity and affixes the CE mark.

Registration in the EU database (Article 49). Point 6 law enforcement systems are registered in the non-public section of the EU AI database. The non-public section is accessible to competent authorities but not to the general public — a recognition that operational law enforcement information requires confidentiality. Providers register the system; deployers who are public authorities register their deployment separately.

Post-market monitoring and serious incident reporting (Articles 72 and 73). After deployment, the provider maintains a post-market monitoring system and reports serious incidents — events that cause or risk causing significant harm to health, safety, or fundamental rights — to the relevant market surveillance authority.

The Deployer's Obligations (Articles 26 and 27)

The deployer is typically a law enforcement authority or a Union body supporting such authorities. Deployer obligations under Article 26 include: using the system in line with the provider's instructions, ensuring appropriate human oversight, monitoring the system's operation, informing the relevant authority of serious risks, and keeping logs of the system's operation for a minimum of six months.

Fundamental Rights Impact Assessment (Article 27). This is the obligation that most public-authority deployers will find demanding. Article 27 requires deployers who are public bodies, or private bodies providing public services, to conduct a FRIA before deploying a high-risk AI system. The FRIA must assess the impact on the rights protected under the EU Charter of Fundamental Rights: the right to a fair trial, the presumption of innocence, non-discrimination, privacy, and freedom of movement. It must identify concrete mitigation measures, document residual risks, and be updated when the deployment context changes materially.

For law enforcement AI specifically, the FRIA should address: how the system's outputs will be used in operational decisions; what training is in place for officers who act on system recommendations; what oversight and override mechanisms are available; and what complaint and redress procedure exists for individuals affected by decisions informed by the system.

Public-body deployers must register their deployment — including the FRIA — in the non-public section of the EU database.

Worked Example: Regional Police Force, Recidivism Scoring Tool

A regional police force in Austria is evaluating a third-party AI system that generates a numerical recidivism risk score for suspects at the point of arrest. The score draws on verified prior convictions, documented supervision violations, and case-specific circumstances documented in the case file. Officers use the score as one input alongside interview notes and victim statements when making a custody recommendation to the duty magistrate.

Classification. The system assesses the risk of a person re-offending — point 6(d) of Annex III. It is not based solely on profiling or personality traits (it uses objective, case-specific facts), so Article 5(1)(d) does not prohibit it. The Art 6(3) filter is inapplicable: the system directly conditions a liberty-affecting decision. Classification: high-risk.

Provider obligations. The software vendor must document the system under Annex IV, including disaggregated performance metrics by nationality and prior-conviction category. The vendor's risk management documentation must address false-positive harm (an officer recommends remand on the strength of a score that turns out to be wrong) and demographic disparate impact. Before selling into Austrian law enforcement, the vendor completes internal conformity assessment under Article 43, issues an Article 47 Declaration of Conformity, and registers the system in the non-public EU database under Article 49.

Deployer obligations. The police force, as a public-authority deployer, conducts an Article 27 FRIA before deploying the tool. The FRIA identifies that the system must never be the sole basis for a custody recommendation — it must be presented alongside human analysis of the case facts. The force documents its override procedure (officers document when they depart from the score and why), trains custody officers on the system's limitations and failure modes, and registers the deployment in the non-public EU database. It sets up an operational log retained for six months, aligned with Article 26 record-keeping requirements.

Timeline. Both the vendor and the force must be compliant by 2 December 2027. The documentation workload — Annex IV pack, conformity assessment, FRIA — is substantial. For a deployment of this sensitivity, starting compliance preparation in early 2026 is not overcautious.

The Non-Public Database and Why It Matters

Registration under Article 49 is often overlooked in discussions of law enforcement AI, partly because the non-public section is not visible to civil-society researchers or the general public. But the registration requirement serves two practical functions. First, it creates a centralized record accessible to competent market surveillance authorities and data protection authorities — meaning a gap in the register is itself an audit finding. Second, for deployers who are public bodies, registration of the FRIA creates a documented accountability trail: which authority deployed which system, under what stated safeguards.

Providers and deployers should treat registration not as a filing task but as a governance milestone that confirms all prior obligations (conformity assessment, FRIA, technical documentation) have been completed.

Penalties and Why the Fundamental-Rights Stakes Are Different Here

For most high-risk AI systems, the sanctions calculus is straightforward: non-compliance risks €15 million or 3% under Article 99(4). That ceiling applies here too.

But law enforcement AI also sits adjacent to the Article 5 prohibitions. A system initially classified and deployed as high-risk Annex III — supported by documented objective facts — can drift into prohibited territory if the provider or deployer allows profiling-only scoring to creep in, or if the system is retrained on datasets that shift it toward purely demographic predictions. An Article 5 breach brings the €35 million or 7% ceiling under Article 99(3).

Beyond financial penalties, law enforcement AI produces decisions that directly affect liberty. A misclassified system, or a compliant system badly deployed, can result in unlawful detention or prosecution. No fine calculation captures that. The FRIA and human oversight requirements exist precisely because the Act's drafters understood that the harm from failure here is qualitatively different from a misconfigured HR-screening tool.

How Confir Helps

Confir's rule-based classification engine runs your system's intended purpose and functional description through the Annex III point 6 criteria and the Article 5(1)(d) boundary, and returns a documented classification finding — the same output every time, with the rule that fired shown in plain language. That reproducibility is what an audit needs.

For deployers who are public authorities, Confir's Article 27 FRIA workflow structures the assessment across the seven Charter rights most at stake in law enforcement contexts, generates a print-ready assessment document, and logs it immutably alongside the deployment record for the non-public database registration.

For providers, the Annex IV technical documentation pack covers the required fields — training data characteristics, performance metrics, risk assessment, monitoring procedures — so you are not assembling the documentation from scratch under time pressure.

Related guides

• Article 6 risk classification tool
• Article 6 high-risk categories
• determine your AI's risk level
• EU AI Act classification framework
• Article 8 compliance obligations
• high-risk AI system requirements