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:
The assistant may only answer from material you have reviewed, and every published answer shows where it came from. No source, no answer.
Nothing is published automatically. A human approves every answer before a customer can see it, and that approval is recorded.
Published answers are re-checked against your material and product data over time. When the facts move on, the answer gets flagged instead of quietly going stale.
When no reviewed answer exists, the assistant admits it and hands the question to a human instead of guessing in front of the customer.
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 BIQ 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 SafeGuard, 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
Can prompt engineering alone prevent hallucinations?
No. Prompt engineering means writing better instructions for the model, and a good instruction does lower how often answers get invented. But an instruction is a request, not a technical limit, and you cannot verify a promise after the fact. Real prevention sits in the setup around the model: answers bound to your own sources, a human who approves before publication, ongoing checks against the current material, and an honest handover to a person when no reviewed answer exists.
Does a human review gate slow everything down?
Less than it sounds. The questions customers ask most change slowly, so the bulk of the review work happens once, when the first batch of answers is approved. After that, review means looking at new answers and flagged changes. For most small teams that is a few minutes per week in one sitting, not a daily chore.
What should happen when my source material changes?
The system should notice, not you. Published answers need to be checked against the current material and product data on an ongoing basis. When something no longer matches, the answer gets flagged for review instead of staying live and quietly going wrong. If a tool cannot do this, every update to your material is a silent risk.
Is it bad for the customer experience when the assistant says it does not know?
The opposite. A confident wrong answer costs trust and sometimes money. An honest handover tells the customer their question was understood, is taken seriously and will be answered by a person. As a side effect, your team gets a list of exactly the questions your approved material is still missing.
Klariton is built around exactly these four properties: answers bound to their sources (BIQs), a human review gate, SafeGuard drift checks and honest escalation. The free AI visibility check, a quick look at how AI assistants currently see your brand, is a no-setup way to start.