A support answer went out with a precise figure in it. The figure was wrong, and nothing in the system had ever been given the number it claimed to be quoting. The answer was fluent, specific, and confident, which is exactly why nobody questioned it.
Most teams respond to that by trying to make the system more accurate. That is the right instinct and the wrong first move. Accuracy is a dial you can only push so far. What you can decide outright is what the system is never allowed to say.
A confident wrong answer costs more than no answer. The first one gets repeated. The second one gets asked about.
Two different problems
There is a difference between an answer that is a bit off and an answer that is the wrong kind of thing entirely.
A slightly-off answer is a quality problem. You improve it with better source material, clearer instructions, a stronger model. It gets better in increments and it never gets perfect.
The wrong kind of answer is a policy problem. A specific number the system has no source for. A claim about results your business has never measured. A confident recommendation in a situation where the honest response is that there is not enough information. These are not almost-right. They should never appear at all, at any quality level.
The second category is the one you can actually close, because it is a decision rather than an improvement.
Write the list before you need it
The list is short and specific to your business. For most operations it is four or five items:
- Numbers it cannot source. Prices, timelines, quantities, percentages. If the figure is not in the material the system was given, it may not appear.
- Claims about outcomes. What results a customer will get, how much they will save, how long something will take.
- Commitments. Anything that sounds like a promise on behalf of a person. Approvals, exceptions, refunds, dates.
- Confident answers to questions it has no basis for. The hardest one, because a system left to itself will always prefer answering to declining.
- Anything about a specific named person or account that was not in the request.
Writing it down beforehand matters for the same reason writing down an expected range matters. Afterwards, looking at a bad answer, there is always a reading where it was fine. Deciding in advance is what makes it a rule instead of a discussion.
The check is not a better prompt
This is where most attempts stop, and it is why they do not hold. Telling the system what to avoid is guidance, and guidance is probabilistic. It works most of the time, which for a rule means it does not work.
Naming a thing in an instruction also draws attention to it. Anyone who has written "do not mention pricing" and watched pricing appear knows the shape of this already.
What holds is a separate check between the answer and the customer, that does not ask the system to grade itself:
| Instead of | Do |
|---|---|
| "Never quote figures you cannot source" in the prompt | Scan the output for numbers, confirm each appears in the source material, fail the answer if one does not |
| "Be honest about uncertainty" | Require the answer to cite which document it came from, fail it when there is no citation |
| Trusting the system to decline | Give it an explicit decline path, and make declining a valid success rather than a failure |
The pattern is the same in all three. The check is mechanical, it runs after the answer exists, and its verdict is pass or fail rather than a score. A rule with a score attached is a preference.
Failing has to be allowed to be cheap
A check like this is only useful if the system is permitted to produce nothing. If every request must end in an answer, the check becomes a formality: someone will widen it the first week it blocks something inconvenient.
So decide what happens on a fail, and make it a real outcome rather than an error. The answer goes to a person. Or the customer gets a short honest response saying this needs a human and one is coming. Both of those are better than the confident wrong answer, and neither is a failure of the system.
The thing that makes this workable is that declining is rare when the list is specific. A well-drawn rule catches a handful of answers a week, not half of them. If it is catching half, the list is too broad, not the system too cautious.
What to take away
- Separate the answers that are a bit off from the answers that should never exist. Only the second kind can be closed with a rule.
- Write the never-say list before you need it, and keep it to the handful of things you can define precisely.
- Put a mechanical check between the answer and the customer, and make "no answer" a legitimate outcome rather than an error.
Nobody can hand you this list. It depends on what your business can defend, who your customers are, and what a wrong answer actually costs you. That part is not technical and it does not get delegated. The AI does the busywork, you still make the calls.