AI in the Administration of Justice: What Annex III Point 8 Actually Requires

A judge in Rotterdam uses an AI system to search case law. A civic tech startup in Tallinn builds a tool that helps voters compare party positions. A legal aid organization in Vienna deploys a chatbot that helps asylum seekers understand their procedural rights.

Which of these is high-risk under the EU AI Act? The answer matters because getting it wrong means either drowning in compliance obligations that don't apply, or shipping a system that triggers Article 6(2) without the required risk management, documentation, and human oversight in place.

Annex III Point 8 covers "Administration of justice and democratic processes." It's the smallest category by word count in the Annex, but it touches the most sensitive institutional functions in any democracy. Here's how to read it, what the draft Commission guidelines say, and what teams building or deploying these systems need to document.

The Actual Text and Its Two Branches

Annex III of Regulation (EU) 2024/1689 lists eight areas where AI systems are classified as high-risk under Article 6(2). Point 8 has two distinct branches:

8(a): Judicial authorities and ADR. AI systems intended to assist judicial authorities in researching and interpreting facts and the law, and in applying the law to a concrete set of facts. This also covers AI systems intended to be used for alternative dispute resolution (ADR).

8(b): Elections and voting behavior. AI systems intended to be used to influence the outcome of an election or referendum, or the voting behavior of natural persons in the exercise of their vote in elections or referendums.

The language is deceptively simple. The implementation questions are not.

Branch 8(a): What Counts as "Assisting Judicial Authorities"?

The key phrase is "assist judicial authorities in researching and interpreting facts and the law, and in applying the law to a concrete set of facts."

According to the Praxikon analysis of the draft Commission guidelines, the classification question is: Does the AI support legal interpretation, application of facts to law, or ADR?

This is broader than it first appears. A case law search tool that merely retrieves documents based on keywords probably doesn't qualify. But a system that ranks relevance, suggests applicable precedents, or summarizes holdings in context starts to look like "researching and interpreting."

The distinction matters operationally. Teams need to document:

• The intended purpose and context of use
• Whether the system performs retrieval only, or also interpretation, ranking, or recommendation
• Who the end user is (judicial authority, legal professional, or general public)
• Whether outputs directly inform judicial decisions or serve as background research

The CloseIT analysis of Article 6 notes that the classification turns on intended use, not just technical capability. A system that could theoretically assist judicial interpretation but is marketed and deployed only for law firm research might fall outside Point 8(a), though it could still trigger other Annex III categories depending on its application.

ADR systems present their own complexity. Mediation platforms that merely schedule sessions and share documents are unlikely to qualify. Systems that analyze dispute patterns, suggest settlement ranges, or recommend outcomes based on case characteristics almost certainly do.

Branch 8(b): The Democratic Influence Question

Point 8(b) covers AI systems "intended to be used to influence the outcome of an election or referendum, or the voting behavior of natural persons."

This is where the draft guidelines become essential reading. According to Praxikon's summary, the guidelines include exceptions for "limited support tools," though the precise boundaries remain subject to finalization.

A voter information tool that presents party positions neutrally, without ranking or recommendation, likely falls outside the scope. A system that personalizes political content, targets voters based on predicted preferences, or generates persuasive messaging almost certainly falls inside.

The challenge is that "influence" is a spectrum. Every piece of political information influences voters in some sense. The regulatory question is whether the AI system is intended to shape voting behavior, not merely inform it.

Teams building civic tech need to document:

• Whether the system presents information neutrally or with ranking, recommendation, or personalization
• Whether outputs are generated, curated, or merely retrieved
• Whether the system targets specific voter segments based on predicted characteristics
• The relationship between the deployer and any political campaign, party, or advocacy organization

The Article 6(3) Exception: When High-Risk Doesn't Apply

Article 6(3) provides an exception for AI systems that "do not pose a significant risk to the health, safety, or fundamental rights of natural persons." This exception applies to Annex III systems, but with important limitations.

The exception is blocked when the AI system performs profiling of natural persons. For Point 8 systems, this is a significant constraint. A judicial assistance tool that analyzes patterns in a defendant's history, or a voter information system that segments users by predicted political preferences, cannot claim the Article 6(3) exception regardless of how limited its actual risk might be.

Documentation requirements don't disappear even when the exception applies. Teams must still record why they believe the system doesn't pose significant risk, and that assessment must be defensible to market surveillance authorities.

Compliance Timeline: The 2027 Deadline

The compliance deadline for Annex III systems is 2 December 2027, extended from the original August 2026 date by the 2026 Digital Omnibus. This applies to both providers (developers and distributors) and deployers (organizations using the systems).

For providers, the obligations include:

• Risk management system (Article 9)
• Data and data governance (Article 10)
• Technical documentation (Article 11)
• Record-keeping and logging (Article 12)
• Transparency and instructions for deployers (Article 13)
• Human oversight mechanisms (Article 14)
• Accuracy, robustness, and cybersecurity (Article 15)

For deployers, Article 26 obligations include using the system in accordance with instructions, ensuring human oversight, monitoring for risks, and maintaining logs. Where Article 27 applies, deployers must also conduct a Fundamental Rights Impact Assessment (FRIA).

The FRIA requirement is particularly relevant for Point 8 systems. AI in judicial contexts directly affects due process rights. AI in electoral contexts affects political participation rights. Both trigger the fundamental rights analysis that Article 27 requires.

What to Document Now

Teams working on Point 8 systems should start documentation before the compliance deadline, not after. The minimum viable documentation set includes:

1. Intended purpose statement. What the system does, who uses it, and in what context.

2. Classification rationale. Why Article 6(2) and Annex III Point 8 do or do not apply, with specific reference to the intended use.

3. Article 6(3) analysis. Whether the exception might apply, and whether profiling blocks it.

4. Obligation mapping. Which provider and deployer obligations are triggered, and who is responsible for each.

5. Human oversight design. How human decision-makers interact with system outputs, and what authority they retain to override or disregard AI recommendations.

The ALLAI analysis notes that not just the intended purpose, but also "reasonably foreseeable use" should be considered. A system designed for legal research that is predictably used by judges to inform sentencing decisions may trigger Point 8(a) even if the provider didn't explicitly market it for that purpose.

The Implementation Reality

Point 8 systems operate in institutional contexts where the stakes are highest and the tolerance for failure is lowest. A recruitment AI that makes a bad recommendation costs someone a job interview. A judicial AI that makes a bad recommendation can cost someone their liberty.

The compliance framework reflects this asymmetry. But compliance frameworks don't implement themselves. The gap between "we have a risk management system" and "our risk management system actually catches the failure modes that matter" is where most projects die.

Before shipping any Point 8 system, answer three questions: What does "good enough" look like for this use case? Who gets paged when the system produces an output that a human reviewer flags as problematic? How does rollback work if a systematic error is discovered after deployment?

If all three can't be answered with specifics, the system isn't ready for production, regardless of what the compliance documentation says.

For teams navigating these requirements, the Human × AI Content Hub tracks ongoing developments in European AI policy and implementation practice.