Annex III: the high-risk categories, listed plainly

Annex III lists the areas where an AI system may be classified high-risk under Article 6(2). Here is what each of the eight covers, described rather than interpreted.

Annex III is the list Article 6(2) points at. Its opening line is precise: high-risk AI systems pursuant to Article 6(2) are the AI systems listed in any of the following areas. Eight areas follow, most of them broken into lettered sub-points.

This post describes what the annex says. Whether a particular system falls inside one of these areas is a judgement about that system, and this is not that judgement.

The eight areas

Reading an entry properly

Annex III entries are narrower than their headings suggest, and the detail is where the answer usually sits. Area 4, employment and workers' management, is the one most organisations touch, so it is worth reading in full rather than by title.

It covers AI systems intended to be used for the recruitment or selection of natural persons, in particular to place targeted job advertisements, to analyse and filter job applications, and to evaluate candidates. Separately, it covers systems intended to be used to make decisions affecting terms of work-related relationships, the promotion or termination of work-related contractual relationships, to allocate tasks based on individual behaviour or personal traits or characteristics, or to monitor and evaluate the performance and behaviour of persons in such relationships.

Three phrases in that do the work. Intended to be used sets the test by purpose rather than by outcome. Place targeted job advertisements reaches earlier in the process than most people expect, before anyone has applied. And monitor and evaluate the performance and behaviour extends past hiring into how people are managed once employed.

Area 5 is similarly specific. It covers evaluating eligibility for essential public assistance benefits and services, creditworthiness and credit scoring, risk assessment and pricing for life and health insurance, and triage or dispatch of emergency services. It carries an express exception: systems used for the purpose of detecting financial fraud are excluded from the creditworthiness entry.

Three things the list makes clear on its own

Several areas carry a permitted-use qualifier

Biometrics, law enforcement, and migration all open with wording limiting the area to uses permitted under relevant Union or national law. The annex is not authorising those uses. It is saying that where they are lawful, systems doing them sit in the high-risk list.

Area 1 carves out verification

The biometrics entry excludes systems used for biometric verification whose sole purpose is confirming that a person is who they claim to be. Opening a phone with your own face, or confirming identity at a gate, is a different thing from identifying an unknown person in a crowd, and the annex separates them.

Area 4 is the one most organisations touch

Recruitment and selection is named explicitly, including placing targeted job advertisements, analysing and filtering job applications, and evaluating candidates. So is monitoring and evaluating performance and behaviour in work relationships. Most organisations do not run biometric identification or border control systems. A great many buy recruitment or workforce tools.

Being listed in Annex III is not the end of the classification question. Article 6(3) provides a route by which a system in one of these areas may not be high-risk where it does not pose a significant risk, subject to conditions and a documentation duty. Read Article 6 alongside the annex rather than the annex alone.

Annex III is not the only route to high-risk

Article 6 provides two paths. Annex III is the second of them. The first, in Article 6(1), covers AI systems intended to be used as a safety component of a product, or which are themselves a product, covered by the Union harmonisation legislation listed in Annex I, where that product is required to undergo third-party conformity assessment.

That first route matters for manufacturers of regulated products such as medical devices, machinery and vehicles, and it operates independently of the areas listed here. An organisation that reads Annex III, finds nothing that fits, and concludes it holds no high-risk systems has checked one of two routes.

What being in Annex III triggers

Classification is not the end of anything; it is what determines which obligations attach. Where a system is high-risk, the requirements in Chapter III Section 2 apply to it, and who carries them depends on your role.

A provider carries the substantial set: the risk management system under Article 9, data governance, the technical documentation in Annex IV, record-keeping, transparency and instructions for use, human oversight design under Article 14, accuracy and robustness, conformity assessment, and post-market monitoring under Article 72.

A deployer carries Article 26 instead, which is a shorter list:

• Use the system in accordance with the instructions for use that accompany it.
• Assign human oversight to natural persons who have the necessary competence, training and authority, as well as the necessary support.
• Where you control the input data, make sure it is relevant and sufficiently representative in view of the intended purpose.
• Monitor operation, inform the provider where relevant, and suspend use where the system presents a risk within the meaning of Article 79(1).
• Keep the logs the system generates automatically, to the extent they are under your control, for a period appropriate to the purpose and at least six months.

Article 26 also carries two sector provisions. Financial institutions already subject to internal governance requirements under Union financial services law are treated as meeting the monitoring duty by complying with those rules. And the monitoring obligation does not extend to sensitive operational data of deployers that are law enforcement authorities.

Why the intended purpose does the work

Annex III repeats the phrase intended to be used throughout, and that framing has a practical consequence worth understanding.

Classification follows what a system is meant for, as set by the provider and described in its instructions for use, rather than what any particular customer happens to do with it. A general-purpose writing tool does not become a high-risk recruitment system because somebody used it to screen applications, and a system intended for recruitment does not stop being one because a particular deployer uses it lightly.

The corollary is where deployers need care. Article 25 sets out circumstances in which a party other than the original provider is considered a provider of a high-risk system, including where they put their own name or trademark on it, make a substantial modification, or modify the intended purpose of a system in a way that makes it high-risk. Using a tool well outside what the provider intended is the route by which a deployer acquires the provider's obligations, and that is a heavier set.

Most organisations are deployers rather than providers. The distinction is worth settling early, because the two lists are very different in size, and Article 25 sets out circumstances in which a deployer can become a provider.

What to do with this list

The useful exercise is not reading Annex III and asking whether it feels relevant. It is listing the AI systems your organisation actually uses, then reading each entry against that list.

1. 1Write down the AI systems in use, including ones bought by a department rather than by IT, and ones embedded in a product you already had.
2. 2For each, record what it is used for, in the language of the activity rather than the vendor's.
3. 3Read the Annex III entries against those descriptions, noting that the test is the intended purpose.
4. 4Check the Article 6(1) route separately if you make or place products on the market.
5. 5For anything that may fall inside, record who the provider is and what documentation you hold from them.
6. 6Take advice on the ones that look close to the line. Article 6(3) provides a derogation with conditions attached, and that is a legal judgement rather than a reading exercise.

Step one is where this usually stalls, and it is the step that has nothing to do with the regulation. An organisation that cannot list its AI systems cannot answer any question the AI Act asks, whatever the answer would have been.

How EmberHound fits

Working out whether Annex III is relevant to you starts with knowing which AI systems your organisation actually uses, including the ones bought by a department rather than by IT. That inventory is the prerequisite for every other question in the regulation.

The AI Act Workspace records the systems an organisation uses, what each is used for, and which need a closer look. It produces indicators and a likely classification for a human to confirm, never a determination. It is in early access.

This article is general information, not legal advice. It describes Annex III as consolidated at 27 July 2026. Classification of a specific system requires advice from someone qualified to give it.