How Do You Correct Something AI Has Wrong About Your Business?

When an AI system states something wrong about your business, the instinct is to fix the answer. You usually can’t, and it isn’t the right first step anyway. The first task is to work out why the system produced that answer, because “wrong” describes the output. It doesn’t identify the cause. An outdated source, a conflicting record, a fact attached to the wrong company, a correct fact misread, and a claim with no source at all are different problems, and each is corrected in a different place. Some of those places are under your control. Some aren’t.

Start Where You Would With a Wrong Number

Suppose a management dashboard shows annual revenue of $42 million when the correct figure is $47 million. Nobody competent would say the dashboard hallucinated. They would ask where the number came from. Is one of the feeding systems out of date? Are two systems using different definitions of revenue? Did the figure come from the wrong subsidiary? Is the underlying number right but labelled in a way that invites the wrong reading? Was something miscalculated along the way? Or is there no identifiable source for $42 million at all?

The error is visible at the end of the chain. Seeing it there doesn’t tell you where it entered.

An AI answer about a business is the end of a similar chain. Depending on the system and the question, it may involve searching the web, selecting some of what was found, interpreting it and writing a response, or it may draw on what a model learned in training. The difference is that a business can’t inspect most of that chain. It can see the answer, sometimes the sources cited, and the public information that exists about it. Diagnosis works from those.

Sometimes the honest conclusion will be that the system made it up. Language models do produce what OpenAI describes as “plausible but false statements”, and the company calls this a fundamental challenge for all of them. But “it hallucinated” is a poor first diagnosis, because it ends the investigation before anyone has looked for a cause that could be fixed.

Wrong describes the output. It doesn’t tell you the cause.

Pin Down What Is Actually Wrong

Start by writing the error down precisely. “ChatGPT gets us wrong” isn’t something you can investigate. “Asked which firms in our region offer X, it said we stopped offering X in 2021” is. Note the question that produced it, the system, the date, and any sources the answer cited.

Then check that the claim is wrong in the way it seems. Sometimes it’s a correct fact about the wrong subject. Sometimes it’s a historical fact presented as current. Sometimes it’s correct for one part of the business and stated as true of all of it. Sometimes, on inspection, the business’s own information is the thing that’s inconsistent.

That distinction matters more than it looks. A wrong fact needs correcting. A correct fact that has been misread needs clarifying. They are not the same job.

Five Kinds of Wrong

A useful way to investigate an incorrect answer is to look for five patterns. They are a diagnostic framework, not a map of how AI errors are distributed. They overlap, and the evidence available from outside a system won’t always separate them cleanly. Naming them still changes what you do next.

Outdated information. The system is using something that was true once: a former executive, a discontinued service, an old office, a previous owner, last year’s pricing. The source isn’t lying. It has simply stopped being current. The fix is about freshness, both in the originating source and in current evidence elsewhere.

Conflicting information. Credible sources say different things, and the system has relied on the wrong one or blended them. Your website may be right while a directory, profile or article isn’t. What happens when AI has conflicting information about your business is a subject in its own right. For correction, the practical point is that you have to find the conflicting source before you can do anything about it.

Identity or relationship ambiguity. This takes two forms. In the first, information is attached to the wrong entity: a similarly named company, a former employer, a parent or subsidiary, a different person with the same name. That is the territory of entity clarity. In the second, the system has found the right facts and misunderstood how they relate: what a figure describes, which period it covers, whether a statement applies to one product or the whole company, whether something is historical or current. A human reader often infers the intended relationship from context that a machine doesn’t interpret the same way. Correct information being present is not the same as the intended relationship being explicit.

Unsupported inference. No source states the wrong claim, but the available evidence is incomplete or ambiguous enough for a system to infer it. A firm that lists three industries it has worked in may be described as specializing in them. A page that mentions an office without saying it closed may be read as evidence that it’s still open. The sources are accurate. The conclusion drawn from them isn’t.

Apparent fabrication. This is the case where an outside observer can identify no source, ambiguity or reasonable inference that explains the claim. It resembles the everyday idea of a model simply making something up, although “hallucination” is used more broadly for false model outputs of any origin. It’s real, and it’s the case where the business has least to work with.

Be careful with that last category. Failing to find a cause isn’t proof that none exists, and most of the chain is invisible from outside. Often the most you can say is which explanation is most plausible.

When Every Fact Is Correct

Consider a hypothetical market research firm. Its website introduces an annual report on automation in manufacturing, and a methodology note further down the page explains that the research surveyed 400 mid-sized manufacturers. The headline statistic, set in large type near the top of the page, reads: “Our 2025 research found that 62% delayed an automation investment in the past year.”

Every element is accurate. The firm exists, the survey happened, it covered 400 manufacturers, and 62% of them said they had delayed an investment.

Then a prospective client asks an AI assistant about the firm and is told that 62% of its clients have delayed automation projects.

No source fact is false. The answer is still wrong. The statistic says who did the research but not who was researched. That information exists, further down the page, and nothing in the statistic itself connects the 62% to the survey population. On a site that also talks about “our clients”, a reader of the figure alone is left to guess. A person reading the whole report would get it right. A system working from the statistic and its immediate surroundings might not.

There’s nothing to correct here in the usual sense. The corrective work is clarification: putting the subject into the statistic itself (“62% of the 400 mid-sized manufacturers we surveyed in 2025”), and making plain nearby how they were selected and that they are not the firm’s clients. It’s the dashboard equivalent of a correct number with an ambiguous label. Fixing the label won’t guarantee a different answer, but it removes the reading that made the wrong one available.

None of this proves the ambiguity caused the error. It identifies a plausible cause that the firm can act on, which is usually the best that diagnosis from outside the system can offer.

When the Wrong Fact Lives Somewhere Else

Now consider a hypothetical software company that used to integrate with a platform we’ll call Platform X. It ended that support in 2023. An established industry directory still lists the Platform X integration as available, and AI assistants sometimes repeat it.

The first step is obvious: ask the directory to correct its listing. If it offers a correction process, use it.

The harder case is the realistic one. The directory doesn’t respond. It has no correction mechanism. The listing is part of an archived review that won’t be edited. A business can’t edit someone else’s website.

At that point the company’s own website matters, but not in the way it might assume. Its current integrations page simply doesn’t list Platform X. That absence contradicts nothing. A system that finds the directory’s claim and the company’s silence has no explicit evidence that the claim is wrong.

A clear statement does. An integrations page, a changelog or a support article that says “Support for Platform X ended in March 2023” is evidence against the incorrect claim in a way that omission isn’t. So is saying what customers should use instead. Correct information existing isn’t the same as evidence that contradicts the incorrect claim.

The website shouldn’t be thought of as the source of truth, as if AI systems were obliged to defer to it. An AI system may not prefer what a company says about itself over independent sources. It’s better understood as the place where a business can make its own current facts explicit when it can’t control what others publish. Where legitimate independent sources also carry the current information, such as a partner’s marketplace listing, a release note on a third-party platform or a current profile on a well-maintained directory, they provide corroborating evidence rather than leaving the company’s own statement to stand alone.

Volume is a different matter. Publishing the same correction across a dozen thin pages to drown out one stale listing creates repetition rather than independent corroboration, and risks turning clarification into manipulation.

Correcting Evidence and Reinforcing It

Most corrective work falls into two different activities.

Correcting erroneous evidence means fixing the source that’s wrong: your own pages, profiles you manage, directories and databases that accept corrections, publishers willing to update a record.

Reinforcing accurate evidence means making current information explicit where a wrong source can’t be changed. That includes stating dates, scope and status (“ended in 2023”, “applies to our UK business only”, “former managing director”), naming the entity a fact belongs to, and making relationships plain where they are currently left to inference.

Structured data can contribute to that clarity by stating, in a machine-readable form, which organization or person a page describes. It doesn’t fix an inaccurate AI description on its own, and it can’t contradict a claim the visible page never addresses.

Neither activity guarantees a change in any AI answer. Both improve the evidence available to systems that encounter it.

What Other Systems Can Tell You

Asking the same question in more than one AI system, and in more than one wording, is one of the few diagnostic tools a business has. The results are clues, not conclusions.

If several unrelated systems repeat the same wrong fact, a shared evidence problem is worth looking for: a widely copied source, a persistent ambiguity, an entity confusion. The repetition doesn’t prove a common source. If only one system gets it wrong and shows its citations or sources, those are the obvious place to begin. If rewording the question changes the answer, retrieval or context may be part of the explanation, although variation alone doesn’t establish the cause.

Generated answers also vary. SparkToro found substantial run-to-run variability when it repeatedly asked AI tools for brand recommendations. That research didn’t test factual claims about businesses, but it’s another reason not to treat a single response, wrong or right, as a stable observation.

Correction and Propagation Are Separate Events

Back at the dashboard, fixing the figure in the finance system doesn’t change every report that has already pulled it. Some refresh overnight. Some keep a cached copy. Some pull from a different source entirely.

Corrected information reaches AI answers in a similar, less visible way, and there is no single timetable. For Google Search, Google says crawling a changed page “can take anywhere from a few days to a few weeks”, and that requesting a crawl doesn’t guarantee inclusion. OpenAI says that without search enabled, ChatGPT’s responses are based on what the model has learned during training, while with search it can draw on current web sources. Different products work differently, so a correction may show up in one and not yet in another.

Correcting the information environment and seeing the correction in an AI answer are two separate events. The first is work a business can do. The second is an outcome it can observe but not schedule. That is why retesting over time matters, and why an answer that changes once hasn’t necessarily changed for good.

Where the Error Can Actually Be Corrected

A business usually can’t edit an AI answer. It may not be able to change every source that contributed to it. What it can do is investigate why the answer may have occurred, correct the evidence it can reach, make current facts explicit where it has control, remove ambiguity about dates, scope, entities and relationships, strengthen legitimate independent evidence, and then watch whether the answer changes.

None of that comes with a guarantee. But it replaces a question nobody can act on, “how do we fix what the AI said?”, with one that can be worked through: what kind of information problem produced the answer, and where can that problem actually be corrected?