Last updated: October 26, 2026
I represent both sides of this transaction. Some days I am advising a health system on vendor paper, and some days I am supporting the company selling into a system. Before returning to private practice I sat in-house for a large academic hospital system, where I translated existing organization requirements into contractual terms capable of corralling the evolving world of AI technology.
The requirements that stall an AI deal are not misunderstandings. They are misaligned commercial terms that reach the negotiation table late, in a redline, in front of people who already decided the deal could proceed as discussed.
Is legal review really where the deal breaks?
Legal review is where the deal becomes concrete. By the time a draft reaches counsel, each commercial team has spent weeks building an internal case for this partner. Neither team asked the other side a question whose answer could end the conversation.
The redline is the first document that makes each institution state a position in writing. Two positions turn out to be incompatible and counsel looks like the barrier. Many times, counsel is just making sure the organization’s governance and compliance principles remain intact against a technology those same policies could not appropriately contemplate.
Which positions are stalling AI deals?
While the specific sticking points may vary deal to deal, I typically am navigating one or more of the following issues in all of these conversations. Many times, health systems have standing protocol to address each of them. However, the avalanche of AI and AI-enabled tech has quickly illustrated how those same protocols do not fully (or at all) contemplate how vendors actually operate the AI tools on the market.
Secondary use of data
Secondary use in the software market traditionally fit into a few categories of analytics, commercial use, or product support. A common example was marketing, where the question was whether a third party receiving data had any permissible reason to use that data based on the contract between the health system and its vendor.
AI has introduced a new wrinkle with model training, and that training rarely stops at the vendor. Unless your health system is directly contracting with an OpenAI/Anthropic/Perplexity/etc., the tool runs on a model someone else built and operates. That model provider is a party in its own right, with its own terms governing what happens to data that reaches it, and the health system usually finds it on a subprocessor list rather than in the sales conversation. A commitment on training therefore has to hold at two levels and the vendor controls one of them.
A vendor cannot grant what it does not control. The health system’s starting position is typically narrow: no training on its data by anyone beyond the contracted vendor, and meaningful limits on what that vendor does at its own layer. The drafting question is whether the vendor can hold that line through its own supply chain, and it often can. Anthropic’s commercial terms state that it may not train models on customer content, and OpenAI’s services agreement commits that it will not use customer content to develop or improve its services unless the customer explicitly agrees. While these published terms could vary between the vendor and the AI platform provider, the contract between the health system and vendor should require the vendor to confirm which terms govern its model access, represent that it has not opted into anything broader, and give notice before those terms change.
Ownership across the stack
Intellectual property and data ownership is rarely a single question in an AI agreement. The base model belongs to whoever trained it, which is frequently not the vendor. The health system contributes its data, and in most deployments it also contributes configuration: the prompts, clinical rules, and thresholds that make the tool behave the way this organization needs it to. Those prompts then generate valuable outputs. Improvements derived from any of those layers form another layer as well.
Vendor paper tends to resolve one of those layers cleanly and leave the rest to inference. The health system’s practical question is narrower than ownership: what can we do with what this tool produces, what can the vendor do with what we put in, and which of those rights survive termination.
Configuration is the layer I would isolate first. It is built by the health system, it carries real clinical judgment from the people who will use the tool, and it is frequently the layer swept into the vendor’s definition of product improvement without anyone intending that result. Naming the layers separately in the agreement, andsaying what happens to each one at termination provides workable avenues for a long-term enterprise partnership.
Patient data posture
Where protected health information lives, which downstream processors the health system will accept, and what happens to data after de-identification.
The subprocessor relationship described above also governs where data physically goes and who may hold it. A health system that has mapped its data flows for every other vendor frequently has no equivalent map for an AI tool, because the processing happens on infrastructure the vendor does not own and under terms the health system has never seen.
Where PHI reaches that subprocessor, there is a second agreement to reconcile. Enterprise subprocessors typically require a BAA before they will process PHI at all, and that BAA runs between the subprocessor and the vendor rather than the health system. The obligations a health system negotiates into its own BAA with the vendor do not automatically travel upstream, and what I am seeing is that the subprocessor’s form will not undertake all of them. That gap belongs in the vendor paper, where the vendor either commits to the health system’s requirements regardless of what its upstream BAA says or discloses where it cannot.
From my experience, both sides are well-versed in navigating de-identification and aggregation requirements as a baseline. The divergence comes from the health system’s intention to limit what happens to de-identified data once it travels past the vendor. Those limits reach past training into benchmarking, aggregate reporting, and any downstream product the vendor builds from that data, which is frequently where the vendor’s own commercial model sits. The vendor is then being asked to give up something it had already priced into the deal.
Liability capacity
A health system sets insurance and liability minimums keyed to data exposure, and a tool that touches PHI carries minimums running into the millions.
The conflict isn’t necessarily the number assigned to the cap, it’s how the two sides value risk. For the health system, any engagement carries a baseline risk amount and the scope of that arrangement typically raises the floor needed for the health system to comfortably “stand” in the partnership. On the flip side, a vendor’s coverage is set by its insurance tower and its revenue stage. Similar to software adoption policies for health systems, cyber insurance policies for AI technology and services are still catching up to what these products do. As a result, health systems expect certain insurance commitments that the vendor policy does not reach. A workable middle ground is defining liability tiers by the exposure of data with varying caps based on the liability at issue.
Whether the tool can be vetted at all
Every vendor arrives with a regulatory position, and the health system should be able to test it rather than assume it as true.
Whether the FDA’s regulations reach a given tool is the clearest example. The vendor settled that question before its conversations with the health system, because its route to market depended on the answer. On the health system side the question tends to belong to nobody in particular, so the vendor’s characterization travels through diligence as background and is assumed established in most procurement contracts. Health systems should be ready to test that assumption as part of their implementation process.
Testing functionality depends on what the tool produces. Some AI tools return a result alongside a record of how they reached it. Others return a result with no verifiable context. The first supports an acceptance test, an audit right, and a defensible allocation of clinical liability. The second supports none of them, which is why the diligence question is not whether the vendor stands behind its tool but what the health system can independently review to uphold its clinical safety standards.
How can legal help close these deals?
Commercial teams know the organization has requirements. What they may not see is how each deal interplays with those requirements. As an example, the same data and security requirements that governed procurement of a scheduling platform now apply to a tool that interprets clinical information. The commercial team runs both through the same implementation process, because the protocol treats them as the same category of purchase. That protocol was built around data security and system uptime, and it does not reach the operational controls a clinical information tool actually needs: who reviews an output before it informs care, what happens when the tool is wrong, and who at the health system owns that call.
Legal sees these questions last, but is well positioned to ask them first. The positions above were settled before anyone put redlines to paper. Empowering business teams to tackle these issues in the commercial diligence phase mitigates the need for legal to pause the partnership momentum to figure out these decision points.
- Coach commercial teams on vendor diligence. Will this tool touch PHI at all? How much are we sharing? Do we control which records reach the vendor, or does the vendor get broad access to everything in our system? Those answers shape the entire negotiation and help direct conversations to the liability and data sharing issues at the onset of partnership conversations.
- Explain why each parameter matters. A commercial team that understands training rights as a question about whether the product keeps improving, rather than a clause legal cares about, will push for a real answer and recognize a vague one. The same holds for upstream model terms and access scope.
- Ask where the tool has been deployed at comparable organizations. Some AI tools were built for an individual clinician or a small practice, and the vendor’s paper reflects that history.That is not disqualifying, but it tells you early that the agreement will need to be built out to contemplate an enterprise relationship rather than lightly negotiated. Having the commercial team request other health system references for the tool can provide valuable insight around both the implementation and contracting process.
None of this requires legal in every early conversation. Instead, the commercial team is now equipped to enter discussions with vendors already contemplating terms that will necessarily inform the ultimate contract between the two sides.
FAQ
Our AI governance policy is still in progress, or our current policy does not address AI at all. How do we buy anything in the meantime? Communicating this to the vendor earlier allows two things: i) both parties are aware of the known gap and ii) the contract can be negotiated to contemplate additional AI governance assessment review once the organization policy becomes official. A policy written for data storage and transmission has no position on inference,context retention, or model improvement. Forcing the question into the nearest existing exclusion produces a term nobody at the table can defend. Involving the appropriate stakeholders, such as whoever owns the policy, and have them set a position for this purchase. A position scoped to a single deal is faster than a full governance framework and it gives the negotiation something to workfrom.
The vendor says we can see how the tool reached its conclusion. How do we test that? Ask what the underlying record contains, who at the health system can read it, how long the vendor retains it, and whether the health system can pull it without the vendor’s assistance. A record that exists only inside the vendor’s environment, or only for as long as the vendor chooses to keep it, will not support an audit or a defense when it is needed.
Is this just a HIPAA problem? HIPAA sets a floor and most of these disputes happen above it. Two parties can be fully compliant and still hold incompatible positions on secondary use, access, or liability allocation. Those are institutional choices, not regulatory requirements.
Our deal is already in legal review and it has stalled. Is it recoverable? Usually, if nobody has named the stall as a structural conflict yet. Take a step back and establish which side’s position is actually fixed, then decide whether a narrower scope makes the conflict disappear. Deals die when both sides keep trading language on a term neither of them controls.
Should a health system require uncapped liability from every vendor? Taking a blanket approach to liability will create redundant friction in your contracting process. Does the tool touch PHI? Ifnot, does it touch any personally identifiable information? If not, will it interact with clinicians in a way that affects clinical care? Each yes moves the requirement up. A blanket requirement applied without that filter narrows the vendor pool for reasons unrelated to the risk.
Next step
If a health system AI deal is stalled at legal review, or you want these positions mapped before you start one, please reach out to me and the rest of the Elevare Law team.
