TL;DR
When ChatGPT states something false about your brand — a wrong founding date, a discontinued product described as current, your company confused with a similarly named one, an invented controversy — the damage is instant, confident and invisible. You cannot edit the model. You can change the evidence the model learns and retrieves from, and you can use the vendor’s own correction channels.
This playbook covers the five error types and why they happen, a triage framework that tells you which errors are worth fixing and which to ignore, how to detect what ChatGPT actually says (base answers behave differently from browsing answers), how to correct the underlying signals, when to escalate, and how to tell whether a fix has taken.
Two truths to set expectations: corrections to the retrieval layer can land within days; corrections to what the base model “knows” may not land until a future training cycle, if ever. And for genuinely defamatory or inaccurate personal-data claims, UK publishers have legal levers — defamation and the right to rectification — that sit above any SEO tactic.
Verdict: treat brand hallucinations like a reputation incident, not a ranking problem — triage by severity, fix the sources, log everything, and escalate the serious cases through the right channel.
A customer asks ChatGPT whether your software still supports a feature you discontinued two years ago, and it confidently says yes. A journalist asks who founded your company and gets a name that belongs to a competitor. A prospect asks if your firm was “involved in that data breach” and the model fabricates a plausible-sounding incident that never happened. None of this appears in your analytics. No alert fires. The first you hear of it is a confused email — or worse, a deal that quietly went elsewhere.
This is the new shape of brand risk. For twenty years reputation management meant influencing what ranked on the first page of search: you could see the offending result, link to it, and work to push it down. An AI answer is different in three uncomfortable ways. It is synthesised, so there is often no single page to fix. It is confident, presented in fluent prose with no hedging that would warn a reader to check. And it is invisible, delivered privately to one user with no public footprint you can monitor in the usual way. A false claim that would once have been one result among ten is now the answer.
The good news is that this is a tractable problem if you treat it correctly. The bad news is that most people treat it incorrectly — either panicking over trivial errors that no buyer will ever see, or assuming nothing can be done because “you can’t change the model.” Both are wrong. This playbook is written for UK brand owners, in-house marketers and agencies who need a repeatable process: how to find what ChatGPT says, decide what is worth fixing, change the signals that actually move the answer, escalate the serious cases, and confirm the fix held.
It is worth being clear-eyed about scale before we start, because it shapes how seriously to take this. A meaningful and growing share of buyers now open an AI assistant before they open a search engine when they want a quick read on a company — is it legitimate, what does it do, who is behind it, is it any good. For those users the model’s answer is not one input among many; it is the briefing. If that briefing is wrong, you are losing or winning deals on the basis of a sentence you never saw and never wrote. That is a different category of risk from a bad review on the third page of search, and it deserves a process rather than the occasional panicked spot-check.
1. What a brand hallucination actually is (and why it happens)
“Hallucination” is doing a lot of work as a term, and lumping every error together is the first mistake. There are five distinct failure types, and they have different causes and different fixes. Naming the type you are looking at is the difference between a targeted correction and flailing.
Fabrication. The model invents something with no basis — an award you never won, a controversy that never occurred, a product you never made. Cause: the model is pattern-completing plausibly rather than recalling a fact.
Staleness. A once-true fact that is now wrong — a former CEO, a discontinued product, old pricing, a closed office. Cause: the fact was true in the training data and nothing newer has overwritten it.
Entity conflation. The model merges you with a different organisation that shares a name, a sector or a founder’s name. Cause: weak entity separation in the underlying data — the model genuinely cannot tell two “Apex”s apart.
False attribution. Something real but not yours is credited to you, or vice versa — a competitor’s feature, a partner’s failure, an industry statistic. Cause: proximity in the source material without clear ownership signals.
Sentiment/framing error. The facts are roughly right but the spin is wrong — you are described as “struggling” or “controversial” on thin evidence. Cause: the model has absorbed a skew from a small or unrepresentative slice of sources.
There is a structural reason smaller and mid-sized UK brands suffer more of this than household names, and it is worth understanding because it tells you where your vulnerability lies. A model’s confidence about an entity scales with how much consistent information about it appeared in training. A global brand is described accurately in thousands of places, so the model has a dense, self-correcting picture. A regional B2B firm or a niche consumer brand may appear in only a handful of sources, some of them thin or out of date — so the model has a sparse picture and fills the gaps by inference, which is precisely when fabrication and conflation creep in. The thinner your published footprint, the more the model improvises. That makes a consistent, well-corroborated information footprint not just good marketing but the primary defence against being hallucinated about in the first place.
Underneath all five sits one architectural fact that governs every fix: ChatGPT answers from two different places, and they behave differently. Some answers come from the model’s parameters — what it “knows” from training, frozen at a cutoff and changed only by retraining. Others come from a live retrieval or browsing step that fetches current pages and summarises them. A staleness error in a browsing answer can be fixed by updating the page it fetches, sometimes within days. The same staleness baked into the parametric layer may persist until the next training cycle, regardless of what you publish. Before you spend effort on any correction, establish which layer the wrong answer is coming from. Fixing the wrong layer is the most common way to waste a week.
A worked example makes the distinction concrete. Say the model insists your former managing director still runs the company. If you ask the question with browsing enabled and the model fetches your current leadership page and gives the right name, the error is purely parametric — the truth is reachable, the model just defaults to stale internal knowledge when it does not look. Your fix is to make the live signal so unambiguous and well-corroborated that retrieval is favoured, and then to wait out the parametric lag. If, instead, the browsing answer is also wrong, a stale source is being fetched — an outdated directory, an old press cache, a profile you forgot to update — and your fix is to find and correct that specific source. Same symptom, opposite remedy. The five-minute diagnostic of running the question both ways saves the wasted week.
2. The triage framework (decide what to fix before you fix anything)
Not every hallucination is worth your time, and chasing trivial ones burns goodwill and budget you will want for the serious ones. Triage first. Score each error you find on two axes — how damaging it is if a real buyer sees it, and how likely a real buyer is to surface it — and let that decide the response. This matrix is the deliverable of this article: run a brand audit, drop each error into a cell, and act accordingly.
| Low exposure (rarely surfaced) | High exposure (commonly surfaced) | |
| High harm (reputational / commercial) | Monitor and log. Fix the underlying source opportunistically. Escalate if it is defamatory or concerns personal data. | Treat as an incident. Correct sources immediately, escalate through vendor channels, and consider legal review. |
| Low harm (cosmetic / trivial) | Ignore. Note it; do not spend on it. | Fix cheaply via source updates; do not escalate. Worth it only because the volume of exposure is high. |
How to estimate exposure. Exposure is driven by how likely someone is to ask the question that triggers the error. “Who founded [your brand]?” and “Is [your brand] legitimate / safe / still operating?” are high-exposure questions — buyers and journalists ask them constantly. An obscure detail about a 2019 product line is low-exposure. Map the questions your real audience asks, not the ones that annoy you most.
The severity checklist. Before escalating anything as an incident, confirm: (1) the claim is factually false, not merely unflattering; (2) it appears for realistic, commonly asked prompts, not contrived ones; (3) it is reproducible, not a one-off generation; and (4) it would plausibly change a reasonable person’s decision about you. An error that fails any of these is a monitor-and-log item, not an emergency.
The discipline this matrix enforces is emotional as much as analytical. Brand owners react to errors about themselves the way anyone reacts to being misrepresented — with a disproportionate urge to correct the record immediately, regardless of whether anyone else will ever encounter it. That instinct is the enemy of a good programme. The error that stings you most is frequently a low-exposure one that no buyer will ever trigger, while the genuinely dangerous error is often something blander that you have stopped noticing. Forcing every finding through the harm-and-exposure grid replaces the urge to defend your pride with a decision about where the commercial risk actually is. Most findings should land in monitor-and-log; reserve incident-grade effort for the top-right cell, where harm and exposure are both high.
3. Detection: finding what ChatGPT actually says
You cannot fix what you have not observed, and a single casual query is not observation. Hallucinations are probabilistic — the model may give a clean answer once and a fabricated one the next time — so detection has to be systematic. Build a standing battery of brand questions and run it deliberately.
Build a prompt battery
Write down the questions a prospect, a journalist, a job candidate and a sceptic would each ask about you, in their words. Cover identity (“who are they, who founded them, where are they based”), status (“are they still operating, are they legitimate, are they any good”), specifics (products, pricing, leadership) and risk (“have they had any controversies or breaches”). Phrase them naturally, the way a person types, not the way a marketer writes. This battery becomes your repeatable audit — the same questions, run on a schedule, so you can see drift over time rather than guessing.
The framing of each question matters more than people expect, because models answer the question they are asked, not the brand you are anxious about. A neutral “tell me about ExampleBrand” and a loaded “why is ExampleBrand controversial” can produce wildly different answers — the second can lead the model to manufacture a controversy to satisfy the premise. Include both neutral and adversarial framings deliberately, because a hostile prospect or a rival’s due-diligence will use the loaded versions, and those are exactly the prompts most likely to surface a damaging fabrication. Also include comparison prompts (“who is better, ExampleBrand or [competitor]”), because that is how a great many purchase-stage buyers actually use these tools, and it is where false attribution and sentiment errors tend to appear. A battery that only asks polite, open questions will miss the answers that actually cost you business.
Probe both layers, and probe more than once
Run each question several times, and run it both with and without browsing or live retrieval enabled where the interface allows. Divergence between the two is diagnostic: a clean browsing answer over a wrong base answer tells you the error is parametric; a wrong browsing answer tells you a bad source is being fetched, which is the more fixable case. Watch for the model’s confidence too — a hedged “I’m not certain, but” is a softer problem than a flat, wrong assertion. Capture the exact prompt, the date, whether browsing was on, and the verbatim answer. That record is what makes a later escalation credible and a later re-audit meaningful.
For anything beyond a handful of brand terms, manual checking does not scale, and an automated audit is worth standing up. The illustrative routine below queries a model’s API with each prompt in the battery, compares the answer against a list of known-false strings you are watching for, and flags drift. It is schematic, not production code.
| # Illustrative brand-hallucination audit (schematic, not production code) battery = [ “Who founded ExampleBrand?”, “Is ExampleBrand still operating in the UK?”, “Has ExampleBrand had any data breaches?”, ] watchlist = [“acquired in 2021”, “founded by J. Rival”, “ceased trading”] for prompt in battery: for run in range(5): # probe repeatedly; answers vary answer = model.ask(prompt, browsing=False, temperature=0) hits = [w for w in watchlist if w.lower() in answer.lower()] if hits: log(date=today, prompt=prompt, run=run, browsing=False, answer=answer, flagged=hits) |
Rule-5 notes for anyone automating this. Where it breaks: model answers are non-deterministic, so a single clean run does not mean the error is gone; vendors ship new model versions without notice, which can reintroduce or fix errors overnight; and browsing answers depend on what is live that day, so results are not reproducible across time. Reproducibility metadata to record: model name and version, temperature, browsing on/off, date, and prompt verbatim — without these your log is anecdote, not evidence. Cost at volume: at current commercial API pricing a battery of, say, twenty prompts run five times daily across a couple of models is a small monthly cost — on the order of a modest subscription, not a budget line — but it scales linearly, so cap the battery to questions that matter. Failure threshold and fallback: if automated monitoring costs more in engineering time than the harm it surfaces, fall back to a manual monthly spot-check of your top ten brand questions — most small brands never need more than that.
4. Correcting the underlying signals
Here is the principle that governs everything in this section: you cannot edit the model, so you edit its evidence. ChatGPT’s answer about you is a function of what the web, structured data and authoritative references say about you. Change those inputs convincingly and consistently, and the answer eventually changes — fast for the retrieval layer, slowly for the parametric layer. Scattershot fixes do not work; the model weighs consensus, so you are trying to shift the balance of what credible sources say, not plant a single contradicting page.
It helps to abandon the mental model of “submitting a correction” entirely. There is no record to amend, no editor to email who will change the one canonical entry. What you are doing is closer to landscaping than editing: you are reshaping the terrain of evidence so that water runs the way you want it to. Every authoritative surface that states the right fact clearly is a slope tilted in your favour; every stale or ambiguous source is a slope tilted against. You win not by removing every adverse source — often impossible — but by making the truthful, well-structured signal so dominant that any reasonable summarisation of the evidence lands on it. That reframing matters because it sets the right expectation about effort and time: terrain takes longer to reshape than text takes to edit, but once reshaped it holds.
Fix your own authoritative surfaces first
Start with the pages you control and that models treat as primary: your About page, your product pages, your leadership pages. State the correct fact plainly, unambiguously and in a way a machine can parse — a clear sentence beats a clever one. If your own site is vague about your founding date or your current product line, you cannot be surprised that the model guessed. These are also the pages a browsing step is most likely to fetch, so getting them right is the single highest-leverage move for retrieval-layer errors.
Strengthen your structured entity
Models lean on structured, machine-readable identity to tell entities apart — the descriptions held in knowledge bases and the structured markup on your own pages. A well-maintained entry in the open knowledge graph that feeds many systems, consistent organisation markup on your site, and matching details across your major profiles all reduce the conflation errors that come from the model being unable to distinguish you from a namesake. Consistency across these surfaces is the signal; a single contradicting detail anywhere undermines it.
The detail that catches people out is that machines are literal in a way humans are not. A human reader knows that “Apex Ltd,” “Apex Limited” and “Apex” are the same firm and that your Companies House registration, your LinkedIn page and your website footer all refer to one organisation. A model, working from scattered sources, may not — especially if a different Apex exists in an adjacent sector. The remedy is tedious but high-leverage: pick one canonical form of your name, one canonical description, one set of core facts, and make every surface you control agree on them down to the wording. The aim is to leave no daylight between your representations for the model to fill with a guess. This is unglamorous housekeeping, but for conflation errors it is frequently the entire fix, because you are removing the ambiguity that caused the merge in the first place.
Build third-party corroboration
Self-assertion is weak; corroboration is strong. The model trusts a fact more when independent, credible sources agree on it. This is where brand-safety work and ordinary digital-PR converge: a correct, well-sourced reference in reputable third-party coverage does more to move a stubborn answer than ten edits to your own footer. If the wrong fact persists because some authoritative source out there still carries it, the durable fix is to get that source corrected, not merely to contradict it on your own turf.
Think of it as moving a centre of gravity rather than winning an argument. A model that has seen the wrong fact in a dozen places and the right one in two will tend toward the wrong one, however emphatic your own page is. The work is to tilt the balance of credible sources — a corrected industry directory here, an accurate trade-press mention there, a fixed entry in a widely-mirrored reference there — until the weight of evidence the model encounters points the right way. This is slow, unglamorous and exactly the kind of distributed, earned-reference work that also builds ordinary authority, which is why brand-safety and link-earning programmes tend to reinforce each other rather than compete for budget.
There is also an order-of-operations economy here. Fix the cheap, controllable surfaces first — your own pages and structured data — because they are free and they are what a browsing step reads. Only then invest in the expensive, earned corrections to third-party sources, and only for errors that survived the cheap fixes and scored high on the triage matrix. Spending digital-PR budget to correct a low-exposure, low-harm error that a simple page edit would have handled is the most common way these programmes waste money.
A blunt caveat: none of this is instant, and none of it is guaranteed. You are improving the odds that the next time the model retrieves or retrains, it lands on the truth. For retrieval answers that can be a matter of days; for deeply baked parametric errors it may take a model generation, and a few errors may simply persist until the vendor’s data improves. Set that expectation internally before you start, or the work will be judged a failure for not doing something it never could.
5. Escalation: using the vendor’s own channels
Alongside changing the evidence, use the front door. Major AI providers offer feedback mechanisms — the thumbs-down and report controls in the interface, and in some cases dedicated channels for factual corrections and for rights or safety complaints. These are most useful for clear, reproducible, high-harm errors, and far less useful for matters of framing or opinion. When you submit one, give them what your detection log already contains: the exact prompt, the verbatim wrong answer, the correct fact, and a link to an authoritative source that supports it. A vague “you’re wrong about us” goes nowhere; a precise, evidenced report is something a reviewer can act on.
Be realistic about the limits. Vendor feedback is a request, not a guarantee, and there is rarely a published service level for individual corrections. It works best as one channel among several — you report through the front door and you fix the underlying sources, so that whether the correction comes from human review or from the next data refresh, the evidence supports the right answer either way. Treat escalation as insurance on top of the source work, not a substitute for it.
One operational habit makes escalation far more effective: report once, clearly, and keep the reference. Bombarding a feedback channel with the same complaint repeatedly does not accelerate review and can get the reports deprioritised; a single, well-evidenced submission, logged with the date and any acknowledgement you receive, is both more likely to be actioned and more useful later if the matter ever escalates further. Keep these submissions in the same dated log as your detection results, so that for any given error you can show, in one place, when you first observed it, what you reported, to whom, and whether it has since improved. That continuous record is what separates a brand that can demonstrate diligence from one that merely felt aggrieved.
6. Where this breaks in production
The failure modes here are mostly about mistaking the nature of the system. These are the ones that derail correction programmes.
Fixing the wrong layer. Updating a page does nothing for a parametric error, and waiting for retraining does nothing for a bad-source retrieval error. Fix: diagnose the layer first (Section 3) and direct effort accordingly.
Mistaking variance for a fix. The model gives a clean answer once and you declare victory; it reverts on the next user’s query. Fix: confirm a correction across repeated runs over time, not a single happy result.
Silent model updates. A new model version reintroduces an error you had cleared, or fixes one you were still working. Fix: keep the audit running on a schedule so version changes show up as drift you can see.
Chasing opinion as if it were fact. Trying to “correct” a model for describing you as expensive or niche wastes effort and credibility with vendor channels. Fix: confine corrections to verifiable factual errors; handle framing through ordinary reputation and content work.
The Streisand effect. Loudly contesting a minor, low-exposure error can generate the very coverage that teaches the model the wrong thing more firmly. Fix: let triage govern — quiet, low-exposure errors are usually best monitored, not amplified.
7. Measuring whether the fix took
Correction without measurement is hope. Because answers vary and layers update on different clocks, you confirm a fix the same way you detected the problem: re-run the battery on a schedule and watch the rate, not a single result.
- Track a hallucination rate, not a binary. For each watched error, record how often it appears across repeated runs. “Down from four-in-five to one-in-five” is real progress; “it was fine when I checked” is not data.
- Respect the lag. Expect retrieval-layer corrections to show within days of the source change and parametric ones to lag by a model generation or more. Judging a parametric fix after a week guarantees a false negative.
- Re-baseline after model updates. When a vendor ships a new version, re-run the full battery; treat it as a new baseline rather than assuming prior fixes carried over.
- Log everything, permanently. Your dated records of prompt, version and answer are both your measurement and your evidence if a case ever escalates to a vendor complaint or legal action.
A practical caution on attribution: when an error improves, resist the urge to credit your most recent action automatically. Because vendors update models and refresh retrieval indexes on their own schedule, a correction that lands the week after you fixed a page may have been your doing — or may simply be a new model version that happened to ship. The way to tell the difference over time is to change one signal at a time and watch which changes coincide with which improvements. You will not always get a clean read, but a disciplined log across several cycles will show you which of your levers actually move answers for your brand and which are theatre, and that knowledge is what lets you spend the next quarter’s effort where it works.
8. The UK angle: when this becomes a legal matter
Most brand hallucinations are an SEO-and-PR problem. A minority are a legal one, and UK brand owners have levers that do not exist purely as marketing tactics — worth knowing where the line sits.
Defamation. Where an AI states something false that seriously harms your reputation, UK defamation law is, in principle, engaged — the difficulty is procedural rather than conceptual, around who is responsible for an automated statement and what remedy is realistic. The practical first step is almost always a documented complaint to the provider with your evidence, not litigation; but for a genuinely damaging, persistent, false factual claim, qualified legal advice is appropriate, and your detection log is the foundation of any such claim.
Inaccurate personal data. Where the false statement is about an identifiable individual — a named founder or executive — UK data-protection law provides a right to have inaccurate personal data corrected, which can be exercised against the organisation processing it. This is a distinct and sometimes more direct route than defamation for personal, as opposed to corporate, errors, and the regulator provides guidance on how such requests work.
Editor’s flag. How established legal doctrines apply to AI-generated statements is unsettled and moving quickly in the UK and elsewhere. The principles above are durable; the specifics are not. Confirm the current position with primary sources and take qualified legal advice before acting on the legal routes — treat them as escalation options to raise with counsel, not as steps to self-administer.
The strategic point is one of sequencing. For the vast majority of errors, the source-and-signal work in this playbook is faster, cheaper and more effective than anything legal. The legal routes matter for the small set of cases that are both seriously harmful and stubbornly persistent — and even then, the evidence those routes require is exactly the dated, verbatim detection log you have been keeping all along. Good operational hygiene and good legal posture turn out to be the same discipline.
Your Monday-morning action plan
One executable sequence you can start this week:
- Write your prompt battery — ten to twenty real questions a prospect, journalist, candidate and sceptic would ask about your brand, in their words — and run each one several times in ChatGPT, with and without browsing, capturing prompt, date, browsing state and verbatim answer.
- Classify every error you find by type (fabrication, staleness, conflation, attribution, framing) and drop it into the triage matrix by harm and exposure. Act only on the high-harm cells; monitor-and-log the rest.
- For each error worth fixing, diagnose the layer: clean-with-browsing means fix the live source; wrong-with-browsing means a bad source is being fetched; wrong-both-ways means it is parametric and slower to move.
- Correct your own authoritative surfaces first — About, product and leadership pages — stating the right fact plainly, then strengthen your structured entity and consistency across major profiles so namesakes stop getting merged with you.
- For high-harm, reproducible errors, submit an evidenced report through the provider’s feedback channel, attaching the exact prompt, the wrong answer, the correct fact and a supporting source link.
- Put the battery on a monthly schedule, track each error as a rate rather than a yes/no, and re-baseline after any model update. Flag any seriously harmful, persistent, false claim about a named person or your reputation for legal review.
Treat what ChatGPT says about you as part of your reputation surface, because to a growing share of your audience it is the reputation surface — consulted privately, trusted implicitly, and never seen by you unless you go looking. You cannot reach into the model and retype the answer. You can make the truth the easiest, best-supported, most consistent thing for it to find, report the dangerous errors through the right door, and keep the receipts. Done patiently, that is how a confident falsehood becomes, over a cycle or two, a confident fact.
