In the deposition, the plaintiff's attorney reads the sentence aloud slowly, so the jury can hear it land: "So the AI tool recommended the discharge, and your hospital discharged the patient, and the patient died at home eighteen hours later." The hospital's counsel had expected this. What she had not fully braced for was the follow-up, delivered almost gently: "And where in your contract with the vendor does it say the vendor is responsible for that decision?" It does not say that anywhere, because no contract can. This is the lesson procurement, legal, and clinical leaders most need and most often learn too late: buying a vendor's AI does not move the clinical accountability off your institution. The duty of care does not transfer. It cannot be purchased away, indemnified away, or contracted away. And "the vendor's model did it" is not a defense to a board, a plaintiff, a family, or a surveyor.

The Obligation That Cannot Be Sold

Start with the principle, because everything about the contract flows from it. When a clinician acts on an AI output that touches a patient, and when an institution deploys a tool into the care its clinicians deliver, the legal and ethical duty of care sits with the clinician and the institution. That duty is a feature of the professional relationship with the patient, not a feature of the software. You can outsource the building of a tool. You cannot outsource being the treating clinician or the accountable hospital. The patient's relationship of trust is with you, the license on the line is yours, and the standard of care you are measured against is the standard of a reasonable clinician or institution, not the standard of a reasonable software buyer.

This is why the framing "we bought the tool, so the vendor owns the risk" is a category error that has cost institutions dearly. The vendor may owe you contractual obligations, warranties, and in some cases indemnification for certain failures, and those are worth negotiating hard. But the vendor is not in the room with the patient, is not the licensed professional making the call, and cannot be. The AI is a component you chose to introduce into a duty that remains yours. Introducing it does not dilute the duty; if anything, it adds new obligations, to validate it, to monitor it, to disclose it where the law requires, and to keep a competent human meaningfully in the loop, precisely because you brought a new source of risk into your patients' care. The cardinal rule of this entire program is here in its sharpest institutional form: AI assists, the clinician decides, the record proves it, and the accountability stays human no matter whose logo is on the software.

It helps to name the parties whose responsibilities genuinely can be allocated by contract, and those whose cannot, because the confusion between them is where money and safety are lost. The table below separates the two.

Read the table as a single message. Everything in the "No" rows stays with you and is the substance of what a plaintiff, a surveyor, or a board will examine. Everything in the "Yes" rows is what the contract is actually for: not to move the duty, but to give you the money, the information, and the access to carry a duty that never left.

It helps to see how this connects to the evolving standard of care, because the exposure runs in two directions at once. A clinician can be liable for following a wrong AI recommendation, and a clinician can also be liable for ignoring an accurate one when a reasonable clinician would have heeded it. That dual liability is a direct consequence of the duty being human: the tool is neither a shield when you follow it nor an excuse when you do not. It is one input into a judgment that remains yours to make and to defend, which means the thing that carries you through a bad outcome is not the vendor's contract but the quality and documentation of the human decision. A short, honest note explaining why the clinician agreed or disagreed with the AI, grounded in the patient in front of them, is worth more in a courtroom than any indemnification clause, because it is evidence that the duty was actually met rather than delegated to a machine.

You can buy the tool. You cannot buy your way out of being the one the patient trusted. The duty of care is not a line item, and no contract can move it.

What the Contract Can and Cannot Do

If the duty of care cannot transfer, it is fair to ask what the contract is even for. The answer is that the contract cannot move your clinical accountability to the patient, but it can and must govern the relationship between you and the vendor: what the vendor owes you, what happens when the tool fails, what you are allowed to know, and what protections you carry when something goes wrong. A well-negotiated contract does not make the vendor accountable for the patient. It makes the vendor accountable to you, and it preserves your ability to meet the accountability you cannot escape. That is a crucial distinction, and it reframes every clause below. You are not negotiating to hand off the duty. You are negotiating for the tools, the information, and the protections you need to discharge a duty that is staying with you.

So read the contract as a clinical-safety document, not merely a commercial one. The clauses that matter are the ones that determine whether, after go-live, you can actually keep the tool safe and prove that you did. Five deserve particular attention.

Indemnification and liability caps

Indemnification is the vendor's promise to cover certain losses, and liability caps are the ceiling on what the vendor will pay. These matter enormously, and they are where the vendor's lawyers have been most careful. Watch for a liability cap set at the value of the contract, which for a tool that could contribute to a patient death is a cap wildly disconnected from the potential harm. Watch for indemnification that covers intellectual-property disputes but pointedly excludes clinical harm. Watch for language that makes the vendor liable only for defects in the software as delivered, while disclaiming everything about how it performs in your environment. None of these clauses will move your duty to the patient, but they determine whether, when a harm occurs, you are left holding the entire financial and reputational weight while the vendor's exposure is capped at a number that would not cover a single case. Negotiate them as if a serious harm will one day happen, because across a large deployment, eventually one will.

A concrete way to test a proposed cap is to hold it against the exposure it is supposed to absorb. A single serious clinical-harm claim in the United States routinely resolves well into seven figures once defense costs, settlement, and reputational remediation are counted. A liability cap pinned to a subscription that costs a fraction of that is not protection; it is a number chosen to protect the vendor. The point of naming this out loud in negotiation is not to win an argument but to make a conscious, documented decision: either the cap moves closer to the real exposure, or leadership knowingly accepts and mitigates a defined residual risk with its eyes open. What you must never do is sign a mismatched cap while believing you are covered, because that belief is the precise thing that leaves the institution exposed.

Data use and PHI

The contract governs what the vendor may do with your patients' data, and this is both a privacy obligation and a safety one. You need a business associate agreement, clarity on whether the vendor may use your PHI to train or improve its models, whether de-identified data is being retained and monetized, and what happens to the data when the contract ends. A vendor quietly using your patients' data to improve a product it then sells to your competitors is a governance and ethics problem you want surfaced in the contract, not discovered later. And because the duty for that PHI remains yours under HIPAA regardless of what the vendor does with it, the data-use clauses are another place where your obligation does not transfer even though the data physically leaves your walls.

Model-change notification

This clause is easy to overlook and central to safety. The model you validated in your pilot is a specific artifact, and vendors update their models. If the vendor can change the model underneath you without telling you, then the tool your clinicians are trusting today may not be the tool you validated, and you would have no way to know your validation had expired. A model-change notification clause requires the vendor to tell you before material changes, so you can re-validate. Without it, your entire local validation, the thing that let you deploy responsibly, has a silent expiration date the vendor controls. This is not a technicality; it is the difference between a tool you can vouch for and a tool that has quietly become something you have never actually evaluated. When such a notice arrives, it is not paperwork to file; it is a trigger to re-validate before continued reliance, because the artifact you approved has changed.

Audit rights and performance data

Because monitoring the deployed tool is your obligation and cannot transfer, the contract must give you the access to meet it. Audit rights, and the right to your own performance data in a form you can analyze, are what let you watch for drift, confirm subgroup performance in production, and investigate when something goes wrong. A vendor who resists audit rights is asking you to be accountable for a tool you are not permitted to inspect, which is an untenable position for a clinical leader to accept. Watch, too, for audit rights that exist on paper but resolve only to aggregate dashboards; without access to your own row-level performance data, you cannot independently confirm subgroup performance or reconstruct what happened in a specific event, and your accountability is left under-resourced. The right to audit and the right to export your data are the practical instruments of an accountability you cannot give away.

Notice the pattern across all five clauses, because it is the same pattern each time. In every case, the vendor's default language is written to minimize what the vendor owes and maximize what the vendor controls, and in every case the correction is the same: shift the clause so that it supports your ability to carry the duty. The liability terms should reflect clinical harm, not just contract value. The data terms should keep your stewardship of PHI intact. The change-notification term should keep your validation honest. The audit term should keep your monitoring real. A contract negotiated on this principle is not adversarial for its own sake; it is simply a contract written by someone who understands that after the signatures dry, the patient's safety and the institution's defensibility will rest entirely on structures the vendor cannot provide, and that the clauses exist to make those structures possible rather than to pretend they are unnecessary.

Dual Liability and the Limits of the BAA

Two ideas get quietly conflated in procurement conversations, and separating them is one of the most useful things a clinical leader can do. The first is that the standard of care now cuts both ways, so the institution and clinician sit inside a dual-liability structure that no contract resolves. The second is that a business associate agreement, the document everyone knows to demand, is far narrower than most buyers assume. Both are worth slowing down on, because both are places where a leader who has read the contract carefully and still misunderstood these two points will be exposed.

Take dual liability first, in the operational form procurement should internalize. Because a clinician can be liable both for following a wrong AI output and for disregarding an accurate one, the tool does not reduce the institution's exposure to a single failure mode that a warranty could plausibly cover; it creates a two-sided judgment that only a documented human decision can defend. This has a direct contract implication. No indemnification clause can reach a claim that the clinician exercised poor judgment, in either direction, because the judgment is the clinician's and the institution's, not the vendor's. The contract can help pay for a defect in the software; it cannot help defend a decision. That is why the record, the short note explaining the clinician's reasoning, is the asset that matters most, and why leaders who pour negotiating energy into indemnification while neglecting documentation practices have optimized the wrong variable.

Now the BAA, which is routinely treated as though it were a general safety and liability shield when it is nothing of the kind. A BAA is a HIPAA instrument. It binds the vendor, as your business associate, to safeguard the PHI you disclose to it, to use and disclose that PHI only as permitted, to report breaches, and to return or destroy PHI at termination. That is important and non-negotiable, but look at what it does not do. The table below draws the line explicitly.

The practical lesson is that "we have a signed BAA" answers a privacy question and almost nothing else. A leader who treats the BAA as evidence that the AI is safe, validated, or covered against clinical harm has confused a privacy contract for a safety program. The BAA belongs in the deal, but the clinical-safety clauses, indemnification and cap, model-change notification, audit rights, and the internal validation and monitoring that no contract supplies, are separate work that a BAA neither performs nor excuses. Surveyors and plaintiffs know this distinction cold; procurement should too.

One more subtlety belongs here because it trips up experienced buyers. A BAA does bind the vendor to safeguard PHI, but it does not automatically constrain whether the vendor may use your data to train or improve its models, because HIPAA permits certain uses by a business associate that a covered entity would not expect. That is why the data-use terms discussed earlier are a separate negotiation from the BAA itself: the BAA answers "will you protect it," while the data-use clause answers "what may you do with it, may you train on it, may you retain it, and what happens to it when we part." Assuming the BAA settles both questions is one of the most common and expensive misreadings in health-AI procurement, and it is exactly the gap a careful plaintiff or regulator will probe.

A Worked Example: The Defense That Fails

Consider two institutions that deployed the same sepsis-prediction tool, and imagine that at each a patient was harmed when the tool contributed to a delayed diagnosis. Both are sued. Watch how differently the two stories end, and notice that the difference was decided long before the harm, at the contract table and in the governance file.

Institution A treated the purchase as a transfer of risk. Its leaders believed that because they had bought a reputable, even FDA-cleared, tool, the responsibility for its outputs rested with the vendor. They did minimal local validation, deployed broadly, monitored little, and when the harm occurred their instinct was to point at the vendor: the model made the call. In the litigation, this defense collapses immediately. The treating clinician acted on the output and was the licensed decision-maker; the institution deployed the tool into its care with thin validation and thinner monitoring; and the contract, when produced, shows a liability cap far below the harm and no clause obligating the vendor for clinical outcomes. "The model did it" is not a defense; it is an admission that the institution deployed a tool it did not adequately validate or monitor and then tried to disown the decision its own clinician made. The vendor's contractual exposure is capped and largely irrelevant to the patient's claim, which was always against the institution and the clinician.

Institution B understood that the duty stayed with it. It validated the tool locally, ran a gated pilot, deployed with a human-in-the-loop workflow, monitored performance including subgroups, and negotiated a contract with real audit rights, model-change notification, and an indemnification and cap that reflected clinical risk. When the harm occurred, its defense is entirely different. It can show that a competent clinician made the decision with the tool as one checkable input, that the institution had validated and was actively monitoring the tool, that it had met its disclosure and governance obligations, and that the event was investigated properly. Institution B is not automatically absolved, because harm can occur even in a well-run system. But it is defending the conduct of a responsible institution that met its duty, rather than trying to hide behind a vendor it cannot hide behind. The contract did not remove Institution B's accountability. It equipped Institution B to meet it, and that is the most a contract can do.

The Institutional Posture That Holds

The through-line of all of this is a posture, and it is worth stating plainly for the people who sign the contracts and answer for the deployments. Approach every clinical AI acquisition as the introduction of a new source of risk into a duty of care that remains entirely yours. Negotiate the contract hard, not to transfer the duty, which is impossible, but to secure the indemnification, the liability terms, the data protections, the model-change notification, and the audit rights that let you carry the duty responsibly. Then build the internal validation, monitoring, disclosure, and human-in-the-loop structures that actually discharge it, because those, not the contract, are what a plaintiff or a surveyor will examine. The contract protects the institution financially at the margins. The governance protects the patient, and it is the governance that also protects you.

There is a practical corollary procurement and legal should internalize together. When a vendor's draft states that the customer is "solely responsible for clinical use," that clause is not the trap it might first appear to be, because it merely restates a truth you already own: the duty is yours. The danger is not the clause; it is letting that clause become cover for a contract that gives you none of the tools to carry the duty it correctly assigns you. A vendor can accurately say you are responsible for clinical use and, in the same document, deny you audit rights, refuse model-change notification, and cap liability at a number unrelated to harm. That combination is the one to reject, because it hands you the whole duty while withholding the means to discharge it. Accept the responsibility, which is yours regardless, but only alongside the protections that make meeting it possible, and never in exchange for them.

The temptation, especially under budget pressure and vendor enthusiasm, is to treat a signed contract with a reputable vendor as the end of the safety work, as though the logo and the clearance and the indemnification clause together add up to a transfer of responsibility. They do not, and the belief that they do is precisely what leaves an institution exposed. The mature posture is almost the opposite: the contract is the beginning of your obligations, not the end of them. You have brought a powerful, imperfect tool into your patients' care, and you now own everything that follows, the validation, the monitoring, the disclosure, the competent human check, and the honest reckoning when something goes wrong. That ownership is not a burden the right vendor can lift. It is the job, and it is the job precisely because the patient trusted you, not the software, and no clause in any contract can make that untrue.

Key Takeaways

• Buying a vendor's AI does not move the clinical accountability off your institution: the duty of care is a feature of the professional relationship with the patient, not the software, and it cannot be purchased, indemnified, or contracted away.
• "The vendor's model did it" is not a defense to a board, a plaintiff, a family, or a surveyor; the treating clinician remains the licensed decision-maker and the institution remains the accountable deployer.
• The contract cannot transfer your duty to the patient, but it can and must make the vendor accountable to you, preserving your ability to meet an accountability you cannot escape. Read it as a clinical-safety document, not just a commercial one.
• Scrutinize indemnification and liability caps as if a serious harm will one day happen: beware caps set at contract value, indemnification that excludes clinical harm, and language limiting the vendor to defects in the software as delivered.
• Dual liability means a clinician can be liable both for following a wrong AI output and for ignoring an accurate one, so no indemnification reaches the judgment; the short note documenting the clinician's reasoning is the asset that defends it.
• A BAA is a HIPAA privacy instrument: it governs safeguarding, permitted uses, breach notice, and PHI return, but it does not cover clinical accuracy, validation, malpractice, or your duty to monitor, so a signed BAA is not evidence the tool is safe.
• Model-change notification is a safety clause and audit rights plus row-level data export are the practical instruments of a non-transferable monitoring duty; aggregate dashboards alone leave that duty under-resourced.
• The mature posture: the contract is the beginning of your obligations, not the end; negotiate it hard to carry the duty responsibly, then build the validation, monitoring, disclosure, and human-in-the-loop structures that actually discharge it, because those, not the contract, are what protect the patient and the institution.