EU AI Act Annex III Deep Dive 2026: HR AI, Healthcare AI & Recruiting Systems — High-Risk Classification Guide

Post #2 in the sota.io EU AI Act High-Risk Classification 2026 Series

The EU AI Act's Annex III is where abstract regulation becomes concrete product decisions. Two of its eight categories generate the most developer questions in 2026: Category 4 (Employment and Workers Management) and Category 5 (Access to Essential Services). If you build AI for hiring, HR workflows, healthcare diagnostics, creditworthiness assessment, or benefits eligibility, you are almost certainly in Annex III scope — and the August 2026 enforcement timeline is not moving.

This post dissects exactly which AI features trigger high-risk classification in these categories, explains the notification requirements from the Draft High-Risk Classification Guidelines (consultation closes June 23, 2026), and gives you the compliance obligation checklist that activates the moment you cross the threshold.

Why HR AI and Healthcare AI Get Special Treatment

The EU AI Act's high-risk framework is grounded in fundamental rights impact. Recital 51 identifies the reasoning: AI systems making or materially influencing decisions about employment, access to healthcare, creditworthiness, or social benefits have direct, potentially irreversible consequences on people's livelihoods, health, and access to essential services.

The proportionality argument in the draft classification guidelines (Section 3.1) is explicit: these categories deserve heightened oversight because the affected individuals rarely have meaningful opt-out options. You cannot typically decline an employer's AI-assisted screening tool or a hospital's diagnostic AI — participation is effectively mandatory.

This asymmetry of power between AI deployer and affected individual is the structural reason HR AI and healthcare AI face higher requirements than, say, AI-assisted document drafting or product recommendation engines.

Annex III Category 4: Employment, Workers Management, Access to Self-Employment

What Falls In

Category 4 covers AI systems "intended to be used for recruitment or selection of natural persons, notably for advertising vacancies, screening or filtering applications, evaluating candidates in the course of interviews or tests."

It also covers AI intended for "making decisions on promotion and termination of work-related contractual relationships, for allocating tasks, and for monitoring and evaluating performance and behaviour of persons in such relationships."

The draft classification guidelines clarify four specific trigger scenarios:

4.1 Automated CV Screening and Ranking
Any AI that ranks, scores, or filters job applications without human review of individual decisions is high-risk under Category 4. The threshold is not about full automation — even AI that "recommends" reject/advance for batches of candidates qualifies if a human typically acts on the recommendation without independent review of each case.

4.2 Video Interview Analysis
AI systems analysing facial expressions, tone of voice, word choice, or behavioural patterns in interviews to generate candidate scores or recommendations. This includes asynchronous video interview platforms where AI processes recordings before human review.

4.3 Performance Monitoring and Scoring
AI that continuously monitors worker output, assigns productivity scores, or generates performance assessments used in employment decisions (pay review, promotion, termination) falls squarely in Category 4. Remote worker monitoring tools with AI-generated scores are a common undetected example.

4.4 Task Allocation Algorithms
Gig economy platforms using AI to allocate work assignments based on worker performance history or behavioural profiles. The CJEU's Uber/Deliveroo jurisprudence has reinforced EU regulatory attention here — the AI Act now formalises the compliance obligations.

What Falls Out

The draft guidelines introduce a "marginal functionality" exemption worth understanding. An AI feature that merely schedules interviews (without ranking or scoring candidates), suggests interview questions without analysing candidate responses, or generates job descriptions is not Category 4 high-risk. The trigger is decision-making or material influence on employment outcomes, not any use of AI in HR workflows.

Standard applicant tracking systems (ATS) that sort applications by keyword match without generating scores or rankings are borderline — the draft guidelines suggest these are not high-risk unless the keyword ranking directly determines which applications receive human review.

The Recruiting Platforms Problem

If you run a SaaS platform that provides recruiting features to employers (a multiparty model), the classification question is more complex. Under Article 6(3), you are the provider of the high-risk AI system. Your customers deploying the system are deployers. Both carry obligations, but the provider obligations — technical documentation, conformity assessment, CE marking, registration — fall on you.

If your platform embeds third-party AI (OpenAI, Anthropic, custom models via API) into recruiting features, you remain the provider of the high-risk AI system. The upstream AI model provider is not your compliance backstop.

Annex III Category 5: Access to Essential Private and Public Services

Category 5 is broader than its name suggests. It covers AI used to:

• Evaluate creditworthiness or establish credit scores (except for fraud detection)
• Make decisions on health insurance premiums, underwriting, or claims
• Assess eligibility for social benefits or social services
• Evaluate risk in life and health insurance
• Dispatch emergency services

For SaaS developers, the practical zones of concern are fintech AI and healthtech AI. Let me address each.

Healthcare AI: The Category 5/6 Overlap

Healthcare AI creates classification complexity because it appears in two Annex III categories:

Category 5(c): AI used in the evaluation of health and life insurance where the AI system determines premiums, coverage eligibility, or claim processing decisions.

Category 6: AI systems used as safety components in products covered by EU medical device regulations (MDR 2017/745 and IVDR 2017/746), or AI systems that are themselves medical devices under those regulations.

The distinction matters for compliance pathway. Category 6 systems follow a dual-compliance track: EU AI Act obligations layer on top of existing MDR/IVDR requirements. The national competent authorities for AI Act enforcement and the notified bodies for medical device regulation are different actors — coordination between these tracks is the developer's responsibility.

Category 5 Healthcare Triggers

The specific AI use cases that trigger Category 5 for healthcare:

Health insurance premium calculation: Any AI that inputs health data, claims history, or biometric data to generate personalised insurance pricing. Even "AI-assisted actuarial tools" offered as SaaS qualify.

Claims adjudication AI: Systems that automatically accept, reject, or flag health insurance claims for manual review based on AI scoring. The trigger is influence over the outcome, not full automation.

Risk stratification for insurers: AI identifying "high-risk" patients for insurers or employers for cost management purposes. This has significant intersection with GDPR special category data processing under Article 9 — expect double scrutiny.

The Medical Device Boundary

Category 6 (medical devices) has a different trigger. The relevant question is: does your AI system provide a medical purpose as defined in MDR Article 2(1)? The definition includes:

• Diagnosis, prevention, monitoring, treatment, or alleviation of disease
• Investigation, replacement, or modification of anatomy or physiology
• Prediction, prognosis, or monitoring of disease

Software that analyses medical images, interprets lab results, detects abnormalities in diagnostic scans, or supports clinical decision-making for treatment selection is almost certainly a medical device under MDR. If that software uses an AI/ML model as its core mechanism, it triggers both MDR compliance and EU AI Act Category 6 high-risk classification.

Clinical Decision Support (CDS) software occupies a contested regulatory space. The EU has no equivalent to FDA's Digital Health Center of Excellence guidance clarifying CDS scope. The draft classification guidelines (Section 4.2) note that CDS software that "merely provides information" without making treatment recommendations sits in a grey zone — but enforcement practice from 2024/2025 notified body decisions suggests the threshold is lower than developers expect.

Annex III Category 4/5 Compliance Obligations Map

Once your system is confirmed high-risk under Category 4 or 5, the following obligations activate under Articles 9–17:

1. Risk Management System (Article 9)

A documented, ongoing risk management system covering:

• Identification and analysis of known and foreseeable risks associated with each intended purpose
• Estimation and evaluation of risks from intended use and reasonably foreseeable misuse
• Risk mitigation measures adopted in design and development
• Residual risks after mitigation (must be judged acceptable relative to intended purpose)

The key requirement developers underestimate: risk management must be iterative. The initial pre-deployment assessment is not sufficient — you need a process for continuous review as the system is updated or as real-world performance data emerges from post-market monitoring.

2. Data Governance (Article 10)

Training, validation, and testing datasets must meet specific requirements:

• Relevant design choices documented
• Examination for possible biases that could affect fundamental rights
• Identification of data gaps or shortcomings and how they were addressed
• Appropriate statistical properties (including "representativeness" requirement)

For HR AI and healthcare AI, data governance documentation must explicitly address demographic bias. An AI system that produces statistically disparate outcomes by gender, ethnicity, age, or disability status may satisfy the technical accuracy requirements while failing the Article 10 bias examination.

3. Technical Documentation (Article 11 + Annex IV)

Annex IV specifies the 14-element technical documentation package. For HR and healthcare AI, the most demanding elements are:

• Element 3: "Detailed description of the system including its general logic and key design choices" — requires source-level documentation of model architecture and training approach
• Element 4: "Detailed information about the monitoring, functioning and control of the AI system" — real-time monitoring capability with override mechanisms
• Element 6: "Measures put in place in relation to technical robustness, including vulnerability testing" — adversarial input testing, distribution shift analysis
• Element 7: "Description of any pre-trained model or tool used" — if you use foundation models or third-party AI components, this requires documentation of their known limitations

4. Record-Keeping (Article 12)

Automatic logging with "level of granularity appropriate to the intended purpose" covering:

• Period of each use
• Reference database(s) against which input data was checked
• Input data
• Natural persons involved in verification of results

For employment AI, this creates a practical requirement: every AI-influenced hiring decision must be logged with enough granularity to support an individual's right of explanation under GDPR Article 22. The Article 12 requirement and GDPR Article 22(3) requirements must be co-designed — retrofitting logging later is significantly more expensive.

5. Transparency and Information to Deployers (Article 13)

High-risk AI providers must supply deployers with instructions for use including:

• Identity and contact details of provider
• Characteristics, capabilities, and limitations of the AI system
• Level of accuracy, robustness, and cybersecurity performance
• Known or foreseeable circumstances which may lead to risks to health, safety, or fundamental rights
• Human oversight measures, including technical measures to facilitate interpretation of outputs
• Expected lifetime and maintenance/update instructions

6. Human Oversight (Article 14)

High-risk AI systems must be designed and developed to enable human oversight. The specific requirements:

• Individuals assigned to human oversight must be able to fully understand the system's capabilities and limitations
• Must be able to detect anomalies, dysfunctions, and unexpected performance
• Must be able to disregard, override, or reverse AI system outputs
• Must be able to interrupt operation via "stop" button or similar mechanism

For employment and healthcare AI, Article 14(5) adds a specific requirement: where AI outputs could result in significant harm to natural persons, the deployer must ensure that human oversight is exercised by "appropriately competent persons" before the output is acted upon. This is the closest the EU AI Act comes to a mandatory human-in-the-loop requirement — and it applies directly to automated CV screening, medical diagnostic outputs, and insurance coverage decisions.

7. Accuracy, Robustness, and Cybersecurity (Article 15)

High-risk AI systems must be designed to achieve appropriate levels of accuracy, robustness, and cybersecurity throughout their lifecycle. For Category 4 and 5 systems, the benchmarking requirements include:

• Consistent performance across different demographic groups
• Resilience against errors, faults, and inconsistencies in inputs
• Protection against adversarial manipulation of model inputs
• Technical documentation of performance metrics used and testing methodology

8. Conformity Assessment and CE Marking (Articles 43–51)

For most Category 4 and 5 high-risk systems, the conformity assessment pathway is self-assessment (internal conformity check under Annex VI). Third-party notified body involvement is only mandatory for:

• Biometric identification systems
• AI systems with safety components for regulated products (Category 6)
• Systems where harmonised standards explicitly require third-party assessment

Self-assessment for HR AI and insurance/credit AI means the provider must complete the Annex VI procedure, which includes verifying all Article 9–15 obligations are met, drawing up the EU Declaration of Conformity, and affixing the CE marking before EU market placement.

9. Registration in EU Database (Article 49 + Article 71)

Before placing a high-risk AI system on the EU market, providers must register in the EU AI Act database (operated by the EU AI Office). The registration captures:

• Name and contact details of provider
• Intended purpose of the AI system
• General description of capabilities
• Status of the AI system (new, substantially modified)
• Union representative contact details (for non-EU providers)

The EU AI database went live in Q1 2026. The registration API documentation is available at euaidb.europa.eu. Registration is a precondition for legal market placement — not a post-launch formality.

The "Substantial Modification" Trap

One area where HR and healthcare AI SaaS providers routinely fail: the substantial modification rule under Article 6(2) and Recital 66.

If you make a substantial modification to a high-risk AI system already on the market, the modified system is treated as a new system — it must undergo conformity assessment again, documentation must be updated, and the modified system must be re-registered. A "substantial modification" includes:

• Changes to the intended purpose
• Changes that significantly affect the risk profile
• Changes to the training data that could affect performance relative to the conformity assessment basis
• Architectural changes to the core AI model

For HR AI SaaS that continuously trains on user data (improving recommendations from ongoing hiring decisions), this creates a compliance design question: at what point does iterative model improvement constitute a substantial modification requiring new conformity assessment? The draft classification guidelines do not provide a quantitative threshold — they suggest a risk-based assessment of whether the modification "creates new risks or increases existing risks."

The practical answer for HR AI providers: establish a model versioning and change control process that documents each update and includes an assessment of whether the change constitutes a substantial modification. This process should be built into your CI/CD pipeline, not added as a post-hoc compliance exercise.

GDPR Intersection: Special Category Data in HR and Healthcare AI

Category 4 and 5 high-risk AI systems almost always process GDPR special category data under Article 9. Employment AI processing health information or disability status, healthcare AI processing medical data, and insurance AI processing health history all require:

• Explicit consent under Article 9(2)(a) or an alternative legal basis (employment necessity under 9(2)(b), vital interests under 9(2)(c), etc.)
• A Data Protection Impact Assessment (DPIA) under Article 35 — mandatory when processing biometric data, health data, or data about vulnerable persons at scale
• Data minimisation — only the special category data strictly necessary for the AI system's function
• Records of processing activities (RoPA) updated to reflect the AI system's data flows

The EU AI Act does not replace GDPR obligations — it layers on top. For developers building Category 4 and 5 systems, the compliance programme must address both simultaneously. The conformity assessment under the AI Act and the DPIA under GDPR have significant documentary overlap — a coordinated approach that satisfies both simultaneously avoids duplication.

Checklist: Is Your HR AI or Healthcare AI High-Risk?

Category 4 Triggers:

• Does your AI rank, score, or filter job applications?
• Does your AI generate candidate assessments from video, text, or behavioural data?
• Does your AI monitor worker performance and generate scores used in employment decisions?
• Does your AI allocate work tasks based on worker profiles or history?
• Does your AI generate recommendations for promotion, assignment, or termination?

If any checkbox is ticked: Category 4 applies.

Category 5 Triggers:

• Does your AI evaluate creditworthiness or generate credit scores?
• Does your AI determine health or life insurance premiums?
• Does your AI process insurance claims by generating accept/reject/escalate decisions?
• Does your AI assess eligibility for social benefits or essential services?
• Does your AI generate risk stratification for health insurers or employers?

If any checkbox is ticked: Category 5 applies.

Medical Device Overlap (Category 6):

• Does your AI provide diagnosis, monitoring, or treatment support for a medical condition?
• Does your AI interpret diagnostic images, lab results, or clinical measurements?
• Does your AI support clinical decision-making for treatment selection or dosing?

If any checkbox is ticked: Category 6 also applies — dual MDR/AI Act compliance pathway.

Timeline: What Must Be Done and When

For systems already on the EU market before August 2026: transitional provisions in Article 111 provide 24 months from the Act's entry into force (February 2025) for providers to bring existing systems into conformity. That window closes February 2027 — but the practical compliance design and development work for systems using the full transitional period needs to begin now.

Sovereign Infrastructure Consideration for HR and Healthcare AI

High-risk AI systems under Category 4 and 5 typically process substantial volumes of sensitive personal data. For EU-based deployers, the data sovereignty question has become acute following the 2023 Meta (Schrems II implementation) and 2024 data transfer enforcement actions.

Running HR AI or healthcare AI on US cloud infrastructure — even with Standard Contractual Clauses — creates legal exposure that the AI Act's data governance requirements (Article 10) make harder to paper over. Article 10's requirement to document data sources, examine datasets for bias, and maintain records of training and validation data implies an audit trail that is practically difficult to produce for data processed on non-EU infrastructure subject to CLOUD Act production orders.

sota.io provides EU-native managed hosting for AI workloads — Hetzner Germany, no US parent company, no CLOUD Act exposure. For teams building Category 4 or 5 high-risk AI systems, deploying on EU-sovereign infrastructure is not just a compliance preference — it becomes a measurable risk reduction in the Article 10 documentation process.

What's Next in This Series

This post covered the two most commercially relevant Annex III categories for SaaS developers. The next post in this series covers the conformity assessment procedure in detail — the technical documentation package, self-assessment workflow, and what EU AI database registration looks like in practice for a SaaS provider placing a high-risk system on the EU market.

Series navigation:

• Post #1: EU AI Act High-Risk AI Classification 2026: Is Your AI System High-Risk? Developer Self-Assessment Guide
• Post #2 (this post): Annex III Deep Dive — HR AI, Healthcare AI & Recruiting Systems
• Post #3: High-Risk Conformity Assessment — Technical Documentation, Testing & CE Marking
• Post #4: Post-Market Monitoring & Surveillance Obligations
• Post #5: Complete Annex III Compliance Stack Finale