The day moved from framing (keynote and two morning panels) into three parallel working groups at 11:00, then into the Utah working lunch, where the discussion was pointed at the AI liability bill Utah intends to bring to the coming legislative session. The notes below follow that order so the reader can see how each working group fed the lunch conversation.
Liability follows traditional tort law. The risk allocation group did not see a need for a new liability regime. Outcomes will be fact dependent: product liability turns on who controlled the solution, and negligence follows traditional duty standards.
The most significant idea of the day: state law that bars vendors from disclaiming all liability. Contract provisions that attempt a blanket disclaimer would be null and void. Utah had framed this as protection for smaller health systems; the group believed there would be appetite to apply it to all health systems.
Assurance has to be tied to the claim and intended use, and it cannot stop at deployment. The assurance group converged on a shared responsibility model with substantial weight on the deployer.
Clinicians want a label, transparency, and training, not a vendor vetting burden. The provider protections group raised sharp concerns about autonomous solutions and about rural clinics with little capacity for oversight, and saw value in third party evaluators.
1. Morning sessions: threads that carried into the working groups
Four points from the keynote and the morning panels resurfaced repeatedly in the breakouts and are worth recording as framing:
Proof of good action, including audits, can protect a vendor. This became the bridge between the assurance discussion and the liability discussion: the evidence a vendor generates about its own conduct is also its best defense.
The Doctronic and UpDoc examples were used as contrasting reference points for how products are entering clinical use through the Utah sandbox.
Generative AI as a medical device versus the practice of medicine remains the open jurisdictional question. Where the line sits determines whether FDA, the state, or the medical board is the primary regulator.
AI inside ACO arrangements may compel CMS to request quality metrics for the use of AI in those ACOs. Reimbursement, not just regulation, may become a driver of evidence requirements.
2. Working Group 1: Risk Allocation and Liability
Facilitated by Brenton Hill. Unit of analysis: health systems, developers, and the contracts and instruments between them.
Where the discussion landed
The group concluded that liability for clinical AI will follow traditional tort law and will be fact dependent. Two anchors emerged:
Product liability: responsibility follows control over a given solution. The party that designs, configures, and controls the system as deployed is the party most exposed under a product theory.
Negligence: traditional duty standards apply. Clinicians and health systems are measured against the duty of care they already owe, with AI treated as one more input to that judgment rather than a separate standard.
There was no consensus that a dedicated AI liability regime is needed at this stage. The energy went instead to the contractual layer, where the group saw the real imbalance.
The proposal that drew the most attention
State law voiding vendor blanket liability disclaimers
Utah floated the idea of a statute providing that a vendor may not disclaim all liability for its AI solution, and that any contractual provision purporting to do so would be null and void.
Utah framed the idea as protection for smaller health systems that lack the leverage to negotiate these terms. The working group pushed further and believed there would be appetite to apply the rule to all health systems, regardless of size.
This was the single biggest output of the session and is the item most likely to shape the Utah bill.
Discussion points the group worked through
Allocation of liability: who is responsible when clinical AI contributes to patient harm, the clinician, the health care organization, the developer, or some combination, and whether fault should follow each party’s actual role, decisions, and control over the system.
Conditions for shifting liability: whether clinicians who use AI appropriately should have liability shift to the health system or the developer, and whether a clinician safe harbor is needed when they reasonably rely on an incorrect output. The documentation burden of proving safe harbor eligibility after an incident was a recurring concern.
Developer accountability: whether developers should carry explicit legal duties around design, disclosures, safety, and ongoing monitoring, and whether that responsibility should remain under contracts and existing law or move to a dedicated regime. Whether certain AI systems should be treated as products, making developers directly responsible, was debated without resolution.
Multiple party litigation: how cases work when clinicians, health systems, and developers may all have contributed to an adverse outcome, and the difficulty of attributing an outcome to a particular product or actor.
Directive AI before clinician involvement: when an interaction with an AI system establishes a provider-patient relationship, who is responsible when AI advises, triages, or orders care before a clinician reviews the case, and whether supervising software can realistically be governed using models designed for supervising human clinical staff.
Autonomy levels: whether liability rules should differ depending on whether AI assists a clinician, acts before clinician review, or operates without clinician involvement.
Interaction of accountability systems: how professional discipline, malpractice liability, and consumer protection enforcement should interact when AI causes harm, which forms of misuse are a licensing matter versus a legal violation, and whether AI-specific malpractice insurance is needed.
Market and access effects: whether stronger liability requirements could affect AI availability, adoption, cost, or vendor participation. The assurance group separately flagged the risk to open source development if too much liability lands on developers.
3. Working Group 2: Assurance Standards
Facilitated by Tina Hernandez-Boussard. Unit of analysis: the evidence about the system across its lifecycle.
The group organized itself around three questions: what evidence is needed before deployment, how evaluation continues after deployment, and who is responsible across the ecosystem.
Evidence before deployment
The group kept returning to the claim and the intended use as the starting point. Participants distinguished the underlying model from the application it sits in; the relevant evidence depends on what the system claims to do, the population it will be used in, and the clinical purpose it serves. Considerations raised included intended use and claims, training population and demographic representation, data provenance, appropriateness of outputs for the patient and population, performance and error rates, appropriate metrics and thresholds, controls and safeguards, and clinical and patient outcomes.
Because different models and applications require different metrics and thresholds, evaluation cannot rely on a single universal performance standard. Technical model validation was distinguished from the larger question of whether the system accomplishes its clinical purpose. Generative AI adds difficulty because approaches built for classifiers and other bounded models may not translate. Broader deployment criteria discussed included improvement in the standard of care, avoidance of catastrophic risk, and potential public health benefit.
Evaluation and monitoring after deployment
There was strong agreement that evaluation cannot stop at deployment. Approaches discussed included continuous monitoring, drift detection, internal validation, internal governance, human oversight, randomized controlled trials, independent third party validation, risk-based evaluation, sandboxes, narrow or gated deployment, and postmarket evidence generation.
A significant part of the discussion concerned whether some of the evidentiary burden traditionally placed before deployment could shift toward postmarket evaluation. That approach would require strong postmarket governance and the infrastructure to evaluate systems once they are in clinical use. RCTs were considered as one tool alongside the others, not as a requirement for every system. Monitoring should extend beyond technical performance to patient outcomes, including mortality. For broad or dynamic systems, participants discussed starting narrow, using gated deployment and layers of risk, and moving from sandbox testing toward broader deployment as evidence accumulates. Foundation models were flagged as particularly challenging because they support multiple intended uses.
Responsibility and accountability
Participants placed substantial emphasis on the deployer, which makes the decision to introduce the system and assumes responsibility for acting on its outputs. At the same time, developers, deployers, clinicians, and government entities each control different parts of the system, so the discussion moved toward shared responsibility with clear responsibilities at each layer rather than accountability resting on one actor. The AWS shared responsibility model was raised as an analogy: different actors own different layers, and a failure at one layer can affect the rest.
On liability specifically, participants cautioned that placing too much liability on developers could have unintended consequences, particularly for open source development, and noted the difficulty of attributing a clinical outcome to a single product or actor when many technologies and people contribute to care.
4. Working Group 3: Provider Protections and Clinician Liability
Facilitated by Brian Anderson. Unit of analysis: the individual clinician.
The questions the group was asked to work
Reasonable reliance: whether clinicians should be held responsible when they reasonably rely on AI that produces an incorrect output, failed to flag uncertainty, and resulted in patient harm; and whether clinicians who meet defined requirements should receive safe harbor protection from malpractice liability when AI contributes to an error.
Protection versus accountability: how to encourage appropriate adoption without reducing the clinician’s responsibility to exercise professional judgment, including the risk that clinicians follow institutional AI protocols without sufficient independent judgment.
Scope and oversight: whether protection should apply only when AI is used with the patients, tasks, and settings for which it has been validated, and what constitutes meaningful clinician oversight when the AI output appears reasonable.
Institutional versus individual responsibility: whether liability should depend partly on the health system’s AI governance, training, and protocols rather than solely on the individual clinician.
Practicality: whether documentation, review, and monitoring requirements are workable under real clinical workloads, and whether the records needed to show how AI was used and reviewed create their own burden.
What clinicians said they need
The clinician voice in the room was consistent and practical. Interest in AI is enthusiastic where it clearly benefits patients, but adoption depends on the following:
Confidence that the solution is safe. Safety can be established by published evidence, regulatory documentation, or both.
Transparency on how the algorithm was developed and whether it applies to the patients they actually serve, with limitations and indications stated.
A label for AI models, and performance translated into terms clinicians already use, such as positive and negative predictive value.
External validation from industry bodies and specialty societies.
Clarity on who is liable.
Not having to vet the vendor themselves. If a clinician is being asked to sign off on an agentic recommendation, they need the information and the time to vet that decision.
Protection to use the tools they are already using informally (shadow AI), and room for local clinician decisions about which models to use.
Workforce training, including improvements to graduate medical education and AI literacy, leading toward a re-envisioned team based model of care that incorporates AI.
A workflow that matches what they signed up for, with job descriptions redesigned so clinicians can co-develop AI solutions rather than simply being handed purchased ones.
Accountability upstream of the clinician
Much of the accountability work belongs at the procurement level. Vendors should be encouraged, and in practice expected, to provide the training.
There is real concern about shared liability for fully or near fully autonomous solutions, especially in rural clinics with little capacity for oversight.
Third party evaluators might be helpful in closing the gap between what a clinician can verify and what a health system or vendor asserts.
5. Where the agenda landed: implications for the Utah bill
Utah has chosen to propose an AI liability bill rather than rely on a common law approach, and the working lunch was built to collect feedback on that theory. Read together, the three working groups point to a narrower bill than the title suggests:
The core liability rules do not need rewriting. Product liability keyed to control and negligence keyed to traditional duty already do the work, and the room did not ask for a new regime.
The contractual layer is where the state can act. A provision barring vendors from disclaiming all liability, with any such clause void, was the idea with the broadest support. Utah framed it for smaller systems; the group thought it should reach all health systems.
Any safe harbor for clinicians should be conditioned on use within validated scope and on institutional governance, not on individual documentation that becomes impossible to produce after an adverse event.
Assurance expectations should be tied to the claim and intended use and should continue after deployment. Sandbox and gated deployment models are consistent with a shift of some evidentiary burden to the postmarket phase, provided the monitoring infrastructure exists.
Autonomous and near autonomous solutions, and the rural settings least able to supervise them, need specific attention rather than the general rule.
6. Open questions and suggested follow ups
Scope of the anti-disclaimer provision. Does it reach all health systems or only those below a size threshold, and does it bar only blanket disclaimers or also caps and carve-outs that function the same way?
Defining control. If product liability follows control over the solution, how should a statute or contract treat configuration, local tuning, and prompt or workflow changes made by the deployer?
Label and validation standard. Who issues the AI model label clinicians asked for, and what external validators (industry bodies, specialty societies, third party evaluators) would the state recognize?
Autonomy tiers. Whether the bill should distinguish assistive, pre-review, and autonomous use, and how liability shifts across those tiers.
Rural capacity. What oversight model is realistic for rural clinics deploying near autonomous tools, and whether third party evaluation can substitute for local capacity.
Reimbursement as a driver. Whether CMS quality metric requests tied to AI in ACOs will set de facto evidence standards ahead of any state rule.
7. Participant reflections (on the record)
Sections 1 through 6 follow Chatham House rules and attribute no comment to any individual. The reflections below are different: after the forum, several panelists, facilitators, and participants contributed short written reflections for attribution. Each reflects the author's own views, not a consensus of the room.
Zach Boyd
Director, Utah Office of Artificial Intelligence Policy
We want our policy considerations to be robust, legally sound, and informed by the practical realities of clinical care. Utah is committed to developing a framework that fosters technological innovation while ensuring patient safety.
Eric M. Fish
Partner, Hooper, Lundy & Bookman
As AI capabilities advance, these systems will increasingly resemble human clinicians rather than conventional software. The Wave AI Summit offered a valuable opportunity to explore with innovators, funders, and policymakers what this will mean for the health care ecosystem. Our discussion moved beyond whether AI should be used in medicine and focused instead on how regulatory systems should evolve to support the new paradigm of care that is emerging.
As theories of liability continue to shape policies around health care AI, we explored how building defensibility into the product itself is not only a sound legal strategy but a business imperative. Companies that embed meaningful human oversight, transparency, and accountability from the outset will be best positioned to navigate evolving regulatory expectations and earn the trust necessary for widespread acceptance and adoption.
I left the Wave Summit with a much sharper understanding of how founders and investors view the regulatory landscape, where they see obstacles, and where they see opportunities. The chance to engage with the legal and policy questions that are central to my own work helped deepen those conversations and add important context to their perspectives. The setting provided a forum where we could work together to address the complexities and find ways to advance our common belief that technology can meaningfully answer many of the issues facing health care.
The Wave Summit is a space where innovators, investors, and policymakers can engage in candid, solution-oriented discussions about the challenges of using technology to improve health care delivery. The programming moved beyond simply identifying problems. It gave participants the opportunity to discuss the practical barriers to innovation and develop practical solutions. Few conferences create that kind of working environment. Wave goes beyond just discussions and provides a forum where we do something about them.
The intimate setting is part of Wave’s success. At larger events, it is easy to get lost in the crowd. The Wave Summit created real opportunities for meaningful conversation and genuine relationship-building. I left not only with new professional connections, but new friendships and collaborative relationships that I expect will continue to grow.
Tina Hernandez-Boussard, PhD, MPH, MS, FACMI
Associate Dean of Research and Professor of Medicine (Biomedical Informatics), Stanford University School of Medicine; Facilitator, Working Group 2: Assurance Standards
One theme I took away from our discussion was the importance of moving beyond technical validation to evidence of clinical benefit and patient safety. We also discussed the need for risk-based approaches that allow evidence to accumulate through gated deployment and ongoing monitoring.
I also agree that assurance should consider reasonably foreseeable uses beyond a developer’s stated intended use, particularly when it comes to safeguards and deployment restrictions.
Sudha Jayaraman, MD, MSc, FACS
Medical Director, Clinical Strategy and Research, Suki
As a clinical leader at a major ambient AI company, I see the promise of AI in giving valuable time back to the people providing care. Across the healthcare industry, we need to understand how that value can be delivered and measured, and where the risks are. The Wave Summit sessions brought clinicians, policymakers, and industry leaders together to discuss how AI can be applied in a responsible way to close real gaps in health care and deliver value for patients and health systems. The sessions inspired me to think more carefully about how policymakers, health systems, and startups can work together to deliver solutions that are safe and effective.
Chris Robertson
Professor and N. Neal Pike Scholar in Health & Disability Law, Boston University
A developer’s intended use is key, and it is the touchstone for FDA law where that applies. But a developer’s marketing may indicate a broader intended use than it really wants to be responsible for, a common problem with drugs and devices. And even then, intended use does not exhaust the developer’s responsibilities.
As state tort law recognizes, developers are also responsible for foreseeable uses. They need to make those uses safe, or make them non-operative through design choices such as gating. Failing those design solutions, they need to warn, instruct, and potentially train users about foreseeable uses that were not intended. Hospitals likely have similar duties when they bring a technology into the institution: foreseeing how it is likely to be used, even if not intended.
Carmel Shachar, J.D., M.P.H.
Assistant Clinical Professor of Law, Harvard Law School
A developer’s stated intended use matters, but it cannot be the whole story. Marketing may invite broader uses than a developer formally claims, and foreseeable uses can create safety responsibilities even when they fall outside the stated intended use.
If a use is foreseeable, developers should make it safe, design the system to prevent it, or, where neither is feasible, provide meaningful warnings, instructions, and training. Gating is one way to keep a use from becoming operational; disclosure alone may not be enough. The same principle applies inside hospitals. Institutions bringing AI into care should consider not only how a tool is supposed to be used, but how clinicians are likely to use it in practice, and whether the surrounding workflows and oversight make those uses safe.
The emphasis on intended use raises an important practical question: intended by whom, and as reflected in what? The product documentation, its marketing, or the way it is deployed? Those signals may point in different directions, and assurance should account for that mismatch.
