This article describes insurance and contract mechanisms as they are generally found in commercial practice across markets. It does not state the law of any jurisdiction, it quotes no policy wording and no contract, and it names no insurer, vendor or form. Where a jurisdiction is not mentioned, that is not a statement about that jurisdiction. Nothing here is legal advice anywhere.
- A certificate of insurance proves that a policy existed on a date. It is not the policy, it confers no rights on the holder, and it does not change when the policy is cancelled, exhausted or endorsed. Read the wording, not the certificate.
- The vendor's policy answers to the vendor. Its aggregate limit is shared across every customer, and a model or platform failure that reaches many customers draws on that one aggregate from every direction at once.
- Additional insured status is a general liability mechanism. On the technology errors and omissions cover an AI failure actually engages, it is rarer, narrower, and still subject to the shared aggregate and the exclusions.
- A contractual indemnity can be uninsured. Liability wordings commonly exclude liability assumed under contract beyond what the law would impose anyway, which is precisely the liability a negotiated indemnity creates.
- The indemnity cap is commonly a year of fees. The gap between that figure and a plausible loss is the deployer's own exposure, and the only policy that answers to the deployer is the deployer's own.
Section 1. The certificate
A certificate of insurance is a one-page summary, usually prepared by the vendor's broker, stating that the vendor holds policies of certain types with certain limits as at a certain date. It exists because reading a full policy in every procurement is impractical, and it does its job well: it tells a buyer that the vendor is not uninsured. It does nothing else, and the page usually says so in a line of small type stating that it is issued for information only, confers no rights on the holder, and does not amend, extend or alter the coverage afforded by the policies listed.
Three things follow, none of them controversial and all of them routinely forgotten. The certificate is a snapshot: the policy may be cancelled for non-payment, exhausted by other claims or endorsed with a new exclusion the next day, and the certificate on file will not change. The certificate is not evidence of what the policy covers: it names a class of insurance and a limit, and says nothing about the insuring clause, the definition of covered services, the exclusions or the retroactive date, which between them decide whether any given loss is inside the cover. And the certificate is not a promise to the deployer: it is a description of a contract between the vendor and its insurer, to which the deployer is a stranger.
The practical consequence is that a certificate should be treated as the beginning of a question rather than the answer to one. The question is: would this policy respond to the loss we are actually worried about, and if it did, how much of it would reach us. The certificate cannot answer either half.
Section 2. Whose policy it is, and what it shares
The vendor's technology errors and omissions or professional liability policy insures the vendor. Its insuring clause responds to claims made against the vendor for the vendor's wrongful acts in providing the vendor's services. A deployer facing a claim from its own customer, its own regulator or its own employee has no claim on that policy at all. It has, at most, a claim against the vendor, which the vendor may then seek to pass to its insurer. Two contracts stand between the deployer's loss and the vendor's insurer, and each has its own terms.
The second point is arithmetical and it is the one procurement most often misses. Liability policies typically carry a per-claim limit and an annual aggregate, and the aggregate is shared across every claim by every claimant in the policy year. For a conventional service provider that is manageable, because failures tend to be customer by customer. An AI vendor is different in a specific way: a defect in a model, a prompt, a retrieval layer or a platform tends to affect every customer using it at the same time. That is the characteristic shape of an AI failure, and it means a single incident can draw on the vendor's aggregate from every customer simultaneously. The limit on the certificate is the most that any one customer could theoretically recover if nobody else claimed. In the scenario that matters, everybody else does. The wider question of how systemic failure interacts with limits, on the deployer's own side, is treated at agentinsured.eu, on systemic model failure and aggregation.
A third point sits underneath both. A vendor's policy may itself now carry an artificial intelligence exclusion, or a sublimit for AI-related claims, because the market has been adding them. A certificate will not show this. Only the endorsement schedule will, and a vendor that has not read its own endorsements will report its cover in good faith and wrongly.
Section 3. Additional insured status
Being named as an additional insured on a counterparty's policy is a familiar and useful mechanism, and its familiarity is the problem, because it comes from a different class of insurance.
On a general liability policy, covering bodily injury and property damage, additional insured endorsements are standard, well understood, and give the named party direct cover for claims arising out of the insured's operations. Contractors, landlords and event organisers use them daily. A deployer who has seen the mechanism work in that context reasonably expects it to work the same way on the vendor's errors and omissions cover.
It usually does not, for three reasons. Additional insured endorsements on professional and technology liability policies are less common, because those policies insure the professional judgment of a specific insured and extending that to a third party sits awkwardly with their structure. Where they are granted, they are frequently narrower: limited to the deployer's vicarious liability for the vendor's acts, not to the deployer's own liability for deploying the system, which is the liability the deployer actually carries as an operator. And even a broad endorsement leaves the deployer drawing on the same shared aggregate described in section 2, alongside the vendor and every other customer, and subject to every exclusion in the wording, including the one discussed next.
None of that makes the status worthless. It makes it a small thing that is often presented as a large one, and a deployer should ask for the endorsement text, read what liability it actually extends to, and price it accordingly.
Section 4. The indemnity, and why it can be uninsured
The strongest-sounding protection in the contract is the indemnity: the vendor's promise to hold the deployer harmless against losses arising from the system. It is negotiated hard, it is drafted carefully, and it is the sentence most likely to be read aloud when a board asks whether the risk is covered.
Two mechanisms limit it, and they compound. The first is the contractual liability exclusion found in many liability wordings. In general terms, it removes cover for liability the insured has assumed under a contract, except to the extent the insured would have been liable anyway in the absence of the contract. An indemnity that merely restates what the vendor would owe at law adds nothing and is insured. An indemnity that goes further, which is the entire purpose of negotiating one, creates liability the vendor would not otherwise have, and that is the liability the exclusion is written to remove. The result is that a deployer can hold a well-drafted indemnity from a well-insured vendor and discover at claim that the indemnity is a promise from the vendor's balance sheet, not from its insurer. Whether the balance sheet can honour it is a credit question, and for an early-stage AI vendor it is not an idle one.
The second mechanism is the cap. Vendor contracts commonly limit liability, including under the indemnity, to a multiple of fees, and twelve months of fees is a frequent formulation, with a carve-out to a higher cap or an uncapped position for a short list such as confidentiality breach or intellectual property infringement. For a deployer paying a modest subscription for a system that takes or shapes decisions affecting large numbers of people, the cap can be a very small fraction of a plausible loss. Everything above the cap is the deployer's, and it was always going to be: the vendor's insurer, where it responds, responds only up to the vendor's liability, and the vendor's liability stops at the cap.
The allocation of liability between a model provider and a deployer as a matter of principle is set out at who pays, the foundation model provider or the deployer. This section is about something narrower and more practical: even where the contract puts the liability on the vendor, the money may not follow.
Section 5. A note on strict liability regimes
In jurisdictions that treat software as a product for the purposes of strict product liability, a manufacturer can be liable to an injured person without proof of fault. In the European Union that position arrives through Directive (EU) 2024/2853, which member states must transpose by 9 December 2026. This desk has read that directive's dates at source; it has not read the position in any other jurisdiction and characterises none.
The relevance here is limited and worth stating precisely. A strict liability regime changes who an injured person can sue and what they must prove. It does not rewrite the contract between vendor and deployer, it does not enlarge the vendor's policy, and it does not lift the indemnity cap. A deployer that is also, on the facts, a manufacturer or importer under such a regime carries that exposure in its own name, and the vendor's insurance is as remote from it as from anything else in this article. The European treatment of that double exposure is at agentliability.eu, on the AI Act and the Product Liability Directive together, and the global comparison of where strict liability reaches deployers at where strict liability exists.
Section 6. What to ask for instead
Ten requests, in place of a certificate. A vendor that can answer most of them is a vendor that has read its own cover, which is itself useful information.
- The insuring clause of the technology errors and omissions or professional liability policy, verbatim.
- The definition of the services or products the policy covers, and confirmation that the system being procured falls within it.
- The exclusions in full, with specific attention to contractual liability, to any artificial intelligence exclusion or sublimit, and to any exclusion for regulatory fines.
- The per-claim limit, the aggregate, and whether defence costs sit inside or outside them.
- The retroactive date, since a claims-made policy responds only to acts after it, and the system may have been in use earlier.
- The text of any additional insured endorsement offered, and the liability it actually extends to.
- An undertaking to notify the deployer of cancellation, non-renewal or material change, with a stated notice period.
- The indemnity cap, the carve-outs, and a worked example against a loss the deployer considers plausible.
- Whether the vendor's own contracts with its model or infrastructure providers pass any liability upstream, or stop at the vendor.
- The vendor's incident procedure and its notification commitment to the deployer, since a loss the deployer learns of late is a loss the deployer's own insurer may decline.
The eighth request is the one that most reliably changes the conversation. A cap expressed as twelve months of fees sounds reasonable in the abstract and looks different next to a number.
Section 7. The only policy that answers to you
Everything above points in one direction. The vendor's insurance protects the vendor. It may, in a good case, put the vendor in funds to honour part of an obligation to the deployer, after two contracts, one shared aggregate and a set of exclusions have each taken their share. It is a useful thing for a vendor to have and a poor thing for a deployer to rely on.
The deployer's exposure, as the party that put the system in front of its customers, its regulator and its staff, is the deployer's own, and only the deployer's own policy answers to it. Whether that policy responds to an AI-related loss is the question this network exists to help answer, and it is a question with a wording answer rather than a general one. The practical treatment of the vendor contract from the smaller operator's side is at insureyouragent.com, on reviewing an AI vendor contract for liability gaps, and the question of what an insurer can recover from a vendor after paying the deployer's claim, which is where a good vendor contract does earn its keep, is at agentinsured.eu, on subrogation and vendor contracts.
The related question of whether a vendor's assurance, as distinct from its insurance, tells a deployer anything is at required and available assurance. The short version is the same: a certificate of any kind describes the vendor, and the deployer's position has to be established separately.
Section 8. The point in one sentence
A vendor's certificate, its additional insured endorsement and its indemnity are three documents that each describe a promise to somebody else or a promise with a ceiling, so a deployer that reads them as its own cover has not read them.
Questions
What does a vendor's certificate of insurance actually prove?
That a policy of the stated type and limit existed on the date the certificate was issued. That is all. A certificate is a summary prepared by a broker for information; it is not the policy, it does not amend the policy, it confers no rights on the person holding it, and it is commonly issued with a statement that it does not do any of those things. The policy can be cancelled, exhausted or endorsed the day after the certificate is issued and the certificate will not change. A buyer who wants to know what the vendor's cover would do in a loss has to read the insuring clause and the exclusions, not the certificate.
Why does the vendor's policy limit matter less than it looks?
Because it is shared. A technology errors and omissions policy typically carries a per-claim limit and an annual aggregate, and the aggregate is shared across every claim by every customer of the vendor in the policy year. An AI failure that affects many customers at once, which is the characteristic shape of a model or platform failure, draws on that single aggregate from every direction simultaneously. The figure on the certificate is the most any one customer could theoretically recover if nobody else claimed. It is not the amount available to you.
Does being named as an additional insured on the vendor's policy protect a deployer?
Less than the phrase suggests. Additional insured status is a well-established mechanism on general liability policies, where it gives a named party cover for claims arising from the insured's operations. The cover an AI failure usually engages is technology errors and omissions or professional liability, and additional insured endorsements on those policies are less common, narrower where they exist, and often limited to vicarious liability for the vendor's acts rather than the deployer's own. Even where granted, the status gives the deployer a claim on the same shared aggregate, alongside the vendor and every other customer, and it does not survive the policy's exclusions.
How can a contractual indemnity from the vendor be uninsured?
Through the contractual liability exclusion, which is common in liability wordings. It removes cover for liability the insured has assumed under a contract, except where the insured would have been liable anyway in the absence of the contract. An indemnity that goes beyond what the vendor would owe at law, which is the whole point of negotiating one, is precisely the liability the exclusion targets. The result is that a deployer can hold a well-drafted indemnity from a well-insured vendor and find, at claim, that the indemnity is a promise from the vendor's balance sheet and not from its insurer.
What is the typical shape of an indemnity cap in AI vendor contracts?
A multiple of fees, commonly the fees paid in the preceding twelve months, with a carve-out to a higher cap or an uncapped position for a short list of matters such as confidentiality breach or infringement. For a deployer paying a modest subscription for a system that makes decisions affecting large numbers of people, the cap can be a very small fraction of a plausible loss. The gap between the cap and the loss is the deployer's own exposure, and it does not shrink because the vendor is insured, because the vendor's insurer, if it responds at all, responds only up to the vendor's liability, and the vendor's liability stops at the cap.
What should a deployer ask for instead of a certificate?
The wording. Specifically: the insuring clause of the vendor's technology errors and omissions or professional liability policy, the definition of the services or products it covers, the exclusions in full including contractual liability and any artificial intelligence exclusion, the per-claim and aggregate limits and whether defence costs erode them, the retroactive date, and an undertaking to notify the deployer of cancellation or material change. Then, separately, an honest assessment of the deployer's own cover for the same loss, because that is the only policy that answers to the deployer rather than to the vendor.