Vincent Oduya was VP of Operations at a regional insurance company when the incident happened. Their AI underwriting assistant had been processing auto policy applications for eight months without issue. Then a system update changed the way the model handled ZIP code data, and for eleven days, without anyone noticing, the model was systematically declining applications from two urban ZIP codes at a rate 40% higher than the historical baseline. The error was caught by a compliance analyst reviewing aggregate approval patterns. By the time Vincent found out, they had 340 affected applications, a potential fair lending exposure, and a state regulator who had already received two complaints. He had no communications plan, no template, and no idea what to say first or to whom. "I have handled product recalls," he said. "I have handled data breaches. Nothing prepared me for explaining that an algorithm had done this."

AI incidents are a distinct communications challenge rather than an ordinary product crisis with unusual technical detail. The technical complexity makes them harder to explain to the people who most need an explanation. The automated nature of the failure creates questions of accountability that a standard product error does not raise. And the potential for harm to be distributed across many people, often people who did not know they were interacting with an AI system at all, adds a dimension of stakeholder complexity that most crisis playbooks were never designed for.

What Makes AI Incidents Different

Causation is hard to explain simply. "Our model weighted the wrong variable" is technically accurate and completely meaningless to a regulator, a journalist or an affected customer. What you need is language that explains what happened at a human level without being so vague that it sounds like concealment, and that language is genuinely difficult to write. The natural instincts pull in opposite directions: precision produces jargon, and simplification produces something that reads as evasion. Getting it right takes drafting, testing on someone outside the technical team, and revision. You cannot do that in the first two hours of a crisis, which is exactly when you will need it.

The scale can be discovered retrospectively. In a data breach you generally know, fairly early, roughly how many records were affected. AI failures may have been accumulating for days or weeks before anyone discovers them, as Vincent's did over eleven days, and establishing the full scope requires a retrospective audit that runs alongside the communications response rather than before it. This has an unpleasant consequence: every update about additional affected individuals or decisions restarts the story. An organization that announces a number before it is confident in the number will be announcing a larger one later, and each revision costs more credibility than the original disclosure did.

Questions of accountability are novel. "Who is responsible?" is a harder question to answer when the decision was made by a system, and the difficulty is not merely presentational. The honest answer usually involves a chain: the team that built the model, the process that approved the update, the monitoring that did not catch the drift, and the executive accountable for the function. Your communications need to answer the question directly. If you do not, critics will answer it for you, and they will use the least charitable framing available, which is typically that the organization deployed something it did not understand and then hid behind it.

The Three Audiences and What Each Needs

Effective crisis communication requires different messages for different audiences, delivered in a specific sequence. Getting the sequence wrong is as damaging as getting the message wrong, because each audience interprets the order in which it was told as a statement about its priority. A regulator who learns of an incident from a press release starts the relationship in a worse place than one who received a preliminary fact sheet the same day.

Regulators and Legal Counsel

Most regulated industries have mandatory incident notification timelines. Financial services, healthcare and public sector organizations typically have 24 to 72 hours from discovery to notify the relevant regulators, and the clock starts at discovery rather than at the point when you have a complete picture. This notification is not a press release. It is a factual report of what is known, what is unknown, and what remediation steps are underway, and it should say plainly which of those three categories each statement belongs to. The tone is cooperative and precise. The goal is to demonstrate that you are in control of the situation and engaging proactively rather than defensively.

Vincent's company had a legal obligation to notify the state insurance regulator within 48 hours of discovering a potential fair lending violation. They did so, with a preliminary fact sheet that was explicit about what remained unknown. That proactive posture significantly shaped how the regulator treated them over the following weeks, and it is the part of the response Vincent had the least trouble executing, because the obligation was documented even though the communications plan was not.

Affected Individuals

Affected individuals want to know four things: what happened to me, why, what you are doing about it, and what I get. They are owed a clear, plain-language explanation of how they were affected, what the organization is doing to remedy it, and what specific steps they can take, whether that means appealing a decision, requesting a review, or contacting a named person. This message should not be filtered through corporate communications language. It should read like something written by a person who understands that the recipient has been harmed, because anything else compounds the original injury with the impression that the organization is managing its exposure rather than addressing theirs.

A workable template structure runs: "We are writing to let you know that [specific action - your application, decision, etc.] may have been affected by a technical error in our [plain-language description of system]. We identified this error on [date]. [What you are doing to fix it.] [What this means for you specifically.] [What your options are.] [Contact information for a named person.]" The bracketed fields are the ones that have to be filled with specifics; the value of drafting the structure in advance is that during an incident you are filling fields rather than deciding what a letter of this kind should contain.

Public and Media

Public statements about AI incidents should be brief, factual and forward-looking. Lead with acknowledgment of the problem rather than with defense of the organization, include a plain-language technical explanation, and describe the remediation steps already underway. Avoid hedging language that sounds like minimization, because a statement that reads as though it were negotiated by lawyers will be reported as one that was, and the hedge becomes the story.

The single most damaging communication mistake in AI incident response is to describe the error as a "glitch" or an "anomaly." Both words signal one of two things to any informed reader: that you do not understand what happened, or that you do not take it seriously. Neither is a position you want to occupy in front of a regulator. Describe what actually occurred even when the explanation is more complicated, because a complicated explanation delivered plainly reads as competence, whereas a simple word that explains nothing reads as evasion.

Pre-Incident Preparation

The lesson from Vincent's experience is that the crisis communication plan for an AI incident cannot be written during the crisis. Every component of it requires decisions that take time and consultation, and the incident consumes exactly the people whose input the plan needs. It has to exist before anything goes wrong, and it has to be specific enough that someone who has never handled an incident can follow it at two in the morning.

A minimal pre-incident communications kit contains:

• An escalation path. Who is notified when? List the sequence, from technical team to legal to communications to executive to regulator, and the trigger for each step. Define "incident" clearly enough that the on-call engineer knows when to pull the first string, because an escalation path that depends on a judgement call by the person least equipped to make it will not fire.
• A regulatory notification template for each relevant regulator, with the required fields and the default language your legal team has pre-approved.
• A customer-facing notification template for at least two scenarios: a decision-affecting error of the kind Vincent's company had, and a data exposure. Both should be pre-approved by legal and cleared with whoever reviews your plain language, since those two reviews pull in opposite directions and reconciling them mid-incident is slow.
• A holding statement for media inquiries, meaning the two-sentence response that buys time while you gather facts without saying anything you will have to walk back: "We are aware of a technical issue affecting [description]. We are actively investigating and will share more information as it becomes available. Our priority is [affected party]."
• Named spokespeople and their backups. Do not discover who speaks to the regulator or the media during the incident itself, and do not leave the backup unnamed on the assumption that the primary will be available.

The question worth putting to your own leadership is not whether you will have an AI incident. It is whether you will have a plan when you do. Vincent's company recovered, largely because the regulatory obligation was documented well enough to be followed under pressure. Everything that was not documented, which was most of the response, had to be invented in the days when their attention was least available for inventing anything.

Anti-Patterns

• Calling it a glitch or an anomaly. The words signal either that you do not understand what happened or that you are not treating it seriously, and both readings are worse than the complicated truth.
• Announcing a number before the retrospective audit supports it. AI failures accumulate before discovery, so an early figure usually becomes a larger figure, and each revision restarts the story at a higher cost than the first disclosure.
• Letting the regulator learn of it from the media. Sequence is read as priority, and a regulator who is briefed last begins the inquiry from a position you then have to argue your way out of.
• Sending affected individuals a corporate statement. A letter written in institutional language to someone who has been harmed compounds the harm with the impression that the organization is managing exposure rather than remedy.
• Leaving accountability unanswered. If you do not say who is responsible, critics will supply an answer, and it will be the least charitable one available.
• Drafting the plain-language explanation during the incident. It needs testing on someone outside the technical team, and the first two hours of a crisis is when that is least possible.
• Naming a spokesperson without a backup. Incidents do not schedule themselves around availability, and an unnamed backup becomes a decision made under pressure.

Practice Prompts

• Write the plain-language explanation for a plausible failure of one AI system you operate, then test it on a colleague outside the technical team and revise until they can restate what happened.
• Identify every mandatory notification obligation that applies to your AI systems, with the regulator, the trigger, and the window measured from discovery rather than from confirmation.
• Draft the escalation path for one system, then check whether the definition of "incident" is specific enough for the on-call engineer to apply without calling anyone.
• Fill in the customer notification template for a decision-affecting error, using a real system and a realistic error, and note which bracketed fields you could not complete.
• Write your holding statement now, in two sentences, and have legal pre-approve it before there is anything to hold.
• Name the spokespeople and their backups for regulator contact and media contact, and confirm each of them knows they hold the role.
• Ask how you would establish the scope of a failure that had been running for weeks: what audit would you run, who would run it, and how long would it take?

Reflection

The detail worth dwelling on in Vincent's account is who found the error. Not the model monitoring, not the engineering team, but a compliance analyst reviewing aggregate approval patterns, which means the discovery was a matter of someone happening to look at the right summary. Ask what the equivalent path is in your own organization, and whether it depends on a person's initiative or on a control that fires whether or not anyone is paying attention. The communications problem and the detection problem are connected, because the length of time between failure and discovery is what turns an incident into a disclosure with a growing number attached.

The second question is about the letter. If one of your AI systems made a decision that harmed someone, who in your organization would write to them, and what would that letter sound like? Most organizations discover that the answer is the communications function, working from a corporate template, at a moment when nobody has capacity to argue for a different tone. Drafting that letter in advance is cheap, uncomfortable, and one of the few parts of incident response you can genuinely do well while nothing is on fire.

Glossary

• Escalation path: the documented sequence of who is notified when, from on-call engineer through legal, communications and executive to regulator, with a defined trigger at each step.
• Holding statement: a short pre-approved response to media inquiries that buys time while facts are gathered without committing to anything you may have to retract.
• Mandatory notification window: the period, typically measured from discovery rather than from full understanding, within which a regulated organization must inform its regulator.
• Preliminary fact sheet: the initial factual report to a regulator, explicit about what is known, what is unknown, and what remediation is underway.
• Retrospective scope audit: the after-the-fact analysis that establishes how many people or decisions an AI failure affected, run in parallel with the communications response.
• Plain-language reviewer: the person who checks that a customer-facing notification can be understood by its recipient, a review that pulls against legal review and has to be reconciled in advance.

Related Lessons

Several lessons develop parts of this material. Incident Response for AI Security Breaches covers the technical and containment side of the response that runs alongside these communications. AI Project Risk Management and Contingency Planning deals with the monitoring and fallback questions that determine how long a failure runs before discovery. Risk & Compliance Communication and Public & Community Communication extend the audience-specific messaging discussed here into routine rather than crisis conditions. Stakeholder Engagement & Public Accountability addresses the accountability question in its non-crisis form, and Fairness & Bias Evaluation covers the evaluation work that would have surfaced a disparate decline rate before a compliance analyst happened to notice it.

Closing

What made Vincent's situation difficult was not the error itself, which was a straightforward consequence of a system update, but that every communications decision had to be made from scratch under time pressure and in public. The components that would have helped are all unglamorous and all writable in advance: an escalation path with a usable definition of an incident, pre-approved regulatory and customer templates, a two-sentence holding statement, and named spokespeople with named backups. None of them require knowing what the incident will be. All of them are considerably harder to produce once it has started, which is the only real argument for doing the work now.

Key Takeaways

• AI incidents are a distinct communications challenge. Technical complexity, retrospective scale discovery and novel accountability questions require purpose-built playbooks rather than adapted product-crisis templates.
• Sequence your audiences: regulators and legal first, inside any mandatory notification window, affected individuals second, public and media third.
• Regulators want cooperative and precise. Proactive notification with a preliminary fact sheet is almost always better than waiting for a complaint to trigger an inquiry.
• Affected individuals want plain-language specifics: what happened to me, what you are doing, what my options are, and a named contact rather than a mailbox.
• Never describe an AI error as a "glitch" or an "anomaly." It signals that you do not understand what happened or that you do not take it seriously.
• Build the communications kit before the incident: escalation path, regulatory templates, customer notification templates, a holding statement, and named spokespeople with backups.

Frequently Asked Questions

How quickly do we actually have to notify a regulator? It depends on your sector and jurisdiction, and you should establish the specific obligation for each of your systems in advance rather than researching it during an incident. Financial services, healthcare and public sector organizations typically have 24 to 72 hours from discovery. The detail that catches people out is that the clock generally starts at discovery, not at the point where you understand the full scope, which is why the first notification is a factual report about what is known and unknown rather than a complete account.

Should we announce the number of affected people as soon as we have one? Only if the retrospective audit supports it. AI failures accumulate before discovery, so an early estimate is likely to grow, and every upward revision is a new news cycle that costs more credibility than the original disclosure. It is better to say that the scope is being established, describe the audit that is establishing it, and give a date by which you will have a figure.

Who should be named as responsible? Someone, and specifically a human role rather than the system. The accountability question is the one critics will answer for you if you leave it open, and "the algorithm made an error" invites the reading that the organization deployed something it did not understand. An honest answer usually describes the chain: what was built, what approved the change, what monitoring should have caught it, and who owns the function.

Our legal team wants the customer letter to be more cautious. How do we resolve that? In advance, which is the whole argument for pre-approved templates. Legal review and plain-language review pull in opposite directions, and reconciling them takes iterations that an active incident does not allow. Draft both templates now, run both reviews now, and settle the tone while there is no specific case to argue about. During the incident you should be filling in bracketed fields, not renegotiating the register of the letter.