Short answer
Hallucination guardrails are checks that stop an AI from presenting made-up facts as true. They limit what it answers from, verify each reply against sources and rules before it is sent, and hand off when it cannot back an answer up.- Also called
- Hallucination guard, answer verification, grounding checks
- Work at
- Before, during and after the model writes a reply
- Main types
- Grounding, scope limits, reply checks, saying I don't know, human review
- Cannot do
- Make errors impossible on their own
A hallucination is a fluent, confident answer that is not true: a return window that does not exist, a delivery date nobody promised, a discount nobody approved. Language models produce them because they are built to write likely text, not to check it. Guardrails add the checking.
Types of hallucination guardrails
No single guardrail is enough, so they are layered.
- Grounding. The model answers from retrieved sources, such as the help center, the policies and the customer's live order, not from memory.
- Scope limits. The agent only handles request types it has been set up and tested for.
- Reply checks. Each reply is checked before it is sent, for claims the sources do not support and promises the agent may not make.
- Saying I don't know. When the sources do not cover the question, the agent says so, asks a clarifying question or hands off.
- Human review. Drafts or approvals on the topics where a wrong answer is costly.
- Action limits. The agent can only take actions it is permitted to, so a hallucinated promise cannot turn into a real refund.
Guardrails before, during and after a reply
Each stage catches a different failure.
| Stage | Guardrail | Example |
|---|---|---|
| Before | Scope and sources | Return questions are answered only from the returns policy |
| During | Lookups | The agent reads the live order instead of guessing its status |
| After writing | Reply check | A reply promising an unapproved refund is rejected |
| After sending | Record and review | The sources behind each reply are kept, so errors can be traced |
Hallucination examples in a Shopify store
Three common failures, and the guardrail that stops each.
- A shopper asks whether a jacket comes in XL. An ungrounded model says yes, because most jackets do. A grounded one reads the product's variants.
- "When will my order arrive?" The model invents Thursday. A grounded one reads the carrier's expected delivery date, or says there isn't one yet.
- Asked about returning a sale item, the model applies the general 30-day policy and misses the final-sale exclusion. Answering only from the returns policy, with its exclusions, prevents it.
Each failure has the same root: an answer written from what is likely, not from what is on record.
In Aide, a return is started under the store's own Shopify return rules, so an item tagged final-sale is excluded by the rule rather than by the model remembering it. Delivery questions are answered from live tracking, with each shipment of a split order shown with its own carrier and contents. Facts that live inside images, such as a size chart or a nutrition panel in a help article, are read into the article text when it is imported, so the answer comes from the chart instead of a guess.
How to stop AI hallucinations
The steps are practical, and most are about sources and scope rather than the model.
- Give the AI the real sources, and keep them current.
- Narrow its scope, and add request types one at a time.
- Check replies before they go out, not after a customer complains.
- Make "I don't know" an acceptable outcome, with a handoff to a person.
- Test on real past conversations before going live.
- When an answer is wrong, fix the source, not just the reply.
The claim this page rejects is the hallucination-free AI. No guardrail makes errors impossible. Layers make them rare, catch most of them before a customer sees them, and leave a trail for the rest.
With Aide, step 6 has a list to work from: every night Aide updates what customers ask that the team answers but knowledge doesn't cover, including articles that say something the team no longer does, each gap checked against the whole knowledge base and proposed with the text and the article it belongs in.
Where Aide fits
Aide writes each reply from the workspace's knowledge, the customer's live order and the team's instructions, and reads the product pages an article names for current stock, sizes and prices. Every reply is checked before it is sent, in two grades. A serious issue, such as a wrong price, stock level or order detail, a promise the policies don't back, a reply that misses the question or a leftover placeholder, gets one rewrite; if that doesn't fix it, Aide asks a clarifying question or hands off. A promise beyond policy, or any claim to be a person, goes to the team at once. A small issue, such as running longer than the length guideline, doesn't hold the reply back; the reason is kept so the team can add the missing article. When knowledge doesn't cover a question, Aide says what isn't known yet and offers the team. The sources behind each reply are on record in the Action Trace.