Why does pre-incident documentation matter for insurance claims?

Insurance claims for AI-related losses depend on the insurer being able to understand what the system was supposed to do and what it actually did. The insurer needs to verify that the loss falls within the coverage scope, that the operator was using the system in the way the policy assumed, and that no exclusion applies. If the operator cannot show how the system was configured, who was overseeing it, and what the intended purpose was at the time of the incident, the insurer faces ambiguity about each of these questions. Ambiguity favours the insurer, not the policyholder. Comprehensive pre-incident documentation removes ambiguity and makes it much easier to demonstrate that a claim is valid.

What is the most common documentation gap that affects AI insurance claims?

The most common gap is the absence of an oversight record. Insurers consistently find that operators can describe what the AI was supposed to do, but cannot show who was responsible for reviewing its outputs or what process existed for catching errors before they affected customers. This matters because the insurer needs to establish whether the operator took reasonable steps to prevent the loss. An operator with no oversight documentation cannot demonstrate that they had a reasonable monitoring process, which is often the basis on which AI-related professional indemnity or liability claims turn.

Documenting AI Decisions for Insurance: A Practical Guide

Q: What documentation does an operator need before an AI insurance claim?

Before any incident, operators should maintain four categories of documentation. First, a system description covering what the AI agent does, who the provider is, the version being used, and the intended use case. Second, an oversight record confirming who reviews AI outputs, what authority they have to override, and how they are trained. Third, a change log tracking any modifications to the system, the prompts, the integration, or the data inputs since deployment. Fourth, an incident log recording any prior errors, complaints, or unexpected outputs, even if not material, and what action was taken. These four documents form the evidence base for any insurance claim. Without them, a claim can be disputed on the grounds that the operator cannot demonstrate how the system was configured or operated at the time of the incident.

Q: Does using a third-party AI tool reduce my liability?

Not automatically. The cases of Moffatt v. Air Canada (2024) and Mata v. Avianca (S.D.N.Y. 2023) both established that the operator of an AI system is responsible for the outputs of that system to the people it affects, regardless of whether the underlying technology came from a third-party vendor. The fact that the AI was built by someone else does not transfer the operator's liability to the tool provider. Operators should review their contract with the AI vendor to understand any indemnification provisions, but should not assume that vendor liability clauses fully cover the losses they might face from customers or courts.

Q: How long should I keep AI decision records?

Retention periods depend on the type of decision and the sector. For decisions that affect customer rights, such as credit, employment, or access to services, the minimum is typically the limitation period for legal claims in the relevant jurisdiction: three years in many EU member states for contractual claims, longer for negligence or regulatory matters. For decisions made under the EU AI Act's high-risk AI framework, Article 12 requires the provider to keep logs for a minimum period that will be specified in implementing acts, likely three to five years. In the absence of specific guidance, keeping AI decision records for five years after the decision is a reasonable minimum for most SMEs operating in the EU.

Key takeaways

Pre-incident documentation determines whether an AI insurance claim succeeds. Insurers need to understand what the system was supposed to do, how it was overseen, and whether an exclusion applies. All of these questions are answered by documentation created before the incident.
The four essential record types are: a system description, an oversight record, a change log, and an incident log. Every operator deploying AI that affects customers or produces outputs others rely on should maintain all four.
The most common documentation gap is the absence of an oversight record. Who reviewed the AI's outputs, and what did they do when they noticed a problem? Without this, operators cannot demonstrate they took reasonable steps to prevent the loss.
Retention should be a minimum of five years for decisions that affect customers, or longer where sector-specific regulations apply. For EU AI Act high-risk AI, the relevant retention obligation will be set in implementing acts expected in late 2026.
Documentation produced for insurance purposes is substantially the same as documentation required for regulatory compliance. Building one programme that serves both is more efficient than maintaining separate records for each.

The Air Canada lesson about documentation

In the case of Moffatt v. Air Canada, decided by the British Columbia Civil Resolution Tribunal in 2024, a passenger relied on information provided by Air Canada's chatbot about bereavement fares. The chatbot gave incorrect information. When the passenger sought the discount he was promised, Air Canada argued that it was not responsible for what its chatbot said. The Tribunal rejected this argument. Air Canada was liable for the representations made by its own AI agent.

The documentation dimension of this case is worth considering carefully. Air Canada presumably had some record of the chatbot's outputs, either through server logs or through the passenger's screenshot evidence. But the question any insurer would ask after a settlement is: did Air Canada have a process to review what the chatbot was telling customers? Did they have an oversight mechanism? Was there a change log showing when the chatbot's responses were last reviewed?

These are not hypothetical questions. They are the questions that distinguish a clean insurance claim from a disputed one. An operator who can show that they had a reasonable oversight process, maintained records of it, and were managing their AI agent responsibly is presenting a very different picture to an insurer than one who cannot answer these questions at all.

The four essential record types

Every operator deploying an AI agent that produces outputs others rely on should maintain four categories of documentation. These are the minimum set. Operators in regulated sectors, or operators whose AI falls within the EU AI Act's high-risk categories, may face additional documentation requirements under their specific regulatory framework.

1. System description

A system description is a written record of what your AI agent does, who the provider is, which version you are using, what it is intended to do, and what it is not intended to do. This does not need to be long. A one-page document that answers these questions is sufficient for most small businesses.

The intended purpose section is the most important part. Write down specifically what decisions or outputs the AI assists with, what the inputs are, and what happens with the output. If the AI drafts customer communications, say so. If it analyses data and generates recommendations that staff then act on, describe the specific workflow. If it generates quotes or pricing, describe the parameters.

Update this document whenever the use case changes. If you start using the AI for something it was not originally intended for, that change should be recorded. This is because insurance policies cover the use case described at the time of underwriting. An AI deployed for customer service that you then use for financial advice may not be covered under a policy that assumed the former. The change log (see below) is where to record the change; the system description is where the current state of the system is documented.

2. Oversight record

The oversight record is the document that most operators do not have and that most insurers most need. It answers three questions: who is responsible for reviewing the AI's outputs, what do they check and how often, and what is the process when they find a problem?

For a small business, this might be as simple as a written policy that states: "AI-generated customer communications are reviewed by [name or role] before being sent. If the reviewer identifies a factual error or a communication that may mislead a customer, the communication is corrected before sending and the issue is recorded in the incident log." This is enough to demonstrate that a human oversight process exists.

For AI that generates recommendations rather than communications, the oversight record should describe who reviews the recommendation, whether they have the authority to override it, and what training or competence they have that enables them to evaluate the AI's output. An AI that recommends a financial product, for example, should have its recommendations reviewed by someone qualified to assess whether the recommendation is appropriate for the customer. Document who that person is and what their relevant qualification or experience is.

The EU AI Act's Article 26(2) requires deployers of high-risk AI to assign human oversight to natural persons with the competence and authority to oversee the system's outputs. Even if your AI is not in the EU AI Act high-risk category, the same principle applies for insurance purposes: you need a person, and that person needs to be named or described in a document. If you cannot do this, you cannot demonstrate your oversight process to an insurer.

3. Change log

A change log records every material change to your AI deployment since the system went live. Material changes include: switching providers or model versions; changing the system prompt or instructions significantly; integrating the AI with a new data source; extending the use case to cover new types of decisions or outputs; and modifying the oversight process.

Changes matter for insurance because the system that produced an incident may be different from the system that was described at the time the policy was placed. If an incident occurs six months after you switched to a new model version, the insurer needs to know that the change occurred and that the oversight process reviewed the new version before it went live.

Keep the change log simple: date, description of the change, who approved it, whether the oversight process was updated in response, and whether the insurer was notified if the change was material. Most policies require notification of material changes. If you are not sure whether a change is material, assume it is and notify your broker.

4. Incident log

The incident log records any prior error, complaint, or unexpected output from the AI, even if it was minor and even if no customer was materially affected. Log the date, what happened, how it was detected, and what was done in response. Include near-misses: outputs that were caught by the oversight process before they reached a customer, and what they revealed about the system's behaviour.

The incident log serves two purposes. First, it is the track record that shows your oversight process is working. A log of ten minor incidents that were caught and corrected is evidence of a functioning oversight process. Second, it is the disclosure record for your next insurance renewal. Most AI liability policies require disclosure of known incidents and claims at renewal. A maintained incident log makes this disclosure straightforward and avoids the risk of non-disclosure invalidating your coverage.

The AI agent incident response guide on this site covers what to do in the immediate aftermath of a material AI incident, including how to preserve evidence and when to notify your insurer. The incident log is the foundation for that process.

How long to keep records

The minimum retention period for AI decision records depends on the type of decision and the sector. A useful baseline for most EU-based SMEs is five years from the date of the decision. This covers the typical limitation period for contractual claims in most EU member states (three years in Germany, five years in France and the Netherlands, varying elsewhere), and provides a buffer for regulatory investigations that may arise years after the decision was made.

For decisions that affect consumer rights, including any AI-assisted decision about credit, pricing, access to services, or employment, the longer of five years and the applicable sector limitation period is the appropriate minimum. For EU AI Act high-risk AI systems, Article 12 of Regulation (EU) 2024/1689 requires automatic logging to be retained for a period to be specified in implementing acts. Until those acts are published, a five-year minimum is consistent with the regulatory intent.

Store records in a form that cannot be altered after the fact. Version-controlled systems, tamper-evident logs, or audit-trail-enabled platforms are appropriate. Editable spreadsheets stored locally are not appropriate as the sole retention mechanism for material records: they cannot demonstrate that a record has not been altered after an incident occurred.

The connection to your insurance policy

When an AI-related claim arises, your insurer will investigate two questions. First, does the loss fall within the coverage scope? Second, was the operator operating the AI in the way the policy assumed? Both questions are answered primarily by documentation.

The coverage scope question is answered by the system description. If the AI was used for a purpose different from what was described at underwriting, the insurer may argue the loss is outside the coverage scope. The system description, updated when the use case changed and kept as a contemporaneous record, is the evidence that the system was being used for covered purposes.

The reasonable care question is answered by the oversight record and the incident log. Most AI liability policies require the operator to have taken reasonable steps to prevent the loss. The oversight record shows that a human review process existed. The incident log shows that prior problems were identified and addressed. Together they demonstrate that the operator was managing the risk rather than ignoring it.

The change log is the evidence that connects the policy conditions to the state of the system at the time of the incident. If the policy assumed a specific model version or configuration, and a change was made after inception, the change log shows when the change occurred and what review preceded it.

For a deeper look at the coverage landscape and what AI-specific products cover, the agentinsured.eu site provides detailed coverage framework analysis. For the regulatory compliance dimension of the same documentation obligations, the compliance documentation guide on agentliability.eu covers the EU AI Act requirements in full.

Getting started: a one-hour documentation sprint

If you currently have no AI documentation, this is where to start. Block one hour and produce the following. First, open a document and write a one-page system description for your primary AI deployment: what it does, who the provider is, what version, what the intended purpose is, and what it is not authorised to do. Second, add a section naming the person responsible for oversight and describing in two or three sentences what they check and how often. Third, note the date the AI was deployed and any material changes since then. Fourth, list any incidents, errors, or complaints involving the AI since deployment, even if minor.

Save this document with today's date in the filename. This is your baseline record. From today, maintain it as a living document: update the change log when anything changes, add entries to the incident log when anything goes wrong, and review the system description annually or when a new use case is introduced.

This is not a substitute for a full compliance or insurance review. The five questions before deploying an AI agent guide on this site covers the broader risk assessment. The coverage pathway explains the steps to move from documentation to an actual insurance submission. But the one-hour sprint gives you a foundation where previously there was none, and that foundation changes your position significantly when something eventually goes wrong.

Frequently asked questions

What documentation does an operator need before an AI insurance claim?

Before any incident, operators should maintain a system description, an oversight record, a change log, and an incident log. Together these four documents establish what the AI was doing, who was responsible for reviewing its outputs, whether any material changes occurred, and whether there were prior problems. Without them, a claim can be disputed on the grounds that the operator cannot demonstrate how the system was configured or operated at the time of the incident.

Does using a third-party AI tool reduce my liability?

Not automatically. Moffatt v. Air Canada (2024) and Mata v. Avianca (S.D.N.Y. 2023) both established that operators are responsible for the outputs of their AI systems to the people those outputs affect. Vendor indemnification clauses in software contracts may cover some losses but should not be assumed to cover all liability exposure. Review your vendor contract and your insurance policy together, not separately.

How long should I keep AI decision records?

A minimum of five years from the date of the decision is appropriate for most EU-based SMEs. This covers the typical limitation period for contractual claims in most EU member states and provides a buffer for regulatory investigations. Decisions affecting consumer rights, credit, or employment may require longer retention under sector-specific rules.