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.
Continuing from Module 8
Module 8 ended with a portfolio: a small number of candidates the organisation intends to fund, and a set of gates it treated as constraints without opening them. This module opens them. The question is no longer whether an investment is worth making — it is which rules apply to it, what role the organisation occupies, what has to be true before it can go live, and who is entitled to say yes.
Regulation is a routing problem, not a wall
Most organisations discover regulation in the worst possible order. A system is selected, a business case is approved, an implementation date is announced — and only then does someone ask whether it is a medical device, what the lawful basis for the data is, and who signs it off. The answer arrives as an obstruction, which is how regulation acquires its reputation as a wall.
It is better understood as a routing problem. A small number of facts about a proposed use determine which regimes apply, and therefore which evidence has to exist, which experts have to be involved and how long approval will take. Established early, those facts make the path predictable. Established late, they make it expensive.
The practical payoff is speed and confidence. An organisation that can route a proposal in an afternoon can say yes quickly to the many use cases that carry light obligations, concentrate its scarce regulatory and clinical-safety attention on the few that carry heavy ones, and give a straight answer to a supplier instead of a six-month silence. Good governance is not the opposite of momentum; unpredictable governance is.
Where a use case lands, and from when
Routing starts at the intended purpose, not the technology. Dates are the applicable dates taught in this module; confirm the position in force with qualified advice before acting.
Six questions that route almost everything
What is the intended purpose, stated precisely?
Not 'an AI tool for radiology' but what it is claimed to do, for whom, in which population and with what influence on a decision. Intended purpose is the single fact that drives medical-device status, AI Act categorisation and most of what follows. It is also the fact suppliers state most loosely.
Who is the actor, and in what role?
Are you deploying a system placed on the market by someone else, or are you developing it, putting your own name on it, or changing it materially? Provider and deployer obligations differ substantially, and the role is a consequence of what you do, not of what you would prefer to be.
Who is affected, and how directly?
Patients, staff, applicants for a job, the general public. Effects on people's health, employment or access to services attract heavier obligations than a system that reorders an internal work queue with no bearing on individuals.
What data does it use, and under what route?
Personal data, special-category health data, pseudonymised research data, or none. This determines the data-protection analysis, whether a DPIA is needed and whether the access route exists at all.
How much does the human in the loop actually decide?
A draft a clinician rewrites, a ranked worklist, an alert, an automated decision with no meaningful human involvement. This affects transparency duties, oversight requirements and whether the rules on solely automated decisions come into play.
What changes after go-live, and who is told?
Model updates, retraining, new indications, new populations. A version change can convert a settled classification into an open question, so the trigger has to be agreed before the first deployment, not after the first surprise.
The regimes a healthcare AI use case can meet
EU AI Act — Regulation (EU) 2024/1689
Asks: Is this an AI system, is the use prohibited, does it carry transparency duties, and is it high-risk either through Annex III or through the regulated-product route?
Applies to the use of the system, layered on top of any product legislation. Being lawful under the AI Act says nothing about whether the tool is any good.
MDR / IVDR — medical-device regulation
Asks: Does the software have a medical intended purpose? If so, which class, which conformity route, and is the version in front of you the one that was assessed?
Independent of the AI Act and frequently simultaneous with it. Device status follows intended purpose, not the sophistication of the technology.
GDPR — Regulation (EU) 2016/679
Asks: What personal data, for what purpose, on what Article 6 basis and which Article 9 condition, as controller or processor, and does it need a DPIA?
Applies whenever personal data is processed, including for development, evaluation and monitoring — not only in live clinical use.
EHDS — Regulation (EU) 2025/327
Asks: Does this touch electronic health data for primary care delivery or for secondary use such as research, innovation or policy? What will interoperability and access look like when the phased obligations arrive?
Mostly forward-looking in 2026, and already a reason to make interoperability and data-governance choices deliberately rather than by default.
National supervision and healthcare governance
Asks: Which national authorities supervise this, and what does the national healthcare inspectorate expect of a provider deploying digital care?
In the Netherlands the AI Act supervision architecture is still being finalised, while existing duties on providers using medical devices and delivering digital care apply now.
One system, four regimes at once
A single fictional example, to make the parallel structure concrete. Meadowbrook Health Group is considering software that flags suspected intracranial haemorrhage on CT and moves those studies up the reporting worklist. One system, four live regimes, none of which waits for the others.
Medical device
It has a medical intended purpose — supporting the prioritisation of studies with suspected time-critical findings — so it is a device and needs a valid CE marking under MDR for exactly that purpose.
Artefact: Declaration of conformity, certificate, instructions for use, version identifier.
AI Act
If it is a safety component or product covered by Annex I harmonisation legislation and requires third-party conformity assessment, the product route to high-risk applies, with the obligations that follow for the provider and a narrower set for the deployer.
Artefact: Provider's AI Act documentation, instructions for the deployer, the organisation's record of how it is used and overseen.
Data protection
It processes patient images and identifiers to deliver care. A lawful basis and an Article 9 condition are needed, the supplier's role as processor or controller must be settled in the contract, and a DPIA is likely appropriate given the scale and the nature of the data.
Artefact: DPIA, processing agreement, records of processing, retention position.
National healthcare governance
The provider must satisfy itself that the device is genuinely CE-marked for this purpose before use, and must be able to show it is delivering digital care under the conditions the inspectorate expects.
Artefact: Conformity check at acquisition, clinical safety documentation, named owners, incident route.
Notice what the table does not contain: an argument about whether the tool is good. Regulatory routing establishes which questions must be answered and by whom. Whether the evidence justifies deployment in your population is Module 6's question, and whether it can be operated safely is Module 7's. Confusing the three is the most common failure in AI assurance meetings — a room that has satisfied itself the CE mark is valid and believes it has therefore established clinical benefit.
The routing view also explains why speed is achievable. Of ten proposals in a typical pipeline, most will be neither prohibited nor high-risk nor medical devices. Recognising that quickly, and saying so in writing, is what frees the organisation to spend its regulatory effort on the two that are.
From Module 6
Module 6 owns whether the evidence supports the claim. Regulatory conformity and scientific credibility are not the same test: a CE-marked device can have thin evidence for your population, and a well-evidenced tool can still be unlawful to deploy in the way you intend. Ask both questions, and never let one answer stand in for the other.
From Module 7
Module 7 owns the safety case: failure modes, hazards, controls, oversight, monitoring signals and stop rules. That work is an input here, not a repeat. Regulation asks a different question — which legal regime applies and what it obliges you to produce — and a strong safety case is one of the artefacts the governance route consumes.
The passport, the routing questions and the decision categories in this module are teaching structures for organising a leadership conversation. They summarise obligations from the sources cited in the references, but they are not a legal instrument, they do not replace advice from your data protection officer, regulatory function or legal counsel, and completing them is not evidence that a deployment is compliant.
Visual Guide 07 — AI Governance in Healthcare
Keep the terminology map next to you while you continue the technical track.
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.