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.
Governance that accelerates responsible AI
Regulation tells you what has to be true. Governance is how your organisation decides that it is true, records the decision and knows who is accountable for it afterwards. Done well, it is the fastest part of the process; done badly, it is the reason a six-week deployment takes nine months and arrives with nobody willing to own it.
The difference between an approval path and a committee maze is not the number of bodies involved. It is whether each body has a defined question, a defined input and the authority to answer. A maze is a sequence of meetings where the question is 'any concerns?', because a meeting with no specific question cannot produce a decision — only a request for more information.
The design goal is a route where a light-touch proposal can be cleared in one pass, a heavy one has a predictable path with named owners, and both produce the same artefact at the end.
Who decides what, and what they produce
Product / use-case owner
States the intended purpose precisely, the affected population, the workflow and the change trigger. Owns the passport as a document and is accountable for its accuracy.
Artefact: Completed regulatory & governance passport, intended-use statement.
Clinical owner (and clinical safety)
Whether the clinical claim, the workflow and the oversight design are acceptable in practice, and whether the evidence is adequate for this population.
Artefact: Clinical safety case and sign-off, oversight and escalation design.
Data protection officer / privacy
The lawful route: Article 6 basis and Article 9 condition, controller/processor position, DPIA scope and outcome, retention.
Artefact: DPIA, records of processing, data processing agreement.
Medical-device / regulatory expertise
Device status and conformity validity for the intended purpose, AI Act category and role, and what a version change triggers.
Artefact: Classification note, conformity verification record, change-control terms.
Information security
Access control, data flows, hosting and sub-processing, and the security conditions attached to go-live.
Artefact: Security review, data flow diagram, penetration or assurance evidence.
Procurement & contracting
That the contract actually contains what governance relied on: change notification, data rights, audit and exit, liability and instructions to a processor.
Artefact: Contract schedules mapping to the governance conditions.
Executive / board governance
Whether to proceed, proceed with conditions, or not proceed — and accepts the residual risk on the organisation's behalf. Also owns the decision to stop.
Artefact: Recorded decision with conditions, owners and review date.
The regulatory & governance passport
The passport is a single page carried by every AI use case from first proposal to decommissioning. Its purpose is not documentation for its own sake — it is to make the same twelve facts available to every body that has to decide something, so that no meeting spends its time reconstructing what the system does.
1. Intended use, stated precisely
What it does, for whom, in which population, and how it influences a decision. If two people would write this differently, nothing downstream can be settled.
2. Users and affected people
Who operates it, who is affected by its output, and whether they are told.
3. Role: provider or deployer
What the organisation is doing with the system, and whether any activity — rebranding, modification, own development — changes the role.
4. AI Act route
Prohibited, transparency, Annex III high-risk, product-route high-risk, or none — with the fact the classification depends on, and the applicable date.
5. MDR / IVDR status
Device or not; if a device, class, conformity route, certificate reference and the version in use.
6. Data categories and lawful route
What data, whose, Article 6 basis and Article 9 condition, controller/processor position, retention.
7. DPIA and FRIA status
Whether each is required, its status, and where it lives. Teaching guidance: the fundamental rights impact assessment obligation applies to specified deployers of Annex III high-risk systems, is tied to the 2027 application date, and is a reason to design the assessment into the route now.
8. Evidence and conformity artefacts
Conformity documentation, instructions for use, the local evidence position from Module 6, and the safety case from Module 7.
9. Oversight design
Who oversees the system in operation, with what competence, what information and what authority to override or stop.
10. Accountable owners
Named individuals per domain — clinical, data protection, regulatory, security, operational — not job titles in a table nobody maintains.
11. Decision and conditions
Proceed, proceed with conditions, clarify a fact first, or do not proceed — with the conditions, their owners and their dates.
12. Change and review triggers
What would reopen the decision: a new version, a new indication, a new population, a monitoring signal, a regulatory change, or a review date.
Exports the blank passport template with its guidance — an educational structure, not legal advice, and not a record of your own answers.
Four decisions the route can produce
Proceed
Every applicable route is settled, the artefacts exist, and the owners are named. Most proposals in a healthy pipeline should end here quickly.
Proceed with conditions
The route is clear and something specific is outstanding — a contract clause, a DPIA sign-off, a transparency notice, a monitoring arrangement. Conditions need an owner and a date, or they are a wish.
Clarify a fact first
The classification genuinely turns on a fact nobody has established: the exact intended purpose, the conformity route, whether the supplier is a processor. The right next action is to get the fact, not to guess the classification.
Do not proceed in this form
The use is prohibited, no lawful route exists, or the organisation would take on obligations it cannot discharge. Say so explicitly, record why, and describe what a different form would need to look like.
Optional depth: six ways an approval path becomes a mazeFailure patterns in AI assurance routes, each with the smallest change that fixes it.
Serial committees with no defined question
Fix: Give every body one question it owns and the input it needs to answer it. Run in parallel wherever the answers are independent.
Classification decided by the enthusiast
Fix: The person proposing the system should draft the passport; someone with regulatory competence should confirm the classification. Both, in that order.
Approval as a one-off event
Fix: Record change triggers and a review date at approval. An AI system that has not been looked at since go-live is an unowned system with a certificate.
Governance discovered after procurement
Fix: Route at proposal, before a supplier is selected. The routing conversation is short; the retrofit is not.
Conditions with no owner
Fix: Every condition names a person and a date, and the decision record is checked against them before go-live.
Treating low legal risk as clearance
Fix: Run the clinical safety and evidence questions on their own track. Module 7's safety case is required by the organisation whether or not the AI Act requires anything.
Who owns the decision?
Six questions arise during the assurance of a single fictional deployment. For each, choose the owner who should answer it. Several questions touch more than one function — pick the one that must decide, not everyone who should be consulted.
1. "The supplier wants to keep our transcripts to improve its model."
The service agreement contains a clause permitting the supplier to retain de-identified transcripts for product improvement. The project team regards it as standard and would like to accept it to avoid renegotiation.
2. "Is our version still the one that was certified?"
Nine months after go-live the supplier announces an update that improves performance on a subgroup. The clinical team is keen; nobody can immediately say whether the change affects the conformity position.
3. "Nobody has time to review every draft properly."
In practice, clinicians are signing generated documentation with a median review time far shorter than the pilot assumed. The oversight design on paper says every output is reviewed by the responsible clinician.
4. "We need the right to be told before the model changes."
Governance has concluded that advance notice of material model changes, a description of what changed, and a right to run a local check are required. The draft contract contains none of them.
5. "Do we accept the residual risk and go live?"
Every function has reported. The lawful route is settled, conformity verified, the safety case accepted with two open monitoring conditions, and the contract amended. A residual risk remains that local performance is weaker than the published evidence suggests.
6. "Is the shortlisting tool high-risk, or not?"
HR's recruitment screening proposal has reached assurance. Views differ: the project sponsor argues it is administrative, the privacy lead thinks Annex III may apply, and nobody has written down the analysis.
A useful test of the route you have designed: can you tell a supplier, at first contact, roughly how long approval will take and which three artefacts you will need from them? If yes, governance is a capability. If the honest answer is 'it depends who raises what', it is a maze, and the cost is paid in delay on every use case rather than in scrutiny on the ones that need it.
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.