When AI quietly breaks things, who pays?
David Halbreich, an insurance recovery partner at Reed Smith, breaks down how AI companies should handle coverage gaps that come up as the industry grows. He covers straddle claims that fall between tail and go-forward D&O policies after a merger, how governance disclosures in applications can turn into warranties an insurer uses to deny a claim, who should sign off on AI use questions, when the claim clock starts for slow-building model degradation, and how business interruption coverage applies to outages at cloud and compute vendors.
When an AI company calls you for the first time, it is usually after a demand letter has arrived. Without naming names, what is the most common thing a general counsel tells you their program covers that, once you read the endorsement schedule, it does not?
The most common misconception like this that I encounter is not about the “what” of coverage, but rather the “when.” With all the merger activity in the AI space, there has been renewed focus on “straddle” claims that fall through the cracks of the tail and going-forward policies after a merger.
Directors and officers (D&O) coverage, which applies to liability for wrongful acts by company leadership in the course of running the business, and errors and omissions (E&O) policies, which apply to liability for lapses in professional services provided by the company, are essential for AI companies. Both D&O and E&O policies are typically issued on a claims-made basis. That means they apply to claims that are asserted against policyholders during the policy period (in contrast to occurrence-based policies that apply to loss arising from an “occurrence” or accident that took place during the policy period, irrespective of when the claim against the insured is ultimately made).
Claims-made policies may also include a “retroactive date” limiting how far back the conduct giving rise to the claim can have occurred for coverage to apply.
When a target company is acquired, it is customary to obtain extended reporting period coverage (also referred to as “runoff” or “tail” coverage”) that prolongs the window during which claims can be reported under the policy. The acquiring company will generally procure a new policy (often called “go-forward” coverage) that becomes effective at or around the closing date and is designed to respond to claims arising from conduct occurring after the transaction.
On paper, this framework appears to provide continuous protection for historical liabilities (under the tail coverage) and future conduct (under the go-forward coverage). However, problems can arise when a claim does not fall squarely into one time period or the other. Tail policies often contain broad exclusions for claims involving any conduct after the cutoff date, but such claims may not be covered by the go-forward policy, either, insofar as they also involve pre-merger conduct. Claims that allege both pre- and post-transaction wrongful acts straddle the cutoff point between the tail policy and the go-forward policy are often referred to as “straddle” claims, and the policyholder can be caught in the middle with no coverage.
This is a problem that can plague even sophisticated deal and in-house counsel, who may have thought they had done all they needed to in procuring both tail and go-forward policies. It is critical to review the policies—and relevant exclusions—in tandem to consider how the policies will respond in the event of a straddle claim. That way, if necessary, the policyholder should get policy clarifications or enhancements that will squarely assign straddle claims to one policy or the other and avoid a coverage gap.
Underwriters are now asking for governance artifacts: bias testing records, human-in-the-loop protocols, model cards, evaluation results. When those answers get incorporated into the policy by reference, at what point does a governance representation stop being an underwriting input and become a condition precedent or a warranty the carrier can use to deny? What language do you strike?
This is an area where policyholders probably benefit from adding more specificity. Adding requirements for knowledge/intent and materiality of misstatements can avoid turning incorporation of the application into a strict warranty. Policyholders should also seek limitations on the consequences of misstatements, with coverage restricted only as to those covered individuals responsible for the misstatements, or only restricted for the company if certain identified individuals knew of the misstatement. Policyholders should also make sure that the policy specifies that misstatements in the application will not be grounds for rescission of the entire policy.
Application questions about AI use are often answered by a risk manager who does not know what every product team is running. How should a company build the internal process for answering those questions, and who should be signing?
This is a challenging issue that organizations have had to confront before it arose in the context of AI. If you think of the quintessential original property risk, fire, there are all kinds of best practices for fire prevention and risky behaviors that may need to be avoided. More broadly, companies that manufacture and move physical products may be asked to provide information about company policies related to worker and consumer safety and otherwise avoiding loss in the course of their ordinary and necessary operations. This is also an issue that does not just arise in the insurance context. Clients may have requirements, like data security protocols, that their service providers—including lawyers like me—have to adhere to.
The first aspect of addressing this issue is simply establishing the necessary protocols to begin with. So for AI use, there may be policies around which specific agents or products can be used, in which contexts they may be used, what information can be provided to them, etc.
But then there’s the rub of getting everyone in the organization to comply, and how to ensure that they are doing so. That’s an issue that can fill whole textbooks and is beyond the scope of this discussion, except to say that being able to certify externally that policies or best practices are being adhered to starts with having that confidence within the organization, which is vital to risk management in any event.
In that sense, AI companies are similar to other organizations with many products, organizations, operations, processes, and diverse risks. I would advise a risk manager to institute an organized process several months before the renewal date of the existing program that would advise the organization of the upcoming renewal, emphasize the importance to the renewal of understanding the different products the company is running, and advising that risk management will follow up with the individual teams so as to get as complete a picture as possible. And because this field is so fast moving, questions about the products the teams are running should also include getting information about new products that may be tested or rolled out in the course of the next policy period so that the insurance implications can be incorporated into the renewal process.
With respect to the insurance application aspect of this more specifically, I think the starting point is similar to what I always advise risk managers, which is to carefully read the policy—or in this case, the application. Just as understanding the specific wording of the company’s insurance policies and what’s covered is critical before there is a loss so that the company can make sure it has the coverage it needs, risk managers should carefully review and understand whatever representations they’re being asked to certify in an application.
Don’t just sign something because you assume it’s “standard.” If what an insurer is asking for is too broad, or is not something one person can reasonably attest to, the company should work to revise the representation to something more reasonable. For example, a risk manager can make representations about what policies a company has in place more easily than about how policies are being followed. Companies can also try to make it explicit that the risk manager’s attestation is limited to their own knowledge (which may be coupled with the need to provide information about the process for issues being reported to the risk manager).
Model degradation is gradual. A claims-made policy needs an act, error, or omission and a claim. When a customer discovers eighteen months of quietly deteriorating outputs, when does the clock start, and how do related claims provisions either help or hurt the policyholder in that fact pattern?
Under a claims-made policy, the policy applies if the claim is made during the policy period. The fact that the alleged error or omission giving rise to the claim may predate the policy will not affect coverage unless the policy has a retroactive date that cuts off coverage for errors before that date. For AI companies whose business may involve a long lag time between when alleged errors took place (unknown to the policyholder) and resulting claims may arise, pushing the retroactive date back as far as possible may be a priority during placement.
While insurers will often impose a retroactive date of when you first placed coverage with them, they can often be persuaded to extend the retroactive date back further to when the policyholder had coverage from another insurer. This is among the reasons that it is important not to let claims-made coverage lapse.
Related claim provisions provide that if a claim during the current policy period arises from the same or related errors that gave rise to a previous claim from before the policy period, both claims will be treated as a single claim, which would mean that the new claim would not be covered under the current policy; however, if notice for the related previous claim was provided under the policy that was in effect then, the related new claim may be covered under that old policy. The definition of “related” can vary, so it’s important to know what your policy says.
Related claim provisions could be detrimental in that fact pattern if a new claim is related to an old claim, but coverage under the old policy that was in effect when the old claim was made is not available. That could be because notice was not provided under the old policy, or because the per-claim or aggregate limit of the old policy has been exhausted. For a scenario like the one described, if the customer’s claim were considered “related” to other similar past claims raised by other customers, the policyholder could find that there is no coverage left under that older policy because those limits have already been exhausted in connection with the older claims.
On the other hand, there are situations where it may be beneficial to the policyholder for a new claim to be related to an older claim. Increasingly, insurers have been trying to manage their exposure to AI risks by adding policy provisions that narrow coverage. Relating a new claim back to an earlier claim made during a period when a policy with broader coverage applied could enable the policyholder to access coverage that would not be as readily available under the current policy—as long as the old policy still has sufficient limits available to cover both related claims.
Traditional business interruption requires physical damage. AI companies concentrate their operational risk in third party compute, model providers, and inference APIs. How are contingent business interruption and system failure grants being drafted for that dependency, and what waiting periods and dependent vendor schedules are you fighting over?
Courts around the country have taken different positions on whether digital loss triggers business interruption coverage. As might be expected, the outcome tends to depend on specific policy language, so AI companies will want language that addresses the risks they face.
With respect to waiting periods, even a brief outage of a few hours can have a massive impact on AI companies, so longer waiting periods that were common in the past are not practical for those companies. The goal of waiting periods has traditionally been thought of as distinguishing between minor temporary issues, on the one hand, and significant disruptions that a policyholder could not just accommodate as a routine part of every day business, on the other hand. For AI companies in the business of providing compute-powered services literally all the time, it may make more sense to address that distinction with concessions on monetary deductibles as a way to reduce waiting periods.
For dependent vendor schedules, policyholders will generally want more flexibility with respect to listing requirements, and this can be essential for some policyholders. But for AI companies that may depend heavily on a discrete and identifiable set of vendors like data centers and electricity providers, a bigger issue is often avoiding vendor sublimits that insurers try to impose to mitigate such risk concentration. Underwriters may also require proof of redundancy or back-up plans to address this.
Download: 2026 Credential Risk Report
