AMA Draws a Harder Line on Liability for Clinical AI
The American Medical Association is trying to redraw one of the most consequential fault lines in digital medicine: who is responsible when a clinical AI tool contributes to patient harm. Its newest issue brief assigns distinct duties to physicians, AI developers and healthcare organizations that deploy these systems, pushing back on the idea that clinicians should serve as the final safety barrier for tools they did not build and often cannot fully inspect.
The timing is telling. Clinical AI is moving from back-office automation into real decision support, and in some settings it is beginning to act with partial autonomy. As these tools become more deeply embedded in care delivery, liability can no longer be treated as a vague afterthought. The framework instead treats it as a core design and implementation problem.
Physicians Are Still Accountable for Judgment, Not Invisible Failures
Under the AMA framework, physicians remain responsible for exercising independent clinical judgment when they use AI-assisted recommendations. They are expected to interrogate outputs, recognize when an AI suggestion does not fit the patient in front of them, and override the machine when necessary. In other words, the physician’s role is not passive endorsement; it is active clinical reasoning.
The AMA draws a sharp boundary around what physicians can reasonably be blamed for. If an AI-driven clinical decision support tool omits critical data, produces a flawed recommendation, and hides the error from the clinician, the physician should not be held responsible for the resulting harm. Jennifer Goldsack, who leads the AMA Center on Digital Health and AI, said physicians are being asked to function as a safety net for failures outside their control, including failures they may not even be able to identify.
One sentence captures the practical consequence: a clinician cannot catch a defect that the system itself conceals.
That point matters because many AI failures are upstream problems, not bedside mistakes. If the model was poorly trained, deployed without proper validation, or left to operate in a workflow where its limitations are opaque, the clinician at the point of care may be the last person who can meaningfully intervene, but not the person who created the risk.
Developers Carry Responsibility for Safe Design and Transparent Limits
The AMA places the most direct technical burden on AI developers. They are expected to design tools that are safe, accurate and usable in clinical practice, and to give users enough information to understand how the system performs and where it can fail. The framework explicitly favors usable performance data and known limitations over generic warnings or disclaimers.
That distinction is central. A disclaimer does little if it merely tells a physician that an algorithm may be wrong without explaining when, why or under what conditions the error is likely to occur. Clinicians need to know the intended use, the performance characteristics and the operational limits of the tool, because those details determine whether an output is trustworthy in a specific patient scenario. In a high-stakes setting, vague caution language is not a substitute for engineering discipline.
The AMA’s logic is straightforward: liability should follow control. The party best positioned to prevent a defect should carry the responsibility for preventing it. If the risk lies in the model architecture, the training data, the validation process or the interface design, then the developer is the stakeholder with the greatest ability to fix it before harm reaches the bedside.
Health Systems Must Vet the Tool Before It Reaches the Exam Room
Hospitals, health systems and physician practices enter the framework as deployers, and their responsibilities are more than administrative. Before asking clinicians to rely on a tool, these organizations are expected to evaluate whether it is suitable for the intended clinical setting, train staff on how to use it and monitor performance after deployment.
That post-deployment oversight is critical because AI does not stay static. Models can drift as patient populations, clinical workflows and input data change over time, and performance can degrade long after an initial go-live decision. A system that works reasonably well in one setting may behave differently in another, especially if the organization has not created a formal process for tracking adverse events or detecting declining accuracy.
Training remains a weak point. The AMA cited its 2026 survey showing that a quarter of physicians received no AI training, while 92% wanted more of it. Those numbers describe a familiar mismatch: organizations are deploying technology into care environments faster than they are preparing clinicians to use it safely. Without training, even a well-built tool can become a liability multiplier, especially if users do not understand what the system can and cannot do.
Patient Harm Needs a Clear Path to Recourse
The AMA framework also argues that patients harmed by clinical AI should have a route to seek recourse, including compensation. Goldsack framed that as part of a broader safety architecture: when responsibility is clear, patients are more likely to find the proper party for redress, and harm becomes less likely in the first place because each stakeholder knows what it is responsible for preventing.
This is where the framework moves beyond abstract governance. It does not just ask who should apologize after an error; it asks who had the capacity to stop that error before it reached the patient. In a system where responsibility is diffuse, everyone can point elsewhere. In a system with defined duties, the risks become more visible, and the incentives to validate, train and monitor become stronger.
The AMA’s position also reflects mounting pressure from the front lines of medicine. Physicians have increasingly embraced AI for decision support and administrative relief, but they also want clear liability rules before the technology becomes routine. A third of physicians in an AMA survey identified clear liability frameworks as the main driver of AI adoption, suggesting that trust in these systems depends as much on legal architecture as on technical performance.
The FDA Debate Is Moving Toward Developer Accountability
The liability framework lands in the middle of a larger policy fight over regulation of generative AI in medicine. In recent comments to the Food and Drug Administration, provider groups including the AMA argued that AI developers should be responsible for monitoring healthcare devices that use generative AI. Their concern is practical: placing that burden on clinicians or health systems could stretch already strained organizations, especially smaller and rural practices that lack the staff and technical capacity to oversee complex AI systems.
As clinical AI becomes more autonomous, the pressure to assign responsibility will only intensify. The central issue is no longer whether AI will enter healthcare; it is whether the legal and operational structure around it will match the speed of deployment. Without that structure, clinicians may be left carrying the consequences of failures they neither designed nor could detect, while vendors and deployers remain too far removed from the patient to feel the cost of their decisions.
The AMA’s framework does not resolve every liability dispute, but it does narrow the question to something more concrete: who controlled the risk, who could have prevented it and who must answer when the system fails.