High-Risk or Not? Classifying Your AI System Under the EU AI Act

Classification is the hinge the entire EU AI Act swings on. Decide a system is high-risk and you inherit a full obligation set: risk management, data governance, technical documentation, logging, human oversight, conformity assessment. Decide it is not, and you owe comparatively little. Get the decision wrong in the optimistic direction and you have built a non-conformant system that a market surveillance authority can pull from the market, with the cost landing on the business line that shipped it. This is the analysis teams most want to be simple. It is not, and the seniority of the people who should own it reflects that.

The requirement: how Article 6 defines high-risk

The EU AI Act creates a tiered structure: prohibited practices (Article 5), high-risk systems (Articles 6 through 27), limited-risk systems with transparency obligations (Article 50), and everything else. Article 6 sets the classification rules for high-risk, and it works through two distinct routes.

Route one, Annex I product safety (Article 6(1)). An AI system is high-risk if both conditions hold: it is intended to be used as a safety component of a product, or is itself a product, covered by the Union harmonisation legislation listed in Annex I (machinery, toys, lifts, medical devices, in-vitro diagnostics, radio equipment, and so on); and that product is required to undergo a third-party conformity assessment under that legislation. This route catches AI embedded in regulated physical products.

Route two, Annex III use cases (Article 6(2)). An AI system is high-risk if it falls within one of the use cases listed in Annex III. Annex III enumerates eight areas:

1. Biometrics: remote biometric identification, biometric categorisation by sensitive attributes, and emotion recognition within permitted bounds.
2. Critical infrastructure: safety components in the management and operation of digital infrastructure, road traffic, and utilities such as water, gas, heating, and electricity.
3. Education and vocational training: admissions, evaluating learning outcomes, assessing the appropriate level of education, and detecting prohibited behavior during tests.
4. Employment, workers management, and access to self-employment: recruitment, screening, filtering applications, evaluating candidates, and decisions on promotion, termination, task allocation, and monitoring or evaluating performance.
5. Access to essential services: eligibility for public assistance benefits, creditworthiness and credit scoring (with a carve-out for fraud detection), risk assessment and pricing in life and health insurance, and emergency dispatch prioritisation.
6. Law enforcement: within permitted bounds, things like assessing the risk of offending or re-offending, polygraph-type tools, and evaluating evidence reliability.
7. Migration, asylum, and border control: risk assessments, examination of applications, and detection tools.
8. Administration of justice and democratic processes: assisting judicial authorities in researching and interpreting facts and law, and influencing elections.

If your system's intended purpose lands in one of these, it is presumptively high-risk.

The exemption teams reach for too quickly: Article 6(3)

Here is where classification gets genuinely subtle. Article 6(3) provides that a system listed in Annex III is not high-risk if it does not pose a significant risk of harm to health, safety, or fundamental rights, including by not materially influencing the outcome of decision-making. The Act gives four conditions, at least one of which must apply:

• (a) the system performs a narrow procedural task;
• (b) it is intended to improve the result of a previously completed human activity;
• (c) it is intended to detect decision-making patterns or deviations from prior patterns and is not meant to replace or influence the previously completed human assessment without proper human review; or
• (d) it performs a preparatory task to an assessment relevant to the Annex III use cases.

There is a hard backstop. The exemption never applies if the AI system performs profiling of natural persons (Article 6(3), final subparagraph). Profiling pulls you back to high-risk regardless of how narrow the task looks.

There is also a paperwork consequence. A provider who concludes a system is exempt under Article 6(3) must document that assessment before placing it on the market and register the system in the EU database. You do not get to quietly decide you are exempt. You have to show your work, and authorities can review it.

Why teams get this wrong

The classification mistakes cluster into a few patterns, and most surface only when a regulator or internal audit pulls the thread.

Anchoring on the model instead of the use case. Annex III is organized by intended purpose and context of use, not by model architecture. The same underlying model can be high-risk in a hiring context and unremarkable elsewhere. Teams that ask "is this model high-risk?" are asking the wrong question. The right one is "what is this system intended to do, and where."

Treating Article 6(3) as a default escape hatch. Because the obligations are heavy, there is strong motivation to find a system "not significant." Teams stretch "preparatory task" or "narrow procedural task" to cover systems that materially shape a decision. If a recruiter almost always follows the system's ranking, the system is not merely preparatory. It is influencing the outcome, and the exemption is shaky.

Missing the profiling backstop. A system that scores or segments individuals based on personal data to predict something about them is profiling. Once profiling is in play, Article 6(3) is off the table entirely, no matter how procedural the framing. This trips up "we only assist the human" arguments constantly.

Forgetting the documentation duty. Even a correct exemption decision is non-compliant if undocumented. Teams that decide "not high-risk" in a meeting and move on have skipped the Article 6(3) documentation and the EU database registration the Act requires.

Ignoring deployer-side reclassification. A deployer who puts a non-high-risk system to a high-risk use, or substantially modifies a system, can change its classification and pull obligations onto themselves. Classification is not frozen at the provider's original intent, which matters in any enterprise that both buys and adapts third-party models.

What good evidence looks like

If an authority questions your classification, they want a reasoned, documented decision, not a conclusion. Strong classification evidence includes:

• A documented intended-purpose statement that matches what the system actually does in deployment and matches section 1 of your Annex IV dossier.
• An explicit Annex I and Annex III walkthrough showing which categories you considered and why each does or does not apply.
• For any Article 6(3) exemption claim: the specific condition relied on, (a) through (d), the evidence the system does not materially influence outcomes, and an explicit confirmation that the system does not perform profiling.
• The Article 6(3) documentation itself, completed before market placement, plus EU database registration.
• A reassessment trigger, a documented process to revisit classification when intended use, deployment context, or the system itself changes, including deployer modifications.

The standard an authority applies is whether your reasoning is defensible on its face. "We decided it was low-risk" is not. "Annex III point 4 applies, but the system only flags anomalies for mandatory human review, performs no profiling, and recruiters override it in X percent of cases per our logs, so Article 6(3)(c) applies" is the shape of a defensible record.

The runtime-record approach

Notice that the strongest exemption arguments depend on facts about how the system behaves in production: whether it materially influences outcomes, how often humans override it, whether it operates within its declared narrow task. Those are runtime facts, and they are far more persuasive backed by records than by assertion. Cytra is designed to capture that kind of operational evidence. AI and agent tool calls route through a managed gateway, currently in private beta, that applies deterministic policy and writes each event to a per-tenant, tamper-evident SHA-256 hash-chained ledger, with a standalone collector available to stream signed events from inside your environment. The aim is to let a classification or exemption decision rest on evidence of how the system actually ran, such as override rates, scope of action, and human-review steps, rather than on intent alone. Cytra keeps you aligned and audit-ready, not certified, and coverage means mapping evidence to control objectives, not guaranteeing a classification outcome. SOC 2 and a HIPAA BAA are in process.

The classification checklist

• Start from intended purpose and context of use, not model architecture.
• Run the Annex I product-safety test (Article 6(1)): regulated product plus third-party conformity assessment.
• Walk through all eight Annex III categories (Article 6(2)) and record which apply.
• If claiming the Article 6(3) exemption, name the specific condition, (a) through (d), and evidence the system does not materially influence outcomes.
• Confirm the system performs no profiling. If it does, the exemption does not apply, full stop.
• Document the exemption assessment before market placement and register in the EU database.
• Back "we only assist the human" claims with override and influence evidence, not assertion.
• Set a reassessment trigger for changes in use, context, or the system, including deployer modifications.