When an AI-assisted decision harms a patient, the first question everyone asks is the hardest one to answer: who is responsible? The clinician who acted on the output? The company that built the model? The hospital that bought and deployed it? As of July 2026 the honest answer is that the law has not settled this. There is little decided appellate case law directly on injury from clinical AI, so courts and scholars reason by analogy from two older bodies of law — medical malpractice and products liability — neither of which was designed for a statistical model that recommends care without explaining itself. This page maps the three doors a claim can walk through, states the competing views fairly, and flags where the ground is still moving. It is general information for orientation, not legal advice. As of July 2026.
Why is there no settled answer yet?
Two features make clinical-AI liability genuinely open rather than merely complicated.
The first is the absence of on-point precedent. Malpractice and products-liability doctrines are mature, but their application to a clinician following an algorithm, or to a developer whose model drifted, has barely been tested in decided cases. That means the framework below describes how existing law would likely be applied, not how courts have ruled.
The second is the explainability gap. Many models cannot show the reasoning behind an output, which strains doctrines built around conduct a court can inspect and second-guess. Sullivan and Schweikart put the problem directly, asking whether current tort doctrines are adequate for injuries caused by AI and concluding that black-box systems complicate both the negligence and the products-liability paths 4. The clinical decision support system that cannot say why it flagged a patient is harder to litigate in either direction.
Three doors a claim can walk through
A patient's claim can target one of three parties, under three different theories. They are not mutually exclusive — a single case can pursue more than one — but they behave very differently.
| Door | Target | Governing theory | Why it is hard |
|---|---|---|---|
| 1 | The clinician | Medical malpractice (negligence vs the standard of care) | Standard of care is set by peer practice, which AI is only starting to shape 12 |
| 2 | The developer | Products liability | Software may be a service not covered as a product; learned-intermediary and black-box hurdles 34 |
| 3 | The health system | Negligent deployment, credentialing, disclosure | Duties are still being defined; turns on governance and procurement 2 |
Door 1 — malpractice against the clinician
The most likely first target is the clinician, judged under the familiar malpractice standard: did they act as a reasonably careful practitioner would in the same circumstances? Applied to AI, this produces a paradox that Price, Gerke, and Cohen identified early. Because the standard of care is defined by what competent peers do, the legally safest way to use an AI recommendation today is as a confirmatory check — following it when it agrees with the care a reasonable clinician would already provide, and treating a divergent recommendation with caution 1. The uncomfortable implication is that the tool is safest to follow precisely when it adds the least, and riskiest to follow when it might add the most: acting on a novel, correct-but-unconventional recommendation exposes the clinician if the outcome is bad, while ignoring it is defensible so long as standard practice has not yet embraced it.
That equilibrium is temporary. The same authors note that the standard of care evolves: once a tool becomes widely accepted, using it becomes the norm, and at that point failing to use it — or overriding a correct output — can itself become the negligent act 1. So the clinician's exposure shifts over time from "you relied on the machine" toward "you ignored the machine," and no bright line marks the crossover.
Mello and Guha sharpen the litigation picture. A core difficulty, they observe, is that a plaintiff often cannot separate a breach of the clinician's duty of care from a malfunction of a specific component of the AI system — the error could live in the model, in the data, in the interface, or in the human response to the output 2. That entanglement makes causation genuinely hard to prove and pushes both sides toward the party who is easiest to reach: the treating clinician. The human-in-the-loop design that keeps a clinician reviewing every output is a patient-safety feature first — and, not incidentally, the reason the clinician remains the natural defendant.
Door 2 — products liability against the developer
The intuitive target — the company that built the model — is in practice the hardest to reach, for several converging reasons the scholarship lays out.
- Product or service? Products-liability law was built for tangible products with design and manufacturing defects. Software, and especially a model delivered as an ongoing service, may be characterized as a service rather than a product, which can place it outside the strict-liability framework and back into ordinary negligence 4.
- The learned-intermediary doctrine. In health care, this doctrine channels a manufacturer's duty to warn through the trained professional who exercises independent judgment. Applied to AI, it tends to route responsibility through the clinician who chose to act on the output, insulating the developer 3.
- The black-box problem. Proving a design defect usually means showing a safer alternative design or an identifiable flaw. When the system's decision process cannot be inspected, that proof is difficult, which is part of why Sullivan and Schweikart question whether the doctrines fit at all 4.
- Contract and preemption. Vendor agreements allocate risk in advance, and for regulated devices, federal law can preempt some state claims — further narrowing the path to the developer.
Maliha, Gerke, Cohen, and Parikh frame the stakes of this imbalance: liability uncertainty that leaves clinicians and health systems bearing most of the risk can chill adoption of beneficial tools, so the policy challenge is to balance safety against innovation rather than to load all exposure onto the point of care 3. Their work is a reminder that where liability lands is more than a question of fairness after an injury — it is also a lever that shapes whether useful AI gets used at all.
Door 3 — the health system and the enterprise layer
The third door is the one growing fastest. Even where the clinician acted reasonably and the developer is out of reach, the organization that selected, validated, deployed, and monitored the tool can face its own duties — in how it credentialed the system, whether it monitored for drift, what it disclosed to patients, and how it governed use. Mello and Guha's recommendations point here: they emphasize transparency and disclosure, including about how a model performs across patient subgroups, as part of managing liability risk 2. The practical upshot is that an institution's AI governance — procurement diligence, local validation, monitoring, and disclosure — is both good safety practice and part of its liability posture. The discipline of appraising the evidence before deployment is covered in how to read an AI validation study, and the privacy obligations that run alongside it in HIPAA and LLMs: what is permitted.
The practical layer: insurance and contracts
Long before a court allocates fault, two private mechanisms do most of the real work. Malpractice insurers price and absorb the clinician's exposure, and vendor contracts allocate risk between the health system and the developer through indemnification, warranty, and limitation-of-liability terms. Mello and Guha emphasize managing liability risk in advance through exactly these levers — governance, disclosure, and contracting — rather than waiting to litigate after harm 2. For most organizations, the negotiated indemnity clause and the insurance tower will decide who actually pays long before the common-law doctrines above are tested in a courtroom. That is also why disclosure to patients — increasingly expected, and in some states now required — is becoming a standard term: it manages the consent dimension of liability at the same time.
Where does the device line sit?
One regulatory distinction shapes all three doors: whether the software is regulated as a medical device. The FDA's clinical decision support guidance turns in large part on whether a clinician can independently review the basis for a recommendation, rather than being expected to rely on it — software that supports independent review is treated differently from software the user is meant to follow 5. That line matters for liability because device status brings its own duties, disclosures, and, in some cases, federal preemption, while non-device software is governed mainly by the general law above. The related concept is set out in the glossary on FDA software as a medical device, and the scale of what has been cleared is tracked in FDA-cleared AI devices by year and specialty. Because outputs can be confidently wrong, the failure mode described in AI hallucination in clinical contexts is exactly the kind of error these doctrines will eventually be asked to allocate.
How to read this page
Four cautions travel with everything above.
First, the law is unsettled and moving. This page describes how mature doctrines are likely to apply, informed by the leading scholarship, in the absence of much decided case law directly on clinical AI. A single appellate decision or a new state statute could change the picture, which is why this page carries a 90-day cadence.
Second, jurisdiction governs. Malpractice and products-liability rules differ by state, and some states are beginning to legislate on AI directly, so the analysis depends on where the injury occurs.
Third, the three doors interact. Where the developer is hard to reach, exposure concentrates on the clinician and the health system; where a tool becomes standard, the clinician's risk migrates from using it to not using it.
Fourth — and most important — this is general information, not legal advice. Any actual dispute or risk-management decision turns on specific facts, contracts, and jurisdiction. Confirm any real question about liability for AI-assisted care with qualified counsel and your risk-management and compliance teams before acting.
Sources and method
This page synthesises the peer-reviewed legal scholarship on clinical-AI liability: the standard-of-care analysis and its paradox from Price, Gerke, and Cohen 1; the litigation and risk-management framing from Mello and Guha 2; the safety-versus-innovation and products-liability analysis from Maliha, Gerke, Cohen, and Parikh 3; and the tort-adequacy critique from Sullivan and Schweikart 4 — together with the FDA's clinical decision support guidance for the device line 5. Every characterization above is tied to the primary source cited beside it. We revisit this page every 90 days and whenever a court, legislature, or regulator issues something that changes how liability for clinical AI is allocated. Statuses and the state of the law are current as of July 2026.