When an AI Says Something False About Your Company

Before you do anything about a false statement, find out which of four mechanisms produced it. A stale memory in the weights, a wrongly retrieved page, a confusion between you and a similarly named entity, and a conflation inside one answer need four different responses, and three of the four are useless against the other causes.

Diagnose before you do anything

Reproduce it first, several times, in a clean session with memory disabled, and record the output. One screenshot is not a diagnosis because the output is sampled — see the sampling protocol for why. Then work through these questions in order.

1. Did it cite sources? If yes, the grounded path ran and the fault is probably in what it retrieved. If no, it answered from the weights.
2. Did your server see a fetch? Check your access log for the minute around the query. A user-agent fetch confirms the grounded path and tells you exactly which URL was pulled.
3. Open the cited sources. Does the false claim appear in one of them? If it does, this is not a model problem, it is a source problem, and the source is where the fix goes.
4. Ask it to name its source explicitly. On the parametric path it will often produce a plausible URL that does not exist. Checking that URL is a fast confirmation of which path you are on.
5. Is the false fact true of somebody else? A company with a similar name, a product with the same name, a founder who shares a name. This is more common than people expect and it changes the remedy completely.

The four mechanisms

Mechanism Description Stale parametric memory The claim was true once, or appeared in text that was true once. Old pricing, a former product name, a departed founder, a discontinued feature. No citation, and it recurs consistently across runs. Wrongly retrieved source The retrieval stage pulled a page that carries the false claim — an outdated page of yours, a directory listing, a competitor comparison, a scraped copy of an old version of your site. The answer will usually cite it. Entity confusion The model has merged you with a differently named-but-similar entity. Symptoms are facts that are oddly specific and completely unrelated: a wrong headquarters, a wrong founding year, an industry you are not in. Conflation within the answer Several correct sources are in context and the generated sentence combines them incorrectly — your product name with a competitor’s price. Every cited source is accurate; the sentence is not. This is the failure mode covered in more depth in the hallucination pages.

The general background is in the taxonomy of hallucination types and why models produce confident wrong answers; what follows here is specifically about a claim concerning an organisation you control information about.

Fixing a stale parametric memory

The uncomfortable truth first: you cannot edit a model. Nothing you publish changes weights that are already trained. What you can do is change the balance of evidence available to the next training run and to every retrieval that happens in the meantime, which is a slow instrument and the only one there is.

1. Publish the correct fact somewhere canonical and unambiguous. One page, one URL, stating the current fact in plain sentences with the date. “Multigrid was founded in 2025” is retrievable; “we have been doing this for a while” is not.
2. Remove or correct your own stale pages. The most common source of a stale claim about a company is that company’s own archived page, still live, still indexed, still retrievable. Fix it or redirect it; do not merely add a newer page beside it.
3. Correct the third-party sources. Directory listings, profile pages, aggregators, old press releases, Wikipedia and Wikidata where applicable. These are heavily represented in training corpora and heavily retrieved, and a correction there is worth more than ten pages on your own site.
4. State the correction explicitly, including the wrong version. A page saying “the product was renamed from X to Y in March 2026” is retrievable by a query about X. A page that only mentions Y is not.
5. Be patient and re-measure. Corrections propagate on the timescale of retraining and recrawling, not on the timescale of a support ticket.

Fixing a wrongly retrieved source

This is the tractable case and the one worth most of your effort, because the fault is in a document rather than in a model.

• If it is your page: correct it, and make the corrected version the canonical one. If the old page must stay for historical reasons, date it visibly at the top and say what superseded it.
• If it is an outdated copy of your page: a scraped mirror, a cached aggregator entry, a syndication partner who never updated. Ask for removal or update. Where you have a legal basis, use it; where you do not, a polite request to a site that does not want wrong data often works.
• If it is a third party stating something false: that is the actual problem and no amount of publishing on your own domain fixes it. The claim lives there and will keep being retrieved from there.
• If it is a page of yours that should not be retrievable at all: old changelogs, superseded pricing, staging content that got indexed. Remove it properly — a 410, or a noindex on a page that remains crawlable. Note the trap from the robots.txt page: blocking it in robots.txt means the noindex is never read, so the URL can stay listed indefinitely.

Make the correct page unambiguously better as a retrieval target: one question per page, the fact in the first sentence, a visible date, and the wrong version named so a query about the wrong version reaches the correction. That is ordinary retrieval-friendly structure applied to a specific sentence you want to win.

Fixing entity confusion

If the assistant thinks you are somebody else, the underlying failure is entity resolution rather than fact retrieval, and the remedy is to make your identity machine-legible rather than to argue about the fact.

1. Publish an Organization block with sameAs listing every profile that is also you: your company registry entry, LinkedIn, GitHub, Crunchbase, Wikidata, X. The sameAs property exists exactly for this, and it is the single highest-value piece of structured data for an ambiguous name.
2. Use one name consistently. Legal name, trading name and product name diverging across your own pages is what created the ambiguity in many cases.
3. Disambiguate explicitly in prose. A sentence such as “Multigrid, the LLM gateway, is unrelated to the electrical engineering firm of the same name” is directly retrievable by the query that produces the confusion, and prose is what gets chunked.
4. Fix the identifiers in the knowledge bases. Wikidata in particular is widely ingested, and a correct entity there with the right identifiers is a strong disambiguation signal.

The channels that exist

Assistant products generally offer a feedback control on individual answers — a thumbs-down or a report link — and some operators publish a contact route for factual complaints. Use them, with the caveat that none of them is a documented correction pipeline with a stated turnaround, and you should not expect confirmation.

What makes such a report more likely to be actionable: the exact prompt, the exact output, the date and model, and a URL where the correct fact is stated in plain language. What makes it less likely: a complaint with no reproduction, or a demand about a claim that is actually published on a site you do not control.

Checking whether the same false claim appears across several models is part of the diagnosis: a claim that appears in one model and not others points at that model’s training data, while one that appears everywhere points at a source on the web that all of them read. Running the same prompt across providers through one API makes that comparison a loop rather than an afternoon.

What has no chance of working

• Asking the assistant to remember the correction. It may agree within the conversation and it changes nothing outside it.
• Blocking the crawler after the fact. Blocking collection now does not remove what was collected before, and it removes you from the retrieval that could have surfaced your correction.
• Publishing a rebuttal without removing the source. If the false claim is still live and retrievable somewhere, you have added a second document to the corpus rather than replaced the first.
• Keyword-stuffing the correct fact. Repetition is not what retrieval scores, and it degrades the page for the humans who would otherwise have cited it.
• Asking a lab to retrain. Not a service that exists, at any price, for any company.

When it is about a person

Statements about an identified individual are a different legal category from statements about a company. In the EU and the UK, data protection law gives individuals a right to have inaccurate personal data rectified, and the privacy group noyb filed complaints against OpenAI in 2024 and again in 2025 arguing that inaccurate generated statements about individuals engage that right. Those matters were pending rather than decided at the time of writing, and outcomes here will move.

Practically, a request framed as a data-protection rectification request, sent to the operator’s published privacy contact, with the reproduction and the correct information attached, is a materially different instrument from a general feedback form — and it is the one with a statutory basis behind it. Defamatory statements about a person or a business are their own category with their own remedies, and that is a question for a lawyer rather than for an SEO process. Related background is in GDPR and language models and the legal questions around AI.

Nothing here is legal advice. The regulatory position on generated statements about individuals is actively developing and differs by jurisdiction.

Related

• Measuring Whether AI Assistants Mention You
• E-E-A-T for Technical Content, Concretely