The standard of care will absorb AI without granting it immunity

In a malpractice claim, plaintiffs typically argue that a clinician or institution breached the standard of care. The standard is not perfection. It is reasonableness measured against professional norms.

As AI tools become more common, professional norms will shift, and the standard of care will shift with them. That movement does not imply that using AI will be negligent or that refusing AI will be negligent. It implies that clinicians and institutions will need to justify their choices.

The American Medical Association has taken a position that is both cautious and institutionally significant. It emphasizes transparency, responsibility, and the need to address liability arrangements when AI systems are deployed, as described in the AMA’s Augmented intelligence in medicine page and its principles PDF. This matters because professional guidance often becomes a reference point in litigation.

A clinician who uses an LLM for clinical reasoning will be asked: did you understand its limitations, did you verify its claims, and did you document your reasoning? Those questions are uncomfortably familiar. They resemble how malpractice law has treated other decision supports.

Product liability will be tested, and vendors will resist the label

A parallel track involves product liability. If an AI-enabled tool is framed as a defective product, a plaintiff may pursue the developer or vendor under theories such as design defect, failure to warn, or manufacturing defect.

Vendors will often argue that their tools are decision aids that require clinical judgment, invoking the learned intermediary concept. Plaintiffs will argue that the vendor designed the system to influence clinical decisions, marketed it as reliable, and failed to warn adequately about known limits.

This is where regulatory classification becomes consequential.

Regulation will define the border between office software and medical device

The FDA has spent the last several years clarifying which software functions qualify as medical devices and which are excluded. The distinction is not academic; it determines oversight expectations, evidence standards, and postmarket responsibilities.

In early statements and frameworks, FDA emphasized a total product lifecycle approach for AI and the need to manage iterative modification. The agency’s discussion paper, Proposed Regulatory Framework for Modifications to AI/ML-Based Software as a Medical Device, and its public overview, Artificial Intelligence in Software as a Medical Device, have become standard reference points.

Clinical decision support software occupies a particularly contentious boundary because it can be framed as informational. FDA’s newly updated guidance, Clinical Decision Support Software, published January 6, 2026, clarifies the scope of oversight for CDS intended for healthcare professionals and reiterates how non-device CDS criteria are interpreted.

Why does this matter for liability? Because regulatory framing affects what courts may see as reasonable diligence. A health system using a tool that would plausibly be regulated as a device, while treating it as generic text software, may appear reckless.

The Office of the National Coordinator for Health IT has also advanced transparency requirements through the HTI-1 Final Rule. The decision support intervention requirements aim to surface training data and performance context for health IT products. This strengthens the evidentiary record available to clinicians, and it also raises the bar: if a system disclosed limits and an institution ignored them, the record may be damaging.

Outside the United States, the EU Artificial Intelligence Act establishes obligations for high-risk systems and links AI requirements to regulated products. Even for U.S. litigation, the EU approach may influence vendor practices and expectations around risk management documentation.

Privacy law will create liability of a different kind

Malpractice is not the only liability channel.

Privacy and consumer protection law will attach to LLM deployments when patient data is mishandled, leaked, or used outside agreed purposes.

HIPAA compliance remains central for covered entities and business associates, yet many LLM use cases involve consumer tools. Patients or staff may paste PHI into systems without appropriate contractual protections.

A practical marker of whether a vendor is appropriate for PHI is the willingness to sign a business associate agreement. OpenAI maintains guidance on obtaining a BAA for API use cases, as described in How can I get a Business Associate Agreement (BAA) with OpenAI?. Health systems should treat BAAs as necessary but insufficient; they govern contractual responsibility, not technical security.

Federal agencies have also tightened attention to consumer health data. The FTC has emphasized obligations under the Health Breach Notification Rule and published a final rule update in the Federal Register. These requirements can capture health apps outside HIPAA and can pull vendors and service providers into a notification and enforcement ecosystem.

HHS has issued guidance on tracking technologies used by HIPAA-regulated entities, reflecting concern that seemingly innocuous web data can become identifiable health information, as described in Use of Online Tracking Technologies by HIPAA Covered Entities and Business Associates.

These developments imply a liability regime where data governance errors can become enforcement actions and reputational collapse even when clinical harm is not proven.

Courts will ask whether the institution acted like it understood risk

A hospital that deploys LLMs and treats them as ordinary office tools will struggle in litigation.

Risk management practices are emerging in the literature and in institutional memos. A 2025 briefing from the Integrated Healthcare Association, Understanding Liability Risk from Using Healthcare AI Tools, discusses policy questions such as whether patients should be notified and how developers should share performance information.

Academic and clinical commentary has begun cataloging malpractice themes for LLMs. A 2025 review in the biomedical literature discusses legal liability considerations for generative AI in healthcare and cites a dedicated legal review on LLM malpractice liability, available through Ethical and practical challenges of generative AI in healthcare.

These sources reinforce a practical conclusion: institutions will be judged on governance as much as on outcomes. Courts and regulators often evaluate whether the institution followed a recognizable safety process.

A defensible governance stack

A defensible approach to LLM deployment in clinical care can be organized into a governance stack.

1) Scope definition

Define which tasks are permitted: documentation drafting, patient instruction rewriting, message drafting, and chart summarization are easier to defend than autonomous triage or diagnosis.

2) Human responsibility

Assign a responsible clinician or committee for each use case. Responsibility should be explicit.

3) Training and competency

Train users on limitations, including hallucination, omission risk, and prompt sensitivity.

4) Vendor diligence

Require documentation of training data provenance, performance validation, and update practices. Contractual terms should address indemnity, incident response, and audit support.

5) Auditability

Retain prompts, outputs, and edits. LLM use without a trace invites adverse inference in litigation.

6) Patient disclosure policy

Develop a policy on when patients are told that AI assisted drafting or decision support. This is contested territory, yet the absence of policy is indefensible.

7) Monitoring and incident response

Track errors, near misses, and patterns of misuse. Create a route for rapid suspension of a tool.

8) Privacy and security controls

Align with HIPAA security practices, and consider emerging guidance on AI within security frameworks, including discussions in Updating HIPAA Security to Respond to Artificial Intelligence.

This stack does not eliminate risk. It makes risk legible.

The deeper shift: medicine becomes partially software governance

Hospitals have long governed drugs, devices, and infection control. They now have to govern language systems.

That shift has social consequences. Clinicians will need to accept that their documentation is no longer purely their own and that software may influence their style of reasoning. Patients will need to decide what disclosures they expect and what level of AI involvement they consider material.

The legal system will not resolve these questions quickly. Courts move case by case. In the meantime, institutions that treat LLM deployment as a patient safety intervention will be better positioned than those that treat it as a productivity hack.

The coming reckoning is unlikely to be theatrical. It will be procedural. It will be won by whichever side can show a careful paper trail.

What a court will want to see

Legal liability in medicine is rarely decided by novelty. It is decided by documentation. If a clinician relies on a generative tool, the later question will be whether reliance was reasonable and whether the process met professional expectations.

The most defensible record will show five things. First, the tool’s role was bounded. Second, the clinician exercised independent judgment. Third, the clinician understood the tool’s limitations. Fourth, the patient was informed when disclosure was material. Fifth, the organization maintained oversight.

Professional policy statements have begun to sketch the contours of that oversight. The AMA principles for augmented intelligence call for transparency, equity, and clear accountability, including attention to liability when system failure contributes to harm. Risk managers have also started writing operational checklists, such as the liability risk guidance from the Integrated Healthcare Association, which frames disclosure and vendor contracting as core control points.

Contract clauses that stop being boilerplate

• Data handling terms that match HIPAA obligations and local policy.
• Indemnification for model defects that are within the vendor’s control.
• Audit rights for performance monitoring and incident investigation.
• A change management clause that requires notice when the model is updated.
• A clear statement about whether the tool is intended for clinical decision support under the FDA’s CDS guidance.

A final point is practical: the institution should decide whether, and how, patients are told that AI contributed to a recommendation. The question is not philosophical. It is evidentiary. When disclosure is inconsistent, it becomes harder to defend the adequacy of informed consent.

Documentation as the quiet center of liability

Health law has long favored artifacts over intentions. In litigation, what matters is rarely the clinician’s private reasoning. What matters is what can be demonstrated. For LLMs, that means logs, policies, and a defensible explanation of why the tool was used.

This is where the AMA Principles for Augmented Intelligence intersect with ordinary risk management. If a hospital deploys an LLM, it should be able to answer three questions without improvisation.

First, what problem was the system designed to solve, and what problems was it never meant to address. Second, how does the system behave when it is uncertain. Third, who had authority to override the system, and what training supported that authority.

Courts are likely to treat those questions as variants of foreseeability. A risk that was foreseeable and unaddressed becomes a liability magnet. A risk that was catalogued, mitigated, and monitored remains a dispute, yet it becomes a dispute that the defense can argue with evidence.

A minimalist recordkeeping standard

• Preserve prompts and outputs for high-impact use cases, such as triage suggestions or medication related summaries.
• Record the clinician edits and the final signed note.
• Track model version, retrieval sources when RAG is used, and the time of generation.
• Retain incident reports when a model output is suspected of contributing to harm.

A system with disciplined recordkeeping is easier to improve and easier to defend. The effort feels bureaucratic, yet it is often the difference between an adverse event that prompts learning and an adverse event that prompts years of litigation.