AI hallucinations about your brand: an incident response plan
An incident response plan for AI hallucinations about your brand: severity triage, escalation paths, holding statements and who owns what in comms and legal.
- Treat a damaging AI hallucination like any brand incident: capture evidence, triage severity, assign one owner, and escalate by rule, not by mood.
- Severity depends on the claim type (legal, safety, financial), how many engines repeat it, and whether customers or press have acted on it.
- Holding statements should state the correct fact and the source, never repeat the false claim, and never blame the user who asked.
When an AI system invents something damaging about your brand, run it as an incident, not a content task. Capture evidence, triage severity by claim type and spread, name one owner, escalate to legal for anything alleging wrongdoing, issue a holding statement that states the correct fact, and correct the sources the engines rely on. Then monitor until every engine changes.
This guide is for comms, legal and brand teams. For the hands-on correction steps, see how to fix wrong AI information.
01Why do AI hallucinations about brands need an incident process?
Because they can cost money before anyone inside the company notices. In 2025, Minnesota solar installer Wolf River Electric sued Google after an AI Overview allegedly said the state attorney general was suing it, when it was not a defendant. The complaint cites a customer who cancelled a $150,000 contract after reading the claim, and seeks $110 to $210 million in damages.[1]
Errors are not rare. Columbia University's Tow Center tested eight AI search engines on 1,600 queries and found they gave incorrect answers about sources more than 60% of the time.[2]
Legal remedies are uncertain and slow. In May 2025, a Georgia court granted OpenAI summary judgment in Walters v. OpenAI, a defamation suit over a ChatGPT output.[3] Your response plan cannot depend on winning in court.
02How do you triage severity?
Severity drives everything else: who is woken up, how fast, and what is said. Score each incident on three questions: what kind of claim, how far it has spread, and whether anyone has acted on it.
| S1 · Critical | S2 · High | S3 · Routine | |
|---|---|---|---|
| Claim type | Alleged crime, lawsuit, fraud, safety risk, regulatory breach | Wrong pricing, terms, ownership, financial facts | Outdated or minor factual errors |
| Spread | Several engines or a widely used surface | One major engine, repeatable | Occasional, hard to reproduce |
| Impact seen | Customer, investor, press or regulator has acted on it | Sales or support hearing it | No known impact |
| Response time | Same day | Within 2 business days | Next routine cycle |
| Owner | Comms lead + legal | Brand or marketing lead | Content or SEO owner |
| Escalate to | General counsel, CMO, exec team | Head of marketing | Error ledger only |
Response times are a starting point; set your own in your governance policy. The point is that they are decided before an incident, not during one.
When in doubt between two levels, pick the higher one and downgrade later. Downgrading costs a few hours of attention; under-reacting to a claim that a journalist is already checking costs far more.
03What should happen in the first 24 hours?
The first day is about evidence and containment, not about winning the argument.
- 1Capture evidenceHour 0–2Screenshots with date, time, prompt, engine, model if shown, location, logged-in state. Save cited links and archive copies.
- 2Reproduce and scopeHour 2–6Re-run the prompt and close variants on every major engine and market. Record which repeat the claim.
- 3Trace the likely sourceHour 2–8Identify pages the engine cites or that state similar wording: news, court records, forums, directories.
- 4Triage and assignHour 4–8Score severity, name one owner, notify legal for any S1, open a ticket in the error ledger.
- 5Prepare holding linesHour 8–24Approve a short statement for sales, support, investor relations and press inquiries.
- 6Submit platform reportsHour 8–24Use each engine's feedback or legal route, with the correct fact and a primary source.
The channels for each engine are listed in how to report incorrect information to ChatGPT, Gemini and Perplexity.
04Who owns what?
Most incidents stall because everyone assumes someone else is handling it. Write the roles down before you need them.
| Role | Owns | Does not own |
|---|---|---|
| Incident owner (comms lead) | Timeline, coordination, status updates | Legal judgment |
| Legal | Whether the claim is potentially defamatory, wording of formal complaints, litigation holds | Public messaging tone |
| Brand / marketing | Source corrections on owned and third-party sites, facts page | Statements to regulators |
| Sales and support leads | Briefing front-line teams, logging customer mentions | Changing the story |
| Investor relations | Investor and analyst questions | Public statements beyond the approved line |
| Monitoring owner | Re-running prompts and reporting status | Deciding severity alone |
If you work with an outside partner, give it a named role in the table. A partner that already operates inside your CMS and approval chain can ship source corrections the same day; one that sends recommendations by email cannot.
05What should a holding statement say?
A holding statement buys time without making things worse. It should state the correct fact, point to a source, and avoid repeating the false claim in full.
Illustrative holding lines. For customers: "Some AI tools are showing incorrect information about [Company]. [Company] is not a party to any action by [authority]. Our current status is published at [link]." For press: "We are aware of inaccurate AI-generated summaries about [Company]. The facts are [one sentence]. We have reported the error to the platforms concerned."
Do not blame the customer or journalist who asked an assistant; they did what millions of people do. Avoid speculating about why the engine got it wrong, and avoid threatening language in public statements; leave that to legal letters if needed.
06What mistakes make an AI incident worse?
Under pressure, teams reach for responses that feel decisive but widen the damage. Four are common.
Publishing a rebuttal that repeats the false claim word for word. A headline such as "No, we are not being sued for fraud" creates a new page that pairs your brand with the allegation. Engines may retrieve it and summarize it badly. State the correct fact instead.
Blocking AI crawlers in frustration. Blocking the engines' search crawlers does not erase what they already learned, and it prevents them from reading your corrections. OpenAI, for example, says sites must allow its OAI-SearchBot to be eligible for ChatGPT search results.[5]
Arguing with the assistant. Telling a chatbot it is wrong in your own session may change that one conversation but does nothing for other users. It also leaves no useful record unless you use the formal feedback route.
Letting each team improvise. Sales says one thing, support another and a regional office posts a third version on social media. One approved line, shared within hours, prevents that.
07What should front-line teams be told?
Sales, support, partner managers and investor relations often hear about an AI error first. Give them a short brief, the approved line and a place to log every mention: who raised it, which engine, what it said and when.
Those logs serve two purposes. They show how far the claim has spread, which feeds severity, and they provide evidence of business impact if legal action is ever considered. Ask teams not to send screenshots to customers or argue about the error on public channels.
08When should legal escalate?
Escalate to legal immediately when the output alleges crime, fraud, litigation, regulatory action or safety risk, or names an individual. Legal will decide whether formal routes apply, such as Google's legal content reports or an individual's privacy request to OpenAI, and whether to preserve evidence for possible claims.
Courts are still working out who is responsible for AI outputs. A Canadian tribunal held Air Canada liable for wrong information from its own website chatbot,[4] while the Walters court found for OpenAI over a third-party chatbot.[3] The safer assumption is that you must fix the problem yourself, whatever the eventual legal outcome.
09How do you close an incident?
An incident closes when the correct fact appears consistently, not when the platform acknowledges your report.
10How do you detect incidents earlier?
Most companies find out from a customer or a journalist. A standing prompt set, run on a schedule across engines and markets, catches many incidents before they reach a buyer. Include prompts that test risk: "Is [Company] being sued?", "Is [Company] safe?", "[Company] scam", "[Company] complaints".
Formal governance makes this repeatable. Our guide to AI visibility governance covers policy, roles and approvals. If you want the monitoring and source fixes run for you, OwnlyReal operates this loop through your own approval chain and is built for teams where being misrepresented by AI is a business risk.
Questions people also ask
What should I do if AI makes up false information about my company?
Capture evidence, check which engines repeat it, triage severity, assign one owner, involve legal for anything alleging wrongdoing, issue a holding statement and correct the sources engines rely on.
Can I sue over an AI hallucination about my brand?
Some companies have tried, such as Wolf River Electric against Google, but the law is unsettled and at least one defamation case against OpenAI was dismissed. Take legal advice, and fix the sources in parallel.
Should our statement repeat the false claim to deny it?
Avoid it. State the correct fact and link to a primary source. Repeating the false wording can create more pages that engines retrieve.
Who should own AI hallucination incidents?
Usually the comms lead, with legal on call for serious claims, marketing owning source corrections and a named person re-running prompts until the error clears.
How do we know when an AI incident is resolved?
When the false claim no longer appears across repeated runs on every engine tested, the sources are corrected, and monitoring has stayed clean for several weeks.
