Roadmap to AI Adoption in Healthcare — June 2026 Edition

Executive tear-sheet

Healthcare organisations are adopting AI into clinical and operational decisions — triage, diagnosis support, documentation, scheduling, prior authorisation — while sitting on the most sensitive category of personal data the law recognises. For a data protection officer the reassuring news is that almost none of this is unprecedented: the obligations that bind healthcare AI are extensions of regimes the sector already runs. Health data is special-category data under the GDPR, lawful only on a narrow set of conditions. Software that informs diagnosis or treatment is a medical device, regulated as such by the EU Medical Device Regulation and, in the UK, by the MHRA. And the EU AI Act layers a high-risk regime on top for AI used in those settings. This guide sequences those anchors into a checklist a DPO can act on, and is honest about its boundary: KYE Protocol™ governs whether an AI action is authorised and evidenced — not whether a diagnosis is correct.

Key findings

• Health data is special-category data under GDPR Article 9: processing is prohibited unless a specific condition (such as health-or-social-care purposes under Article 9(2)(h)) applies, on top of an Article 6 lawful basis.
• Software intended to inform diagnosis or treatment is a medical device: under the EU Medical Device Regulation it must be CE-marked, and in the UK the MHRA regulates it and is reforming the rules for software and AI as a medical device.
• The EU AI Act treats AI used as, or as a safety component of, a regulated medical device as high-risk, attaching risk-management, data-governance, logging and human-oversight duties to the deployer.
• The obligations converge on runtime evidence — a named accountable owner, logged decisions, demonstrable human oversight — which is exactly the authority-and-evidence boundary a DPO must be able to show a regulator.

Health data is special-category data — start there

TL;DR The GDPR singles out data concerning health as a special category whose processing is prohibited by Article 9(1) unless one of the Article 9(2) conditions applies — most commonly, for care providers, the Article 9(2)(h) condition for the provision of health or social care.

The GDPR singles out data concerning health as a special category whose processing is prohibited by Article 9(1) unless one of the Article 9(2) conditions applies — most commonly, for care providers, the Article 9(2)(h) condition for the provision of health or social care. Crucially, that condition sits on top of an ordinary Article 6 lawful basis, not instead of it. For a DPO the first AI-adoption question is therefore not technical but legal: for each AI use that touches patient data, which Article 6 basis and which Article 9 condition apply, and is that mapping written down before the system goes live? An AI scribe that records a consultation, a model that flags sepsis risk, and a tool that drafts a discharge summary may each rest on different conditions — and each must be documented.

Clinical AI is usually a medical device

TL;DR If software is intended by its manufacturer to inform diagnosis, prognosis, treatment or monitoring, it is generally a medical device.

If software is intended by its manufacturer to inform diagnosis, prognosis, treatment or monitoring, it is generally a medical device. In the EU it falls under the Medical Device Regulation (EU) 2017/745 and must be CE-marked to the appropriate risk class before it is placed on the market. In the UK the MHRA is the regulator, and it has set out a programme to reform how software and AI as a medical device are regulated. The practical consequence for a DPO is that procurement diligence has a second axis beyond data protection: is this product a regulated medical device, is it correctly classified and conformity-assessed, and does the deployment stay within the manufacturer's intended purpose? Using a device outside its intended purpose can move regulatory responsibility onto the deploying organisation.

The EU AI Act adds a high-risk layer

TL;DR For AI specifically, the EU AI Act classifies AI systems that are themselves a medical device — or a safety component of one — as high-risk, and attaches the full high-risk obligation set: risk management, data governance, technical documentation, record-keeping (logging), transparency, human oversight and post-market monitoring.

For AI specifically, the EU AI Act classifies AI systems that are themselves a medical device — or a safety component of one — as high-risk, and attaches the full high-risk obligation set: risk management, data governance, technical documentation, record-keeping (logging), transparency, human oversight and post-market monitoring. These are deployer-facing duties, not just manufacturer duties. For a healthcare DPO the AI Act is best read not as a new silo but as a structured restatement of controls the medical-device and data-protection regimes already imply — with logging and human oversight made explicit and continuous.

What a DPO should put in place

TL;DR Read together, the three anchors point at the same operational demand: the obligations bind while the system is in use, and they must be evidenced.

Read together, the three anchors point at the same operational demand: the obligations bind while the system is in use, and they must be evidenced. The DPO's adoption checklist is therefore concrete. Maintain an inventory of AI systems that touch patient data or clinical decisions. For each, record the Article 6 basis and Article 9 condition, the medical-device status and intended purpose, and the named clinician or owner accountable for oversight. Require that consequential AI actions are logged and attributable, and that a human can review and override them. That evidence — who was authorised to act, on what basis, with what oversight — is precisely the boundary KYE Protocol™ governs: not whether the model is clinically right, but whether each action it takes is authorised, overseen, and provable to a regulator at the moment it happens.