Part 2: EU AI Act Core Requirements for Medical Devices

By Vaclav Vlcek, MD

Part 1: Regulatory Foundations and Scope covered classification: an AI-enabled medical device is high-risk under Article 6(1) where the AI is a safety component of, or itself is, a product covered by Annex I, Section A legislation such as the MDR or IVDR, and that product requires third-party conformity assessment, subject to Article 6(1c). This part covers what meeting that classification costs in practice.

The Act attaches a defined set of requirements to a high-risk system. Many of them overlap with duties the MDR and IVDR already impose and with controls that ISO 13485 and IEC 62304 already address, so much of the work is extending the compliance system a manufacturer already runs rather than building a parallel one.

Summary

A high-risk AI medical device must meet requirements for risk management, data governance, technical documentation, logging, transparency, human oversight, accuracy, robustness and cybersecurity, together with a quality management system, conformity assessment and post-market monitoring.

Many map onto existing MDR and IVDR obligations and onto the standards-based framework of ISO 13485 and IEC 62304, and under Article 17(3) the Act's quality management system can be built into the existing MDR or IVDR quality management system, which is commonly structured around EN ISO 13485. Under Article 43(3) the Section 2 requirements and the assessment of the Article 17 quality management system form part of the applicable MDR or IVDR conformity-assessment procedure.

The operative post-market monitoring and incident-reporting duties arise independently under Articles 72 and 73. Their procedures are not wholly outside the integrated assessment, though: Article 17(1)(h) and (i) require the quality management system to include the post-market monitoring system and the serious-incident reporting procedures, and assessment of that QMS forms part of the sectoral procedure under Article 43(3). Chapter III, Sections 1 to 3 (except Article 6(5)) apply from 2 August 2028 to systems classified solely through Article 6(1), subject to Article 111; Annex III must be assessed separately.

Other parts of the Regulation have applied earlier, so that date should not be read as switching on the whole Act. By 2 August 2027 the Commission must also adopt delegated acts under Article 2(13) that may limit specified obligations in Articles 9 to 15 and 17 to 25 on two cumulative conditions: that Annex I Section A legislation provides equivalent or higher protection, and that the limitation does not reduce the overall level of protection the Act provides. None was in force as at 10 August 2026, so no present relief should be assumed.

What the Act Requires of a High-Risk Medical Device

The applicable MDR or IVDR third-party conformity-assessment requirement, not the class label by itself, may satisfy Article 6(1)(b). The requirements that follow are the Act's own.

Once the relevant Chapter III provisions apply, a provider has to run a risk-management system, govern the applicable training, validation and testing data, draw up and keep technical documentation up to date, ensure an automatic logging capability, make the system transparent to deployers, build in human oversight, and achieve appropriate levels of accuracy, robustness and cybersecurity. Those are the Section 2 requirements.

Around them sit the operator obligations in Section 3, Articles 16 to 27, including the quality management system under Article 17 and the retention of logs under the provider's control under Article 19. Conformity assessment, the declaration of conformity, CE marking and registration follow in Section 5, Articles 40 to 49. Post-market monitoring and incident reporting sit separately again, in Chapter IX, Articles 72 and 73.

The table below maps the central requirements to their article in the Act and to the nearest MDR and IVDR anchors. It is not an exhaustive account of every obligation in Articles 16 to 27. Where there is no sufficiently close sectoral counterpart, the row is marked "—".

Table 1: Requirements for a high-risk AI medical device, mapped to the AI Act and the MDR/IVDR. AI Act references are to Regulation (EU) 2024/1689 as amended by the Digital Omnibus, Regulation (EU) 2026/1744; sectoral references are to the MDR and IVDR.

Two rows repay a closer look. Article 49 registration is narrower than it is often taken to be: it principally covers Annex III systems and providers claiming the Article 6(3) derogation, and it does not generally require a system classified solely through Article 6(1) to be entered in the AI Act database.

Two qualifications. MDR and IVDR registration continues separately and is not displaced: EUDAMED's actor, UDI and device, and notified body and certificate modules have been mandatory since 28 May 2026, with the market surveillance module mandatory for competent authorities and the Commission (Commission EUDAMED overview); the vigilance and the Clinical Investigations and Performance Studies modules are not yet mandatory. And EUDAMED is not a substitute for AI Act registration where the same system independently falls within Annex III: in that case Article 49 has to be assessed in addition.

Article 26 is a different thing again: it sets the deployer's duties, such as human oversight in use and monitoring. Article 26(8) requires deployers that are public authorities or Union institutions, bodies, offices or agencies to comply with Article 49; it does not establish a separate registration regime. Article 49(3) is the operative provision, and it requires those deployers, and persons acting on their behalf, to register covered Annex III systems other than those in Annex III point 2. It adds no AI Act database obligation for a system classified solely through Article 6(1).

Three requirements carry the most new work. The MDR and IVDR already cover clinical and performance data, software lifecycle controls, usability, risk management, technical documentation and post-market surveillance, so these are not wholly new territory. What the Act adds is more explicit and prescriptive AI-specific control.

Example: human oversight (Article 14). The duty is to build in appropriate and proportionate capacity for an oversight person to monitor operation, interpret output, disregard or override it, and intervene or stop the system. A triage tool that silently reorders a patient queue may well fail that, if effective oversight is absent, though whether it does depends on the complete design and the deployment arrangements. Giving a clinician visibility of the ranking basis, and a recorded override, is a practical way to evidence the capacity rather than a literal statutory requirement.

Risk management and cybersecurity are the opposite case: much is already in place. The Article 9 risk-management duty can be integrated with the EN ISO 14971 processes a manufacturer already runs, and the Article 15 cybersecurity work can build on IEC 81001-5-1, rather than starting either from nothing. EN ISO 14971:2019 with A11:2021 is cited in the Official Journal under the MDR and IVDR; EN 62304 and EN IEC 81001-5-1 are not currently in those lists.

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. Where the AI system is itself the SaMD, it satisfies Article 6(1)(a) without relying on safety-component status. Where AI is only a component of broader medical-device software, the safety-component analysis remains necessary. It is high-risk through Article 6(1) only where Article 6(1)(b) is also satisfied, subject to Article 6(1c), so a self-declared Class I standalone device is not automatically high-risk. Where both conditions do hold, the device carries the applicable MDR or IVDR safety and performance duties and the Act's AI-specific ones at once.

The Act operates alongside the applicable MDR or IVDR Annex I general safety and performance requirements rather than amending them, adding its own duties on data governance, human oversight and robustness (Articles 10, 14 and 15).

For quality management, the point is integration. Article 17(3) of the Act lets a provider that already runs a sectoral QMS fold the Act's QMS elements into it. The reference is to the MDR or IVDR quality management system, commonly structured around EN ISO 13485 (cited in the Official Journal in the 2016 edition with AC:2018 and A11:2021) rather than to any standard by name. The joint MDCG and AI Board guidance reaches the same conclusion (MDCG 2025-6). That guidance is the latest officially listed joint guidance on the interplay, but it is non-binding, dated 19 June 2025, and published before the Digital Omnibus, so it is outdated wherever its dates or legal propositions conflict with the amended Regulation.

In practice, a manufacturer extends its ISO 13485 QMS to cover data governance, algorithm risk, lifecycle monitoring, and change control.

Example: A manufacturer with an established ISO 13485 system does not open a second quality manual. It adds procedures for dataset approval and versioning, defines who signs off a model change, and extends its existing design-control and change-control processes to cover retraining. The audit trail and document control it already runs carry the new records.

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. If the standard itself is unfamiliar ground, we cover it from the beginning in IEC 62304 - Getting Started.

That layer covers control of training and validation data, the automatic logging capability under Article 12, examination and mitigation of possible bias, the transparency and interpretation information required where applicable, 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).

Example: a field update. A manufacturer ships a monthly model refresh trained on new data. Where the change was predetermined by the provider at the initial conformity assessment and included in the Annex IV technical documentation, and the system is one that continues to learn after being placed on the market, the refresh is not a substantial modification. It remains subject to documented change control, the technical documentation and Article 72 monitoring. The test for the other direction is narrower than it looks. Where a post-market change was not foreseen or planned in the initial conformity assessment, and it either affects the AI system's compliance with the Section 2 requirements or modifies the assessed intended purpose, it constitutes a substantial modification and a new conformity assessment is required through the applicable sectoral procedure. Moving outside an assessed performance envelope is a strong warning sign rather than the test itself.

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 technical documentation is where most of that lands.

The through-line for a SaMD manufacturer: the AI Act and the applicable sectoral Regulation, the MDR or the IVDR, are binding law and continue to apply. The standards sit differently. EN ISO 13485:2016 with AC:2018 and A11:2021, and EN ISO 14971:2019 with A11:2021, are currently cited in the Official Journal under the MDR and IVDR, so conformity with them confers a presumption of conformity for the requirements they cover. EN 62304 and EN IEC 81001-5-1 are not in the current lists, and standards remain voluntary in any case. Compliance comes from folding the AI-specific documentation and controls into the design, development, QMS and post-market processes early, and from bringing that evidence into the sectoral assessment rather than running a second one.

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 is the first point of contact, and the two regimes classify separately. An AI-enabled medical device is high-risk under Article 6(1) with Annex I, Section A where both conditions are met. The MDR classifies under Articles 51 and 52, and what matters for Article 6(1)(b) is not the class label but whether third-party conformity assessment is legally required for that device. Classes IIa, IIb and III involve a notified body, and so do Class I devices placed on the market sterile, having a measuring function, or constituting reusable surgical instruments, though there the involvement is limited to the sterility, metrology or reuse aspects. It is the applicable third-party conformity-assessment requirement, not the class label by itself, that may satisfy Article 6(1)(b). MDR classification does not determine AI Act status, and a system may separately meet the Annex III 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, and it carries a carve-out that is easy to miss. The Act requires post-market monitoring under Article 72. Under Article 72(4) that monitoring may be integrated into the existing MDR or IVDR post-market surveillance systems and plans, provided an equivalent level of protection is achieved.

Serious-incident reporting works differently for medical devices. Under Article 73(10), for devices covered by the MDR or IVDR the AI Act reporting duty is limited to incidents within Article 3(49)(c), infringements of Union-law obligations protecting fundamental rights, and those go to the nationally designated authority. Device health-and-safety events must be assessed against the applicable MDR or IVDR vigilance criteria: MDR Article 87 and the wider vigilance provisions, or IVDR Article 82.

That narrowing is not a general no-double-reporting rule. Where an event independently satisfies both Article 3(49)(c) and the applicable MDR or IVDR vigilance criteria, both reporting duties may need to be considered. Each trigger is assessed separately.

Conformity assessment is the fifth, and the most useful. Under Article 43(3) the Section 2 requirements and the assessment of the Article 17 quality management system form part of the applicable sectoral procedure (MDR Article 52 or IVDR Article 48) rather than running as a second exercise. The Article 72 and 73 duties arise independently, but their procedures are drawn into the integrated assessment through the quality management system required by Article 17(1)(h) and (i).

Article 43(3) preserves the sectoral assessment choices, so whether a notified body is involved follows from the MDR or IVDR. Where one is involved, the Article 43(3) competence and designation conditions apply in addition. A body already notified under the MDR or IVDR may perform the assessment only where the existing sectoral notification has checked and evidenced that it meets the requirements of Article 31(4), (5), (10) and (11). The Annex I Section A notified bodies to which Article 43(3) refers must apply for designation under the Act by 28 January 2028, which is a deadline to apply rather than to hold designation.

Example: A manufacturer placing a new Class IIb SaMD on the market after the applicable date, or making significant changes in the design of an existing type or model from that date so that Article 111(2) applies, brings its AI Act evidence (the data governance file, the logging design and the human-oversight rationale) into the applicable sectoral conformity-assessment submission. The result is an integrated sectoral conformity-assessment process and a single technical-documentation set. Scheduling and how the audit is actually run remain matters for the notified body, so Article 43 does not by itself guarantee one audit cycle instead of two.

What Part 2 Establishes, and What Comes Next

A manufacturer that has worked through this part knows the requirement set, knows that much of it extends the MDR and ISO 13485 systems already in place, and knows that the Section 2 requirements and the Article 17 QMS assessment enter through the sectoral assessment rather than beside it.

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: Cross-Regulatory Intersections and Practical Compliance 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.

Frequently Asked Questions

1. What does the EU AI Act require for a high-risk medical device?

   • The Section 2 requirements are risk management, data governance, technical documentation, automatic logging, transparency to deployers, human oversight, and appropriate levels of accuracy, robustness and cybersecurity. Section 3 (Articles 16 to 27) holds the operator obligations including the Article 17 quality management system; Section 5 (Articles 40 to 49) holds conformity assessment, the declaration, CE marking and registration; and Chapter IX (Articles 72 and 73) holds post-market monitoring and incident reporting, with the Article 73(10) carve-out for MDR and IVDR devices.

     On timing: Article 113 assigns 2 December 2027 to the Article 6(2) and Annex III route and 2 August 2028 to the Article 6(1) and Annex I route. Where only one route applies, the date is clear. The Regulation does not expressly resolve the date where both routes independently apply.

2. Can the AI Act quality management system be merged with an ISO 13485 QMS?

   • Yes. Article 17(3) lets a provider that already runs an MDR or IVDR quality management system, commonly structured around EN ISO 13485, include the Act's QMS elements within it, and MDCG 2025-6 confirms the same for MDR and IVDR quality systems. In practice a manufacturer extends its ISO 13485 system to cover data governance, algorithm risk, lifecycle monitoring, and change control.

3. Does the AI Act require a separate conformity assessment from the MDR?

   • Not as a separate exercise. Under Article 43(3) the Section 2 requirements and the Article 17 quality-management-system assessment form part of the applicable MDR or IVDR procedure; the Article 72 and 73 duties arise independently, though their procedures are assessed through the Article 17(1)(h) and (i) quality management system. Article 43(3) preserves the sectoral assessment choices, so whether a notified body is involved follows from the MDR or IVDR, though for a qualifying Article 6(1) device one ordinarily will be. Where one is involved, the Article 43(3) competence and designation conditions apply in addition.

4. Does a high-risk AI medical device have to be registered in the AI Act database?

   • Generally no, where it is classified solely through Article 6(1). Article 49 registration principally covers Annex III systems and providers claiming the Article 6(3) derogation. MDR and IVDR registration continues separately and is not displaced by that. But where the same system independently falls within Annex III, Article 49 must be assessed in addition; EUDAMED is not a substitute for it. Article 26, sometimes cited for registration, actually sets the deployer's in-use obligations. Article 26(8) requires deployers that are public authorities or Union institutions, bodies, offices or agencies to comply with Article 49 rather than creating its own regime; Article 49(3) is the operative provision and covers those deployers and persons acting on their behalf, for covered Annex III systems other than those in Annex III point 2.