EU AI Act for HealthTech Developers: When Clinical AI Triggers High-Risk Classification

Post #4 in the sota.io EU AI Act Sector-Specific Developer Series

The EU Medical Device Regulation (MDR) and In Vitro Diagnostic Regulation (IVDR) cover AI that diagnoses or treats disease. But what about clinical AI that supports healthcare workflows without formally being a medical device? AI that helps prioritise patient queues, score insurance eligibility, flag high-risk patients for outreach, or assist administrators in allocating care resources?

For HealthTech developers, this gap is exactly where the EU AI Act's Annex III high-risk classification lands. Your AI may not be subject to MDR/IVDR notified-body procedures — but it can still be a mandatory-registration, risk-managed, human-overseen, conformity-assessed system under the AI Act. And the deadline is 2 August 2026.

This guide covers the full compliance picture for clinical AI that lives outside MDR/IVDR scope but inside EU AI Act Annex III.

Why MDR/IVDR Alone Doesn't Define Your Compliance Obligations

The MDR and IVDR apply to software with an intended medical purpose: diagnosing, preventing, monitoring, treating, or predicting disease. If your AI does this, it is a Software as Medical Device (SaMD) and subject to MDR conformity assessment — with or without the EU AI Act.

But healthcare is vastly larger than clinical diagnosis. HealthTech developers build tools that:

• Score patient risk for resource allocation (not formal diagnosis)
• Prioritise referral queues based on urgency indicators
• Assess insurance eligibility or predict claim outcomes
• Identify populations likely to benefit from outreach programmes
• Automate administrative triage in electronic health records (EHR)
• Support clinical staffing decisions with workload and outcome projections

None of these are necessarily medical devices. But several trigger EU AI Act Annex III high-risk classification — and that means all the obligations that come with it.

Which HealthTech AI Qualifies as High-Risk Under Annex III?

The EU AI Act Annex III lists eight categories of high-risk AI systems. Two are directly relevant to HealthTech:

Annex III Point 5(a) — Healthcare Access Eligibility

AI systems used by or on behalf of public authorities to evaluate natural persons' eligibility for essential public assistance benefits and services, including healthcare services — and to grant, reduce, revoke, or reclaim those services.

In practice, this means:

• Regional health authority AI that prioritises waiting lists for specialist care
• NHS, GKV, or similar public payer tools that auto-adjudicate funding approvals
• AI that scores social care eligibility including health and disability components
• EHR workflow AI used by public hospital systems for patient routing decisions

Developer note: If you sell B2G (business-to-government) HealthTech — your AI is likely high-risk under Point 5(a). This includes white-label EHR modules that public systems deploy to make or support access decisions.

Annex III Point 5(c) — Life and Health Insurance Risk Assessment

AI systems intended for risk assessment and pricing for individuals in the context of life and health insurance.

In practice, this means:

• Actuarial AI that scores applicant risk for health insurance underwriting
• AI that adjusts premium pricing based on health data or lifestyle indicators
• Wellness programme AI that feeds into insurance pricing models
• Predictive health scoring that insurers use to set coverage terms

Developer note: If you supply InsurTech or HealthTech tools used in underwriting workflows, Point 5(c) captures you. This applies regardless of whether the insurer runs the model or you provide it as a service.

Other Annex III Points That May Apply

• Point 2 (Critical infrastructure): AI managing hospital infrastructure, energy systems in medical facilities, or utility management for healthcare premises
• Point 4 (Employment): AI used to manage healthcare workforce allocation, scheduling with outcome implications

The Clinical Decision Support Grey Zone

The most common HealthTech AI scenario — clinical decision support systems (CDSS) — sits in a contested area. A CDSS that presents information to a clinician, who then makes the final decision, is often argued to be outside both MDR/IVDR and EU AI Act Annex III.

However, the EU AI Act's recitals and the European Commission's classification guidance signal that the bar for "high-risk" is lower than many assume. The question is not whether a human formally has final authority — it is whether the AI output materially influences a decision that affects a person's access to essential services or their fundamental rights.

If your CDSS output is routinely acted upon without meaningful human review, it may be treated as high-risk even if the legal structure maintains a "clinician decides" step. Regulators will look at the actual workflow, not just the contract.

Safe harbour for non-high-risk CDSS: A CDSS that provides educational or statistical information to clinicians (population averages, literature references, dosage ranges) without making recommendations specific to a named patient is generally not high-risk. The moment it produces patient-specific recommendations that influence access, discharge, or care pathway decisions, the risk calculus shifts.

Core Developer Obligations for High-Risk Clinical AI

If your HealthTech AI system is high-risk under Annex III, the following obligations apply as of 2 August 2026:

Art. 9 — Risk Management System

You must establish, implement, document, and maintain a risk management system covering the full lifecycle of your AI system. For clinical AI this means:

• Hazard identification across all plausible uses (including misuse and unexpected use cases)
• Risk estimation for each hazard, with particular attention to vulnerable populations (patients with comorbidities, elderly patients, patients with limited health literacy)
• Risk control measures, documented with evidence
• Residual risk evaluation and acceptability decisions
• Post-deployment monitoring feedback into the risk management loop

The AI Act's risk management system under Art. 9 differs from MDR's risk management (ISO 14971) in that it extends explicitly to foreseeable misuse and systemic discriminatory effects — both highly relevant for clinical AI trained on non-representative datasets.

Art. 10 — Data and Data Governance

High-risk AI systems must be trained, validated, and tested using datasets subject to governance practices that ensure:

• Relevance, representativeness, freedom from errors, and completeness
• Examination for possible biases (Art. 10(2)(f)) — critical for clinical AI where protected characteristics (age, ethnicity, gender) can produce discriminatory outputs
• Adequate coverage of all clinical populations the system will encounter in deployment
• Separation of training, validation, and test datasets

For HealthTech developers, Art. 10 demands particular attention to dataset provenance and bias auditing. Using synthetic data or data derived from unrepresentative hospital populations without bias analysis is an Art. 10 compliance gap.

Art. 11 — Technical Documentation

Before placing your AI system on the market or putting it into service, you must compile technical documentation that enables authorities to assess compliance. For clinical AI this must include:

• A general description of the system and its intended purpose
• Detailed description of the system's components (architecture, training approach, algorithms)
• Evidence of testing and validation across the clinical populations covered
• Results of the Art. 9 risk management process
• Cybersecurity risk assessment and mitigation measures (Art. 15)

Technical documentation must be maintained and updated throughout the system's lifecycle.

Art. 14 — Human Oversight Measures

This is the article most HealthTech developers underestimate. Art. 14 requires that high-risk AI systems be designed so that natural persons can:

• Fully understand the system's capabilities and limitations
• Monitor the system for anomalies, dysfunction, and unexpected outputs
• Override the system's output or interrupt operation
• Identify situations where the AI's reliability may have decreased (e.g. data drift, distribution shift)

For clinical AI, Art. 14 means your system must present confidence levels and uncertainty information in a form that clinicians can meaningfully interpret. A system that outputs a binary "approve/reject" or a risk score without uncertainty bounds fails Art. 14.

Implementation note: Implement explainability features (e.g. SHAP values, attention highlighting, or natural-language rationale) and ensure your UI presents these to the responsible clinician — not just to your back-end logs.

Art. 16 — Provider Obligations Overview

Providers of high-risk AI systems must:

• Ensure the system complies with the requirements of Chapter III, Section 2
• Have a quality management system (Art. 17)
• Draw up technical documentation (Art. 11)
• Implement conformity assessment (Art. 43) before market placement
• Register in the EU database (Art. 49)
• Affix CE marking
• Issue an EU declaration of conformity (Art. 47)

Art. 17 — Quality Management System

You must implement a QMS covering:

• Your regulatory compliance strategy
• Risk management procedures (feeding into Art. 9)
• Data governance procedures (feeding into Art. 10)
• Post-market monitoring (Art. 72)
• Incident management and serious incident reporting (Art. 73)
• Corrective action procedures (Art. 20)

The QMS must be documented and subject to internal audit. Deployers (hospitals, insurers) will typically demand QMS documentation as part of procurement.

Conformity Assessment for Clinical AI (Art. 43)

The EU AI Act creates two conformity assessment paths for Annex III high-risk AI systems:

Self-assessment path: For most Annex III high-risk systems not covered by harmonised standards, providers can conduct internal conformity assessment — systematically checking compliance against the requirements of Chapter III, Section 2, documenting this in the technical documentation, and issuing a declaration of conformity. This is available to most HealthTech developers unless:

• The system is also a medical device (SaMD) subject to MDR/IVDR — in which case notified body involvement may be mandatory under the MDR/IVDR conformity path and the AI Act simply adds obligations to that process
• The Commission has identified the system as requiring mandatory third-party assessment

EU Database Registration (Art. 49/51): High-risk AI systems under Annex III must be registered in the EU's EUDB before market placement. The provider submits technical information, intended use, and risk management evidence. This is a public registry — your competitors and regulators will be able to see your registered systems.

The MDR/IVDR + AI Act Intersection: Double Obligation Scenarios

Some HealthTech AI systems are both medical devices and Annex III high-risk AI systems. For those systems, the compliance obligations stack:

If your system sits in the intersection, you typically run a single conformity assessment process that satisfies both. But the AI Act requirements (particularly around data governance, human oversight, and discriminatory bias) are additive — MDR conformity alone does not satisfy the AI Act.

HealthTech-Specific Implementation Checklist (30 Items)

Organisation & Governance

• 1. Classified each AI system against Annex III categories (Point 5(a), 5(c), or others) and documented the classification rationale
• 2. Determined whether each system is also a medical device under MDR/IVDR, with legal opinion if borderline
• 3. Appointed an EU AI Act compliance lead with authority over AI product decisions
• 4. Established a QMS per Art. 17 with documented procedures for all AI lifecycle stages
• 5. Defined the legal entity that acts as "provider" for each system (you or your deployer?)

Risk Management (Art. 9)

• 6. Documented all intended uses and reasonably foreseeable misuses of each system
• 7. Identified hazards specific to clinical populations (elderly, paediatric, patients with comorbidities)
• 8. Conducted hazard analysis for discriminatory outcomes across protected characteristics
• 9. Implemented risk control measures with documented evidence of effectiveness
• 10. Defined residual risk acceptability criteria with clinical input

Data Governance (Art. 10)

• 11. Documented the provenance and representativeness of all training datasets
• 12. Conducted bias analysis across demographic subgroups (age, sex, ethnicity, socioeconomic factors)
• 13. Demonstrated that validation datasets cover the full clinical population in deployment scope
• 14. Maintained strict separation between training, validation, and test sets
• 15. Documented data preprocessing steps and their effect on representation

Technical Documentation (Art. 11)

• 16. Prepared technical documentation per Annex IV (system description, architecture, training, testing)
• 17. Included performance metrics across all relevant subgroups — not just aggregate accuracy
• 18. Documented cybersecurity risk assessment (Art. 15) and penetration testing results
• 19. Maintained version history linking each system version to its corresponding documentation
• 20. Stored documentation in a format accessible to national competent authorities (NCAs) without undue delay

Human Oversight (Art. 14)

• 21. Implemented explainability features (SHAP values, rationale, confidence intervals) visible to responsible clinicians
• 22. Designed UI to surface uncertainty flags when input data is outside training distribution
• 23. Implemented override mechanism with audit trail — clinician can reject AI output with documented reason
• 24. Provided clinician training on the system's capabilities, limitations, and known failure modes
• 25. Defined escalation procedures for when AI output should be escalated to senior review

Conformity & Market Placement

• 26. Completed internal conformity assessment per Art. 43 and documented in technical file
• 27. Issued EU declaration of conformity (Art. 47) for each system
• 28. Registered all Annex III high-risk systems in the EUDB (Art. 49/51)
• 29. Affixed CE marking on conforming systems

Post-Market & Incident Management

• 30. Implemented post-market monitoring plan (Art. 72) with automated data collection on system performance, clinical outcomes, and anomalies — feeding back into the Art. 9 risk management loop

Practical Timeline for HealthTech Developers (2026-H2)

Now — 2 August 2026:

• Complete risk classification for all deployed clinical AI
• Draft technical documentation and begin internal conformity assessment
• Identify data governance gaps and begin bias auditing

2 August 2026 (AI Act enforcement begins):

• All Annex III high-risk systems must meet Art. 9/10/11/14/17 requirements
• EU database registration must be completed (Art. 49)
• CE marking and declaration of conformity must be in place

August 2026 onwards:

• Post-market monitoring active (Art. 72)
• Serious incident reporting operational (Art. 73): if your system contributes to a serious incident, reporting to the NCA is mandatory
• Annual QMS internal audits

GDPR Intersection: Health Data Is Special Category

Clinical AI almost inevitably processes health data under GDPR Art. 9 — special category data requiring explicit legal basis beyond general consent or legitimate interest. For high-risk clinical AI, you typically need:

• Art. 9(2)(h) (medical diagnosis, treatment, or healthcare management) as the health data processing basis
• A Data Protection Impact Assessment (DPIA) under GDPR Art. 35 — mandatory for large-scale processing of health data
• Data minimisation and purpose limitation rigorously enforced — clinical AI often processes far more data than it needs

If your system triggers both EU AI Act high-risk status and GDPR Art. 9 processing, run a combined DPIA + AI Act risk management process to avoid duplicating effort. The documentation overlaps substantially.

What This Means for EU-Sovereign Infrastructure

Clinical AI involves health data — the most sensitive category under GDPR. Running that AI on US-headquartered platforms creates a jurisdiction risk: CLOUD Act requests could compel disclosure of patient data to US authorities without EU court oversight.

For EU public health authorities and insurers subject to procurement rules, this is not a theoretical concern. Annex III high-risk AI systems used in public healthcare must typically be procured in compliance with national data protection requirements — many of which require EU-jurisdiction hosting for health data.

EU-native managed PaaS (Hetzner Germany, no US parent entity) eliminates the CLOUD Act exposure at the infrastructure layer. For HealthTech providers selling to public health systems in particular, EU-sovereign hosting is increasingly a procurement prerequisite, not a differentiator.

Next in the Series

#5/5 — GovTech / Public Sector AI: Annex III Point 1 (biometric) and the full public sector obligations under EU AI Act — AI in administrative decision-making, benefit adjudication, and democratic processes. How government AI suppliers navigate mandatory third-party conformity assessment.

This post is part of the sota.io EU AI Act Sector-Specific Developer Series. Posts in this series: EdTech #1, HR-Tech #2, FinTech #3, HealthTech #4 (this post), GovTech #5 (coming next run).