EU AI Act + European Health Data Space (EHDS): Complete Health AI Compliance Guide for Developers (2026)

You are building an AI system that reads medical imaging, predicts patient deterioration, assists clinical diagnosis, or trains on electronic health records. You are operating in — or serving — the European Union. You are, simultaneously, subject to two major EU regulatory frameworks that have overlapping but distinct requirements: the EU AI Act and the European Health Data Space Regulation (EHDS).

Most health AI developers know about one or the other. Very few have mapped the intersection. This guide does exactly that.

What Is the European Health Data Space (EHDS)?

The European Health Data Space (Regulation (EU) 2023/2854, commonly written EHDS) is the EU's dedicated framework for health data. It entered into force on 26 March 2025 and applies progressively through 2027-2029.

EHDS has two distinct pillars:

Pillar 1 — Primary Use (Chapter II, Arts. 3–13): Patient Rights

Primary use governs individuals' rights over their own health data:

• Art. 3: Natural persons have the right of access to their electronic health data
• Art. 4: The right to supplement and correct health data
• Art. 5: The right to restrict access by healthcare providers
• Art. 6: The right to data portability via MyHealth@EU (the EU-wide patient data exchange infrastructure)

For AI developers: primary use rights affect the training data consent landscape. Patients can restrict access to their records — which means your training pipeline cannot assume blanket availability.

Pillar 2 — Secondary Use (Chapter III, Arts. 14–46): AI Training and Research

Secondary use is the pillar that directly affects AI developers. It governs access to health data for purposes beyond the individual's direct care: research, public health, policy, and AI training and development.

Art. 14(1): Secondary use is permitted for:

• Scientific research (including AI research)
• Development and innovation activities (including AI systems development)
• Training, testing, and evaluating AI systems, including large-scale models
• Public health purposes and health policy

Art. 14(2): Secondary use data may include:

• Electronic health records
• Disease registry data
• Claims and reimbursement data
• Genomics data
• Patient registries
• Real-world evidence data

Critical legal basis for AI training: EHDS Art. 14 establishes a specific legal basis for processing health data (a special category under GDPR Art. 9) for AI training — provided access is obtained through the health data access body (HDAB) mechanism described in Arts. 36–40.

The Dual Regulatory Overlay: Where EU AI Act Meets EHDS

When you build AI on health data, two compliance regimes apply simultaneously. They are not redundant — they address different risk dimensions.

The frameworks reinforce each other at several intersection points — and conflict nowhere, but create additive compliance burdens that you must address in combination.

Intersection Point 1: AI Act Annex III High-Risk Healthcare AI

EU AI Act Annex III, Point 5 defines health AI systems as high-risk:

Annex III 5(a): AI systems intended to be used as medical devices and safety components of medical devices, as referred to in Regulation (EU) 2017/745 and Regulation (EU) 2017/746, or AI systems that are themselves medical devices.

Annex III 5(b): AI systems intended to be used for the administration, management, and distribution of healthcare resources and services, for triage or prioritisation of patients, clinical decision support, diagnostics or disease management, health monitoring, and patient risk assessment.

What this means in practice:

If your health AI is high-risk under Annex III 5: you must comply with Arts. 9–25 of the EU AI Act, including risk management (Art. 9), data governance (Art. 10), technical documentation (Art. 11), transparency (Art. 13), human oversight (Art. 14), accuracy and robustness (Art. 15), conformity assessment (Art. 43), CE marking (Art. 49), and registration in the EU database (Art. 71).

Also note: If your AI qualifies as a medical device under MDR (2017/745) or IVDR (2017/746), it is also subject to those regulations — creating a three-regulation compliance stack (MDR/IVDR + EU AI Act + EHDS) for clinical-grade AI systems.

Intersection Point 2: Training Data Quality — Art. 10 + EHDS Art. 33

For high-risk AI under the EU AI Act, Art. 10 imposes strict data governance requirements on training, validation, and testing datasets. EHDS Art. 33 imposes data quality and utility labelling on all EHDS-hosted datasets. Together they create a combined data quality obligation for health AI trained on EHDS secondary use data.

EU AI Act Art. 10 Requirements

For training data used in high-risk AI systems, Art. 10(2) requires:

1. Relevant, representative, free of errors, and complete: The training data must be relevant for the intended purpose, adequately representative of the deployment population, free of errors that could affect system performance, and sufficiently complete for the risk profile.

2. Appropriate data governance practices: Statistical properties, population coverage, data collection and labelling methodologies, and data selection criteria must be documented.

3. Examination for biases: Training data must be examined for possible biases that could affect health outcomes, particularly across demographic groups (age, sex, ethnicity, disability status, geography).

4. Special category data: Where training data includes special categories (including health data under GDPR Art. 9(1)), additional safeguards must be in place and documented.

5. Synthetic data: Use of synthetic health data to address representativeness gaps is permitted but must itself meet quality requirements.

EHDS Art. 33 Data Quality and Utility Labels

Health Data Access Bodies (HDABs) must apply standardised quality and utility labels to datasets made available for secondary use. These labels address:

• Data completeness: Percentage of fields populated across the dataset
• Data accuracy: Validation against reference standards
• Data coverage: Population representativeness (age, sex, region, clinical subgroup)
• Temporal scope: Date range and collection period
• Coding standards: ICD-10, SNOMED CT, LOINC compliance
• Update frequency: How often the dataset is refreshed

The combined obligation: When you access health data through the EHDS HDAB mechanism for AI training, the Art. 33 quality labels provide evidence for your Art. 10 data governance documentation. However, EHDS quality labels do not automatically satisfy Art. 10 — you must still document the specific selection criteria, bias examination, and representativeness analysis for your particular AI system's intended purpose.

Intersection Point 3: The HDAB Access Mechanism for AI Training Data

To access health data for AI training under EHDS, you must go through the Health Data Access Body (HDAB) in each Member State. HDABs are the gatekeepers for secondary use data access.

The EHDS Secondary Use Application Process (Art. 45-46)

1. Submit a data access application: Describe your AI system, its intended purpose, the specific datasets you need, and the proposed use.

2. Data permit assessment (Art. 46): The HDAB assesses:

   • Legitimacy of purpose (does it fall within Art. 14(1) permitted uses?)
   • Proportionality (minimum data necessary for the AI training objective?)
   • Safeguards (technical and organisational measures for data protection)
   • Public interest (does the AI system serve healthcare improvement?)

3. Data permit issuance: If approved, the HDAB issues a data permit that specifies:

   • Permitted dataset(s)
   • Access period and data volume
   • Processing purposes and restrictions
   • Output controls (what you can publish or export from the analysis)

4. Secure processing environment: EHDS Art. 50 requires that secondary use processing occurs in a secure processing environment — a controlled technical infrastructure provided by or validated by the HDAB. You cannot simply download health datasets to your own infrastructure.

5. Results export: You may export aggregate results, trained models (subject to privacy conditions), and statistical outputs — but not the underlying individual patient records.

For AI developers: The secure processing environment requirement significantly affects your MLOps architecture. You cannot train models in your own cloud environment on EHDS data — you must bring your training code to the data, not the data to your training environment.

Intersection Point 4: GPAI Models Trained on Health Data

If you are developing a General Purpose AI (GPAI) model (Arts. 51-56) and your pre-training or fine-tuning corpus includes health data accessed via EHDS, additional obligations apply:

GPAI + EHDS Secondary Use

Art. 14(2)(c) explicitly permits training of "AI systems, including large-scale models" as a secondary use purpose. However:

1. Output restriction: The data permit specifies what you can export from the secure processing environment. For GPAI models, you may export the trained weights but typically not memorised training examples.

2. GPAI Art. 53 obligations: If your GPAI model has systemic risk (FLOP threshold ≥ 10²⁵), you must disclose training data summaries under Art. 52(2). For EHDS-sourced data, this disclosure must not violate patient privacy — the Art. 33 quality labels and dataset identifiers (not individual records) may be disclosed.

3. GPAI CoP Chapter 2 (Copyright/TDM Opt-Out): EHDS data has a different legal basis than copyright opt-out — it is accessed through the Art. 14 HDAB mechanism. The TDM opt-out (DSM Art. 4(3)) that applies to web-scraped data does not apply to EHDS data, which has its own access and purpose restrictions.

4. Downstream deployer restrictions: A GPAI model trained on EHDS data must inform downstream deployers (via Art. 53 technical documentation) of any restrictions on deployment contexts that could re-identify individuals or violate the data permit scope.

Intersection Point 5: Transparency Obligations — AI Act Art. 13 + EHDS Art. 32

Both frameworks impose transparency requirements on health AI:

EU AI Act Art. 13 (high-risk AI): Requires instructions for use that include:

• The purpose, conditions, and limitations of use
• The level of accuracy, robustness, and cybersecurity
• Any known or foreseeable circumstances that may lead to risks
• Human oversight measures and contraindications

EHDS Art. 32 (AI systems developed using EHDS secondary use data): Requires that publications, products, and services developed using EHDS data acknowledge the EHDS source and the HDAB that granted access.

Combined disclosure requirement: A health AI system built on EHDS data must disclose both its EHDS data provenance (Art. 32) and its operational accuracy/limitation profile (AI Act Art. 13). For healthcare providers deploying such systems, this creates an information cascade they must pass to clinicians and patients.

Python HealthAIComplianceChecker

from dataclasses import dataclass, field
from enum import Enum
from typing import Optional


class AIActRiskTier(Enum):
    HIGH_RISK_5A = "high_risk_medical_device"          # Annex III 5(a)
    HIGH_RISK_5B = "high_risk_health_management"       # Annex III 5(b)
    LIMITED_RISK = "limited_risk"                       # Art. 52 transparency only
    MINIMAL_RISK = "minimal_risk"                       # No AI Act obligations
    GPAI_GENERAL = "gpai_general"                       # Arts. 52-53 base obligations
    GPAI_SYSTEMIC = "gpai_systemic_risk"                # Arts. 52-55 full obligations
    RESEARCH_EXEMPT = "research_exempt"                 # Art. 2(6) exemption


class EHDSDataAccess(Enum):
    NOT_APPLICABLE = "no_health_data"
    PRIMARY_USE = "primary_use_direct_care"
    SECONDARY_USE_PERMITTED = "secondary_use_hdab_permit"
    SECONDARY_USE_REQUIRED = "secondary_use_hdab_required"


@dataclass
class HealthAISystem:
    name: str
    # AI Act classification inputs
    is_medical_device: bool = False           # MDR/IVDR classification
    clinical_decision_support: bool = False   # Diagnosis, triage, treatment suggestion
    patient_risk_assessment: bool = False     # Deterioration, sepsis, readmission
    health_resource_management: bool = False  # Scheduling, allocation, prioritisation
    is_gpai: bool = False
    gpai_flops: Optional[float] = None        # 10^25 threshold for systemic risk
    
    # EHDS inputs
    trains_on_ehr_data: bool = False
    trains_on_claims_data: bool = False
    trains_on_genomics_data: bool = False
    trains_on_imaging_data: bool = False
    
    # Computed
    ai_act_tier: AIActRiskTier = field(init=False)
    ehds_access_type: EHDSDataAccess = field(init=False)
    
    def __post_init__(self):
        self.ai_act_tier = self._classify_ai_act()
        self.ehds_access_type = self._classify_ehds()
    
    def _classify_ai_act(self) -> AIActRiskTier:
        if self.is_gpai:
            if self.gpai_flops and self.gpai_flops >= 1e25:
                return AIActRiskTier.GPAI_SYSTEMIC
            return AIActRiskTier.GPAI_GENERAL
        if self.is_medical_device:
            return AIActRiskTier.HIGH_RISK_5A
        if any([self.clinical_decision_support,
                self.patient_risk_assessment,
                self.health_resource_management]):
            return AIActRiskTier.HIGH_RISK_5B
        return AIActRiskTier.MINIMAL_RISK
    
    def _classify_ehds(self) -> EHDSDataAccess:
        health_data = any([
            self.trains_on_ehr_data,
            self.trains_on_claims_data,
            self.trains_on_genomics_data,
            self.trains_on_imaging_data,
        ])
        if not health_data:
            return EHDSDataAccess.NOT_APPLICABLE
        if self.ai_act_tier in (AIActRiskTier.HIGH_RISK_5A,
                                 AIActRiskTier.HIGH_RISK_5B,
                                 AIActRiskTier.GPAI_SYSTEMIC):
            return EHDSDataAccess.SECONDARY_USE_REQUIRED
        return EHDSDataAccess.SECONDARY_USE_PERMITTED
    
    def compliance_obligations(self) -> list[str]:
        obligations = []
        
        # AI Act obligations
        if self.ai_act_tier in (AIActRiskTier.HIGH_RISK_5A, AIActRiskTier.HIGH_RISK_5B):
            obligations += [
                "AI Act Art. 9: Establish and maintain risk management system",
                "AI Act Art. 10: Data governance — representative, bias-examined, documented datasets",
                "AI Act Art. 11: Technical documentation (Annex IV)",
                "AI Act Art. 12: Logging — automatic event recording during operation",
                "AI Act Art. 13: Transparency — instructions for use for deployers/users",
                "AI Act Art. 14: Human oversight — design for intervention, override, halt",
                "AI Act Art. 15: Accuracy, robustness, cybersecurity targets",
                "AI Act Art. 43: Conformity assessment (internal control or notified body)",
                "AI Act Art. 49: CE marking + declaration of conformity",
                "AI Act Art. 71: Registration in EU database (EUDB) before deployment",
            ]
        if self.is_medical_device:
            obligations.append(
                "MDR 2017/745 / IVDR 2017/746: Medical device classification + CE marking (parallel obligation)"
            )
        if self.ai_act_tier == AIActRiskTier.GPAI_GENERAL:
            obligations += [
                "AI Act Art. 52: Transparency + copyright compliance policy",
                "AI Act Art. 53: Technical documentation (Annex XI) + downstream disclosure",
            ]
        if self.ai_act_tier == AIActRiskTier.GPAI_SYSTEMIC:
            obligations += [
                "AI Act Art. 52: Transparency + copyright compliance policy",
                "AI Act Art. 53: Technical documentation + downstream disclosure",
                "AI Act Art. 54: Adversarial testing (red-teaming per AI Office guidelines)",
                "AI Act Art. 55: Incident reporting to AI Office",
                "AI Act Art. 55: Cybersecurity measures proportionate to systemic risk",
            ]
        
        # EHDS obligations
        if self.ehds_access_type != EHDSDataAccess.NOT_APPLICABLE:
            obligations += [
                "EHDS Art. 14: Confirm secondary use purpose falls within permitted categories",
                "EHDS Art. 36-40: Apply to Health Data Access Body (HDAB) in relevant Member States",
                "EHDS Art. 45-46: Data permit application — purpose, proportionality, safeguards",
                "EHDS Art. 50: Process data in HDAB-approved secure processing environment",
                "EHDS Art. 33: Verify dataset quality/utility labels for Art. 10 documentation",
                "EHDS Art. 32: Acknowledge EHDS data source in publications and products",
            ]
        if self.trains_on_genomics_data:
            obligations.append(
                "EHDS Art. 14(2)(b): Genomics data — additional purpose limitation and sensitivity safeguards"
            )
        
        return obligations
    
    def dual_regulation_gaps(self) -> list[str]:
        """Common gaps where Art. 10 and EHDS Art. 33 do not automatically align."""
        gaps = []
        if self.ehds_access_type != EHDSDataAccess.NOT_APPLICABLE:
            gaps += [
                "Gap 1: EHDS Art. 33 quality labels cover dataset-level completeness — "
                "AI Act Art. 10 requires system-specific representativeness analysis for your deployment population",
                "Gap 2: EHDS secure processing environment limits iterative data exploration — "
                "your Art. 10 bias examination may require multiple analysis passes within the SPE",
                "Gap 3: EHDS data permit specifies permitted purpose — "
                "any change in AI system intended use may require a new permit before retraining",
                "Gap 4: EHDS Art. 32 disclosure requirement may conflict with "
                "commercial confidentiality around training data provenance",
            ]
        return gaps


# Example: sepsis early warning AI
sepsis_ai = HealthAISystem(
    name="SepsisGuard v2",
    patient_risk_assessment=True,    # Annex III 5(b)
    trains_on_ehr_data=True,          # EHDS secondary use required
    trains_on_claims_data=True,
)

print(f"AI Act Risk Tier: {sepsis_ai.ai_act_tier.value}")
print(f"EHDS Access Type: {sepsis_ai.ehds_access_type.value}")
print("\nCompliance Obligations:")
for ob in sepsis_ai.compliance_obligations():
    print(f"  - {ob}")
print("\nDual-Regulation Gaps to Address:")
for gap in sepsis_ai.dual_regulation_gaps():
    print(f"  ! {gap}")

Output:

AI Act Risk Tier: high_risk_health_management
EHDS Access Type: secondary_use_hdab_required

Compliance Obligations:
  - AI Act Art. 9: Establish and maintain risk management system
  - AI Act Art. 10: Data governance — representative, bias-examined, documented datasets
  ... [10 AI Act obligations]
  - EHDS Art. 14: Confirm secondary use purpose falls within permitted categories
  ... [6 EHDS obligations]

Dual-Regulation Gaps to Address:
  ! Gap 1: EHDS Art. 33 quality labels cover dataset-level completeness — ...
  ... [4 gaps]

The HealthData@EU Infrastructure

HealthData@EU is the technical cross-border infrastructure that EHDS establishes for connecting national HDAB secure processing environments. It enables:

1. Cross-border data access: Researchers and AI developers can submit a single application to access health data from multiple Member States through a single national HDAB entry point.

2. Dataset catalogues: A pan-EU catalogue of available health datasets with quality/utility labels (Art. 33 labels browsable before application).

3. Federated analytics: Where cross-border transfer is restricted, HealthData@EU supports federated computation — your model trains on data that never leaves the Member State's infrastructure.

Implications for AI developers:

• Federated learning is not just a privacy-preserving option — for some EHDS datasets, it may be the only legally permissible training architecture
• HealthData@EU federated nodes use standardised APIs (FHIR R4 for EHR data) — your training pipeline should be designed to interface with FHIR-formatted datasets
• The HealthData@EU catalogue is the correct starting point for discovering which datasets are available — do not attempt to contact hospitals or health systems directly for secondary use data

25-Item Health AI Dual Compliance Checklist

A — Scope Determination (Items 1–5)

1. Does your AI system perform clinical decision support, triage, diagnosis, or patient risk assessment? → Annex III 5(b) high-risk
2. Does your AI system qualify as or interface with a medical device under MDR/IVDR? → Annex III 5(a) high-risk
3. Is your AI system a GPAI model? → Arts. 52-53 (+ Art. 54-55 if ≥10²⁵ FLOP)
4. Does your training, validation, or test dataset include EHR, claims, genomics, imaging, or registry data? → EHDS secondary use access required
5. Are you in scope of the EU AI Act under Art. 2? → If not, AI Act obligations do not apply but EHDS secondary use rules still apply if EU health data is used

B — EHDS Data Access (Items 6–12)

1. Have you identified the relevant Health Data Access Body (HDAB) in each Member State whose data you need?
2. Have you confirmed your AI training purpose falls within EHDS Art. 14(1) permitted secondary uses?
3. Have you submitted a data permit application with documented purpose, proportionality, and safeguard description?
4. Do you have an approved data permit for each dataset and each Member State?
5. Is your training infrastructure HDAB-approved or located within an approved secure processing environment?
6. Have you reviewed Art. 33 quality and utility labels for each dataset you plan to use?
7. Have you incorporated Art. 33 label information into your Art. 10 data governance documentation?

C — AI Act Art. 10 Data Governance (Items 13–18)

1. Is your training data representative of the intended deployment population (age, sex, ethnicity, comorbidities, geography)?
2. Have you examined training data for demographic biases that could affect clinical outcomes for specific groups?
3. Is training data free from errors that could affect model performance (label noise, miscoding, missing critical fields)?
4. Have you documented data collection methodology, selection criteria, and statistical properties (Annex IV §2)?
5. For special category data (health data under GDPR Art. 9): are additional safeguards documented?
6. If using synthetic health data: does it meet the same representativeness and bias requirements as real data?

D — AI Act High-Risk Compliance (Items 19–23, high-risk only)

1. Risk management system (Art. 9) established with residual risk documentation?
2. Technical documentation (Annex IV) complete including intended purpose, performance metrics, and post-market monitoring plan?
3. Automatic logging (Art. 12) implemented for clinical events, override instances, and system decisions?
4. Human oversight measures (Art. 14) designed — clinician override, halt capability, decision explanation?
5. Conformity assessment completed — CE marking and declaration of conformity ready for market entry?

E — Transparency and Disclosure (Items 24–25)

1. Instructions for use (Art. 13) prepared for healthcare deployers — accuracy statistics, known failure modes, contraindications, oversight requirements?
2. EHDS Art. 32 acknowledgement included in product documentation, publications, and marketing materials referencing EHDS data provenance?

Common Mistakes

Mistake 1: Downloading EHDS Data to Your Own Cloud

EHDS Art. 50 requires processing in a secure processing environment approved by the HDAB. You cannot simply obtain a data permit and then download the dataset to AWS, Azure, or your own GPU cluster. Data must stay within the SPE. This affects your entire MLOps pipeline: training jobs must run inside the SPE, and only model weights and aggregate results can be exported.

Fix: Design your training pipeline as portable code (containerised) that can be submitted to an SPE environment. Use the HealthData@EU federated analytics API where cross-border data stays local.

Mistake 2: Treating EHDS Quality Labels as Sufficient for AI Act Art. 10

EHDS Art. 33 labels are dataset-level metadata. AI Act Art. 10 requires system-specific data governance analysis for your particular AI system and intended purpose. A dataset labelled as "85% complete" does not automatically satisfy the Art. 10 requirement that training data is "representative, free of errors, and complete" for your specific clinical context.

Fix: Document the gap between Art. 33 labels and Art. 10 requirements explicitly. Conduct your own bias examination and representativeness analysis on top of the HDAB-provided quality metadata.

Mistake 3: Assuming Research Exemption (Art. 2(6)) Covers Clinical Validation

Art. 2(6) exempts AI systems from most AI Act obligations when used "solely for scientific research and development purposes." Once you begin clinical validation studies with patient benefit as an outcome, the system is being "put into service" for a purpose beyond pure research — the exemption likely no longer applies.

Fix: Separate your research prototype (exempt) from your clinical validation system (high-risk). Apply for HDAB access and begin the Art. 9-25 compliance process at the point you move from research to clinical testing.

Mistake 4: Applying for a Single HDAB Permit When You Need Multi-Country Data

EHDS creates national HDABs — one per Member State. If your AI system needs EHR data from Germany, France, and Spain for adequate representativeness, you need separate permits from each country's HDAB. HealthData@EU can streamline this through the single entry point mechanism, but the underlying legal basis is still per-Member State.

Fix: Use the HealthData@EU catalogue to identify which countries have the data you need. Apply early — HDAB permit timelines can be 3-6 months per country in the early implementation period.

Timeline and Applicability Dates

Practical implication: EHDS secondary use infrastructure is not yet fully operational (2027). In the interim, AI developers accessing EU health data for training must rely on existing Member State frameworks (research ethics approvals, national health data authorities) while HDAB infrastructure is being established. Plan EHDS compliance processes now to be ready when HDABs go live.

Summary: The Three-Layer Compliance Stack for Health AI

A clinical AI system built on EU health data faces a three-layer compliance stack:

Layer 1 — Data Access (EHDS): Obtain HDAB permit → process in secure processing environment → export only permitted outputs

Layer 2 — AI System Safety (EU AI Act): Risk management (Art. 9) → data governance (Art. 10) → technical documentation (Art. 11) → logging (Art. 12) → transparency (Art. 13) → human oversight (Art. 14) → accuracy/robustness (Art. 15) → conformity assessment (Art. 43) → CE marking (Art. 49) → registration (Art. 71)

Layer 3 — Medical Device (MDR/IVDR, if applicable): CE marking → notified body assessment → clinical evaluation → post-market surveillance

Layers 1 and 2 apply to most health AI. Layer 3 applies when the AI is or interfaces with a medical device.

Start with Layer 1 — EHDS compliance gates your data access and is a prerequisite for Art. 10 documentation. Without an HDAB permit, you do not have compliant access to health training data, and without compliant training data, you cannot satisfy Art. 10, and without Art. 10, you cannot complete conformity assessment.

The good news: EHDS quality infrastructure (Art. 33 labels, FHIR-standardised datasets, HealthData@EU catalogues) is designed to reduce the operational cost of Art. 10 compliance once it is fully operational. The EU is, deliberately, making compliant health AI data access easier than fragmented pre-EHDS workarounds — provided you engage with the process correctly.

See Also:

• EU AI Act Art.6 — High-Risk AI Classification and Annex III — Art.6 and Annex III Point 5 define which health AI systems trigger the full Art.9–15 compliance stack; the healthcare categories (5a medical devices, 5b clinical decision support) are the direct basis for the dual-regulation burden this guide addresses
• EU AI Act Art.8 — Compliance Requirements for High-Risk AI — Art.8 is the gateway that activates Arts.9–15 once Annex III classification is confirmed; health AI entering the EHDS pipeline will trigger all seven requirements
• EU AI Act Art.10 — Data Governance and Training Datasets — Art.10 data quality obligations run in parallel with EHDS Art.33 dataset labels; this post maps where the two frameworks overlap and where they create additive documentation burdens
• EU AI Act Art.43 — Conformity Assessment: Internal Control vs Notified Body — Annex III 5(a) medical device AI requires notified body assessment; this guide covers how EHDS HDAB permit documentation feeds into the Art.43 conformity assessment evidence package