Does the EU AI Act apply to a hospital outside the EU treating EU patients?

The territorial scope under Article 2 applies where the provider or deployer is established in the EU, or where the output of the AI system is used in the EU. A US hospital treating an EU patient who is physically in the US is generally outside scope. A US health system operating EU subsidiaries that deploy AI for those EU patients is in scope for those EU deployments. Telemedicine arrangements where the AI output is used to make a decision affecting a person in the EU may bring the deployment in scope depending on the specific facts. The conservative architectural approach is to maintain the per-case audit records on any AI workflow that touches EU patients, regardless of where the system runs.

How does MDR conformity assessment integrate with EU AI Act conformity assessment for SaMD?

For software-as-a-medical-device that is high-risk under both MDR and the EU AI Act, the conformity assessment integrates. The notified body assessment under MDR includes the AI Act obligations for the AI components. The technical documentation, the quality management system, and the post-market surveillance plan address both regimes. The provider does not run two separate assessments. The hospital deploying the device, however, has separate deployer-side obligations under each regime.

What is the inspection layer's role when the hospital is the deployer of a vendor's CE-marked AI?

The hospital is the deployer under Article 26 even where the AI is CE-marked by a vendor. The inspection layer produces the hospital-side evidence that the Article 26 monitoring expectation, the Article 19 log retention expectation, the Article 14 human oversight evidence, and the incident notification framework all sit on. The vendor's conformity assessment evidence does not substitute for the hospital's deployer-side evidence. Where the vendor's logs from the AI system are accessible to the hospital, the hospital can use them in combination with the inspection-layer records. Where the vendor's logs are not accessible or do not preserve the hospital-side context (clinician identity, patient pseudonym, hospital workflow stage), the inspection layer is the only source of the hospital-side evidence.

Does the Annex III emergency triage category apply to all hospital triage AI?

Annex III point 5(d) covers AI for dispatching or establishing priority in dispatching emergency first response services, including ambulances and emergency medical patient triage. The text covers triage in the emergency-response context: ambulance dispatch, ED arrival triage where the AI makes or supports the triage assignment. Non-emergency triage (routine appointment scheduling, internal-clinic prioritization) generally falls outside this specific Annex III category but may still attach to other high-risk categories depending on the use. The hospital's classification documentation under Article 6 has to address each AI use case individually.

How does the architecture support GDPR Article 22 automated-decision protections?

GDPR Article 22 gives the data subject the right not to be subject to a decision based solely on automated processing that produces legal or similarly significant effects, with specified exceptions and additional protections. The inspection-layer records support the hospital's response to data subject rights requests under Article 22 by providing the per-decision evidence of what data the AI received, what classification the AI produced, and what human-review step followed. The records also support the hospital's information obligation under Articles 13 and 14 by evidencing the use of AI in the processing.

← Blog

May 23, 2026

EU AI Act for Healthcare: What Articles 6, 12, and Annex III Require of Hospital AI Deployments

EU AI Act high-risk classification applies to several healthcare AI use cases including AI as a safety component of medical devices under Article 6(1) and the Annex III categories covering access to essential services, biometric categorization, and emergency triage. From August 2, 2026, hospitals deploying these AI systems take on deployer obligations under Article 26 and have to support providers in meeting Articles 8 through 17. The Medical Device Regulation and the EU AI Act layer for software-as-a-medical-device. The architecture that satisfies the high-risk regime is per-decision audit records that capture identity, data class, policy state, and decision outcome on the hospital side.

ByParminder Singh· Founder & CEO, DeepInspect Inc.

Industry Verticalshealthcareeu-ai-actmedical-devicesmdrai-compliancehospital-ai

EU AI Act for Healthcare: What Articles 6, 12, and Annex III Require of Hospital AI Deployments

The EU AI Act takes effect for high-risk systems on August 2, 2026. Several healthcare AI use cases fall inside the high-risk regime, either through Article 6(1) as safety components of medical devices regulated under the Medical Device Regulation, or through Annex III categories covering access to essential services, biometric categorization, and emergency triage. Hospitals and health systems operating across EU member states or treating EU patients in cross-border arrangements take on deployer obligations under Article 26 and have to support providers in meeting Articles 8 through 17. I want to walk through exactly which healthcare AI use cases the high-risk regime covers, what the operational obligations look like, and the inspection architecture that closes the evidence gap most hospital AI deployments carry today.

What healthcare AI is high-risk under the EU AI Act

The EU AI Act creates two paths to high-risk classification relevant to healthcare:

Article 6(1): safety component of a regulated product. AI is high-risk where it is intended to be used as a safety component of a product, or is itself a product, covered by EU harmonization legislation listed in Annex I. The Medical Device Regulation (Regulation (EU) 2017/745) and the In Vitro Diagnostic Medical Device Regulation (Regulation (EU) 2017/746) are listed. AI as software-as-a-medical-device (SaMD) under MDR, AI as a safety component of a hardware medical device, or AI integrated into in-vitro diagnostics all attach. The interaction with MDR conformity assessment is specific: the AI Act compliance integrates into the existing MDR conformity assessment for the device, with the notified body assessing both regimes together.

Article 6(2) and Annex III. AI is also high-risk where it falls into a category listed in Annex III. The categories most relevant to healthcare delivery are:

Annex III point 5(a): AI used by or on behalf of public authorities to evaluate eligibility for public assistance benefits and services, including healthcare services.
Annex III point 5(d): AI used to dispatch or establish priority in the dispatching of emergency first response services, including ambulance triage.
Annex III point 1(a): AI for remote biometric identification, where used in healthcare for patient identification at high-risk facilities.
Annex III point 1(c): AI for biometric categorization based on sensitive attributes, where used to infer protected characteristics from biometric data.

The classification is functional, not vendor-defined. A general-purpose AI used inside a triage workflow inherits the high-risk classification from the use case even if the underlying foundation model is not itself classified.

What the operational obligations look like

For a hospital deploying high-risk AI, the operational obligations track Article 26 deployer obligations and the provider obligations the hospital supports under Articles 8 to 17:

Article 26 deployer obligations. The deployer (the hospital, the health authority, the regional health service, or whoever places the system into service) has to:

Use the high-risk AI in accordance with the instructions for use the provider supplies.
Assign human oversight to natural persons with the required competence, training, and authority.
Monitor operation of the high-risk AI system and inform the provider of serious incidents and malfunctions.
Keep the automatically generated logs for at least six months under Article 19, provided they are under the deployer's control.
Inform affected natural persons that they are subject to the use of the high-risk AI where the system makes decisions about them.
Conduct a data protection impact assessment under GDPR Article 35 where applicable, with the AI Act conformity considered.

Article 12 and 19 logging. High-risk AI systems must automatically record events over the lifetime of the system. Article 19 specifies that the logs include period of use, reference databases checked, input data, and identification of natural persons involved in result verification. The records have to be retained for at least six months and accessible to competent authorities. For a hospital deploying an AI triage system, this means the hospital's records have to identify the triage clinician, the patient (or pseudonymous identifier), the input data the AI received, and the decision the AI returned, per case.

Article 13 transparency. The provider has to design the high-risk AI so the deployer can interpret outputs and exercise human oversight. The instructions for use have to describe characteristics, capabilities, limitations, intended purposes, level of accuracy and cybersecurity, and the use cases the system is and is not designed for. Generic model cards from a foundation model provider fail this test for a healthcare-specific use case.

Article 14 human oversight. The provider has to identify and provide the deployer with the means for natural persons to oversee the high-risk AI. For clinical AI, the human oversight is the clinician who reviews and accepts or overrides the AI's recommendation.

Article 17 quality management. Providers maintain a quality management system covering the AI system across its lifecycle. For a hospital that builds its own AI internally for a high-risk use case, the hospital is the provider and the quality management obligations apply to the hospital.

Where hospital AI deployments are exposed

The exposure pattern across hospitals running clinical AI, administrative AI, and patient-facing AI repeats:

The hospital is deploying a vendor AI system that is CE-marked under MDR as a medical device. The hospital has the conformity certificate, the instructions for use, and the post-market surveillance plan the vendor maintains. The hospital cannot produce, per case, the audit record of the input the device received, the output the device returned, and the clinician who accepted or overrode the output. Article 12 expects this record to exist automatically. Without the hospital-side inspection layer, the record sits inside the vendor's cloud and the hospital is dependent on the vendor's cooperation for any reconstruction.

The hospital is using a general-purpose AI service (Microsoft Azure OpenAI, Google Cloud AI, AWS Bedrock, Anthropic, or a clinical-AI wrapper that calls these services) for triage, prior authorization, summarization, or coding. The AI use case meets the Annex III definition for one of the high-risk categories (emergency triage dispatch, access to essential services). The hospital does not have a conformity assessment for the AI as deployed because the foundation model provider has not assessed this specific use case. The hospital is operating as the provider for the configured AI system and the provider obligations under Articles 8 to 17 apply.

The shadow AI pattern persists in hospital staff use of consumer AI for drafting clinical documents, communications, and decision-support queries. The 78% employee unauthorized AI use figure from Cloud Radix applies to hospital staff. PHI lands in services that do not have BAA-equivalent protections under EU data protection rules and that are not part of the hospital's AI inventory. The deployer-side obligations under Article 26 attach to the unsanctioned use as readily as to the sanctioned use, the hospital cannot inventory or oversee the use without the inspection layer.

The cross-border element adds the data transfer dimension. Hospital AI processing involving EU patient data sent to AI services hosted outside the EU faces the GDPR Article 44 transfer rules layered on top of the AI Act obligations. The hospital's data processing agreements with the AI vendors, the standard contractual clauses where applicable, and the data location commitments all sit alongside the AI Act compliance.

The inspection architecture that closes the gap

The architecture has the same shape as the architecture for any high-risk Annex III use case. Healthcare calibration adds PHI detection, integration with the EHR identity stack, and the specific data classes relevant to MDR-regulated devices.

Inline inspection sits at the HTTP AI request boundary between authenticated clinicians and any LLM endpoint, including foundation models behind clinical AI wrappers and MDR-regulated SaMD services. The inspection includes detection for patient identifiers, diagnoses, medications, procedures, lab values, imaging findings, biometric data, and free-text clinical narrative.

Identity attribution names the clinician (or the agent acting under clinician authority) behind each request. The identity record satisfies the Article 19 requirement that the log identify natural persons involved in result verification. For emergency triage AI where the triage decision happens quickly and the human-oversight check follows, the inspection layer captures the AI's input and output and the subsequent clinician decision in the linked audit chain.

Per-case audit records satisfy Article 12 and Article 19 expectations, the Article 26 deployer monitoring expectation, GDPR Article 30 records-of-processing expectations where applicable, MDR post-market surveillance evidence, and the hospital's incident notification framework. Each record contains timestamp, clinician identity, data class, AI system called, decision outcome, and a tamper-evident signature. Retention runs at the longer of the EU AI Act six-month floor, the MDR post-market clinical follow-up retention for the device class, the GDPR retention proportionate to the processing purpose, and the hospital's own medical record retention rules.

The hospital-side records support the conformity assessment evidence base for AI systems where the hospital is the provider (in-house AI for high-risk use cases). The records support the deployer-side evidence base for AI systems where the hospital is the deployer (vendor AI under conformity assessment by the vendor). The same infrastructure produces both.

Where this connects to the broader EU healthcare regulatory stack

The EU AI Act and MDR do not stand alone for healthcare AI in the EU. Other regimes apply:

GDPR governs the processing of personal data and adds Article 9 protections for health data. Article 22 protections for automated decision-making apply where the AI's output is the basis for a decision producing legal or similarly significant effects on the data subject.
The European Health Data Space Regulation (EHDS) creates rights and obligations around primary and secondary use of electronic health data, with implementation phasing through 2026 and beyond.
NIS2 applies to hospitals classified as essential entities, adding incident notification and supply-chain security obligations that interact with AI-related incidents.
Member-state-level laws elaborate on professional secrecy, medical confidentiality, and patient rights.
The HTA Regulation (Regulation (EU) 2021/2282) addresses health technology assessment for medicinal products and some medical devices.

The architecture that satisfies the EU AI Act produces records that contribute to GDPR Article 30 records-of-processing, EHDS access logs where applicable, NIS2 incident evidence, and MDR post-market surveillance. The infrastructure is shared; the vocabulary differs by regulator.

DeepInspect

This is the architecture DeepInspect was built to provide for EU healthcare AI compliance. DeepInspect sits inline between authenticated clinicians and any HTTP-based LLM endpoint, including foundation models behind clinical AI wrappers and MDR-regulated software-as-a-medical-device services. The inspection includes detection for patient identifiers, diagnoses, medications, procedures, lab values, imaging findings, biometric data, and free-text clinical narrative.

Every request produces a per-case audit record containing clinician identity, timestamp, data class, AI system called, decision outcome, and a tamper-evident signature. The records support EU AI Act Article 12 and Article 19 expectations, Article 26 deployer obligations, GDPR Article 30 records-of-processing, MDR post-market surveillance evidence, and the hospital's incident notification framework. For Chief Medical Information Officers, Data Protection Officers, and hospital CISOs facing the August 2, 2026 EU AI Act enforcement date layered onto in-force MDR, GDPR, NIS2, and EHDS obligations, the inspection layer is the architectural component that produces the evidence each regime expects from the same infrastructure. Book a demo today.

Frequently asked questions

Does the EU AI Act apply to a hospital outside the EU treating EU patients?: The territorial scope under Article 2 applies where the provider or deployer is established in the EU, or where the output of the AI system is used in the EU. A US hospital treating an EU patient who is physically in the US is generally outside scope. A US health system operating EU subsidiaries that deploy AI for those EU patients is in scope for those EU deployments. Telemedicine arrangements where the AI output is used to make a decision affecting a person in the EU may bring the deployment in scope depending on the specific facts. The conservative architectural approach is to maintain the per-case audit records on any AI workflow that touches EU patients, regardless of where the system runs.
How does MDR conformity assessment integrate with EU AI Act conformity assessment for SaMD?: For software-as-a-medical-device that is high-risk under both MDR and the EU AI Act, the conformity assessment integrates. The notified body assessment under MDR includes the AI Act obligations for the AI components. The technical documentation, the quality management system, and the post-market surveillance plan address both regimes. The provider does not run two separate assessments. The hospital deploying the device, however, has separate deployer-side obligations under each regime.
What is the inspection layer's role when the hospital is the deployer of a vendor's CE-marked AI?: The hospital is the deployer under Article 26 even where the AI is CE-marked by a vendor. The inspection layer produces the hospital-side evidence that the Article 26 monitoring expectation, the Article 19 log retention expectation, the Article 14 human oversight evidence, and the incident notification framework all sit on. The vendor's conformity assessment evidence does not substitute for the hospital's deployer-side evidence. Where the vendor's logs from the AI system are accessible to the hospital, the hospital can use them in combination with the inspection-layer records. Where the vendor's logs are not accessible or do not preserve the hospital-side context (clinician identity, patient pseudonym, hospital workflow stage), the inspection layer is the only source of the hospital-side evidence.
Does the Annex III emergency triage category apply to all hospital triage AI?: Annex III point 5(d) covers AI for dispatching or establishing priority in dispatching emergency first response services, including ambulances and emergency medical patient triage. The text covers triage in the emergency-response context: ambulance dispatch, ED arrival triage where the AI makes or supports the triage assignment. Non-emergency triage (routine appointment scheduling, internal-clinic prioritization) generally falls outside this specific Annex III category but may still attach to other high-risk categories depending on the use. The hospital's classification documentation under Article 6 has to address each AI use case individually.
How does the architecture support GDPR Article 22 automated-decision protections?: GDPR Article 22 gives the data subject the right not to be subject to a decision based solely on automated processing that produces legal or similarly significant effects, with specified exceptions and additional protections. The inspection-layer records support the hospital's response to data subject rights requests under Article 22 by providing the per-decision evidence of what data the AI received, what classification the AI produced, and what human-review step followed. The records also support the hospital's information obligation under Articles 13 and 14 by evidencing the use of AI in the processing.

← All posts