A chest X-ray triage tool flags an image as normal. The emergency physician, at the end of a long shift, discharges the patient. Months later a finding that was on the image from the start is diagnosed, and the claim letter is addressed to the company that built the software as well.

When AI-enabled medical software makes an error, liability is usually shared between the manufacturer that placed it on the market as a medical device and the clinician or institution that relied on its output. The provider of the training data and the integrator that connected the system to the electronic health record can be drawn in too. For an Israeli medtech or digital health company selling software as a medical device (SaMD) into the US and Europe, the practical question is which policy responds when the same error produces a bodily injury claim and a professional negligence claim at once.

This page deals with products already on the market. Baseline cover is explained on our pages on insurance for digital health companies and life sciences companies insurance.

Key points

A claim reaches more than one defendant – The manufacturer is sued over a design or warning defect and the clinician over negligence. Each turns to a different policy, and the hospital’s insurer may seek contribution from the manufacturer.

The usual gap sits between two policies – Technology errors and omissions (Tech E&O) policies tend to exclude bodily injury, and product liability policies were often written around physical hardware. Software that harms a patient can fall between them.

A model that updates changes the risk the insurer underwrote – A predetermined change control plan (PCCP) settles updates with the FDA. The insurer needs the update mechanism described in the proposal as well.

The regulatory clock moves at different speeds – Regulation (EU) 2026/1744 moved the AI Act’s high-risk obligations for medical devices to 2 August 2028, while the new Product Liability Directive, which treats software as a product, applies to products placed on the market from December 2026. In the US, the FDA’s overarching guidance on AI-enabled device software is still a draft.

The liability chain: who may carry the loss

Four parties can be named when the output of a medical algorithm leads to harm: the manufacturer, the clinical user, the data provider and the integrator. How liability is shared depends on the governing law and the contracts, and on how autonomous the tool is. The more the software decides on its own, the more weight shifts to the manufacturer.

  • The manufacturer (the regulatory holder): usually sued over design defects, or over instructions for use that did not describe the model’s limits.
  • The clinician or hospital: sued for negligent reliance on the output, or for ignoring it. The institution’s insurer may then seek contribution from the manufacturer.
  • The data provider or annotator: a contract capping its liability at the service fee leaves the loss with the manufacturer.
  • The integrator and the foundation model provider: an integration error can show a result against the wrong patient. A third-party foundation model updated by its provider can change product behaviour without the manufacturer touching a line of code, an issue the FDA raised in its August 2026 discussion paper on generative AI-enabled devices. Similar questions arise with AI agents as insured entities.

In the US, the learned intermediary doctrine generally directs a device manufacturer’s duty to warn at the physician rather than the patient. The protection weakens when the software faces the patient directly, or when the physician has no practical way to review the basis for a recommendation, and its reach varies by state. Instructions for use and a description of the population on which the model was validated are risk management first, and evidence in a claim later.

Software as a product: the question that decides which policy responds

Whether medical software is a “product” for strict liability purposes is an open question in some markets, and the answer decides which line of cover is called on. In the EU the answer is now in legislation. In Israel and the US it is decided case by case.

In Israel, the Defective Products Liability Law, 1980 imposes no-fault liability on a manufacturer for bodily injury caused by a defect, and a product can be defective for lack of adequate warnings. The law also recognises a defence where the state of scientific and technical knowledge, when the product left the manufacturer’s control, did not allow the defect to be discovered. Whether the law reaches standalone software that is not installed in a physical device has not been settled and needs individual legal advice. Negligence under the Civil Wrongs Ordinance applies in any case, and it does not depend on the definition of a product.

US courts are divided. Some have been reluctant to apply product liability to intangible software, while in recent years more courts have allowed such claims against AI applications to survive motions to dismiss. Software cleared as a medical device by the FDA is seen by many commentators as closer to a product.

In the EU, the new Product Liability Directive (2024/2853) states expressly that software, including AI systems, is a product, and extends liability to defects arising from updates or from a missing security update. Where the manufacturer is outside the EU, the importer or authorised representative may be liable in its place. The Medical Device Regulation (MDR) already requires manufacturers to have measures in place for sufficient financial coverage of their potential liability, proportionate to risk class and company size.

The insurance consequence is direct. If the product schedule in a product liability policy describes physical hardware, the insurer may argue the software sits outside cover, and a Tech E&O policy tends to exclude bodily injury. The usual answer is a combined life sciences policy, or a product definition that includes software and its updates alongside an express bodily injury carve-back in the professional liability policy.

Four markets, four regulatory clocks

Each market regulates AI-enabled medical software differently, and each regulatory route affects claims exposure and underwriting questions. For an Israeli company, the heavy exposure usually sits in the destination market.

Israel – The Medical Devices Division (AMAR) of the Ministry of Health registers devices under the Medical Equipment Law, 2012, often relying on an existing FDA clearance or CE marking. Which specific requirements will apply to AI software at registration is an open question to raise with the Division. Amendment 13 to the Privacy Protection Law, in force since August 2025, tightens obligations for medical data.

United States – The FDA’s list of AI-enabled devices authorised for marketing includes more than 1,400 devices, most cleared through the 510(k) pathway. A device approved through premarket approval (PMA) may benefit from federal preemption against some state tort claims, while a 510(k) device has far narrower protection. Final guidance on PCCPs for AI-enabled device software functions was issued in December 2024 and updated in August 2025, while the January 2025 lifecycle guidance for AI-enabled device software functions remains a draft. A vendor processing protected health information for a hospital is usually a business associate under HIPAA, directly liable for safeguarding it.

European Union – Under Rule 11 of the MDR, software providing information used for diagnostic or therapeutic decisions is at least class IIa. An AI system that is a safety component of such a device is high-risk under the AI Act, and Regulation (EU) 2026/1744, in force since 27 July 2026, moved those obligations to 2 August 2028. MDR obligations themselves were not postponed.

Asia-Pacific – Japan (PMDA) and Singapore (HSA) have mechanisms for pre-approving changes to medical device software. Most markets in the region require a local registration holder, and some, such as China and India, also require a local insurer.

Market Regulatory framework Effect on exposure What to check in the policy
Israel AMAR registration; Amendment 13 Bodily injury and privacy, with moderate claim volumes Cyber cover for life sciences aligned with Amendment 13
United States 510(k), De Novo or PMA; PCCP; HIPAA The severity market: juries and punitive damages An express US and Canada extension, and a limit that fits the market
European Union MDR Rule 11; AI Act; Product Liability Directive Liability for software and its updates A product definition that includes updates, and the authorised representative as an additional insured
Asia-Pacific PMDA and HSA; local registration holder Exposure runs through the local distributor The distributor as an additional insured, and whether a local insurer is required

One event, several policies: a map of failure scenarios

No single policy responds to every failure scenario of an AI-enabled device. Each scenario brings different defendants and a different line of cover.

Failure scenario Who may be sued Line that may respond What to check
A missed finding that led to patient harm The manufacturer, alongside the clinician and hospital Product liability for medical devices That software is defined as a product, and that a professional services exclusion does not capture the output
Model performance degrades after an update (model drift) The manufacturer Product liability or Tech E&O That the update was disclosed, and that the retroactive date precedes the first version
Biased training data harms a patient group The manufacturer, then the data provider Product liability Data and discrimination exclusions, and the liability cap in the supplier contract
An integration error shows a result against the wrong patient The integrator and the manufacturer Technology E&O An express carve-back for bodily injury arising from software failure
A SaaS outage stops work at a hospital, with no bodily injury The manufacturer as service provider Tech E&O A financial loss limit that matches the service level agreement (SLA)
A breach, leak of medical data or deliberate tampering with the model The manufacturer, sometimes the hospital Cyber The bodily injury exclusion for cyber events, and notification cover under HIPAA and Amendment 13
A regulator requires withdrawal of a software version The manufacturer Product recall That the policy recognises withdrawal of software, not only of a physical product
A validation study for a new version The manufacturer as sponsor Clinical trials insurance A policy for each study and country
Investors allege model performance was overstated The company and its officers Directors and officers (D&O) New AI exclusions, and cover for regulatory investigations

Each line is built for a different part of the event, and each stops somewhere different:

  • Product liability for medical devices: bodily injury or property damage caused by the insured’s product. Stops at the product definition and the territory.
  • Technology errors and omissions (Tech E&O): a customer’s financial loss from a software failure. Usually stops at bodily injury.
  • Medical malpractice: negligence by a physician. Insures the professional, not necessarily the company operating the service.
  • Cyber: incident costs and privacy claims. Bodily injury is usually excluded.
  • Clinical trials: injury to a study participant. Ends with the study.
  • Directors and officers (D&O): claims against management, including over investor disclosure. Not designed for a patient’s bodily injury.

In most medtech companies the policies were bought separately, from different underwriters. The broker (LAMDA Broking) works through the policy wordings with management and legal counsel against the distribution contracts and regulatory documents, so that the product is described the same way in all of them.

A model that keeps learning: when an update becomes a different risk

An update to an AI model may count as a change in risk for the regulator and for the insurer. When the proposal describes one version and the claim arises from a later one, the insurer may ask whether the risk it underwrote is the one that materialised.

A PCCP and the parallel mechanisms in Japan and Singapore allow updates without a new submission, as long as the change stays within pre-authorised bounds. There is no equivalent on the insurance side, and many wordings require the insured to report a material change in risk during the policy period.

The simplest way to narrow the gap is to describe the update mechanism itself in the proposal, not just the current version.

The basis of cover matters. Life sciences product liability is sold on a claims-made or an occurrence basis. On a claims-made basis, harm from a version sold three years ago may be covered only if the policy is in force when the claim is made and the retroactive date precedes the sale. A company that changes insurer, or is sold, needs to preserve continuity of that date or buy an extended reporting period (run-off). The products limit is usually an annual aggregate, and one fault in a version installed across dozens of hospitals may be treated as a single series of related claims under the aggregation clause.

Post-market monitoring records support the company’s defence, and the claimant’s case when they are missing.

Where the gaps between wordings fall

Most coverage gaps for medical software sit in exclusions and definitions, some long-standing and some new. Wording varies widely between insurers.

  • Professional services exclusion in the product policy: when the product is a clinical recommendation, it may capture exactly the algorithm’s output.
  • Bodily injury exclusion in Tech E&O: without a carve-back, a patient’s claim stays outside.
  • Territory and jurisdiction: US and Canada exclusions are common in local policies.
  • AI exclusions: since January 2026, optional standard endorsements have been available in the US to exclude harm arising from generative AI output from general liability, including products-completed operations. For a company whose product is AI, a broad exclusion of this kind can empty the policy.
  • Contractual liability: indemnities in hospital contracts are sometimes wider than liability at law, which is all some policies cover.

The reasonable ask against an AI exclusion is wording that excludes unauthorised use of AI while keeping the insured’s own product inside cover. The London market, including Lloyd’s, has capacity that combines product liability and professional liability in one policy, subject to underwriting.

Common mistakes

  • “The doctor decides, so the liability is theirs”: the learned intermediary doctrine protects the manufacturer only when the physician was adequately warned.
  • Relying on Tech E&O alone: it was written for financial loss, and bodily injury usually stays outside.
  • Updating the model without updating the insurer: the version in the field differs from the one in the proposal.
  • Assuming the EU delay removes the risk: the AI Act delay does not touch the Product Liability Directive.
  • Leaving the device definition as a shortcut: clinical decision support (CDS) software outside FDA oversight can still be sued.

Frequently Asked Questions

We sell software, not a device. Do we need product liability insurance?

If the software is registered as a medical device, or its output informs clinical decisions, it may be treated as a product for bodily injury liability. In the EU the new directive says so expressly, and in Israel and the US the question is open. A product liability policy that defines software as a product, or a combined life sciences policy, may be relevant, subject to the policy wording.

We have a Tech E&O policy. Will it respond if a patient is harmed by the system’s recommendation?

Not necessarily. Tech E&O policies are written for financial loss, and many exclude bodily injury. Some wordings carve back bodily injury arising from software failure, and some combined policies cover both sides. Check the definition of damage and the exclusions, and read them together with the product liability policy.

Our model updates every quarter. Do we need to tell the insurer about every update?

It depends on the wording. Many wordings require notice of a material change in risk, and not every update is one. The practical approach is to describe the update mechanism and any approved change control plan in the proposal, and obtain written confirmation from the insurer that updates within that framework fall within the product description.

Does the AI Act delay change our insurance in Europe?

Only in part. Regulation (EU) 2026/1744 moved high-risk obligations for AI-enabled medical devices to 2 August 2028. The new Product Liability Directive was not delayed: it applies to products placed on the market from December 2026 and treats software as a product. Product liability cover should be prepared for that at the next renewal.

We build on a third-party foundation model. Who is liable if an update by the provider degrades performance?

Towards the patient and the hospital, the manufacturer that placed the product on the market is usually the first port of call. Whether it can recover from the model provider depends on the contract, and standard terms usually cap that provider’s liability heavily. Check that the policy covers failures originating in a third-party component, and record which model versions ran in each period.

We are starting a US study for a new version of the algorithm. Is our existing policy enough?

Usually not. A clinical study needs a dedicated policy for the country of the study and the ethics committee’s requirements, and a standard product liability policy often excludes study participants. Also check that the study version is defined separately from the commercial version, so there is no dispute over which policy responds.

With AI-enabled medical software, a claim reaches everyone who touched the decision, so every policy the company holds needs to describe the same product and the same markets, including how the product is updated.

The above is general information only and does not constitute insurance, legal or other professional advice. Coverage terms, exclusions and obligations are set by the specific policy wording and subject to applicable law. Each case should be reviewed on its own merits against the policy wording and with a qualified adviser.