Healthcare AI regulation must follow the product as it changes

Europe’s AI rules and the UK’s reform programme are developing on different tracks. For healthcare organisations, the practical challenge is to connect each product version with the evidence and responsibilities that support its use.

A hospital may buy an AI tool for a carefully defined task, then encounter a substantially different product after several updates. New functions can change the information it produces, the decisions it influences and the people expected to check it. Regulation therefore needs to be understood through the product’s continuing life, rather than only the documents presented at purchase.

That is particularly important in October 2026. The EU has amended its AI Act timetable, while the UK Government has accepted a programme of recommendations for future healthcare AI regulation. The developments are significant, but they do not create a single European approval route or remove existing obligations for medical devices.

The EU timetable has changed through enacted legislation

The AI Omnibus, Regulation (EU) 2026/1744, entered into force on 27 July 2026. It is no longer simply a proposal. The amendment moves the relevant high-risk requirements to 2 December 2027 for systems classified through Article 6(2) and Annex III, and to 2 August 2028 for systems classified through Article 6(1) and Annex I.

The Commission’s implementation announcement confirms those revised dates and describes accompanying changes to administration, testing and governance. Older summaries that give August 2026 or August 2027 as the applicable high-risk deadlines can consequently mislead a procurement or development team. The relevant question is which provision applies to the particular system.

A later AI Act deadline does not mean a medical product can operate without the medical-device requirements already applicable to it. The timetable concerns a specific layer of regulation. Organisations still need to understand the product’s intended use, existing conformity obligations and the conditions under which they propose to deploy it.

For an investment decision, this argues for separating immediate requirements from preparations for later ones. A clear record of that distinction would be more useful than a single statement that a company is preparing for European AI regulation. It would also make changes in the implementation timetable easier to manage.

Clinical use does not settle the classification

The joint European guidance on medical devices and the AI Act explains the product route to high-risk classification. Under Article 6(1), the AI must be a product or safety component covered by relevant Annex I legislation, and that product must require third-party conformity assessment. The guidance also distinguishes AI Act classification from the risk class assigned under medical-device legislation.

This means that neither using AI in a hospital nor describing it as clinical software automatically answers the classification question. Equally, the product route is not confined to machinery containing an embedded model: standalone medical-device software can be relevant. The June 2025 guidance remains useful for these distinctions, while its original timetable must be read against the later amendment.

A practical product description should identify what the system is intended to do, which information it receives and how its output affects care. A tool that organises administrative information and one that recommends a treatment may share an underlying language model while presenting different regulatory questions.

That description should remain consistent across instructions, demonstrations and sales materials. A purchasing organisation needs to know which capabilities are included in the assessed product and which are experimental, optional or outside the proposed use. Otherwise, an apparently precise specification can become ambiguous when it reaches a clinical team.

The UK reform programme is an implementation commitment

On 6 October 2026, the UK Government accepted all 44 recommendations of the National Commission into the Regulation of AI in Healthcare. Its response supports an approach based on risk and continuing oversight across a product’s life, with work involving regulators, health services, industry and patients. It sets out priorities and next steps rather than making every recommended change immediately operational.

For developers, that distinction matters when estimating the route to market. An announced reform may influence future planning, but the product still needs to be assessed against the requirements applicable when it is supplied. Draft guidance, policy recommendations and legislation should be identified as different kinds of authority.

Healthcare organisations can prepare by identifying what information they need from manufacturers throughout deployment. That might include advance notice of important changes, evidence supporting new functions and a route for investigating unexpected behaviour. Those arrangements have practical value even while the wider regulatory framework develops.

The geography also needs precision. Great Britain and Northern Ireland do not have identical medical-device arrangements. MHRA guidance explains that Great Britain uses the UK Medical Devices Regulations 2002, as amended, while the EU Medical Devices Regulation applies in Northern Ireland under the Windsor Framework. A statement about UK market access should account for that distinction.

A new function can change the regulatory question

The MHRA’s July 2026 guidance on ambient voice products provides a concrete example. It distinguishes administrative transcription or summarisation for clinician review from functions with a medical intended purpose. Use in a healthcare environment alone does not make every such product a medical device. Manufacturers nevertheless need to reconsider the position when features or intended purposes change.

For a hypothetical service, the distinction might become relevant when a documentation tool begins offering diagnostic suggestions. The hospital should be able to identify whether that function has been enabled, which users can access it and what evidence supports the expanded role. Treating every update as routine maintenance would obscure the change.

The same reasoning applies to local modifications. A configuration that changes what information enters the system or how its output reaches clinicians can alter the operating conditions under which performance was established. A deployment record should therefore describe the actual configuration, rather than only the commercial product name.

Clinical review remains important, but it needs a workable process. The reviewer must have enough time and information to identify an error and correct it. A contract that simply says a professional remains responsible does not demonstrate that these practical conditions exist.

Monitoring after deployment is already part of device regulation

Great Britain’s strengthened post-market surveillance requirements took effect on 16 June 2025. The amendments introduced a new part of the UK medical-device regulations dealing with surveillance after products reach the market. These requirements are already in force and should not be confused with the future reforms discussed by the National Commission.

For healthcare AI, useful monitoring connects a reported problem with the product version, setting and decision affected. A complaint that the system produced an incorrect recommendation is difficult to investigate if the underlying input, configuration and update history cannot be reconstructed appropriately.

Monitoring should also distinguish different types of evidence. A model’s statistical performance may change, clinicians may begin using it differently, or a revised pathway may expose it to a new patient population. Each could warrant investigation, but the response would depend on the cause.

A service can prepare by agreeing how concerns reach the manufacturer and relevant internal teams, who can pause a function and how patients continue receiving care during that pause. These are proposed operating arrangements, not a claim that one procedure satisfies every legal requirement.

Planned changes still need defined boundaries

The US Food and Drug Administration’s August 2025 final guidance on predetermined change control plans offers an international comparison. It describes a route for specified modifications to AI-enabled device software within an authorised plan. This is not unrestricted permission to change a model, and a US authorisation does not confer EU or UK market access.

The broader operational question is how a manufacturer demonstrates that an update remains within the evidence supporting use. A healthcare purchaser could ask which changes are expected, how they will be assessed and what happens if performance moves outside agreed boundaries. Those answers connect regulatory planning with the daily management of the product.

Europe’s healthcare AI debate will become more useful when it follows that continuing relationship. Classification establishes which rules apply; assessment examines a defined product; monitoring tests what happens after deployment. Keeping those stages connected helps organisations recognise when the system they use has changed enough to require a new decision.