AI Is Already Describing Your Brand. What If It's Wrong?

Most of the conversation about AI visibility is about getting cited. The harder problem is getting cited inaccurately.

A CMO sees a screenshot: an answer product making a confident claim about her company that is not true. She has a board meeting in ninety minutes. The agenda was supposed to be Q3 pipeline. It is not going to be Q3 pipeline.

Here is what makes this different from every crisis communications playbook written before 2024:

Traditional correction routes involve an identifiable publisher and a policy. You call the outlet, you cite the error, you request a correction. An answer may instead be generated from model memory, retrieval, user context, or some combination of the three — and from the outside, you cannot tell which.

Four ways it goes wrong

The book classifies the failure modes, because the response depends on which one you have. More than one can apply at once.

Outdated facts. The answer repeats something that was once true, or uses an old source without adequate context. Pricing from two rounds ago. A leadership name from before the transition. A feature you deprecated.

Fabrications. The model produces a confident claim for which an audit finds no supporting source at all.

Entity collisions. The output has conflated your company with another — usually a similar name, adjacent category, or shared founder. The internal cause is not observable from outside. What you can do is document the collision and strengthen unambiguous public facts.

Unrepresentative framing. The answer generalises from a narrow or weak source. This is the one that quietly costs the most deals. An enterprise-software leader sees her product mentioned consistently — and consistently described as an "affordable alternative," despite a premium enterprise focus. Nothing is factually false. The framing is still wrong, and it is shaping shortlists.

The discipline: evidence before response

The instinct is to move fast. The book's guidance is to move quickly but not let speed outrun factual and legal review.

First response is confirm and document. Preserve the prompt, the answer, the citations, the product, the model or mode, account state, location, language, and timestamp. Then repeat the exact prompt and a small set of pre-defined variants.

Report the observed frequency honestly. A handful of runs is not proof of determinism. You cannot responsibly say "one in ten users sees this" from five tests. And if there is no visible citation, you still cannot infer the internal source — the product may have used model memory, hidden retrieval, or user context.

This documentation is not bureaucracy. It is what makes escalation possible if the incident turns out to be serious, and it is what stops you from telling a board something you cannot support.

Three severity levels

These are planning examples, not legal rules. Develop the actual thresholds with counsel and communications.

Level one — contained correction. Report the response and correct eligible source facts without amplifying a low-reach claim. Monitor for recurrence and buyer impact. Most incidents belong here, and the biggest mistake is treating them as level two.

Level two — public clarification. Consider a dated factual statement when the claim has material reach or stakeholder impact and a public response is likely to reduce harm. That second condition matters. Communications and counsel should assess wording and channel.

Level three — formal escalation. Involve qualified counsel early for potentially defamatory, privacy, safety, regulatory, contractual, or materially damaging claims.

One practical warning from the chapter, worth repeating: verify the provider's official reporting channel at the time of the incident, because interfaces and URLs change. Do not fabricate a contact you cannot verify. The worst version of crisis comms is a public statement that names a wrong contact and gets corrected by a third party.

Correction is open-ended, not same-day

Plan a rapid communications response and an open-ended correction horizon. These are different clocks and conflating them creates false expectations internally.

Provider response and remediation times are not guaranteed. A corrected source can propagate faster in a retrieval-enabled product than in model memory, but discovery, reindexing, and selection times vary and may not be disclosed. Track three things separately: provider acknowledgment, source recrawling, and repeated outputs.

Correct eligible records where you have standing. Fix a factually wrong Knowledge Panel or source record. Use the feedback link on the generated result. If an eligible Wikipedia article has a material factual error, follow the project's sourcing and conflict-of-interest rules — and do not treat it as a marketing asset. Same for Wikidata: durable factual properties, serious references, disclosed conflicts.

No single surface is guaranteed to control the answer. Do not promise a cascade across every engine.

The prebuttal: a press kit for an AI buyer

The best time to do this work is before an incident.

A press kit for a human reporter has a logo, boilerplate, a fact sheet, a leadership list, and recent news. A press kit for an AI buyer contains the same things — dated, structured, and crawlable.

Maintain a fact-sheet page on your own site that search and answer-engine discovery crawlers can actually reach. Check robots.txt, noindex directives, authentication, CDN rules, and bot protection against each platform's current crawler documentation. An llms.txt file does not override any of those controls.

Date the material facts whose interpretation depends on recency: leadership, pricing, product availability, funding, policies, benchmarks, release status. And do not refresh a date without substantively reviewing the content underneath it.

Preparation makes a response faster. It does not guarantee a false answer will be short-lived. Treat it as reducing time-to-correct, not as insurance.

Who owns this

Routine measurement may sit in marketing or search. A material false or harmful answer needs a named incident owner plus the right communications, legal, security, privacy, product, and executive participation.

Crisis communications should be led by whoever is accountable for corporate communications — in a smaller company, that may be a founder or a generalist, not an SVP. The monitoring owner preserves and surfaces evidence. Assign one accountable incident lead so someone can state what is known, what is being verified, who owns each decision, and when the next update comes.

Do not assume special relationships with AI providers.

Find out before someone screenshots it

The uncomfortable part of this chapter is that most companies discover their misinformation problem during the incident, from a customer or a competitor, rather than from their own monitoring.

Start with neutral factual prompts, then test risk-focused variants in controlled sessions. Record product mode, date, location, prompt, response, and citations every time. And do not publish a provocative output just because a stress test elicited it.

An audit gives you the baseline: what engines currently say about you, which sources they cite, and where the facts have drifted. Running it on a documented cadence is what turns a one-off screenshot into a trend you can actually act on — and it is the difference between finding the error yourself and having a prospect find it for you.

---

This post draws on Chapter 9 of The Citation Economy — "When AI Gets It Wrong: Crisis Comms in an Answer-Engine World." Chapter 8 covers the sentiment and narrative layer; Chapter 11 covers building the entity profile that prevents collisions in the first place.