Clinical AI Liability Turns on Evidence

When a clinical AI tool is tied to patient harm, nobody will start by asking which model produced the output. They will ask who could see which patient records, under whose authority, and where the proof of that access lives. That question lands on the health system, and it lands whether the tool was built by a vendor, tuned by an internal team, or simply plugged into the electronic health record by a well-meaning department.

The American Medical Association has now given that question a framework. In a release dated October 29, 2026, the AMA described a model for clinical AI liability that divides responsibility among three parties according to what each can control. Developers answer for the safety and effectiveness of what they build. Physicians answer for the clinical judgment they can meaningfully exercise. Healthcare organizations, the deployers, answer for how AI systems are selected, implemented, governed, and monitored once they are live in a hospital.

The framework is a policy position, not a statute, and nothing in it changes a court’s duty analysis overnight. But for a healthcare CISO or a Chief Compliance Officer, the third party in that list is the one with a documentation problem. Every verb attached to the deployer, selected, implemented, governed, monitored, is a verb that either leaves a record or leaves a gap. An investigator, an insurer, or opposing counsel will go looking for that record, and the data layer is where most of it must come from. This is exactly the territory where Kiteworks secure data exchange is built to help, by governing and logging how both people and AI systems reach sensitive content so the evidence exists before the question arrives.

Key Takeaways

1. Liability is being split by control.

The AMA’s October 29, 2026 framework would assign accountability to developers, health systems, and physicians according to what each can control.

2. Health systems own the governance record.

Under the framework, deployers answer for how AI is selected, implemented, governed, and monitored, and each of those verbs produces evidence or exposes a gap.

3. HIPAA already applies.

Unique user identification and audit controls are in force today, the Security Rule contains no AI exemption, and waiting for the proposed overhaul is not a plan.

4. The evidence gap is measurable.

In Kiteworks research, half of surveyed organizations could not produce a complete AI data access audit record within one business day.

5. Evidence is the part you can build now.

A governed data layer that ties every AI request to a named human, enforces policy, and writes a tamper-evident log supports your defense without pretending to fix clinical accuracy.

What the AMA Framework Says and Does Not Say

Start with the shape of the proposal, because the details matter for what a compliance office must do with it. The AMA’s stated principle is that liability should follow the authority to prevent or reduce harm. A developer controls how a tool is designed, tested, and documented, so the developer carries risk that originates there. A physician controls the clinical decision at the bedside, so the physician carries responsibility for judgment they can truly exercise. A health system controls which tools enter the building, who is trained to use them, and how they are watched afterward.

The language aimed at health systems is direct. The release says healthcare organizations should be accountable for how AI systems are selected, implemented, governed and monitored in real-world settings. That is a governance standard, and governance standards are proven with documents, logs, and decisions that can be reconstructed, not with intentions.

The physician language is just as pointed, and it works in the health system’s disadvantage. The AMA says physicians should answer for clinical judgment they can meaningfully exercise, and its release adds that physician oversight cannot stand in for adequate evidence and appropriate system design. Read that twice. If a clinician cannot be expected to catch a flaw that was invisible at the point of care, the accountability for that flaw must sit somewhere else, and the framework points toward the developer and the organization that chose, configured, and monitored the tool.

The framework also speaks to patients. It says patients must retain meaningful avenues for seeking accountability and appropriate remedies when harm results from defective AI systems or other actionable failures. That sentence is the reason the evidence question matters. Recourse is only meaningful if someone can establish what happened, and establishing what happened is a records problem long before it is a legal one.

What the framework does not do is equally important. It does not create a new cause of action, it does not amend HIPAA, and it does not tell hospitals which technical controls to buy. It is a statement of where the AMA believes the lines should be drawn, and it will be used the way professional-society positions are usually used, as a reference point in policy debates, in contract negotiations, and eventually in arguments about the standard of care. A compliance leader who treats it as a preview of the questions coming, rather than a rulebook already in force, will read it correctly.

Why Deployers Carry the Evidence Burden

It helps to be honest about why the deployer role is so exposed. Developers hold the model, the training data, and the test results. Physicians hold the clinical relationship. Health systems hold something less glamorous and more discoverable, namely the access configuration, the integration code, the service accounts, the vendor contracts, the training records, and the logs. When a dispute begins, those artifacts are the ones a records request reaches first.

Training is a good place to see the gap. The AMA’s 2026 physician survey, fielded from January 15 to February 2, 2026, reached 1,692 physicians, and 27 percent of them reported receiving no AI training from any source while 92 percent said they want more education and training. Nobody would call that a surprising result. It is, however, a result a plaintiff’s lawyer would find useful, because the framework makes deployers responsible for how tools are implemented and a workforce that has not been trained is part of implementation.

The same survey shows why the liability conversation has moved from the margins to the center. Among the 1,419 physicians who answered a question about regulatory actions that would increase their trust in AI, clear liability frameworks was the action most often ranked first, chosen by 31 percent. That ranking suggests physicians want the rules of the road written down before they carry the risk. Health systems that cannot show how a tool was vetted, who may use it, and what data it can touch will have a hard time answering that concern with anything more than reassurance.

So the deployer burden comes down to a few plain questions a CISO can ask this week. Which AI tools are in clinical or operational use, including the ones nobody formally procured? What patient data can each of them reach? Is each tool, or each agent acting for it, tied to a person who is accountable for what it does? And if a regulator asked for the record of that access from last Tuesday, how long would it take to assemble? The sections below take those questions in turn.

HIPAA Regulates the Data, Not the Model

Healthcare organizations have a structural advantage here, even if it rarely feels like one. HIPAA does not care how clever the model is. It regulates what happens to protected health information, and it contains no AI exemption. When an AI assistant retrieves a chart, a summary tool pulls notes into a prompt, or an agent assembles records for a prior authorization, the Security Rule’s access and audit requirements apply to that activity as surely as they apply to a nurse logging in to the record system.

Two provisions deserve a plain reading. Under 45 CFR 164.312, unique user identification is a required implementation specification, which means assigning a unique name or number for identifying and tracking user identity. The audit controls standard requires hardware, software, or procedural mechanisms that record and examine activity in information systems. Neither says anything about whether the actor is a person or a program. Both say a great deal about whether you can reconstruct who did what.

That is where common AI architectures run into trouble. An assistant that queries patient data through one shared service account makes unique user identification hard to demonstrate, because the log shows the service account and not the clinician or workflow that prompted it. A system prompt that carries broad credentials has the same weakness. These designs are fast to build, which is why they are everywhere, and they are exactly what an auditor will probe because they blur the line between a human decision and a machine action.

The picture on encryption is more nuanced and worth stating carefully. Today, encryption of electronic protected health information is an addressable specification under the same section, meaning organizations must assess it and implement it or document an equivalent alternative. The Office for Civil Rights published a proposed rule in January 2025 to strengthen the Security Rule, and Holland and Knight reported in July 2026 that the projected publication date of the final rule had moved to July 2027, according to the federal regulatory agenda. A proposal is not a requirement. But a health system that waits for the final text before it works out how AI tools touch patient data is waiting on a deadline that does not govern the conduct already in front of a plaintiff or an auditor.

The practical takeaway is that the strongest frame for a healthcare compliance leader is a plain one. HIPAA regulates the data, and it will be applied to AI access to that data under the standards already on the books. The HIPAA Security Rule does not need to be rewritten for an investigator to ask who accessed a record. It only needs the record to exist.

The Evidence Gap Behind the Framework

If evidence is the point, how ready are organizations to produce it? The honest answer is that most are not, and the numbers are consistent across sources that have nothing to do with each other.

Start with audit trails for AI access. In the Kiteworks Data Security and Compliance Risk: 2026 Annual Survey Report, based on responses from 459 security, compliance, and technology professionals collected in the second quarter of 2026, 50 percent of organizations said they could not produce a complete AI data access audit record within one business day, and only 17 percent could produce one within an hour. Two cautions apply. The findings are self-reported, and the figure covers all industries, so it should not be read as a healthcare number. What it does show is how ordinary the gap is. Half the field would miss a one-day deadline.

That deadline is not arbitrary. A regulator’s clock, a litigation hold, or an insurer’s questionnaire does not wait for a week of manual log stitching. An organization that needs several systems and several teams to answer one access question has a process, but it does not have evidence in the sense an auditor means, which is a record that is complete, trustworthy, and available on demand.

Governance confidence tells the same story from a different angle. Grant Thornton’s 2026 AI Impact Survey, released April 13, 2026, found that 78 percent of the nearly 1,000 senior business leaders it surveyed lack full confidence that their organization could pass an independent AI governance audit within 90 days. The survey is not limited to healthcare, and Grant Thornton sells advisory services in this area, so treat the number as a reading of executive confidence rather than a measured audit failure rate. Still, the phrase “within 90 days” is revealing. Leaders are not saying they have no governance. They are saying they could not prove it quickly.

Healthcare-specific data points in the same direction. A benchmark report from SAI360 and Strategic Management Services, built on a 2025 survey of 261 covered entities and business associates, found that 86 percent of respondents said they detect HIPAA incidents through employee reports to management or compliance, while only about 35 percent use automated monitoring of user access to protected health information and 21 percent use automated review of electronic health record audit logs. The sample is self-selected and skewed toward hospitals and behavioral health, so it describes the people who answered rather than the whole sector. Even so, it suggests that in many organizations the first alarm is a colleague noticing something, not a system producing a record.

Put the three together and a pattern emerges that has little to do with any particular model. The weak point is not intelligence. It is attribution, meaning knowing which identity touched which data under which policy, and being able to show it fast. AI tools only make that weakness more expensive, because they act at machine speed and often through accounts that were never designed to carry accountability.

What Defensible Evidence Looks Like for AI Access to PHI

An investigator reviewing an AI-related incident will tend to ask the same four questions in some order. Who or what accessed the data? What exactly was accessed? Under what policy was that access allowed? And can you show that the record of it has not been changed? A defensible program is one that can answer all four without a scramble.

Take the first question. An AI request is not an anonymous event. Someone configured the tool, someone approved its use, and in many workflows a specific clinician or staff member triggered the request. Evidence quality depends on tying the request to a named human who is accountable for it, rather than to a shared credential. Treat the AI agent as one more identity class under the same governance that already covers employees, contractors, and partners, with one set of policies, one identity model, and one record of what each identity did.

The second question is about scope. The HIPAA minimum necessary principle asks organizations to limit use and disclosure of protected health information to what is needed for the purpose. When an assistant can reach an entire repository, that principle depends on policy enforced at the point of access rather than on the good behavior of the tool. Role-based and attribute-based access control give a compliance team a way to express who may see what, under which conditions, and to apply the same rules to a person and to an agent acting for a person.

The third question is about policy. It is not enough that access was permitted. A reviewer wants to see which rule allowed it. That means the decision itself, and not only the outcome, belongs in the record. A policy engine that evaluates each request and logs the result gives a CCO something more useful than a list of events. It gives an explanation.

The fourth question is about integrity. A log that can be edited by the people it describes is a weak exhibit. Tamper-evident audit trails, forwarded to a security information and event management platform that the compliance team can query, turn a pile of events into evidence.

This is the design logic behind Kiteworks Compliant AI and the Secure MCP Server. When an AI assistant connects to enterprise content through that path, each request is linked to the identity of the human who authorized it, checked against attribute-based policy, protected with FIPS 140-3 validated encryption, and written to a tamper-evident audit trail that can be forwarded to the organization’s SIEM. The data policy engine applies the same governance to people and to AI agents, so the compliance team reviews one record rather than reconciling several. The CISO Dashboard and a HIPAA compliance report support the reporting side, helping demonstrate how sensitive content is being accessed and shared.

It is worth being exact about what this does and does not cover, because overclaiming is its own liability. This approach governs access to data. It does not judge whether a clinical recommendation was accurate, it does not replace a developer’s obligation to monitor a model’s performance, and it does not substitute for incident response when an AI tool gives a clinician bad advice. It applies to AI traffic that is routed through the governed layer, and its ability to treat content as protected health information depends on how that content is labeled or classified. The value is narrower than a promise to make AI safe, and more useful for it. When the question is who accessed what, the answer is already on file.

Where the Developer’s Duty Ends and Yours Begins

A governance program built around evidence of data access should not be mistaken for the whole of clinical AI safety, and the AMA is careful about the division of labor. In comments to the FDA on generative AI medical devices, released October 19, 2026, the AMA called for stronger post-market surveillance that tracks a device’s performance throughout its lifecycle, including after deployment, and said that manufacturers must remain accountable for the performance of their products. It also said clinician oversight cannot substitute for rigorous evidence that a device performs safely and reliably in its intended setting.

For a health system, that division carries two lessons. First, a vendor’s performance monitoring and a deployer’s access governance are different obligations, and a contract that covers only one leaves a hole. Second, the deployer cannot hand the whole problem to the vendor. Even if the manufacturer is primarily accountable for how a model performs, the hospital still decides who can use the tool, which records it can reach, and how its activity is logged. Those decisions are the hospital’s, and so is the proof of them.

This is why contract language deserves as much attention as technology. Ask vendors for documentation of intended use, known limitations, and performance, and ask what logging and attribution their products support when connected to patient data. Then confirm your own side. Who inside the organization is named as accountable for each tool, and where does that assignment live? Ownership of AI risk is unsettled in many organizations, and some have no named owner at all. A framework that divides accountability among parties does not help a hospital whose own internal accountability is undefined.

A 90-Day Plan for the CISO and the Compliance Office

Ninety days is a useful horizon because it matches the window Grant Thornton used in its audit-readiness question, and because it is long enough to build something real. A plan does not need to wait for the AMA framework to become anything more than a framework.

Inventory and attribution in days 1 to 30

Build a list of every AI tool and agent that touches clinical or administrative data, including the unofficial ones. For each, record the data it can reach, the identity it uses, and the named person accountable for it. Anything running through a shared service account goes on a remediation list, because it is the pattern most likely to fail unique user identification. This is also the moment to flag tools that accept patient data in prompts without a governed path.

Governed access and policy in days 31 to 60

Route AI access to sensitive content through a single governed layer rather than a scatter of direct integrations. Define policy in terms a compliance officer can read, such as which roles, which data classes, which purposes. Apply the same policy language to people and agents. Confirm that every AI request is linked to a human authorizer and that the log is forwarded to the security monitoring stack. A realistic goal for this phase is coverage of the highest-risk workflows, not every workflow.

The evidence drill in days 61 to 90

Run an exercise that mirrors a real inquiry. Pick a patient record, a date, and a tool, and ask the team to produce a complete record of AI access to it. Time the exercise. If it takes longer than a business day, treat the shortfall as a finding and fix it. Then brief the AI governance committee or board on the result, in terms of exposure and evidence rather than model metrics. Repeat the drill quarterly, because AI integrations change faster than policies do.

None of this requires certainty about how the AMA framework will be adopted. It requires being able to answer a question that every version of the future will ask.

What This Means for Regulated Healthcare Leaders

The AMA framework is a signal about direction. It does not settle who will ultimately pay when clinical AI goes wrong, and reasonable people in medicine, law, and industry will keep arguing about it. But the direction is consistent. Responsibility is moving toward the parties that can control the risk, and the party that controls access to patient data is the health system.

That is an opportunity as much as a burden. Organizations that can show, quickly and credibly, how AI tools are selected, who may use them, what they can reach, and what they did, will negotiate vendor contracts from a stronger position, answer insurers with less friction, and meet regulators with a record already in hand. Those that cannot will discover the gap at the worst possible time, in the middle of an inquiry, with the clock running.

The question to carry into the next governance committee meeting is not whether your clinical AI tools are smart enough. It is whether you could prove, by tomorrow afternoon, who and what touched a given patient’s record, and under which policy. If the honest answer is not yet, there is a clear place to start.

To learn more about producing audit-ready evidence for AI access to patient data, schedule a custom demo today.

Additional Resources

• Blog Post
  Zero‑Trust Strategies for Affordable AI Privacy Protection
• Blog Post
  How 77% of Organizations Are Failing at AI Data Security
• eBook
  AI Governance Gap: Why 91% of Small Companies Are Playing Russian Roulette with Data Security in 2025
• Blog Post
  There’s No “–dangerously-skip-permissions” for Your Data
• Blog Post
  Regulators Are Done Asking Whether You Have an AI Policy. They Want Proof It Works.