Insure Your Agent Operator Edition

Future Proof Intelligence · Published 27 May 2026 · 13 minute read

Your AI agent made a mistake. Here is what to do in the first 72 hours.

AI agents make mistakes. A customer-facing chatbot gives wrong information. A booking tool cancels the wrong appointment. An email assistant commits to something that was never intended. When it happens to your business, the next 72 hours will determine whether the situation resolves cleanly or escalates into a formal complaint, a claim, or worse. This guide gives you a clear sequence of actions, based on how liability develops in real cases, starting from the moment you find out something went wrong.

Key takeaways

  • The most important thing to do first is not to turn off the AI agent. It is to preserve all the logs and records of what happened. You will need them.
  • Notify your insurer within the timeline specified in your policy, even if you are not certain a claim will follow. Late notification can void your right to claim.
  • Do not admit liability to the customer before you understand what happened and before you have spoken to your insurer.
  • The Moffatt v. Air Canada case (British Columbia Civil Resolution Tribunal, February 2024) established that businesses are legally responsible for what their AI agents tell customers, even if no human reviewed the output first.
  • A business with good documentation (what the agent said, when, to whom, under what instructions) is in a significantly better position than one whose logs were lost or overwritten.

Before the response: understanding what happened

Not every AI agent incident is the same, and the right response depends on what type of mistake occurred. Before you do anything else, take a few minutes to categorise the incident. This shapes every decision that follows.

There are four main types to distinguish. The first is wrong information given: the agent stated something factually incorrect that the customer may have relied on, such as a price, a policy, an availability date, or a service specification. The second is a commitment made: the agent promised something your business did not authorise and may not be able to fulfil, such as a refund, a discount, a specific delivery date, or a particular service outcome. The third is an action taken: the agent did something in the world (booked, cancelled, sent, submitted, purchased) that was not authorised or was executed incorrectly. The fourth is content produced: the agent generated text, an image, or other material that creates a third-party issue such as an intellectual property concern, a defamation risk, or a data protection problem.

Once you have identified the type, consider scope: how many customers were affected, what was the potential financial or reputational consequence for each, and whether the underlying error is still active (meaning the agent could still be making the same mistake to other customers right now). Reversibility matters too. A wrong appointment that has not yet happened can be corrected. A payment that has already processed cannot be undone without a formal refund process. An email that has been sent cannot be unsent.

This preliminary assessment does not need to be perfect. It needs to be fast and honest. Write it down. A one-paragraph summary of what you understand to have happened is more useful than a prolonged internal discussion about whose fault it was.

Hours 0 to 4: preserve and assess

The single most important action in the first four hours is evidence preservation. Everything the AI agent produced, every log, every output, every action record, every metadata timestamp, needs to be captured and stored before anything else changes the system state.

Do not update the AI agent. Do not retrain it. Do not patch the underlying model or the instructions. Do not upgrade the platform it runs on. If your AI system is cloud-hosted and updates automatically, take a snapshot of the current configuration, the current prompt or instruction set, and the current version number. If your logs rotate or overwrite on a schedule, export them now.

This is not bureaucratic caution. It is practical necessity. An insurer reviewing a claim needs to understand what the agent was instructed to do, what it actually did, and whether the two diverged. A customer who brings a formal complaint will want the same. If you have changed the system before preserving this evidence, you have made your own position harder to defend and may face questions about why the records no longer match.

Document the affected customers at this stage too. Who received the wrong information, the incorrect commitment, or the unintended action? What did they receive exactly? What is their contact information? You do not need to contact them yet, but you need to know who they are.

Make a preliminary assessment of the potential harm. Is this a minor inconvenience (wrong opening hours given), a moderate problem (wrong appointment time booked), or a significant liability (a financial commitment made to multiple customers on incorrect terms)? Your response will be calibrated against this, and so will your insurer's interest in the matter.

Hours 4 to 24: initial customer contact

How you speak to the affected customer in the first day matters more than most operators expect. The goal at this stage is to acknowledge the problem, demonstrate that you are taking it seriously, and set a realistic expectation for resolution, without making the legal situation worse.

What to say: acknowledge that there was an error, that you are aware of it, and that you are looking into it. Confirm that you will follow up by a specific time (within 24 to 48 hours is typically reasonable). Thank the customer for bringing it to your attention if they did.

What not to say: do not admit legal liability in your own words. There is a difference between "we are sorry this happened and we are looking into it" and "we accept full responsibility and will pay whatever you ask." The first is human and appropriate. The second can bind your business in ways that complicate your insurer's position and close off options that might otherwise be available. The phrasing matters. Keep it honest, keep it warm, and keep it factual about what you know so far.

The Air Canada case is instructive here. When Jake Moffatt contacted Air Canada's customer service team after the chatbot gave him incorrect bereavement fare information, the response he received acknowledged that the chatbot had provided misleading information but told him the real policy overrode whatever the bot had said. That response, read carefully in the tribunal decision, was not compassionate and was not practically helpful. It also did not offer any pathway to resolution short of formal complaint. A business that said "we understand what our system told you, we are sorry for the confusion, here is what we can do" had better options. For the full background on what the Air Canada chatbot case means for your business, that article is worth reading alongside this one.

One practical note: if the agent is still running and still capable of making the same mistake to other customers, this is the window in which you decide whether to pause it. The decision is documented either way. If you pause it, write down why and when. If you keep it running, write down why and what monitoring you put in place.

Hours 24 to 48: notify your insurer

By the end of day two, you should have notified your insurer. This is not optional and it is not something to defer until you know whether a formal claim is coming. Most professional liability policies and cyber liability policies have notification clauses that require you to report circumstances that may give rise to a claim within a defined window. That window is often 30 days from when you first became aware of the incident. Missing that window can void your right to claim on that specific incident entirely.

Notifying your insurer does not mean a claim is being made. It means you are preserving your right to make one if the situation develops that way. Insurers deal with precautionary notifications regularly and do not penalise operators for exercising due diligence.

When you make the notification, be factual and concise. Tell them: what the AI agent did or said, when you became aware of the problem, who the affected customer or customers are and what their potential loss may be, what you have done so far (evidence preserved, customer contacted, agent status), and what you know about the root cause if anything. Do not speculate beyond what you actually know. Do not describe the incident as definitely your fault or definitely not your fault. Stick to the facts.

Ask your insurer for two things in this initial contact: guidance on evidence preservation (in case there are specific records they will need later), and guidance on how to communicate with the affected customer going forward. Insurers often have preferred language for these situations and it is better to use it than to discover after the fact that something you said complicated the claim. For context on coverage gaps for autonomous AI agent actions, the situation is more nuanced than many standard policies currently anticipate.

Document the notification itself: the date, the time, who you spoke to or what email address you sent it to, and any reference number the insurer provides.

Hours 48 to 72: document the incident formally

By the end of the third day, you should have a written incident record. This document is the foundation for any insurance claim, any legal defence, and your own internal review. It does not need to be long. It does need to be complete, accurate, and dated.

A useful incident record contains the following: the date and time the incident occurred (as best you can reconstruct it), a description of what the AI agent did or said, the customer or customers who received the output or experienced the action, what harm if any has resulted so far (financial loss, reliance on wrong information, missed appointment, distress), a copy or reference to the evidence you preserved in hours 0 to 4, a record of the customer communication you sent in hours 4 to 24, the insurer notification record from hours 24 to 48, and a summary of the agent's configuration and instruction set at the time of the incident.

This document should be stored somewhere that is not the AI system itself. A shared folder, a cloud document, an email thread with a clearly labelled subject line. It needs to be retrievable six months or two years from now if a claim develops slowly.

At this stage you are also in a position to give the customer a more complete response. You know what happened. You have spoken to your insurer. You have a clearer picture of what options are available to you. The customer update in the 48 to 72 hour window should be more substantive than the initial acknowledgment: here is what we found, here is what we are doing about it, here is what we are offering. That specific offer is a conversation for you and your insurer to have together. The point is that by 72 hours you should be in a position to have it.

After 72 hours: root cause and change

Once the immediate response is managed, the most valuable thing you can do is a proper root cause analysis. Not to assign blame but to understand exactly what condition in your system produced this outcome, and what change would prevent a recurrence.

The root cause is almost always in one of three places. The instruction set was wrong: the agent was told to do something, or permitted to do something, that it should not have been. The knowledge base was out of date: the agent was drawing on information that was no longer accurate (a price list from last quarter, a policy that had been superseded, a product that had been discontinued). Or the scope was too broad: the agent was permitted to take actions or make commitments that should have required human review before execution.

For each of these, the fix is different. A wrong instruction requires updating the instruction set and testing the agent against a set of cases that would have caught the original error. An outdated knowledge base requires a process for keeping it current, and for verifying that the agent flags uncertainty rather than confabulates when the information it has is incomplete. A scope problem requires adding guardrails: explicit boundaries on what the agent can commit to, and an escalation path that routes consequential decisions to a human.

Document what you changed and why. This is not paperwork for its own sake. If a similar incident occurs later and you are asked whether you took reasonable steps after the first one, this document is your answer. An operator who identified the root cause, made a specific change, and can show what that change was, is in a materially better position than one who patched the system and moved on.

The broader question of who is liable when your AI agent makes a mistake is worth reading at this stage. Understanding the full liability picture helps you calibrate how much of the root cause work is a legal necessity versus a prudent business practice. In most cases the answer is both.

If the incident was significant enough to warrant it, consider whether your internal processes need broader review. Are all your AI agents subject to the same evidence preservation procedures? Do all relevant staff know how to escalate an AI incident? Does your insurance policy actually cover the type of incident that occurred? These questions are uncomfortable after an incident, but they are much cheaper to answer now than during a second one.

For operators who want a more structured framework beyond the 72-hour window, the process of building a formal AI incident response plan is the logical next step from this guide. The 72-hour sequence described here is the immediate response. A formal plan is the infrastructure that makes future responses faster, less stressful, and better documented from the start.

The documentation that protects you

To summarise, here is the documentation you should have in place by the end of 72 hours, and why each piece matters.

Evidence preservation package. Conversation logs, output records, action logs, timestamps, and configuration snapshot. This is the factual record of what happened. Without it, every claim about what the agent said or did is disputed.

Incident record. Date, time, description, affected customers, harm assessment, summary of agent configuration. This is the narrative of the incident. It is required for any insurance claim and for any legal review.

Customer communication log. What you sent, when, to whom, and what response you received. This demonstrates that you responded promptly and in good faith, which is relevant to both the legal analysis and the insurer's view of the claim.

Insurer notification record. Date, time, contact details, reference number, and any guidance received. This proves that you met the notification requirement in your policy. Without it you may lose the right to claim on the specific incident.

Root cause and change documentation. What you identified as the cause, what you changed, and when. This demonstrates that your response was proportionate and considered, not reactive or incomplete.

Keep all of these records for a minimum of three years. In many jurisdictions, the limitation period for a contract or consumer protection claim is three to six years from the date the customer became aware of the harm. Claims can arrive long after you have moved on from the incident mentally.

None of this documentation requires specialist software or legal expertise to produce. A clearly labelled folder in your cloud storage, with dated documents, is sufficient. The goal is that if anyone needs to reconstruct what happened and how you responded, the answer is available in fifteen minutes, not a three-week forensic exercise.

Frequently asked questions

What counts as an AI agent mistake from a business liability perspective?

An AI agent mistake is any output or action by an AI system your business deployed that caused harm to a customer, third party, or your own business. Common examples include a chatbot providing incorrect pricing or policy information that a customer relied on, an AI scheduling tool booking the wrong time or cancelling something it should not have, an AI customer service agent making a commitment your business cannot fulfil, or an AI content tool producing output that infringes on someone's intellectual property. The Moffatt v. Air Canada tribunal decision in February 2024 confirmed that a business is legally responsible for harmful representations made by its chatbot, even if the bot produced the information without a human reviewing it.

Should I turn off the AI agent immediately when something goes wrong?

Not necessarily, and certainly not as your first move. Immediately disabling a system destroys logs that you will need later. Your first move should be to scope the problem: identify what the agent said or did, to whom, and what the potential consequences are. If the agent is still interacting with customers and making the same error repeatedly, then pausing it is the right call. If it was a single incident, you may be better served keeping the system running while you investigate, so you do not create a second incident by disrupting customer service. Document your decision either way.

Do I need to notify my insurer about an AI agent incident?

Yes, and sooner rather than later. Most professional liability and cyber policies have a notification clause requiring you to report circumstances that may give rise to a claim within a defined period, often 30 days of becoming aware. Failing to notify promptly can void your right to make a claim on that incident. Even if you are not sure whether the incident will become a formal claim, notify your insurer as a precautionary measure. Document the date and time of your notification. Do not admit liability to the customer before consulting your insurer.

What records should I preserve after an AI agent incident?

Preserve everything the AI agent produced: conversation logs, output records, action logs, and any associated metadata including timestamps. Preserve records of the customer interaction: the original query or request, the agent's response, and any follow-up communication. Preserve your system configuration as it existed at the time of the incident. Do not update, patch, or retrain the AI system before preserving a snapshot of its current state. This evidence is required both for your own root cause investigation and for any insurer or legal review that follows.

Can customers sue over AI chatbot mistakes?

Yes. The Moffatt v. Air Canada case, decided by the British Columbia Civil Resolution Tribunal in February 2024, established that businesses are legally responsible for harmful representations their chatbots make. The tribunal ordered Air Canada to pay CAD 650.88 in damages plus interest after its chatbot provided incorrect bereavement fare information. In Mata v. Avianca (SDNY 2023), the court held lawyers responsible for citing AI-generated case references that did not exist. Courts across multiple jurisdictions have consistently held that deploying an AI tool does not transfer legal responsibility away from the operator.

References

Previous: the Air Canada chatbot case explained Next: who is liable when your AI agent makes a mistake