Skip to main content

When medical AI contributes to patient harm, liability in the US usually falls first on the clinician, through ordinary malpractice law, and on the hospital that deployed the tool. Suing the AI developer is harder, because courts have been reluctant to treat software as a product. The rules are unsettled and vary by jurisdiction and contract.

A young adult with a family history of congenital heart defects goes through a cardiac screening program. Software analyzes the results and labels them “normal.” The physicians accept that output. Weeks later, the patient dies.

That is the outline of Sampson v. HeartWise Health Systems, a 2023 case described by Michelle Mello and Neel Guha of Stanford in their review of AI liability in the New England Journal of Medicine. The court let claims proceed against the physicians on the theory that they should have scrutinized the software’s output or reached the right answer themselves. The claim for ordinary negligence against the software developer was dismissed. One reason: the developer’s licensing agreement gave physicians final decision-making responsibility.

That case captures the current settlement in miniature. When AI is wrong, the person holding the pen is the easiest to sue. My argument is that this allocation has a predictable side effect. It pushes clinicians toward a defensive pattern: follow the AI when it agrees with standard care, and override it when it does not. That quietly neutralizes AI in the very cases where it might add the most.

This article is general information about how liability rules work, not legal advice. It reflects the position as of May 2026.

Who is liable when AI gives a wrong diagnosis?

In the United States there are three main targets, and each works differently.

The clinician is judged by medical malpractice law. The question is whether the clinician’s care met the standard of care, usually defined by what a reasonable physician in the same specialty would have done. Using an AI tool does not change that test. It only adds a new fact: what the tool said, and what the clinician did with it.

The hospital or health system can be liable directly, for negligent selection, implementation, training or maintenance of a tool, and indirectly, for the acts of its employed clinicians. As AI becomes a matter of institutional policy rather than individual choice, this exposure grows.

The developer is the hardest to reach. Product liability law was built for tangible goods. Mello and Guha reviewed 803 court cases and analyzed 51 judicial decisions involving physical injury from AI and other software, inside and outside healthcare. They found that courts have been reluctant to treat software as a “product,” and that plaintiffs often fail when they cannot point to a specific design defect rather than simply the fact that the software erred. For some FDA-authorized devices, federal preemption can block state-law claims altogether.

They identified three trends worth quoting in substance. Plaintiffs struggle when they cannot explain how and why software failed, which is hard for opaque models. Because AI performs differently across patient groups, it is hard to prove a physician should have known an output was unreliable for a particular patient. And courts have so far not distinguished AI from ordinary software.

How do juries judge doctors who follow or reject AI?

The most useful evidence here is experimental. In a study published in the Journal of Nuclear Medicine in 2021, Kevin Tobia, Aileen Nielsen and Alexander Stremitzer showed a nationally representative sample of 2,000 US adults one of four scenarios. An AI system recommended either standard or nonstandard care, and the physician either accepted or rejected the recommendation. The patient was harmed in every case. Participants judged whether the physician had acted reasonably.

The results pointed to a simple rule. Physicians who accepted AI advice to provide standard care were judged most favorably, and rejecting that advice made them look worse. When the AI recommended nonstandard care, rejecting it did not give physicians the shield one might expect. Lay jurors were not hostile to AI, but they still anchored on the standard of care.

Pair that with earlier legal analysis. In JAMA in 2019, W. Nicholson Price, Sara Gerke and I. Glenn Cohen argued that because malpractice law rewards adherence to the standard of care, physicians face the most risk when they follow an AI recommendation that departs from it. Their conclusion was that current law pushes physicians to use AI mainly as a confirmatory tool.

Put these together and the rational strategy for a clinician is clear. Treat AI as a second opinion that counts only when it agrees with what you would have done anyway.

Why does clinician liability lead to defensive overriding?

Think about where AI adds value. If a model only ever agrees with standard practice, it saves time but changes few decisions. Its clinical value lies in the cases where it sees something the clinician would miss: the subtle nodule, the atypical presentation, the patient whose risk score says “act now” even though they look well.

Those are exactly the cases where following the AI means departing from what a typical colleague would do. If harm follows, the clinician who followed the AI is exposed. The clinician who overrode it and did the conventional thing is protected, even if the AI was right.

So the incentive runs one way. Override when the AI is novel, follow when it is conventional. At scale, that pattern turns AI into an expensive rubber stamp. It also produces a skewed record. Hospitals evaluating a tool will see that clinicians “disagree” with it often, and may conclude the tool is weak, when the disagreement is partly legal self-protection.

There is a second-order problem. As AI becomes common in a specialty, the standard of care itself may shift. At some point a reasonable radiologist may be expected to use an AI second reader, and failing to consult one could become negligent. Mello and Guha raise this possibility directly: not adopting a tool could eventually be viewed as the harmful decision. The clinician is then caught both ways, liable for ignoring AI and liable for trusting it.

A worked example: the same error, three outcomes

Here is a hypothetical to show how the pieces interact.

A hospital deploys an AI tool that flags pulmonary embolism on CT. A patient’s scan is read at night. The tool flags a small embolism. The on-call radiologist, tired and seeing a subtle finding, disagrees and reports the scan as negative. The patient is discharged and later returns with a larger clot.

Scenario one: the radiologist overrode the tool. The plaintiff’s lawyer now has a timestamped record that the software flagged the finding. Whether the radiologist breached the standard of care still turns on what a reasonable radiologist would have seen, but the AI’s flag is powerful evidence. The existence of the tool increased the radiologist’s exposure.

Scenario two: the tool missed it, and so did the radiologist. The radiologist is judged as before, on whether a reasonable radiologist would have caught it. The hospital may face questions about whether the tool was validated for its scanners. The developer is hard to reach, especially if its license makes the radiologist responsible for final interpretation.

Scenario three: the tool flagged a false positive, and the radiologist followed it. The patient is anticoagulated and has a major bleed. The radiologist followed the AI into a departure from what a reasonable colleague might have done. This is the case the Price, Gerke and Cohen analysis warns about.

Notice that in each scenario, the developer’s position is the most secure and the individual clinician’s the least. That is the allocation this article is about.

What is the strongest argument for keeping liability with clinicians?

The best counterargument is that it is right. Clinicians are licensed professionals who make the final decision. They see the patient, not just the data. If they could shift blame to software, they might defer to it too readily, which is automation bias with a legal subsidy. The Federation of State Medical Boards took this view in 2024 policy guidance, holding physicians accountable for decisions they make with AI assistance.

There is also a practical point. Making developers strictly liable for every error could make them unwilling to sell tools at all, or push prices up so far that only rich hospitals could afford them. Some of the most useful AI may never reach the market.

I accept much of this. Clinicians should stay accountable for their judgment. The problem is the asymmetry. The developer designs the model, controls the training data, sets the thresholds and writes the contract. The clinician usually knows little about any of that. Liability that ignores who controls the risk will produce behavior that manages legal exposure rather than patient risk. A fairer settlement would give developers a share of responsibility for defects in the model, leave clinicians responsible for unreasonable use, and hold hospitals responsible for deployment.

That is roughly where Europe is heading. The EU’s revised Product Liability Directive, adopted in 2024, explicitly treats software, including AI systems, as a product, with rules that ease the burden of proof for claimants in complex technical cases. Member states must apply it to products placed on the market from December 2026. The separate AI Liability Directive, which would have created fault-based rules specific to AI, was dropped by the European Commission in 2025.

What this means for hospitals, clinicians and developers

For hospitals, contracts are the main lever today. Mello and Guha point out that health systems are in a buyer’s market and can negotiate. Seek indemnification for errors in model output, minimum insurance requirements, access to validation and performance data, and notice of model changes. Our checklist on buying digital health covers where these questions belong in procurement. Also document how each tool was validated locally and who oversees it, because negligent deployment is a hospital risk, not just a clinician risk. Since May 2025, federal rules under Section 1557 of the Affordable Care Act have also required covered entities to make reasonable efforts to identify and mitigate discrimination risks in patient care decision support tools.

For clinicians, document reasoning when you disagree with an AI output, and when you follow one that departs from usual practice. A short note explaining why is the best protection in either direction. As we argued in the real risk of AI-drafted patient messages, the dangerous moment is agreement without thought.

For developers, disclaimers that assign all responsibility to the clinician may win cases today. They will not win trust. Tools that expose their reasoning, flag uncertainty and document where they perform poorly make reasonable use easier, and reasonable use is what protects everyone.

For policymakers, the question is not whether to create AI-specific liability but how to align it with control.

Frequently asked questions

Can a patient sue an AI company for a wrong diagnosis?

They can try, but it is hard in the US. Courts have often refused to treat software as a “product” for product liability purposes, plaintiffs must usually identify a specific design defect, and federal preemption may bar claims for some FDA-approved devices. Contract terms that give clinicians final responsibility have also helped developers win dismissals. Outcomes vary by state and case.

Is a doctor liable for ignoring an AI recommendation?

Potentially. The legal test is still whether the doctor met the standard of care. If the AI flagged something a reasonable physician would have acted on, the record of the ignored flag can be strong evidence of negligence. As AI tools become standard in a specialty, failing to use or heed them may itself be argued to fall below the standard of care.

Does malpractice insurance cover AI-related errors?

Generally, malpractice policies cover a clinician’s professional services, and AI-assisted decisions are still the clinician’s professional services. But policy wording varies, and some insurers are reviewing how they treat AI. Clinicians and hospitals should ask their insurers directly whether specific tools, especially autonomous ones or generative AI documentation tools, raise any coverage questions.

Who is responsible when an autonomous AI makes a decision without a doctor?

This is the least settled area. When no clinician reviews the output, the usual malpractice framework fits poorly, and responsibility shifts toward the deploying organization and the developer. Hospitals using autonomous tools should get the developer’s acceptance of responsibility in writing, with insurance behind it.

How can hospitals reduce AI liability risk?

Validate tools locally before use, monitor performance after go-live, train staff on each tool’s limits and document oversight roles. In contracts, seek indemnification for model defects, insurance requirements and access to validation data. Keep records of how clinicians used each tool. Most of all, match oversight to risk: a scheduling tool and a diagnostic tool deserve very different scrutiny.

The takeaway

Liability law is not neutral about how clinicians use AI. By placing risk mainly on the person who acts on the output, it rewards using AI to confirm the obvious and punishes following it into the unusual, which is where its value lies. Until responsibility tracks control, expect clinicians to override good advice for legal reasons, and expect hospitals to misread that as a sign the tool does not work.

If you are a clinician, has fear of liability changed how you use AI tools? We’d like to hear honest answers.

Abhishek Shankar

Abhishek Shankar is a three-time founder and CEO of MyBabyBridge, which uses AI and data to make IVF more accessible. He writes about the gap between what works in health pilots and what survives at scale, covering financing, workforce, digital health and equity. He writes more at abhishek-shankar.com.

Leave a Reply