EU AI Act Annex III Explained for Procurement Teams

TL;DR. Annex III of Regulation (EU) 2024/1689 enumerates eight categories of high-risk AI use cases. Any vendor system that falls inside one of them inherits the full Article 6(2) high-risk regime, and your procurement team inherits Article 26 deployer obligations from 2 August 2026. This guide walks each category, names the vendor archetypes that typically land inside it, and identifies the procurement decision points that must be answered before contract signature.

1. Why Annex III is the procurement gatekeeper

Article 6(2) declares an AI system high-risk when it is referred to in Annex III. From that point onward, the deployer (you) carries Article 26 obligations and the provider (your vendor) must satisfy Articles 8 to 21 — risk management, data governance, technical documentation, record-keeping, transparency, human oversight, accuracy and cybersecurity.

The eight Annex III categories are not equally weighted in DACH procurement. Some categories — biometric ID, law enforcement, migration — rarely surface in private-sector vendor catalogues. Others — credit scoring, employment, education, essential services — sit inside the most commonly procured SaaS products in 2026: ATS systems, fraud screening, claims-handling automation, learner-assessment tools, eligibility engines.

A procurement team that does not classify vendor AI under Annex III before signature is signing blind. The contract will not retroactively allocate Article 26 burden, and the supervisory authority will not accept "the vendor said it was minimal-risk" as a defense.

For the upstream framework see the EU AI Act Third-Party Risk pillar.

2. The eight Annex III categories with vendor archetypes

The decision is rarely binary. A document-classification tool sold as generic SaaS becomes Annex III(4) once it is wired into a hiring pipeline. The vendor will not unilaterally re-classify. The deployer must.

3. Annex III(1) Biometrics — what to ask before you sign

Annex III(1) covers remote biometric identification, biometric categorisation, and emotion recognition, except where used purely for biometric verification (one-to-one).

Procurement decision points:

• Is the system one-to-one verification (out of scope for Annex III(1)) or one-to-many identification (in scope)?
• Is it operated in real-time in publicly accessible spaces? If yes, Article 5(1)(h) prohibition applies to law-enforcement deployers — and even private-sector use draws regulator attention.
• Does it infer protected attributes (race, political opinion, religion, sex life)? Article 5(1)(g) prohibits this categorically.
• Workplace deployment of emotion recognition is prohibited under Article 5(1)(f), with narrow medical/safety exceptions.

A vendor pitching "facial-attribute analytics for retail conversion" sits at the intersection of Annex III(1) and Article 5(1)(g). Procurement should require categorical written confirmation that protected attributes are not inferred — and verify with adversarial probes. The PartnerScope Pro tier red-teams biometric and inference systems on this dimension by default.

4. Annex III(2) Critical infrastructure — when SCADA meets AI

Annex III(2) lists AI systems used as safety components in the management and operation of critical digital infrastructure, road traffic, and water/gas/heating/electricity supply.

Procurement decision points:

• Safety component status. Article 3(14) defines safety components as those whose failure endangers health, safety or property. A predictive-maintenance dashboard that alerts a human is borderline; an autonomous shutoff actuator is not.
• Cross-listing with Annex I. Some critical-infrastructure AI also falls under Union sectoral law (machinery, pressure equipment) — the conformity-assessment route changes accordingly (Annex VII vs Annex VI).
• KRITIS overlap (DACH-specific). German critical-infrastructure operators governed by BSI-KritisV face parallel security requirements. AI Act high-risk obligations stack on top, they do not replace.
• DORA boundary for energy/utility group treasury operations. See the DORA + EU AI Act cluster.

For DACH energy and water utilities, Annex III(2) classification is now a mandatory procurement gate. Signing a SCADA-integrated ML vendor without an Annex IV technical file is a foreseeable enforcement risk under BSI and the future AI Office.

5. Annex III(3) Education — automated assessment and proctoring

Annex III(3) covers AI used for admission, evaluation of learning outcomes, allocation to institutions/programmes, and monitoring/detection of prohibited behaviour during tests.

Procurement decision points:

• Is the system used for institutional admission decisions (high-risk) or only for self-paced practice (likely minimal)?
• Does it score essays, code submissions or oral assessments contributing to a final grade? If yes, Article 14 human oversight requirements bite — a teacher must be able to override.
• Proctoring tools (browser lockdown, gaze-tracking, audio analysis) sit at the intersection of Annex III(3) and Annex III(1) where biometrics are involved. Most commercial proctoring is high-risk under both.
• Vocational training inside the workplace can shift the analysis to Annex III(4) employment.

Universities and Berufsschulen procuring assessment tools should require: bias audit on protected groups (DSGVO Art. 9 categories), documented teacher-override workflow, and Article 13 instructions for use that include accuracy limits per language and per disability accommodation.

6. Annex III(4) Employment — the highest-volume Annex III category in private sector

Annex III(4) covers AI used for: recruitment/selection, advertising vacancies, screening/filtering applications, evaluating candidates; and decisions affecting terms of work, promotion, termination, allocation of tasks, monitoring/evaluating performance.

This is the most-procured Annex III category in DACH private sector. Almost every modern ATS, performance-management suite, internal-mobility tool and gig-allocation platform sits here.

Procurement decision points:

Article 26(7) imposes a deployer-side obligation to inform workers' representatives and affected workers before putting an Annex III(4) system into service. Article 27 fundamental rights impact assessment applies. German co-determination law (BetrVG §87(1)(6)) layers a Mitbestimmung obligation on top — the works council must consent, not merely be informed.

A procurement contract that proceeds without the works council motion is a procedural defect that the FRIA cannot cure.

7. Annex III(5) Essential services — credit, insurance, benefits

Annex III(5) lists:

• (a) AI for evaluating eligibility for essential public assistance benefits and services (welfare, healthcare, child support);
• (b) AI for evaluating creditworthiness or establishing credit score (excluding fraud detection — see recital 58 distinction);
• (c) AI for risk assessment and pricing in life and health insurance;
• (d) AI for emergency-call triage / dispatch / medical-priority establishment.

This is the second-largest Annex III bucket in DACH private sector, and the one with the deepest sector-specific overlap.

Procurement decision points:

• Credit scoring (5)(b) overlaps with EBA/BaFin guidance on internal-rating-based models. A vendor model used for IRB approaches inherits banking-supervision obligations regardless of Annex III status.
• Insurance pricing (5)(c) overlaps with EIOPA guidance and national IDD/Versicherungsaufsichtsgesetz rules. Pricing optimisation that varies premium by inferred health, race or socio-economic proxy is doubly exposed.
• Emergency dispatch (5)(d) is rare in private procurement but appears in 112-platform integrations and large hospital networks.
• Public-benefits eligibility (5)(a) typically procured by public-sector buyers; FRIA (Art. 27) is mandatory.

Banks procuring credit-decisioning AI also need to map the vendor against MaRisk AT 9 (Auslagerung) — see the comparison with Vanta's TPRM coverage for what generic platforms miss here.

8. Annex III(6), (7), (8) — public-sector concentration

Categories 6 (law enforcement), 7 (migration/asylum/border), and 8 (justice/democratic processes) are predominantly public-sector procurement. They share: multiple Article 5 prohibitions sit nearby (predictive policing 5(1)(d), social scoring 5(1)(c), real-time remote biometric ID 5(1)(h)); Article 27 FRIA is mandatory in public-body deployment; and election-influence systems (Annex III(8)(b)) intersect with the DSA and the Code of Practice on Disinformation. Annex III(8) legal-research AI applies when intended for use by judicial authorities to research/interpret facts and apply law to a concrete set of facts — a private law firm using a generic case-law search tool is not in scope.

9. The procurement decision tree

A defensible Annex III screening at procurement runs five steps:

1. Vendor self-declaration. Ask the vendor to identify Annex III categories they consider applicable. Treat this as a starting hypothesis only.
2. Independent classification. Map the system's intended purpose (Article 3(12)) and reasonably foreseeable misuse (Article 9(2)(b)) against the eight categories. Cite the exact Annex III sub-paragraph.
3. GPAI scoping. Identify whether the system is built on a GPAI model and whether that GPAI is systemic-risk (Article 51(2) — currently > 10²⁵ FLOPs). See the GPAI deployer cluster.
4. Documentation gate. For Annex III matches, require Annex IV technical file summary, Article 13 instructions for use, and the EU declaration of conformity (Art. 47).
5. Sectoral overlay. Map onto BaFin (financial), BfDI (data protection), BSI (security), EBA/EIOPA (banking/insurance) parallel obligations.

Any of these five steps that produces a "missing" or "contradictory" finding becomes a procurement risk register entry, not a soft TODO.

10. Frequently asked questions

Is a vendor's "we are not high-risk" attestation sufficient for procurement sign-off? No. The Article 6(2) classification is a deployer-side legal conclusion, not a vendor-side commercial statement. The deployer's risk function and counsel sign off on classification, with vendor evidence as input.

What if the vendor system covers multiple Annex III categories? The most stringent obligation set applies. A workforce-analytics tool that doubles as biometric proctoring sits under both (1) and (4) and inherits both worker-representative obligations and biometric-categorisation analysis.

Does Annex III status mean the system is illegal? No. High-risk under Article 6(2) means the system is permitted subject to compliance. Article 5 prohibitions are the categorical bans. Procurement should always verify the Article 5 line first.

When does the FRIA under Article 27 apply? For Annex III(5)(a) public-benefits eligibility and Annex III(6) law-enforcement deployments by public bodies, plus deployments by private parties providing public services. The FRIA is the deployer's responsibility, not the vendor's, but vendor input is required.

Can a Starter-tier PartnerScope assessment classify Annex III? Yes. Every PartnerScope assessment (Starter €99, Pro €299, Enterprise €4,900/quarter) produces an Annex III classification with cited reasoning — this is the minimum output, not an Enterprise-only feature.

CTA

Run a free 60-second EU AI Act Snapshot at partnerscope.eu to classify your vendor's AI under Annex III before contract signature. Or read the complete pillar guide.