How to stop an AI assistant from making things up in front of customers.
When an AI invents a fact and delivers it with full confidence, that is called a hallucination. The fear of exactly that is the most common reason businesses keep AI away from paying customers, and the fear is rational. The cure just isn't a cleverer prompt: it is four structural properties you can check in any tool before you let it speak for you.
Why "please don't hallucinate" doesn't work
Two words you will hear in every sales call, so let's define them first. A prompt is the text you send to an AI model: your question, plus any instructions. The system prompt is a hidden extra instruction the vendor puts in front of every conversation. Many vendors answer the hallucination worry with one sentence right there: only answer from the provided material, say when you are unsure, do not invent facts. That helps. It measurably reduces how often the model fills a gap with plausible fiction. What it cannot do is guarantee anything, because a prompt is a request, not a constraint. The model still generates the statistically most plausible next words, and when the true answer is missing from the material it was given, "plausible" and "true" quietly part ways.
There is a second problem, and for a business it is the bigger one: a promise in a prompt leaves no trail. To audit something means to check later, with records, what was actually done. A prompt cannot give you that. If a vendor tells you "our prompts prevent hallucinations", you have no way to test the claim, no record of what was checked, and no process for the day it fails. You are buying hope with better marketing.
What actually keeps an assistant honest sits around the model, not inside it. Four properties do the work. Each one is something you can see and test in a normal product demo, no technical background required:
Property 1: Answers come only from your own material
The biggest lever against hallucination is limiting what the model may draw from. Out of the box, an AI model answers from its training data, the huge pile of internet text it learned from. An assistant answering from that pile will sooner or later present someone else's facts as yours. An assistant that is bound to your own reviewed material, meaning your product data, your policies, your documentation, can only be as wrong as that material is.
The test you can run in any demo: does every answer show its source? It should sit on the answer itself, not buried in some admin screen, so anyone can trace a claim back to the document it came from. In Klariton, each answer is stored as a small package of question, answer and source. That unit is called a BIQ, and the Buying Answers workflow simply refuses to publish a reply without a source. Whatever tool you evaluate, ask to see where the source lives. If the answer is "the model knows", keep looking.
Property 2: A human approves every answer before it goes live
Generation and publication are two different events, and the space between them is where safety lives. A review gate is exactly what it sounds like: a checkpoint between the two. The AI can draft as many answers as it wants, but no answer reaches a customer until a person has read it and released it. That person sees the draft next to its source and confirms the two actually match.
This sounds slow. In practice it mostly isn't. The questions your customers ask most, things like shipping times, returns and opening hours, change slowly. So the heavy review happens once, at the start. After that, the gate only touches new answers and flagged changes. What you get in exchange is the one thing no prompt can offer: accountability. When every published answer has a named approver and a timestamp, "the AI said it" stops being an excuse, because a person signed it off too.
Property 3: Published answers are checked for drift
The sneaky failure mode is not the answer that was wrong on day one; the review gate catches that. It is the answer that was correct when approved and became wrong later. A price changed. A product was discontinued. A return policy got updated. The answer stayed the same while reality moved on. That gap is called drift, and without a mechanism watching for it, your most trusted answers slowly go stale in public.
The structural fix is to keep checking after publication. Published answers are compared against the current material and product data again and again, and when a mismatch appears, the answer is flagged and routed back to review instead of staying live. In Klariton this is the job of Safe Guard, which watches published answers against the sources they were approved from. The tool-neutral version of the test: change one fact in the source material and see what happens to the answers built on it. If the honest response is "nothing, until someone remembers", the safety story ends on publication day.
Property 4: When there is no answer, hand over instead of guessing
Your knowledge base, the pool of reviewed answers and documents the assistant works from, will always have gaps. Nobody writes everything down in advance. What matters is what the system does when it hits one of those gaps. The wrong behavior is filling it: a fluent, confident paragraph assembled from nothing, delivered to a customer who has no way to tell the difference. The right behavior is unglamorous: say that no verified answer exists, and hand over to a human. That handover is called an escalation, and the customer's question travels with it, so it can become a reviewed answer next time.
An escalation is not a failure; it is the system doing its job. An assistant that hands over honestly turns its gaps into a to-do list for your team. An assistant that guesses turns its gaps into complaints, refunds and screenshots.
Five plain questions to ask any vendor
Governance is just the formal word for who checks what, and when. You do not need to be technical to evaluate any of it. The four properties translate into plain questions, and an evasive answer is an answer too:
Question | What a good answer looks like |
|---|---|
Where do answers come from? | Only from our reviewed material, and every answer shows its source. Not "the model is very accurate." |
Who releases an answer? | A named person approves each answer before publication. Not "you can spot-check if you like." |
Is there an audit trail, a record of every approval? | Who approved what, when, based on which source, retrievable later. Not "we log some events." |
What happens when material changes? | Affected answers are detected, flagged and re-reviewed. Not "just update the answers you remember." |
What happens with no matching source? | The assistant says so and escalates to a human. Not "the model handles edge cases well." |
Notice what is missing from this list: model names, parameter counts, benchmark scores. None of that decides whether an assistant is safe in front of customers; the structure around the model decides. A mediocre model inside this structure is safer than the newest top-tier model without it. And if you want the flip side, what those same assistants currently tell other people about your brand when you are not in the room, that field is called prompt monitoring.
Frequently asked questions
Ask your question about Klariton.
Grounded in Klariton’s own knowledge, cited rather than invented.
How visible is your brand to AI?
The free AI visibility check shows you in under a minute how AI assistants see your shop today.