An NHS hospital in England uses AI to flag chest X-rays for urgent review. After a software update, an image that should have been flagged stays in the routine queue. The report is delayed and the patient is harmed. The system's log says it issued an alert; the hospital's worklist shows none. Who was responsible for getting that alert to a clinician, and who can establish what happened?
The answer depends on where the failure occurred, what each party could reasonably have done, and whether the failure caused the harm. A clinician's professional accountability, an NHS provider's duty of care and a manufacturer's obligations can all matter in the same case. The UK's National Commission into the Regulation of AI in Healthcare has called for clearer responsibilities across that chain. The government accepted all 44 recommendations in October 2026. That response sets out work to do; it did not change the law on who pays compensation.
Three questions to ask about the same incident
| Who was involved? | What would an investigation ask? |
|---|---|
| Clinician or reporting team | What did staff see at the time? Could they reasonably use the routine queue as configured? Was there an independent reason to escalate the image, and did staff know what a missing alert meant? |
| Healthcare provider | Did the service test that alerts arrived at the right worklist after the update? Who monitored the routine queue and owned the fallback? Had earlier warnings or near misses been acted on? |
| Manufacturer or supplier | Did the device process the image and generate the alert correctly? Was the update tested for the supported integration? Were new limitations communicated, and can the supplier retrieve the version and relevant logs? |
This is a fictional case. Each question points to evidence rather than a finding of fault. A model error, a failed connection and an alert that reached the wrong worklist could all look like “the AI missed it” to the clinical team. They call for different fixes and could lead to different conclusions about liability.
Professional accountability, negligence and product liability
The GMC's AI learning resource says doctors, physician associates and anaesthesia associates remain responsible for decisions they take when using AI. It also says those involved in creating, testing or updating technology remain responsible for those aspects. In the X-ray example, reviewing a result when it reaches you and ensuring that the worklist reliably receives results are distinct tasks. What matters is whether people could perform the checks expected of them, with the information and time they had.
A negligence claim asks whether there was a duty of care, whether the standard of reasonable care was breached and whether that breach caused harm. An organisation's own systems and processes can be part of that assessment. NHS Resolution's AI guidance says its existing schemes cover eligible clinical negligence claims for NHS care in England, subject to scheme terms, and recognises that a manufacturer may face product liability if a system failure causes harm. The existence of cover is a different question from whether someone was negligent.
The Consumer Protection Act 1987 provides a route to claim for damage caused by a defective product where the statutory conditions are met. Its application to standalone software and cloud AI is uncertain. The Law Commission's separate product liability consultation, open until 14 January 2027, proposes expressly including software and AI systems. That is a proposal, with no automatic effect on a claim today. For medical devices in Great Britain, manufacturers already have post-market surveillance duties. Device compliance and civil liability answer different questions.
What the government's October response commits to
The National Commission's September report asks who is best placed to prevent each risk, observe a failure and act on it. Its 6 October government response accepts the recommendations and sets out next steps:
- Responsibilities and redress (recommendations 24 and 25). A working group will clarify roles across the life of a product. Its remit excludes determining or redistributing responsibilities. Separate work will look at how patients find out what happened, raise concerns and access redress, potentially including a shared approach to complaints.
- Conditions for safe use (26 and 27). The MHRA will develop guidance on what manufacturers should tell providers about the conditions needed for safe deployment, such as training, monitoring and how to respond to underperformance. It will consider how those conditions should feature in future regulatory requirements.
- Supplier contracts (28). The health departments will review how providers and manufacturers can make responsibilities clearer in contracts, including who will put particular safety measures into practice.
For these recommendations, the response promises further details by spring 2027. That is a timetable for further information, rather than a start date for a new liability or compensation regime.
Make the handoff visible before there is an incident
Start with one failure the service can rehearse. For the X-ray worklist, ask the supplier to show where the output is generated, ask the provider to show how the alert's arrival is verified, and ask the reporting team to show the fallback when alerts stop. Put an owner and escalation route next to each step. Agree who checks the integration after an update, who can pause the tool, and who can access and preserve relevant records if something goes wrong. NHS Resolution's guidance also recommends examining supplier indemnity and how the organisation could recover losses under its contract.
If harm occurs, address the patient's care first. Record what staff actually saw, the decision and timing, and report the event through the local safety route. Preserve relevant software and workflow records through approved channels so the provider and manufacturer can reconstruct events. Good medical practice covers accurate records and reporting adverse medical device incidents. For a suspected device issue in England, alert the local medical device safety lead and use the MHRA’s Yellow Card route. Follow the professional duty of candour and, for providers in England, the statutory requirements that apply to the incident. Explain promptly what is known and what remains under investigation, apologise and tell the patient how to raise a concern.
Frequently asked questions
Did the October 2026 response change who is liable for AI harm? No. It sets out plans for clearer roles, safer deployment and better access to redress. Liability for a particular incident still depends on the applicable law and the facts.
Does signing off an AI-assisted decision make the clinician responsible for a software failure? Sign-off is evidence about who made a clinical decision. It does not resolve whether a product, an update or the way the service was set up also contributed to the harm.
Can an AI supplier contract take away a patient's right to complain or claim? Contract terms can allocate duties and routes for recovery between the organisations involved. A patient's complaint or legal claim is a separate question; responsibility cannot be read from the supplier's contract alone.
For the related reform proposals, read the iatroX guide to the Law Commission's product liability consultation.