The EU AI Act for Medical Devices: Core Requirements
By Vaclav Vlcek, MD
[Part 1] settled where a medical device lands: high-risk under Article 6(1) and Annex I, with the manufacturer as provider. This part covers what that classification costs in practice.
The Act attaches a defined set of requirements to a high-risk system. For a medical-device maker, the useful news is that most of them overlap with duties the MDR, IVDR, ISO 13485, and IEC 62304 already impose. The work is mostly extending the compliance system that already exists.
In short: A high-risk AI medical device must meet requirements for risk management, data governance, technical documentation, logging, transparency, human oversight, accuracy, robustness, cybersecurity, and post-market monitoring.
Most map onto existing MDR, IVDR, ISO 13485, and IEC 62304 obligations, and under Article 17(3) the Act's quality management system can be built into the ISO 13485 system a manufacturer already runs. Conformity is assessed by a Notified Body and, under Article 43, can in most cases run through the existing MDR or IVDR procedure.
What the Act Requires of a High-Risk Medical Device
The classification comes from the MDR or IVDR, but the requirements that follow are the Act's own.
A provider has to run a risk-management system, govern its training and test data, keep technical documentation and automatic logs, make the system transparent to deployers, build in human oversight, and meet thresholds for accuracy, robustness, and cybersecurity.
It then has to pass conformity assessment, issue an EU declaration of conformity, affix the CE marking, register the system, and operate post-market monitoring.
The table below maps each requirement to its article in the Act and to the nearest MDR anchor, so a manufacturer can see what is genuinely new against what already exists.
| Requirement | AI Act | MDR anchor | What it means |
|---|---|---|---|
| Risk management | Article 9 | Article 10(2) | A documented, ongoing process to identify and mitigate AI-specific risks across the lifecycle, aligned with MDR/IVDR safety principles |
| Data and data governance | Article 10 | — | Training, validation, and test data that is relevant, representative, and as free of error and bias as possible |
| Technical documentation | Article 11 | Article 10(4), Annex II | Architecture, training and validation methods, data sources, performance metrics, and explainability, folded into the MDR/IVDR technical file |
| Automatic logging | Article 12 | — | Event logs generated automatically during operation, available for audit and post-market surveillance |
| Transparency to deployers | Article 13 | Article 10(11) | Clear information on purpose, limitations, performance, and the human-oversight role |
| Human oversight | Article 14 | — | Design that allows meaningful human intervention to prevent or reduce risk |
| Accuracy, robustness, cybersecurity | Article 15 | Annex I | Consistent performance, resilience to failure and attack, reliable output under stress |
| Quality management system | Article 17 | Article 10(9), Annex IX | A QMS covering the AI lifecycle, integrated with the MDR/IVDR QMS |
| Conformity assessment | Article 43 | Article 10(6), Article 52 | Assessment before market access, run through the MDR/IVDR procedure by the Notified Body |
| EU declaration of conformity | Article 47 | Article 10(6) | A written declaration of compliance before placing on the market |
| CE marking | Article 48 | Article 10(6) | CE marking to show conformity with the Act and other applicable law |
| Registration | Article 49 | Article 10(7) | Registration of the system in the EU database before market or service |
| Corrective action and information | Article 20 | Article 10(12) | Corrective action and notification when a system presents a risk or falls out of compliance |
| Deployer obligations | Article 26 | — | Duties that fall on the deployer, not the provider: human oversight in use, use per the instructions, and monitoring of operation |
| Post-market monitoring and incidents | Articles 72–73 | Article 10(10), (12), (13) | A monitoring system for real-world performance, with serious-incident reporting and corrective action |
Table 3: Requirements for a high-risk AI medical device, mapped to the AI Act and the MDR.
Two rows in this table are commonly mixed up. Registration of a high-risk system sits under Article 49, and for a medical device it can complement the EUDAMED entry.
Article 26 covers something else entirely: the deployer's duties, such as human oversight in use and monitoring. Keeping the two apart avoids a common misreading.
How the Requirements Land on SaMD
Software as a Medical Device is where the two regimes press together most tightly, because the software is the product. A SaMD that meets the definition of a medical device and undergoes third-party conformity assessment is high-risk under Article 6(1) and Annex I, so it carries the MDR's safety and performance duties and the Act's AI-specific ones at the same time.
In effect, the MDR's Annex I general safety and performance requirements gain a supplement: the Act's requirements on data governance, human oversight, and robustness (Articles 10, 14, and 15).
For quality management, the point is integration. ISO 13485 is the harmonised QMS standard under the MDR, and Article 17(3) of the Act lets a provider that already runs a sectoral QMS fold the Act's QMS elements into it. The Medical Device Coordination Group confirmed the same route in its guidance (MDCG 2025-6).
In practice, a manufacturer extends its ISO 13485 QMS to cover data governance, algorithm risk, lifecycle monitoring, and change control.
IEC 62304 is where the software lifecycle work shows up. The standard already handles software safety and traceability, and the Act adds a layer for the AI-specific parts.
That layer covers control of training and validation data, automatic logging during operation (Article 12), bias detection and explainability, and monitoring of the system's behaviour and updates in the field. Field updates carry their own rule: post-market monitoring runs under Article 72, and an update that counts as a substantial modification triggers a fresh conformity assessment under Article 43(4).
The software lifecycle file grows accordingly. It now holds AI-specific artifacts: model version history, dataset characteristics and governance, and any limits placed on self-learning behaviour.
The through-line for a SaMD manufacturer: the Act extends the MDR, ISO 13485, and IEC 62304, and all three stay fully in force. Compliance comes from folding the AI-specific documentation and controls into the design, development, QMS, and post-market processes early, and from working with the Notified Body toward a single, unified assessment.
Where the Act and the MDR Meet
The Act and the MDR are built to run together, each covering a different dimension of the same device. Five intersections carry most of the practical weight.
Classification lines up first. An AI-enabled medical device is high-risk under Article 6(1) and Annex I of the Act, which sits alongside the MDR's own classification under Article 51, where classes IIa, IIb, and III set the conformity-assessment route.
Risk management is the second point of contact. Article 9 of the Act calls for AI-specific risk management that complements the MDR's requirements in Annex I, Chapter I.
Technical documentation is the third, with Article 11 of the Act adding AI-specific content on top of the MDR's Annex II file.
Post-market surveillance is the fourth. The Act requires continuous monitoring under Article 72, with serious-incident reporting under Article 73, aligning with the MDR's post-market surveillance duties in Articles 83 to 86.
Conformity assessment is the fifth, and the most useful. Article 43 allows a single assessment covering both regimes, run through the MDR procedure in Article 52.
What Comes Next
A manufacturer that has worked through this part knows the requirement set, knows that most of it extends the MDR and ISO 13485 systems already in place, and knows the assessment can run as one exercise with the Notified Body.
Meeting the requirements on paper is the straightforward half. Building an AI-enabled device and a quality system a team can actually run, and keep running as the model changes in the field, is the half that lasts.
Part 3 turns outward, to how the Act meets the other regimes a manufacturer answers to: the MDR at the level of detail, the GDPR for the data underneath the model, and the U.S. FDA for companies serving both markets, followed by a practical compliance path. [Internal link: descriptive anchor to Part 3]
Frequently Asked Questions
What does the EU AI Act require for a high-risk medical device?
Risk management, data governance, technical documentation, automatic logging, transparency to deployers, human oversight, and thresholds for accuracy, robustness, and cybersecurity, followed by conformity assessment, an EU declaration of conformity, CE marking, registration, and post-market monitoring. These are set out across Articles 9 to 21, 43 to 49, and 72 to 73.
Can the AI Act quality management system be merged with an ISO 13485 QMS?
Yes. Article 17(3) lets a provider that already runs a sectoral QMS include the Act's QMS elements within it, and MDCG 2025-6 confirms the same for MDR quality systems. In practice a manufacturer extends its ISO 13485 system to cover data governance, algorithm risk, lifecycle monitoring, and change control.
Does the AI Act require a separate conformity assessment from the MDR?
Not usually. Under Article 43, a medical device high-risk under both regimes can be assessed once, through the existing MDR or IVDR procedure carried out by the Notified Body.
Who registers a high-risk AI medical device, and under which article?
Registration in the EU database is required under Article 49, and for a medical device it can complement the EUDAMED entry. Article 26, which is sometimes cited for this, actually sets the deployer's in-use obligations, not registration.
