Module 9 · 95 min
Regulation & Governance
Know Which Rules Apply — and Turn Them into Decisions. Which rules actually apply to a proposed AI use, and how to turn that into decisions: AI Act classification and the current timeline, MDR/IVDR and software as a medical device, GDPR, EHDS, and an approval path with named owners rather than a committee maze.
- Treat regulation as a routing question — what is the intended use, who is the actor, what data is involved — rather than as a single yes/no gate applied after a system has been chosen.
- Recognise that one system can sit under several regimes at once, and that AI Act, medical-device, data-protection and national supervisory requirements apply in parallel rather than in sequence.
- Place a proposed use into the right AI Act category — prohibited practice, transparency obligation, Annex III high-risk, high-risk through the regulated-product route, or none of these — and state which facts the answer depends on.
- Use the current 2026 AI Act timeline, including the changed application dates for high-risk systems, instead of pre-2026 summaries that are now wrong.
- Distinguish the organisation's role as deployer from the provider role it can acquire by developing, rebranding or substantially modifying a system.
- Judge when software has a medical intended purpose and therefore a device route under MDR or IVDR, and understand what a change or new version can trigger.
- Separate the legal risk classification of an AI system from its clinical risk, and explain why a low legal classification is not a safety argument.
- Make the two data-protection decisions that most often go wrong: the Article 6 lawful basis together with the Article 9 condition, and the controller versus processor role — including why consent is frequently not the right basis in healthcare.
- Explain primary and secondary use under EHDS, the phased dates, and what an organisation can sensibly prepare now.
- Assemble a reusable regulatory and governance passport for any AI use case, and map each decision to a named owner and an evidence artefact.
- Design an approval path that is fast and predictable rather than a committee maze, and distinguish 'proceed', 'proceed with conditions' and 'clarify a fact first'.
Stated as of 28 August 2026
Regulatory content in this module is stated as of 28 August 2026 and reflects the AI Act timeline as amended by the 2026 digital omnibus package. Timetables, national implementation and guidance change; verify the current position against the primary sources in the references before any real decision. Nothing here is legal advice.
The medical-device route: MDR alongside the AI Act
Software can be a medical device. Whether it is depends on its intended medical purpose — what the manufacturer claims it does — and not on whether it contains a model, how sophisticated it is, or how it is marketed internally.
The practical consequence for a healthcare organisation is a duty of verification. Where a device is being acquired and used, the provider organisation is expected to satisfy itself that the product carries valid EU conformity for the purpose it is being used for. That is a check performed at acquisition and first use, not an assumption inherited from the sales deck.
The AI Act does not displace any of this. The Commission's Joint AI Board and MDCG guidance on the interplay exists precisely because the two frameworks apply simultaneously and complementarily, with overlapping but distinct requirements on documentation, risk management, data governance and post-market activity.
Is this software a medical device? Four tests
Is there a medical intended purpose?
Diagnosis, prevention, monitoring, prediction, prognosis, treatment or alleviation of disease, for an individual patient. Claims made in the instructions for use, the labelling and the marketing all count towards establishing the purpose.
Fictional: software that flags suspected haemorrhage on CT has one. Software that reorders a theatre list to reduce gaps does not.
Does it act on data about an individual patient?
Software supporting a decision about a specific person is more likely to be a device than software that reports aggregate operational statistics or supports service planning.
Fictional: a per-patient deterioration score is a candidate for device status; a monthly ward-level occupancy forecast generally is not.
Is it simply presenting or storing data?
Software that only stores, archives, communicates or losslessly displays data typically falls outside the device definition. Interpretation, calculation of a clinically meaningful output, or a recommendation changes the analysis.
Fictional: an image viewer that displays a scan is not a device on this basis; the same viewer with an automated lesion measurement that informs staging may be.
What does the manufacturer actually claim?
Intended purpose is set by the manufacturer, and organisations get into trouble by using a product beyond the claimed purpose. A tool CE-marked for triage prioritisation is not authorised for diagnosis merely because a clinician finds it useful for that.
Fictional: using the worklist prioritisation tool to justify not reporting a study at all would be use outside the intended purpose, with the risk transferring to the organisation.
Rule 11: why a self-certified class I claim deserves scrutiny
MDR Annex VIII Rule 11 is the classification rule for most medical software. It is why the sepsis case above should make you pause: decision-support software that informs diagnosis or treatment is rarely class I. Classification always depends on the manufacturer's intended purpose and on all applicable rules, but Rule 11 is the rule a claim like that must survive.
Class IIa — the general rule
Software intended to provide information used to take decisions with diagnosis or therapeutic purposes is generally class IIa, which requires a notified body.
Class III
Class III where those decisions may cause death or an irreversible deterioration of a person's state of health.
Class IIb
Class IIb where those decisions may cause serious deterioration of a person's state of health or a surgical intervention.
Monitoring software
Software intended to monitor physiological processes is generally class IIa — but class IIb where it monitors vital physiological parameters whose variations could result in immediate danger to the patient.
Class I
All other software falls to class I — the exception, not the default, for clinical decision-support claims.
Teaching guidance, not legal advice: a supplier describing sepsis alerting or deterioration decision-support as self-certified class I is claiming the least-demanding tier for software that usually sits higher. That claim is a verification task for your regulatory expert, not a fact to inherit from the sales deck.
What the deploying organisation owns
Verify conformity at acquisition and first use
Confirm the CE marking exists, that it covers the intended purpose you are relying on, and that the documentation identifies the version being installed. The national inspectorate expects providers acquiring and using medical devices to check EU conformity rather than to assume it.
Match the claim to your use
Compare the manufacturer's stated intended purpose with the workflow you are actually building. A mismatch is a governance decision, not a paperwork problem, and off-label use can shift responsibility onto the deploying organisation.
Know the version, and what a new one means
Record which version is in use and how you would know it changed. Changes to a device can require reassessment by the manufacturer; from the deployer side, the practical requirement is a contractual right to be told before a material change and a decision on whether local revalidation is needed.
Keep vigilance and incident routes live
Device incidents have reporting routes, and internal safety reporting should connect to them. Module 7's monitoring signals and stop rules are the operational side of the same obligation.
Separate device status from clinical adequacy
A valid CE marking establishes a conformity route. It does not establish that the device performs well in your population, integrates into your workflow or produces benefit. That is Module 6's evidence question, asked separately and answered locally.
Change control is where AI-based devices differ most from traditional ones in practice. A model that is retrained, recalibrated or updated by the supplier can behave differently from the one your clinicians learned to trust, even when the version number moves by a decimal. Teaching guidance: put three things in the contract — notification before material change, a description of what changed and its expected effect, and the right to run a local check before the change reaches clinical users. None of that removes the manufacturer's own regulatory obligations; it makes yours executable.
Optional depth: device rules and the AI Act side by sideHow the two frameworks differ in trigger, burden, artefacts and timing — the detail behind 'they apply in parallel'.
What triggers it
- MDR / IVDR
- A medical intended purpose claimed by the manufacturer.
- AI Act
- The category of use: prohibited, transparency, Annex III, or the Article 6(1) product route.
Who carries the main burden
- MDR / IVDR
- The manufacturer, through conformity assessment; the provider organisation verifies and uses correctly.
- AI Act
- The provider of the AI system; deployers carry narrower operational duties.
What the organisation must hold
- MDR / IVDR
- Evidence of valid conformity for the intended purpose, version records, incident routes.
- AI Act
- Instructions for use, oversight arrangements with competent people, logs where applicable, information duties to affected persons and workers.
Timing in 2026
- MDR / IVDR
- Applies now, in full.
- AI Act
- General application from 2 August 2026; the product route to high-risk applies from 2 August 2028 under the amended timeline.
Sources & evidence · 11 sources
This module cites primary legal, public or consensus guidance. Regulatory position stated as of 28 August 2026, reflecting the AI Act timeline as amended by the 2026 digital omnibus package; recheck primary sources before any real decision.
Content reviewed: September 2026. Publication dates of the individual sources are shown in each citation.
European Commission. Regulatory framework for AI — overview and application timeline. Digital Strategy, accessed 28 August 2026.
The Commission's own overview of the AI Act's risk-based structure and staged application. Use it to confirm the current category definitions and dates. It is an explanatory overview, not the legal text, and it does not classify any individual product.
Open sourceEuropean Commission. Enforcement of the AI Act — application dates and supervisory architecture (updated August 2026).
The current statement of which obligations apply from which date, including the amended high-risk dates of 2 December 2027 for Annex III and 2 August 2028 for high-risk AI in regulated products. This page is the check to run before repeating any timeline written before 2026; it does not describe national implementation.
Open sourceRegulation (EU) 2024/1689 of the European Parliament and of the Council laying down harmonised rules on artificial intelligence (Artificial Intelligence Act). OJ L, 12 July 2024.
The legal text: definitions, Article 5 prohibitions, Article 6 high-risk classification and Annex III, Article 50 transparency obligations, and provider and deployer duties. Authoritative on what the obligations are; it does not tell you which category a specific product falls into, which is a factual analysis of intended purpose. Consolidated text as amended by Regulation (EU) 2026/1744 (in force 27 July 2026).
Open sourceRegulation (EU) 2017/745 on medical devices (MDR). Consolidated text. Annex VIII Rule 11.
The primary source for software classification: Rule 11 places software providing information for diagnosis or therapeutic decisions generally in class IIa, higher where decisions may cause serious or irreversible harm, and classifies monitoring software separately. Educational summary only — not legal advice.
Open sourceEuropean Commission, Joint Artificial Intelligence Board and Medical Device Coordination Group. MDCG 2025-6 / AIB 2025-1: FAQ on the interplay between the Medical Devices Regulations (MDR/IVDR) and the AI Act, June 2025.
The official joint position on how MDR/IVDR and the AI Act apply simultaneously and complementarily, including how the Article 6(1) conditions interact with device conformity routes and how documentation obligations overlap. It is guidance on interpretation; it does not amend either Regulation.
Open sourceRegulation (EU) 2016/679 (General Data Protection Regulation). OJ L 119, 4 May 2016.
The source for Article 6 lawful bases, the Article 9 regime for special-category data including health, controller and processor roles, purpose limitation and minimisation, Article 35 impact assessments and Article 22 on solely automated decisions. Determining which basis and condition apply to a specific processing operation is a factual and legal judgement for your DPO.
Open sourceRegulation (EU) 2025/327 on the European Health Data Space. OJ L, 5 March 2025.
Establishes the primary-use and secondary-use frameworks, the phased application from 26 March 2027 with milestones in 2029 and 2031, and the health data access body architecture. It sets direction and dates; national implementation detail and the practical access processes are still developing.
Open sourceAutoriteit Persoonsgegevens. Toezicht op AI wordt concreet: sleutelrol voor de AP en de RDI, 20 April 2026.
The Dutch data protection authority's account of the proposed national AI Act supervision architecture, with coordinating roles for the AP and RDI alongside sectoral supervisors. As of August 2026 this reflects a proposal and an implementation law still being finalised — treat the allocation as provisional rather than settled law.
Open sourceAutoriteit Persoonsgegevens. Aan de slag met de FRIA, 17 August 2026.
Practical Dutch guidance on the fundamental rights impact assessment, including which deployers of Annex III high-risk systems it applies to and how it relates to the DPIA. The obligation is tied to the December 2027 application date for Annex III systems; the guidance is a practical aid, not an additional legal requirement.
Open sourceInspectie Gezondheidszorg en Jeugd. Toetsingskader Digitale Zorg, 11 August 2026.
The Dutch healthcare inspectorate's framework for assessing digital care, setting out the conditions it expects providers to meet when care is delivered with digital means — governance, competence, safety and evaluation. It concerns responsible digital care; it is not an AI-specific product classification system and does not determine device status or AI Act category.
Open sourceInspectie Gezondheidszorg en Jeugd. EU-conformiteit van medische hulpmiddelen: verplichtingen bij aanschaf en gebruik.
States the expectation that healthcare providers verify EU conformity when acquiring and first using a medical device, and that software can be a medical device depending on its medical intended purpose. It establishes a verification duty on the deploying organisation; it does not assess whether a given device performs well in your population.
Open source
Applied practice: Regulatory Classification Lab
Route three proposed uses through intended purpose, the AI Act, medical-device law and GDPR — and see why the answers differ by use, not by technology.
Capstone Board Pack
Add what you just learned to your own strategy document while it is fresh.