Are AI hallucinations real? Can we stop them?

AI hallucinations are real. The awkward part is that they rarely look hallucinatory. They arrive as a tidy paragraph, a plausible quotation, a confident statistic or a reference that appears respectable until somebody tries to open it.

The machine is not seeing things. It has no private cinema of pink elephants. “Hallucination” is the familiar label for a simpler failure: a generative system produces content that sounds right but is false, unsupported or inconsistent.

That distinction matters because the problem is neither magic nor evidence that AI is useless. It is a known failure mode that becomes manageable once we stop treating fluent language as proof.

Yes, the problem is real

The US National Institute of Standards and Technology uses the term “confabulation” for confidently stated but erroneous or false content. It also includes answers that drift away from the prompt or contradict something the model said earlier. NIST notes that this behaviour follows naturally from the way generative systems produce statistically plausible output. [1]

Not every wrong answer is a hallucination. A model can also misunderstand an instruction, make a calculation error or reason badly from correct facts. Hallucination is the more specific problem of presenting invented or unsupported material as though it belongs in the answer.

The most dangerous examples are not obvious nonsense. They are the ones that fit the shape of a good answer: a real-looking source, a believable number, a quotation in the right tone or a concise explanation that happens to be wrong.

Why can a fluent model invent a fact?

Confidence is a style. Evidence is a property.

A language model does not begin by consulting an internal ledger of verified truths. During its initial training, it learns to predict likely continuations from enormous quantities of text. Grammar, spelling and common patterns are highly learnable. Rare, arbitrary facts are much harder to recover from patterns alone.

A 2025 paper by OpenAI and academic researchers adds a second explanation. Training and evaluation often reward a model for attempting an answer, even when it is uncertain. A lucky guess can score as correct; “I do not know” cannot. That creates pressure towards plausible completion rather than honest abstention. [2]

This is why a polished tone is a poor guide to reliability. The system is very good at producing the form of an answer. Whether the content is supported is a separate question.

Can better models solve the problem?

Better models can reduce hallucination rates, and systems can be trained to abstain, ask for clarification or use external tools. But a universal promise of perfectly truthful open-ended answers is the wrong target.

Some questions are ambiguous. Some facts are unavailable. Some sources conflict. A model may lack the evidence, misunderstand it or use it badly. Even systems that retrieve documents before answering can be led astray by irrelevant or manipulated evidence, so source access is an improvement, not a guarantee. [5]

At the level of a particular answer, a hallucination can often be avoided. The model can decline to guess, search for evidence or state its uncertainty. Across every future question and every operating context, however, there is no reliable “never wrong” switch.

That is why a vendor claim that a system “does not hallucinate” deserves a follow-up question: under which tasks, with which evidence, using what definition, and measured how?

Five things that actually reduce hallucination risk

1. Give the model a bounded job

“Summarise this approved report and quote the supporting passages” is safer than “Tell me what the report says” when the report has not been supplied. Transforming known material is usually easier to verify than recalling an open world of facts.

2. Give it authoritative sources

Use approved documents, retrieval or search where factual accuracy matters. Tell the system which sources are allowed and what to do when they do not contain an answer. Source access narrows the problem, but the source set still needs to be relevant, current and trustworthy.

3. Make material claims traceable

Ask for links, quotations, page references or a claim-to-source table. Then check them. A citation is a route to verification, not a certificate of truth. NIST specifically recommends reviewing sources and citations in generative-AI outputs during testing and ongoing monitoring. [1]

4. Separate drafting from checking

Do not rely on “check your answer” as a complete control. Research on Chain-of-Verification found that a staged process of drafting, creating verification questions, answering them independently and then revising reduced hallucination across several tasks. [3]

A 2026 ACL benchmark reached a related conclusion. One-shot LLM self-judging still missed hallucinations even when the correct evidence was available. Models performed considerably better when checking was broken into separate steps: identify the claims, find the evidence, evaluate it and locate the unsupported content. [4]

Verification should be a process, not merely a second confident paragraph from the same model.

5. Match the control to the consequence

A wrong slogan suggestion is irritating. A wrong payment instruction, legal citation, medical statement or board-paper fact can be consequential. The amount of grounding, checking and human review should rise with the cost of error.

A practical control rule

The higher the consequence, the stronger the control.

The five-question hallucination reality check

Before relying on an AI-generated answer, ask five questions:

1. What in this output must be factually correct, rather than merely useful or creative?
2. Which approved source supports each material claim?
3. Is the model allowed to say “I do not know”, ask for clarification or leave a gap?
4. Who verifies the answer before it affects money, rights, health, safety, reputation or compliance?
5. What happens if the answer is wrong?

Andrew's Intel editorial decision aid; not a validated reliability measure or substitute for qualified review.

If the task is low-stakes, reversible and easy to inspect, ordinary human editing may be enough. If the output is factual and material, require source-backed checking. If the answer could cause serious harm or is difficult to verify, an AI system should not be the final authority.

What to ask a vendor who promises “no hallucinations”

The useful questions are not adversarial. They are simply more precise than the promise:

• What do you count as a hallucination, and what kinds of error are excluded from that definition?
• On which tasks, datasets and operating conditions was the claim measured?
• What does the system do when evidence is missing, ambiguous or contradictory?
• How are sources checked, errors logged and incidents escalated after deployment?

A constrained system may genuinely achieve very high reliability within a narrow task. That is valuable. It is not the same as proving that the underlying model cannot invent unsupported content in other settings.

Can we stop having them?

Not in the sense of guaranteeing that every open-ended answer will be true. We can reduce the frequency of confident errors, reward abstention, ground answers in evidence, use tools, test the system and verify material claims. We can also design the workflow so that an error is caught before it becomes an action.

That is the more useful management objective. The model does not need to be infallible for every task. The organisation does need to know where the output came from, who checked it and what should happen when the evidence is weak.

The question to ask is therefore not simply, “Does this model hallucinate?” Serious generative models can. Ask instead: “Where in this workflow does an unsupported claim get stopped?”

The useful target is not zero hallucinations. It is zero unsupported claims quietly becoming organisational facts.