The retroactive date is the most important number in an AI liability policy

Section 1. The mechanic, stated plainly

Liability insurance is written on one of two triggers. An occurrence policy responds to injury or damage that happens during the period, whenever the claim is eventually brought. A claims-made policy responds to claims first made against the insured and notified to the insurer during the period, whenever the underlying conduct occurred, subject to one boundary: the conduct must not predate the retroactive date.

Professional indemnity, errors and omissions, directors and officers, cyber liability and the affirmative AI products now appearing in Europe are almost all claims-made. General liability, the policy most operators think of first, is usually occurrence-based, which is one reason the two behave so differently when an AI failure surfaces.

The consequence in a single example. A policy incepts on 1 October 2026 with a retroactive date of 1 October 2026. In March 2027 a customer brings a claim arising from advice that an AI agent gave in June 2026. The claim is made during the policy period. It is notified during the policy period. It is not covered, because the act took place four months before the retroactive date. Nothing about that outcome is unusual, unfair, or a drafting failure. It is the contract working exactly as written, and the buyer signed the schedule that said so.

Section 2. Why the lag is worse for AI

Every liability line has a reporting lag. What makes AI distinctive is the shape of it.

A conventional professional error is usually discrete. An adviser gave the wrong advice to one client on one day, and the client discovers it when the consequence lands. The act has a date, the date is knowable, and the retroactive date question has a clean answer.

An AI agent's error is usually not discrete. A pricing agent applies a wrong rule to every quote it issues for six weeks. A support agent misstates a refund policy to several hundred customers before anyone escalates. A screening agent weights a field in a way that produces a skewed shortlist across an entire hiring season. In each case the conduct is continuous, the harm is distributed, and discovery comes not from the injured party but from an internal audit, a regulator's question, or a pattern in the numbers that somebody finally noticed.

Two consequences follow. The first is that the discovery lag is long and does not correlate with severity, so the period before your first policy is not a low-risk period simply because nothing has surfaced from it yet. The second is that the conduct does not attach cleanly to a single date, which raises a question the schedule must answer and often does not: for a continuous behaviour spanning the retroactive date, does the policy respond to the part that falls after it, or does the whole matter fall out because the behaviour began before it? That is a wording question with materially different answers between markets, and it is worth asking at quotation rather than at claim.

The related question of whether a systematic failure is one claim or many determines which limit applies and how the deductible bites. We treat that separately in systemic model failure and aggregation risk and in sublimits and aggregate caps.

Section 3. The first-time buyer problem

Almost every European organisation buying affirmative AI cover in 2026 is buying it for the first time. There is no expiring policy to inherit a retroactive date from, so the default is inception, and the default is what appears on the quotation unless somebody asks for something else.

This produces a specific and slightly absurd result. The reason a compliance function finally got budget approved is usually that the organisation now has agents in production doing consequential things. The agents have been running for a year, or two. The policy that budget bought begins on the day it is signed. The entire operating history that made the risk visible and the purchase necessary is on the wrong side of the line.

Operators sometimes assume that the underwriting submission cures this, on the reasoning that they disclosed the deployment history, the underwriter reviewed it, and the premium reflects it. It does not work that way. Disclosure establishes what the underwriter knew when pricing. It does not extend the temporal reach of the contract. Those are separate provisions and only one of them is on the schedule. Our walkthrough of what a submission should contain is at preparing an AI agent underwriting submission.

Section 4. What buys an earlier date

Prior acts cover is negotiable and it is not free. The underwriter's objection is straightforward and reasonable: the period before inception is the period they cannot see, and they are being asked to price behaviour that has already happened and may already have gone wrong without anyone knowing yet.

Three things move that conversation, and all three are records rather than arguments.

Interaction history. Not the volume, the content. What the agent was permitted to do, what it actually did, and what proportion of interactions ended in escalation, correction or refund. An underwriter reading a real distribution is pricing a known exposure. An underwriter reading a summary paragraph is pricing an unknown one.

Change history. Every material change to the prompt, the system instruction, the model version, the retrieval sources and the tool permissions, with dates. This is the single most persuasive artefact an operator can produce for a retroactive date discussion, because it converts an opaque past into a timeline. It is also, not coincidentally, the artefact a certification assessment asks for. The methodology treatment is on agentcertified.eu, on change control as certification evidence.

Incident register. A dated list of what went wrong, what was done, and what changed as a result, including the small ones. Operators worry that disclosing incidents damages the submission. In practice a clean register with entries in it reads better than an empty one, because an empty register on a system that has been live for eighteen months tells the underwriter that nothing was being watched.

Where full prior acts cannot be obtained, a middle position is often available: a retroactive date set to the go-live date of the specific agent, or to the date of a documented change that materially reduced the risk, such as the introduction of human review on a class of output. That is a narrower ask and a more answerable one.

Section 5. Four continuity traps

Once a retroactive date exists, the risk shifts from getting one to keeping it.

Changing insurer. A new insurer sets a new retroactive date. Unless continuity is expressly required in the instruction to market, a cheaper renewal can arrive with the retroactive date reset to the new inception, which deletes prior acts cover at exactly the moment the buyer believes they have improved their position. The premium saving is visible on the invoice. The cover reduction is on the schedule and rarely mentioned.

Changing product form. Moving from an AI endorsement sitting on a cyber policy to a standalone AI liability contract is a change of contract, not an upgrade of an existing one. Continuity between them has to be arranged deliberately, even with the same insurer.

Prior known circumstances. Every claims-made wording excludes matters the insured already knew about, or ought reasonably to have known about, at inception. An earlier retroactive date does not defeat that exclusion. Cover for prior acts covers things you did not know had gone wrong. It does not cover the incident already sitting in your register that you decided not to notify.

Decommissioning and run-off. Retiring an AI agent does not retire the claims it can still generate, and a claims-made policy that lapses stops responding even to conduct that occurred while it was in force. If an agent is switched off, if a business unit is sold, or if the organisation is acquired, an extended reporting period is the mechanism that keeps the tail insured. This is an underconsidered point in a market where agents are frequently replaced with newer ones and the old policy is simply not renewed.

Section 6. The clause worth knowing about

The most useful provision in a claims-made contract for an AI operator is the one that permits notification of circumstances. In broad terms, an insured may notify a circumstance that might reasonably be expected to give rise to a claim, and any claim later arising out of that circumstance is treated as having been made in the period in which the circumstance was notified.

Applied to AI, this is unusually powerful, because AI failures are typically discovered internally before they are complained about externally. The moment an audit shows that an agent has been giving a wrong answer to a recurring question for two months, a circumstance exists. Nobody has claimed. There may be no complaint for a year. Notifying now fixes any resulting claim to this policy year, with this limit and this retroactive date, instead of leaving it to emerge after a renewal or a change of insurer that has reset both.

Two cautions. Notification of circumstances has to be done properly, with enough specificity that the later claim can be tied to it, and vague protective notifications are a well known source of dispute. And notification is not consequence-free: it will be visible at renewal and may affect terms. That is a real cost and it is almost always smaller than the cost of an uninsured claim. What triggers payment once a claim exists is covered in how AI insurance claims work.

Section 7. Why this matters more from here

The European regulatory calendar makes the temporal question sharper rather than softer. Article 50 transparency obligations applied from 2 August 2026 and were not deferred by the Digital Omnibus. The Omnibus, in force since 27 July 2026, moved the Annex III high-risk obligations to 2 December 2027 and the Annex I obligations to 2 August 2028. The revised Product Liability Directive must be applied by Member States from 9 December 2026.

Read those against a claims-made contract and one point stands out. A policy bought today, renewed several times, may be the contract that answers a claim in 2029 arising from a deployment decision taken in 2025 or 2026, in the period before any of these obligations bit. Whether it answers at all is decided by the retroactive date carried through those renewals, not by which regulation was in force when the agent was built. The regulatory dates set when supervision arrives. The retroactive date sets whether your insurance reaches back to the same place. The two calendars are unrelated, and buyers routinely assume they are the same one. The cross-jurisdictional reading of those dates is on agentliability.co.

Section 8. Six things to establish at bind

1. What is the retroactive date, in writing, on the schedule, and how does it compare to the go-live date of the oldest agent in scope?
2. For conduct that is continuous and spans the retroactive date, does the policy respond to the part occurring after it, or fall away entirely?
3. What evidence would move the retroactive date earlier, and what is the additional premium for full prior acts?
4. Is continuity of the retroactive date a stated requirement in the instruction to market at every future renewal?
5. What is the notification of circumstances wording, who inside the organisation is authorised to make a notification, and what is the internal trigger for doing so?
6. What extended reporting period is available, at what cost, and what happens to it on an acquisition or on the decommissioning of an insured agent?

None of these are difficult questions. They are simply questions nobody asks at the point where the limit and the premium are being argued over, and they determine whether the contract reaches the conduct that will generate the claim. The wider renewal-time reading of an AI policy is set out in what changes at an AI insurance renewal.

Section 10. Sources