A UK healthtech founder put it plainly during a scoping conversation: "We have a regulatory consultant for the device side, a clinical safety officer under contract, a DTAC pack we rebuild for every trust, and a DPIA. I have been told we now also need AI governance. What is left for it to govern?"
It is a fair question, and the answer is more specific than most vendors of AI governance services will admit. A UK healthtech company with AI in the product typically faces four regimes at once: medical device regulation, clinical safety standards, NHS procurement assessment, and data protection. AI governance is the layer none of them fully covers and all of them quietly assume.
Four regimes, one AI system
Each regime asks about the same system from a different angle. Medical device regulation asks whether the product conforms and is safe for its intended purpose. Clinical safety asks whether deploying it into a care pathway introduces hazards to patients. NHS procurement asks whether the supplier is safe to buy from. Data protection asks whether the personal data is handled lawfully.
None of them asks, in a sustained way, what the model was trained on, how it behaves as the population shifts underneath it, how bias across patient subgroups is tested after launch, or who inside the supplier is accountable for the model's continued performance. Those questions land in the gaps between the regimes, and buyers are increasingly the ones asking them.
Where the MHRA line falls
Software that has a medical purpose may be regulated as a medical device. The practical test turns on intended purpose: software intended for diagnosis, prevention, monitoring, prediction, prognosis, treatment, or alleviation of disease generally falls in scope, while software that only stores, communicates, or displays data without interpreting it for a clinical purpose generally does not. Classification then determines a great deal downstream, including the conformity assessment route and whether an approved body is involved.
The MHRA has been developing its approach to software and AI as a medical device, including work on the specific challenges of adaptive and machine learning systems. Because that programme has been evolving, firms should verify the current position for their specific product and intended purpose rather than working from general guidance or from what was true at the last funding round. A change in claim wording can move a product across the line in either direction.
Be explicit about the boundary: ISO 42001 is not a substitute for medical device conformity and does not address it. An AI management system will not produce a UKCA marking, will not satisfy an approved body, and will not answer a question about clinical evaluation. Any supplier told otherwise is being sold something.
Clinical safety: DCB0129 and DCB0160
Two clinical risk management standards apply to health IT in England. DCB0129 applies to manufacturers of health IT systems. DCB0160 applies to organisations deploying and using them. Both require a nominated clinical safety officer, a clinical risk management file, structured hazard identification and analysis, and a clinical safety case report that is maintained rather than written once.
The overlap with ISO 42001 risk management is real but partial. Both are structured hazard and risk processes with documented ownership, defined severity and likelihood reasoning, and mitigation tracked to closure. A supplier already running DCB0129 properly has the discipline and much of the machinery.
The difference is scope. The clinical safety case addresses patient harm arising from the system in its clinical context. AI risk management addresses model behaviour, data lineage, subgroup performance, drift, explainability, automation bias in the clinician using the output, and third party model dependencies. Some of that feeds the safety case. Much of it sits outside it. An AIMS does not replace the clinical safety case, and the clinical safety case does not discharge AI governance.
The efficient structure is one hazard process feeding two outputs, with the AI-specific risk taxonomy extending the existing methodology rather than sitting beside it in a second register.
NHS procurement and DTAC
The Digital Technology Assessment Criteria is the NHS assessment covering clinical safety, data protection, technical security, interoperability, and usability and accessibility. Suppliers meet it repeatedly, because it is applied by buying organisations rather than once centrally, and each trust may ask for its own evidence pack.
The Data Security and Protection Toolkit sits alongside it as the annual data security assessment for organisations handling NHS patient data, and appears frequently in the same procurement conversation.
A governed AI management system changes the economics of this. The AI-related sections of an assessment become answerable from an existing evidence base: here is the inventory entry for this component, here is its impact assessment, here is the oversight design, here is the monitoring evidence for the last two quarters. Without it, each trust triggers a reconstruction exercise, and the reconstructions drift apart until two trusts hold different descriptions of the same product.
Suppliers should confirm the current version and applicability of both DTAC and DSPT for their engagement, since NHS assessment requirements have been revised periodically.
Where the AI sits in a healthtech product
Triage and prioritisation. Diagnostic support and image analysis. Risk stratification and population health targeting. Clinical documentation, including ambient scribing and summarisation. Administrative automation, appointment booking, and capacity management. Coding and billing support. Patient-facing chat and symptom checking.
One distinction has to be explicit in the inventory, because everything downstream depends on it: systems influencing clinical decisions carry materially different exposure from systems automating administration. A rota optimiser and a deterioration predictor are both AI, and treating them as one risk class either over-governs the rota or under-governs the patient. The inventory should record intended clinical influence, the affected population, and whether a clinician is positioned to catch an error, for each system separately.
EU AI Act exposure for UK healthtech
Where the product is placed on the EU market, the route into high-risk classification is usually not the Annex III list. AI embedded in a product already regulated under EU product legislation, including medical devices requiring third party conformity assessment, falls into the high-risk category through that route instead.
That distinction matters practically because the obligations attach through the existing conformity assessment rather than as a separate parallel process, and because the timetable for that category runs behind the Annex III timetable. High-risk obligations for Annex I systems, meaning AI embedded in products already regulated under EU product safety legislation, including medical devices, apply from 2 August 2028. Annex III standalone systems apply from 2 December 2027.
Both dates moved. The original timetable set 2 August 2026 for high-risk obligations. The Digital Omnibus on AI, proposed by the European Commission in November 2025, amended this. Political agreement was reached on 7 May 2026, the European Parliament endorsed it on 16 June, and the Council gave final approval on 29 June 2026. The effect is a sixteen-month deferral for Annex III standalone systems and a two-year deferral for Annex I embedded systems. The transparency obligations under Article 50 were not deferred and apply from 2 August 2026 as originally scheduled.
The obligations are unchanged in substance. A provider still needs a risk management system, data governance documentation, technical documentation, human oversight procedures, and a fundamental rights impact assessment where required. In a regulated medical device, that evidence has to sit alongside the existing quality management system and conformity assessment, and retrofitting it into a device already on the market is materially harder than building it in from the start.
What does not change is the limit of the standard. ISO 42001 does not discharge conformity assessment obligations under the EU AI Act or under medical device legislation. It can produce a substantial share of the underlying documentation, particularly on risk management, data governance, human oversight, and post-market monitoring, but the conformity route is separate work.
What ISO 42001 adds that the clinical regimes do not
Clinical safety addresses patient harm in context. Medical device regulation addresses product conformity against intended purpose. Data protection addresses lawful processing. None of them, taken together, systematically addresses:
Training data governance and lineage, including what the model was trained on, whether that population resembles the deployed population, and whether the provenance is documented well enough to withstand a question. Model drift after deployment, with defined monitoring and a threshold that triggers action rather than a chart nobody owns. Performance across patient subgroups, tested repeatedly rather than once at validation. Explainability to the clinician actually receiving the output, which is a design question rather than a documentation question. Governance of third party foundation models sitting underneath the product, where the supplier controls neither the training data nor the update schedule.
These are AIMS territory, and they are increasingly what NHS and enterprise buyers ask about, because they are the questions their own governance forums have started asking them.
And again, plainly: ISO 42001 certification is not regulatory compliance. It does not satisfy the MHRA, it does not satisfy the clinical safety standards, and it does not satisfy the EU AI Act. It evidences that an AI management system exists and operates.
Sequencing for a healthtech supplier
Regulatory obligations first, because they gate market access. If the classification question is unresolved, everything else is provisional.
Clinical safety second, because it gates deployment. No trust will deploy without the safety case, regardless of how good the AI governance is.
AI governance runs alongside both rather than after them, and produces the evidence base the procurement conversations draw on. Run as three separate programmes, these duplicate substantially: three risk registers, three sets of documentation, three owners, and three versions of the truth about what the product does. Run as one management system with three outputs, the hazard analysis, the impact assessment, and the risk register share a spine, and each regime draws the view it needs.
An AI governance readiness assessment establishes the AI inventory, the risk classification, and where the AIMS work sits relative to your existing regulatory and clinical safety obligations, so the programmes are sequenced rather than stacked. Book a scoping call.