Skip to main content
RankRift
Menu
Risk & Brand Safety

An AI Assistant Is Wrong About Your Brand: A Correction Playbook

Document it, find the likely source, correct the source, re-measure. A sequenced response that doesn't rely on hope.

correctionsbrand-safetyincident-response

A salesperson forwards a screenshot at 4pm on a Thursday. An assistant has told a prospect that your company was acquired last year, or that you discontinued the product they are evaluating, or that you do not serve their industry. None of it is true. The founder has seen the thread and wants it fixed today.

It cannot be fixed today, and the first useful thing you can do is slow the response down by one step. What follows is a sequence that starts with evidence and ends with a scheduled re-measurement. It will not promise you an outcome, because nobody can honestly promise one — no organisation controls what a model says, and anyone offering you that control is selling something they do not have.

This post is general information about incident handling, not legal advice. Where a false statement may have caused you harm, or where the claim originates with an identifiable party, get qualified counsel before you act.

Step 1: Document it properly

Screenshots forwarded in chat are not documentation. Before anything else, capture the incident in a form somebody could audit in six months.

Record, for every occurrence:

FieldDetail to captureWhy
Exact promptThe full text, character for characterSmall wording changes produce different answers
Assistant and modelProduct name plus model version if visible"ChatGPT said" is not specific enough to re-test
Date and timeWith timezoneBehaviour changes over time
Locale / regionWhere the query ranAnswers can vary by region
Account contextLogged in or not; any memory or personalization features activePersonalized context can shape output
Full answerThe complete response, not the cropped sentenceContext around the claim matters
Cited sourcesEvery URL the answer surfacedThis is your lead list for step 3
Screenshot + textBoth. Text is searchable, images are harder to dispute
Who observed itName and roleYou may need to ask them follow-ups

Two practical notes. Capture the full answer as text, not only as an image, so you can diff it against later runs. And log where the person was when they saw it, because "our EMEA reseller saw it, nobody in the US did" is a real and useful pattern.

Store all of this in one place with a case ID. From here on, every run goes into the same record.

Step 2: Establish how often it actually occurs

This is the step teams skip, and skipping it is how a company spends a fortnight responding to a single unlucky sample.

Assistant outputs are not deterministic. The same prompt run twice can produce materially different answers, including one that contains a false claim and one that does not. A single observation tells you the claim is possible, not that it is prevalent.

Run it properly before you call it an incident:

  • Re-run the exact prompt at least ten times per affected assistant, via official provider APIs where you have access, or manually with a clean session where you do not. Do not automate consumer accounts or scrape web interfaces.
  • Run five to ten near-variants of the prompt — different phrasings a real buyer would use — because a claim that only appears under one exotic phrasing is a different problem from one that appears across the category question.
  • Run across the assistants your buyers actually use, not only the one in the screenshot.
  • Run from more than one region and account state if you can.
  • Record the count: how many of N runs contained the claim, per assistant, per phrasing, with dates.

Then classify it:

PatternReadingResponse
0–1 of 10, one phrasing, one assistantLikely noise or a one-off retrieval accidentLog it, set a monitoring re-run, do not escalate
2–4 of 10, one phrasingIntermittent; real but narrowInvestigate the source, low urgency
5+ of 10, or present across phrasingsPersistentFull incident response
Present across multiple assistantsPersistent and probably source-drivenFull incident response, prioritise finding the shared source
Claim is defamatory in nature or names a specific accusationHandle as above and involve counsel earlySee the escalation section

Those thresholds are judgement calls for triage, not statistical tests. The principle underneath them is the one that matters: measure frequency before you act, and write the frequency down, because you will need it as a baseline in step 6.

Step 3: Trace the likely source of the claim

A false statement usually has an origin. Assistants assemble answers from a mix of retrieved documents and model-internal representations, and the retrieved part is the part you can inspect. Work through these in order:

1. The citations in the answer itself. Open every URL the assistant surfaced. Frequently the claim is sitting in one of them, stated plainly. This is the fastest path and it resolves a meaningful share of cases.

2. Your own site. Check it before blaming anyone else. Common self-inflicted origins: an outdated press release still live, a "legacy product" page that reads like a discontinuation notice, a careers page describing the company in the past tense, stale structured data, or an old FAQ answering a question you have since changed the answer to.

3. Third-party profiles and databases. Company directories, funding and acquisition databases, review platforms, app stores, partner directories, encyclopaedic references. Acquisition and status errors concentrate here, because these records are updated by third parties and rarely audited.

4. News and trade coverage. A single inaccurate article can be copied across aggregators. Search the specific claim in quotes to find the earliest version.

5. Name collision. Check whether another organisation shares or resembles your name. A large share of "the model says we were acquired" cases turn out to be a different company with a similar name that genuinely was. This is an entity problem, and the fix is the disambiguation work described in entity clarity.

6. No traceable source. Sometimes you will find nothing. That is a legitimate finding, and you should record it as one. It usually means the claim is a plausible-sounding fabrication or a conflation of two facts. Your response is then limited to making the correct information abundant and unambiguous, and monitoring.

Ask the assistant itself where the claim came from only as a lead, never as evidence. Explanations of an answer's provenance are generated text and may not reflect what was actually retrieved. Verify anything it names.

Step 4: Correct the source, not the model

You cannot edit a model. You can change what is available to be retrieved and how clearly it reads. That is the whole of the lever, and it is worth being honest that its effect is uncertain in both size and timing.

On your own properties:

  • Publish a clear, dated, unambiguous statement of the correct fact, on a stable URL, in plain declarative sentences. "As of [date], [Company] is independently owned and operating" beats a paragraph of marketing prose that requires inference.
  • Put it in text, not only in an image, a video, or a PDF.
  • Remove or clearly date the contradicting material. An old press release that is still live and undated is doing real damage.
  • Make sure the page is crawlable and renders without client-side execution.
  • Update structured data to match the visible page. Markup that contradicts the page is a liability, not a fix.
  • Add an FAQ entry answering the false claim directly, in the phrasing people actually use.

On third-party sources:

  • Use the platform's documented correction process. Directories, review platforms, app stores, and reference sites generally publish one. Follow it, in writing, with evidence attached.

  • For news coverage, contact the publication's corrections desk with the specific error and documentation. Most reputable publications publish a corrections policy.

  • Keep a log of every request: date sent, channel, contact, evidence provided, response, resolution date.

  • Where a reference site restricts editing by interested parties, use its talk or dispute mechanism rather than editing directly, and disclose your affiliation. Presenting as a neutral party is both against most such platforms' rules and a reputational risk of its own.

What not to do: do not attempt to flood the web with the corrected claim through low-quality placements, and do not try to influence the assistant through content designed to manipulate retrieval. Both are covered defensively on the risk and brand safety hub, and both create a worse problem than the one you started with.

No correction to a source causes a model to update. Retrieval systems refresh on their own schedules; model weights change only when a provider retrains. A corrected source may be picked up quickly, slowly, or not at all, and we will not tell you which. Plan the work as reducing the probability of the false claim recurring, not as fixing it.

Step 5: Use provider feedback channels where they exist

Several assistant providers offer some mechanism for reporting problematic or inaccurate output, and some publish policies covering data about individuals or organisations. These mechanisms differ substantially between providers, they change, and what one offers another may not.

Because of that, we will not summarise them here as if they were stable. Before you file anything:

  • Read the current documentation for the specific provider, on its official site, and record the URL and the date you accessed it in your case file.

  • Note what the mechanism actually claims to do. Some are feedback inputs into a review process with no stated outcome. Some are formal request processes with defined scopes. They are not equivalent, and neither is a correction request in the sense you would use with a publication.

  • Check whether a separate route exists for personal-data requests, which may apply if the false claim concerns a named individual rather than the company.

  • File through the documented channel, in writing, with your evidence and your frequency data from step 2. The frequency data is what distinguishes a credible report from a complaint about one screenshot.

  • Log the submission date and any reference number, and set a reminder to follow up.

Set expectations internally before you file: a submitted report is not a resolution, response times are not published in a form you can rely on, and no provider that we are aware of commits to a specific outcome for a specific claim.

Step 6: Re-measure on a schedule

The incident is not closed when you send the correction requests. It is closed when the frequency you measured in step 2 has fallen and stayed down.

  • Fix the instrument. Same prompts, same variants, same assistants, same run count, same regions. Changing the measurement between runs destroys the comparison.
  • Cadence. Weekly for the first month, then monthly for a quarter, then fold it into whatever regular visibility measurement you run. Re-run early if a provider ships a major model update.
  • Report a rate, not an anecdote. "3 of 30 runs on [dates] across [models]" is a status. "It seems better now" is not.
  • Expect slow, partial, and non-monotonic movement. Rates can go down, then up again. One clean week is not resolution.
  • Define closure in advance. For example: zero occurrences across three consecutive monthly measurement cycles at the same sample size. Write the criterion down at the start so nobody relitigates it later.
  • Keep monitoring after closure at a reduced cadence. Claims recur, particularly when the underlying source was never actually corrected.

If the rate does not move after the corrections have had time to be picked up, revisit step 3. An unmoved rate usually means the real source was never found, or a copy of the corrected source is still circulating.

When to escalate to counsel

Scope note. This article is general educational and measurement guidance, not legal, tax, financial, security, or platform-specific advice. Current law, first-party platform rules, the facts of the real case, and qualified professional advice control any consequential decision. Everything above is operational. Some situations are not, and the boundary is worth naming clearly. This section describes when to get advice — it does not tell you whether you have a claim, what the law provides, or who might be responsible. Those are questions for a qualified lawyer in your jurisdiction, and the answers vary by jurisdiction and by facts.

Consider involving counsel when:

  • The false claim is a specific factual accusation about wrongdoing, safety, financial condition, or regulatory status, rather than a stale or garbled detail.
  • It concerns a named individual rather than the company.
  • It appears to originate from an identifiable third party rather than from a stale record.
  • It is affecting deals, financing, employment, or a regulatory relationship in a way you can document.
  • You are operating in a regulated sector where inaccurate public statements about your business carry their own compliance obligations.
  • You are considering contacting a third party in a way that could be read as a legal demand. Draft nothing of that kind without advice.
  • The claim persists after documented correction requests through every available documented channel.

What to give counsel: the case file. Documentation from step 1, frequency data from step 2, the source trace from step 3, the correction log from step 4, provider submissions with dates from step 5, and the re-measurement series from step 6. That file is far more useful than a screenshot, and assembling it is the main practical reason the sequence is worth following.

For a fuller treatment of where model output sits relative to statements made by a publisher or a competitor — again as general information only — see when it becomes a legal problem.

In Plain English

When an assistant says something untrue about your company, do not react to the screenshot. Document the exact prompt, model, date, region, and full answer. Re-run it ten or more times across phrasings and assistants and write down how often the claim actually appears, because one bad answer may be noise.

If it is persistent, trace where the claim came from — the answer's own citations first, then your own site, then third-party profiles and news, then name collisions. Correct that source through its documented process, and make the correct fact clear and dated on a stable page of your own. File through the provider's documented feedback channel if one exists, recording the URL and the date you read the policy. Then re-measure on a fixed schedule and define in advance what closure looks like.

Nobody can make a model update on request, and no correction is certain to propagate. What you can do is reduce the probability of recurrence and prove, with dated measurements, whether it worked. This helps most if you have a specific false claim in front of you and a leadership team wanting action. It helps least as a substitute for legal advice, which it is not — if the claim is serious, involve counsel early, and see corrections and disputes for how we handle disputes about our own published measurements.

Download the brand incident playbook to run this sequence with the documentation, frequency, and re-measurement templates already set up.

Primary-source verification

Checked July 28, 2026. The operational and factual guidance above was reviewed against the primary references below. Provider features, prices, policies, interfaces, jurisdictions, and account-specific results can change; recheck the controlling first-party document and your own account or measured data before acting.