Vendor track · Module 6 · 50 min
Add the EU AI Act Layer
Three questions kept apart — the MDR/IVDR question, the AI Act question, and what can serve both: provider, deployer and value-chain roles, the Article 6 routes into the high-risk regime, the transparency and general-purpose layers that apply independently, and the reuse/extend/new map — ending in a learner-authored AI Act Overlay with an explicitly preliminary high-risk hypothesis.
After this module you can
Work out which AI Act questions your product actually raises, which of your medical-device work can carry part of the answer, and which obligations are genuinely new.
- Explain why AI Act classification and MDR/IVDR classification are different questions
- Identify which actor role or roles your organisation may hold
- Describe the Article 6(1) product route conceptually, including the third-party assessment condition
- Recognise the AI Act layers that can apply regardless of high-risk status
- Map the high-risk requirement families onto the medical-device work you already do
- Distinguish reusable evidence from merged obligations
- Write an overlay a legal or regulatory specialist can review
You now have the regulatory obligations mapped across two frameworks. Module 7 builds the operating system that keeps them true as the product, the model and the suppliers change.
This course is educational decision support for vendors and is not legal advice. It structures regulatory reasoning and produces learner-authored working positions. It does not tell you whether your product is a medical device, whether MDR or IVDR applies, what class it is, which conformity route applies, whether a notified body is required, or whether your AI system is high-risk under the AI Act, and it produces no compliance or readiness score. It does not replace a competent regulatory review. MDCG and AI Board guidance is cited throughout because it is the practical reference practitioners use, but it is not binding law: only the regulations themselves bind, and only the Court of Justice of the European Union gives binding interpretations of them. Regulatory basis reviewed: 18 September 2026.
Step 1
Two regulations, two separate questions
Three questions, kept apart: the MDR/IVDR question you answered in Modules 2–4, the AI Act question you answer here, and what evidence or control can serve both. The most expensive misunderstanding in health AI is treating the second as a section of the first.
They are separate legal instruments with separate scope questions, definitions and obligations. A product can be in scope of both, one, or neither. Being high-risk under the AI Act does not change your MDR or IVDR class, and your class is not an AI Act classification. The relationship runs one way, in one place: the product-route analysis asks whether the AI system is a product, or a safety component of a product, covered by listed Union harmonisation legislation and required to undergo a third-party conformity assessment under it. There, your classification and conformity route become inputs.
So “we are already MDR compliant, so the AI Act is covered” is wrong in both directions. The engineering discipline overlaps, which genuinely helps — but the AI Act adds requirement families the MDR does not frame the same way, and it reaches systems that are not devices at all. The joint MDCG and AI Board guidance is the practical reference for the interaction; use it to structure the question, not as a verdict.
The MDR / IVDR question
- Is this a device, and if so what class and conformity route? Answered in your Modules 2–4 artefacts.
The AI Act question
- Is this an AI system, what is your role in the value chain, and does any route or layer of the Act reach it?
What can serve both
- Risk management, data governance, logging, technical documentation and post-market monitoring. Reuse is allowed where requirements genuinely coincide — it is not automatic.
Your product: Can sit in both, one, or neither. Status under one instrument never decides the other.
Four sentences you will hear, and what is wrong with each
“Our MDR class makes us high-risk under the AI Act.”
Different questions. The device classification is an input to one specific AI Act route analysis, not the answer to it.
“We are high-risk under the AI Act, so our device class goes up.”
AI Act status does not alter MDR or IVDR classification.
“We are not a medical device, so the AI Act does not apply.”
The AI Act has routes and layers that are independent of medical-device status entirely.
“We already have a technical file, so AI Act documentation is done.”
Substantial overlap exists and can be reused, but the requirement families are not identical.
Application dates, as of 18 September 2026Useful for planning. Never assessed, and always worth re-checking at source.
2 December 2027
Application date for the high-risk obligations reached through the Annex III listed-use-case route, following the amendments to the AI Act's transitional timing.
2 August 2028
Application date for the high-risk obligations reached through the Article 6(1) product route, which is the route most relevant to regulated medical devices.
Dates as of 18 September 2026, read from the consolidated AI Act text and the Commission's published timeline. The AI Act's transitional provisions have already been amended once, so treat any date you are planning against as something to re-verify in the official sources before you commit to it. You are not expected to memorise these dates, and they are never assessed in this course.
0 of 7 steps complete
- A · Product boundary — Not written yetNot written yet
- B · Workflow and context — Not written yetNot written yet
- C · Claims inventory — Not written yetNot written yet
- D · Draft intended purpose — Not written yetNot written yet
- E · Qualification assessment — Not written yetNot written yet
- F · Classification position — Not written yetNot written yet
- G · Conformity strategy — Not written yetNot written yet
- H · Clinical evidence plan — Not written yetNot written yet
- I · EU AI Act overlay — Not written yetNot written yet
- J · QMS and lifecycle plan — Not written yetNot written yet
Your own writing, section by section. Nothing here is scored, and no section states device status, a class, a route or readiness.
Sources & evidence · 8 sources
This module cites primary legal, public or consensus guidance.
Content reviewed: September 2026. Publication dates of the individual sources are shown in each citation.
Regulation (EU) 2017/745 (MDR), consolidated text 02017R0745 — 19.07.2026
Article 2(1) and 2(12) definitions; Article 10 manufacturer obligations; Article 15 PRRC; Article 52 and Annexes IX–XI conformity assessment; Article 61 and Annex XIV clinical evaluation; Annex II technical documentation; Annex VIII implementing rules and Rule 11.
Open sourceRegulation (EU) 2017/746 (IVDR), consolidated text 02017R0746 — 10.01.2025
Article 2(2) in-vitro diagnostic definition and Article 2(4) accessory definition.
Open sourceRegulation (EU) 2024/1689 (AI Act), consolidated text — 27.07.2026
Article 3 definitions and actor roles, Article 6 high-risk classification routes, Articles 8–15 requirements for high-risk AI systems, Article 25 value-chain responsibilities and the transitional provisions.
Open sourceMDCG 2019-11 rev.1, Qualification and Classification of Software in MDR and IVDR — June 2025
Figure 1 and Figure 2 decision sequences, §3.1–3.3, §4.2.1, Annex II examples and Annex IV classification examples.
Open sourceMDCG 2021-24 rev.1, Guidance on classification of medical devices — April 2026
Supplementary Rule 11 teaching examples. Used as illustrative context, not as a determination.
Open sourceMDCG 2020-1, Clinical evaluation of medical device software
Valid clinical association, technical performance and clinical performance as the structure of a software evidence plan.
Open sourceMDCG 2025-10, Post-market surveillance guidance
Used for the surveillance, PMCF and vigilance loop taught in Module 7.
Open sourceMDCG 2025-6 / AIB 2025-1, interplay between the MDR/IVDR and the AI Act
Used for how the two frameworks sit alongside each other, including integrated documentation and conformity work.
Open source