High-Risk AI under Annex III: Classification Workbook

1. The eight high-risk areas under Annex III

Short answer: Annex III of the EU AI Act lists eight high-risk areas: (1) biometric identification and categorisation, (2) critical infrastructure, (3) education and vocational training, (4) employment and workforce management, (5) essential private and public services (e.g. credit scoring), (6) law enforcement, (7) migration/asylum/border control and (8) administration of justice and democratic processes.

The legal consequence is set out in Art. 6(2) AI Act: the AI systems listed in Annex III are deemed to be high-risk. The classification is therefore not a matter of discretion but a question of allocation — and it has a preliminary question: is this an AI system at all? Art. 3 no. 1 AI Act defines it as a machine-based system that is designed to operate with varying levels of autonomy, that may exhibit adaptiveness after deployment and that infers, from the input it receives, how to generate outputs such as predictions, content, recommendations or decisions.

Annex III is only one of two routes into the high-risk class. The second is set out in Art. 6(1) AI Act: a system is also high-risk where it is intended to be used as a safety component of a product covered by the Union harmonisation legislation listed in Annex I, or is itself such a product, and is subject to a third-party conformity assessment. For this route, the high-risk obligations of Chapter III Sections 1 to 3 only apply from 2 August 2028, for Annex III systems from 2 December 2027 (Art. 113 AI Act as amended by Regulation (EU) 2026/1744; Section 9).

At a higher level, the AI Act follows a risk-based approach (recital 26): prohibited practices under Art. 5, high-risk AI systems under Art. 6 et seq. and AI systems subject to specific transparency obligations under Art. 50. Practical recommendation (not a legal obligation): for each use case, first check Art. 5, then Annex III. In the biometrics area in particular this order matters, because Art. 5(1) AI Act prohibits, among other things, biometric categorisation to infer sensitive attributes ((g)) and emotion recognition in the workplace and in education institutions ((f)).

The Regulation itself describes the areas more narrowly than any summary. No. 1 covers remote identification, biometric categorisation according to sensitive attributes and emotion recognition. No. 2 covers safety components in the management and operation of critical digital infrastructure as well as in road traffic and in the supply of water, gas, heating and electricity. No. 5 covers access to and enjoyment of essential private and public services and benefits, including creditworthiness, health and life insurance and emergency calls.

The examples in the third column are practical allocations, not the wording of the Regulation — what governs is always the text of Annex III itself.

2. Decision tree for classification

Short answer: Classification as high-risk AI takes place in six steps: describe the use case, check the Annex III area, where there is a match assess the Art. 6(3) exception narrowly and confirm high-risk status if the exception does not apply, clarify the role as provider (Art. 3 no. 3) or deployer (Art. 3 no. 4) and document the respective obligations.

The substance of the assessment follows from the AI Act; the order of the six steps is a practical recommendation and does not create a legal obligation of its own.

1. Describe the use case: what exactly does the AI system do? What data goes in, what comes out? Why: the classification attaches to the output and its effect, not to the provider's product label. The basis is the system definition in Art. 3 no. 1 AI Act.
2. Check Annex III: does the use case fall under one of the 8 areas? Why: Art. 6(2) AI Act declares the systems listed there to be high-risk AI. Record the number assessed and the supporting reasoning in writing (practical recommendation, not a legal obligation) — it is the core of your classification file.
3. If yes → assess the Art. 6(3) exception: a 'specific, narrowly defined preparatory task'? Why: the exception applies only where the system does not pose a significant risk to health, safety or fundamental rights; profiling rules the exception out (Art. 6(3) AI Act, Section 3).
4. If no → high-risk confirmed. Why: this triggers the package of requirements in Art. 9 to 15 as well as Art. 17, 43, 49, 72 and 73 AI Act — subject to the limitations by role and Annex III number (Section 8).
5. Clarify the role: are you a provider (Art. 3 no. 3) or a deployer (Art. 3 no. 4)? Why: the role determines the burden of obligations — and it can change: also assess a change of role under Art. 25 AI Act (Section 6).
6. Document the obligations: provider (full Annex IV documentation, conformity assessment) vs. deployer (relevance of input data, logs, FRIA where applicable). Why: the deployer obligations are set out in Art. 26(4), (6) and (7) AI Act, the FRIA obligation only for the group named in Art. 27(1) AI Act (Section 6).

3. Art. 6(3) exceptions

Short answer: By way of derogation, a system listed in Annex III exceptionally does not count as high-risk where it does not pose a significant risk to health, safety or fundamental rights — the exception is, however, excluded as soon as the system performs profiling of natural persons (Art. 6(3) AI Act).

Art. 6(3) can only be applied narrowly. High-risk classification falls away where the system exclusively:

• performs a narrowly defined preparatory task (e.g. sorting)
• or performs a limited task within the use case
• or performs a specific activity that only supports human action (rather than replacing it)

Where the system generates recommendations or assessments capable of materially influencing human decisions, it remains high-risk — Art. 6(3) AI Act then does not support the exception.

In practice, the profiling exclusion is the decisive filter: if the system performs profiling of natural persons — for example assessing suitability, payment behaviour or performance forecasts — reliance on Art. 6(3) is barred, no matter how small the sub-step may appear. Where a provider relies on the exception, it is moreover subject to registration (Art. 49(2) AI Act, Section 6) — the provider therefore documents it and makes it visible.

Practical recommendation (not a legal obligation): record the outcome of the Art. 6(3) assessment, including the profiling question, in the one-page record for each system (Section 11). If in doubt, classify as high-risk; the cost of classifying too high is effort, that of classifying too low is a fine risk under Art. 99(4) AI Act.

4. Special case HR/recruiting (Annex III no. 4)

Short answer: In the HR area, evaluative AI systems (CV match scoring, performance scoring, workforce planning with promotion or dismissal recommendations) are high-risk AI under Annex III no. 4. Purely informational systems such as HR FAQ chatbots, newsletter personalisation or specific appointment-booking bots do not fall under it (Art. 6(3) exception where applicable). In addition, the § 22 AGG reversal of the burden of proof already applies now where there are indications of discrimination (German law; Austria: section 'Legal position in Austria').

In the HR area, a prohibition check comes before the high-risk assessment: Art. 5(1)(f) AI Act prohibits emotion recognition in the workplace and in education institutions. This prohibition has applied since 2 February 2025 (Art. 113 AI Act) and, at up to EUR 35 million or 7 % of worldwide annual turnover, sits in the highest fine tier (Art. 99(3) AI Act). Assess the prohibition under Art. 5(1)(f) AI Act, therefore, before you carry out the classification under Annex III.

Anyone deploying a bought-in HR system is regularly a deployer and bears the deployer obligations under Art. 26(4), (6) and (7) AI Act (Section 6). A fundamental rights impact assessment under Art. 27 AI Act is not part of this for a purely private-sector employer that does not provide public services (addressees: Section 5). Under data protection law, by contrast, a data protection impact assessment under Art. 35 GDPR may be required: it must be carried out in advance in particular where there is a systematic and extensive evaluation of personal aspects (profiling) producing legal effects. Discrimination liability alongside the AI Act is structured differently in Germany and Austria — Germany in Section 12, Austria in the section 'Legal position in Austria'.

5. Special case credit and insurance scoring

Short answer: Annex III no. 5(b) covers creditworthiness assessment, (c) life and health insurance scoring; for precisely these two case groups the fundamental rights impact assessment under Art. 27 AI Act also applies to private deployers.

The obligations for both case groups — the full Annex III requirements as well as the FRIA under Art. 27 AI Act — apply from 2 December 2027; Art. 27 belongs to Chapter III Section 3, whose application to Annex III systems was postponed to that date by Regulation (EU) 2026/1744 (in force since 27 July 2026). On the state of the deadlines, see Section 9.

Number 5 sits in the overarching area 'access to and enjoyment of essential private and public services and benefits', which covers, among other things, creditworthiness, health and life insurance and emergency calls. The FRIA is a deployer obligation, not a provider obligation: under Art. 27(1) AI Act the addressees are public bodies, private providers of public services and the deployers of systems under Annex III no. 5(b) and (c). In substance, Art. 27 AI Act requires, among other things: a description of the use of the AI, identification of the persons affected, assessment of the risks to fundamental rights and the definition of safeguards.

Two points are frequently overlooked in implementation. First, registration: the provider obligation under Art. 49(1) AI Act also covers no. 5, since only the systems under Annex III no. 2 are excluded. Second, the data category: health data and genetic data are subject under Art. 9(1) GDPR to a general prohibition on processing with narrow exceptions — the AI Act classification does not replace that assessment.

Practical recommendation (not a legal obligation): set out the elements of Art. 27 AI Act named above as a separate document for each scoring model and link it to the one-page record from Section 11.

6. Provider vs. deployer obligations

Short answer: Providers (Art. 3 no. 3) bear the main burden: risk management (Art. 9), technical documentation under Annex IV (Art. 11), conformity assessment (Art. 43) and entry in the EU database (Art. 49). Deployers (Art. 3 no. 4) bear the obligations of Art. 26(4), (6) and (7) AI Act and, where they belong to the group covered by Art. 27(1) AI Act, the FRIA (Section 5).

Clarification on Art. 49: for systems under Annex III no. 1, 6 and 7, registration under Art. 49(4) AI Act takes place only in a secure, non-public section of the EU database; the details on paras. 1 to 3 are set out in the table.

Experience shows that the large majority of SMEs are purely deployers; they mostly become providers only through the change of role under Art. 25 AI Act (based on experience, not statistics). The change of role under Art. 25 AI Act therefore needs to be assessed with particular care in the inventory — it occurs on a substantial modification of the intended purpose or the functionality as well as on placing the system on the market under one's own name.

7. Implementation checklist after classification

Short answer: Once the classification under Section 2 is settled, six implementation steps follow: document the AI system in the inventory, draw up an obligations matrix (Section 8), carry out a FRIA where the group covered by Art. 27(1) AI Act is concerned, prepare the technical documentation under Annex IV (provider), configure log retention of at least six months and inform the workers concerned (deployer).

1. Document the AI system (inventory) — create a one-page record for each system (list of fields in Section 11); the classification steps themselves are set out in Section 2.
2. Draw up an obligations matrix — allocate the requirements of Art. 9 to 15 as well as Art. 17, 43, 49, 72 and 73 AI Act to each system (Section 8).
3. Carry out a FRIA (where required) — only for the group covered by Art. 27(1) AI Act (Section 5); separately from this, assess the DPIA triggers under Art. 35 GDPR.
4. Prepare Annex IV technical documentation (where provider) — Art. 11 AI Act, the basis for conformity assessment and registration.
5. Configure log retention (where deployer) — at least six months (Art. 26(6) AI Act); setting this up technically before go-live is a practical recommendation.
6. Information of workers (where deployer) — Art. 26(7) AI Act (Section 6).

8. After classification: the requirements for high-risk AI

Short answer: Once the high-risk classification is settled, a coherent package of requirements from Art. 9 to Art. 15 AI Act applies, supplemented by a QMS, conformity assessment, registration, post-market monitoring and incident response.

The following overview lists the requirements with their reference. Every row is a requirement of the AI Act for high-risk AI systems, not a practical recommendation; limitations by role and Annex III number (such as Art. 49 except no. 2, Art. 17 providers only) are set out in Section 6, the application dates in Section 9.

Alongside this, the transparency obligations of Art. 50 AI Act remain in place where the system additionally falls within their scope: informing people that they are interacting with an AI system (para. 1, providers), machine-readable marking of synthetic audio, image, video or text content (para. 2, providers), informing the persons concerned in the case of emotion recognition or biometric categorisation (para. 3, deployers) and disclosure in the case of deep fakes (para. 4, deployers). High-risk classification and transparency obligations do not exclude one another.

9. Timeline: what applies from when

Short answer: The application schedule follows Art. 113 AI Act as amended by Regulation (EU) 2026/1744: the general start of application on 2 August 2026 has passed; the high-risk obligations of Chapter III Sections 1 to 3 apply to Annex III systems from 2 December 2027 and to Art. 6(1) (Annex I products) from 2 August 2028.

How to read the table: all dates are application dates of the AI Act under Art. 113; the dates 2 December 2027 and 2 August 2028 are based on Regulation (EU) 2026/1744 and are applicable law. The 'Status' column refers to 16 August 2026.

On the Digital Omnibus: Regulation (EU) 2026/1744 (Digital Omnibus AI) has been in force since 27 July 2026. It postpones the application of Chapter III Sections 1 to 3 for Annex III systems to 2 December 2027 and for Annex I systems to 2 August 2028 (Art. 113(3)(c) AI Act as amended). The general start of application of the AI Act — 2 August 2026 — remains unchanged; Art. 4 in the version applicable since 27 July 2026, Art. 5, the GPAI obligations and Art. 50 are not covered by the postponement. Art. 27 (FRIA), by contrast, belongs to Chapter III Section 3 and therefore likewise applies to Annex III systems only from 2 December 2027; the cut-off dates are fixed calendar dates, there is no trigger mechanism via Commission findings.

10. Penalties

Short answer: Art. 99 AI Act tiers the fines in three levels according to the type of infringement; the higher of the two amounts is decisive in each case, and for SMEs and start-ups the lower value applies under Art. 99(6) AI Act.

Enforcement is a matter for national authorities: under Art. 70(1) AI Act each Member State designates at least one notifying authority and at least one market surveillance authority; the contact details of the single point of contact must be made publicly available under Art. 70(2) AI Act. In Germany, the Federal Network Agency (Bundesnetzagentur) has been the competent market surveillance authority since 29 July 2026 (§ 2(1) KI-MIG), unless sectoral authorities — such as BaFin — are competent; the single point of contact under Art. 70(2) AI Act is likewise the Federal Network Agency (§ 6(1) KI-MIG). As at the date of this article (17 August 2026), Austria has not designated a market surveillance authority under Art. 70 AI Act; the RTR AI Service Desk is an information and advisory body without supervisory powers. The AI Act itself applies directly and in identical wording in Germany and Austria; what is regulated nationally are the competent authorities and the penalty regime within the framework of Art. 99(1) AI Act.

11. Documenting the classification and practical review cycles

Short answer: Document a one-page record with six fields for each AI system; the AI Act prescribes the classification and the list of obligations derived from it — the following structure is a practical recommendation without a legal obligation of its own.

Anyone who keeps this page for each system can give a comprehensible justification of the classification when the market surveillance authority asks, instead of reconstructing it after the fact.

Practical review cycles (recommendation, not statutory intervals): update the classification as circumstances require — for new tools, on a substantial modification of the intended purpose or functionality of an existing system, on contract renewals and on amendments to Annex III. In addition, a routine review of the entire portfolio on a quarterly cycle has proven useful (based on experience, not a statutory interval). What is prescribed by law, by contrast, are the application dates from Section 9 and the minimum log retention of six months under Art. 26(6) AI Act; the time limits under anti-discrimination law are set out in Section 12 and in the section 'Legal position in Austria'.

12. Anti-discrimination law in Germany alongside the AI Act

Short answer: The German General Equal Treatment Act (AGG) applies irrespective of the AI Act deadlines and applies as soon as an AI-supported selection or assessment procedure leads to a disadvantage on one of the grounds named in § 1 AGG.

Under § 7(1) and (2) AGG, employees must not be disadvantaged on a ground named in § 1 AGG; this also applies where the disadvantaging person merely assumes such a ground to exist, and agreements to the contrary are void. § 3(1) to (4) AGG distinguishes direct disadvantage (less favourable treatment) from indirect disadvantage (apparently neutral provisions that may put persons at a particular disadvantage) and treats harassment and sexual harassment as separate forms of disadvantage. For algorithmic selection, indirect disadvantage is the key concept.

Procedurally, § 22 AGG is decisive: where, in a dispute, one party proves indications suggesting a disadvantage on a ground named in § 1 AGG, the other party bears the burden of proving that there was no breach of the provisions protecting against disadvantage. The following overview concerns German law exclusively; the Austrian equivalents are set out in the section 'Legal position in Austria'.