Why Your AI Should Never Guess Prices: The Business-Approved Knowledge Rule

Should a customer-facing AI be allowed to tell your customers prices? Yes. A system built on information your business has approved can quote your real prices instantly, consistently, and at any hour, which is precisely the kind of usefulness businesses adopt AI for. The rule that makes it work is short: the price has to come from information your business designated for that purpose, carried to the caller with its qualifiers intact. When a number would be a guess, the correct output is not a price. It is an honest sentence and a path to a person.

The good news, and the point of this article, is that this is an engineering property, not a hope. You do not have to choose between an AI that is useful and an AI that is controlled. But getting both does require understanding that customer-facing AI can fail in two different ways that look identical from the outside: it can invent an answer, and it can state a perfectly real answer it had no authority to give. Engineer against both and the system becomes something rare: fast, helpful, and disciplined at the same time. For the fundamentals of what these systems do, start with our explainer on AI receptionists; this piece goes deeper on the one rule that matters most.

Two failure classes, one lesson

A concrete illustration of the first failure class comes from early 2024, when British Columbia's Civil Resolution Tribunal, a Canadian small-claims body, decided Moffatt v. Air Canada. A traveler had asked the chatbot on the airline's website about bereavement fares, and the chatbot confidently described a retroactive refund process that the airline's actual policy did not offer. The tribunal held the company responsible for the information on its own website, chatbot included, and largely awarded the traveler's claim. The ruling itself is narrow, one decision on one set of facts in one Canadian province. Its usefulness is diagnostic: the system did not crash or misbehave dramatically. It answered fluently and wrongly, and a customer reasonably relied on the answer, because in a conversation there is no asterisk. To the customer, the distinction may be invisible. The answer came through the business's own customer-facing system.

The second failure class needs no tribunal, because it happens without anything being false. Picture a brokerage whose standard commission rate sits, correctly, in its approved information, and a caller who asks the AI assistant to knock a point off if they list this week. The system can retrieve the true rate flawlessly and still must not make that deal. Knowing a fact is not the same as holding authority over it. Invention is a model problem. Authorization is a business problem. They are engineered differently, and a system that handles both is what a trustworthy deployment looks like.

Why fluent systems guess, and why that is manageable

The invention problem is well characterized, which is exactly why it is controllable. In its Generative AI Profile, the National Institute of Standards and Technology describes confabulation: generative systems presenting erroneous content confidently, a natural byproduct of models that generate output by approximating the statistical patterns of their training data, with the risk mattering most where outputs feed consequential decisions. That description tells an engineer exactly what to do: never leave a customer-facing answer to statistical pattern alone. Give the system a defined source of truth and a defined behavior for the moments the source runs out. A known failure mode with a known control is not a reason to avoid a technology. It is a design input.

The five kinds of information your AI touches

Control gets much easier once "what the AI knows" stops being one blurry thing. In our engineering work we separate five kinds of information, and the separation does most of the work:

Model knowledge is what the underlying model absorbed in training: general language, general world. It is why the system converses naturally, and it is never an authority on your business. Even if a model has encountered information about your prices or policies, that does not make its training data an authoritative source for either.

Retrieved information is what the system looks up at answer time. Retrieval is only as authoritative as its source, which is why the source, not the model, is the design decision.

Business-approved information is the heart of the architecture: the facts your business has deliberately designated for customer communication, each with an owner and a shelf life. Your services, your published prices, your real policies. This is the authoritative source for statements the system makes in your business's name, and when it is well maintained, the system can use it with real freedom.

System-of-record information is live operational truth: the actual calendar, the actual catalog. Connecting to it is what upgrades an answer from approved-at-some-point to current-right-now, and it is what lets a system book real appointments instead of making conversation.

Human-authorization territory is everything no data source can settle: discounts, exceptions, custom quotes, judgment. The defining property of this category is that the right answer is not stored anywhere; it is decided by a person with the authority to decide it. A well-built system treats this territory as a destination, not a wall: it recognizes it, gathers what will help, and hands the moment to your team.

Knowing a price is not permission to promise it

That last category is where accurate systems still fail. Return to the brokerage: the commission rate is real, retrieved, and current, and the discount request still belongs to a person. A listed price does not authorize a system to negotiate it, discount it, extend it to a situation it was never quoted for, guarantee it against change, or assemble it into a custom quote. Each of those is a business decision wearing a number. This distinction, between what a system can know and what it may commit, is the heart of the business-approved knowledge rule, and it is a design decision. Nothing in a language model enforces it. Either the engineering draws the line, or the line does not exist.

The architecture: from your source of truth to a spoken answer

Assembled, the pipeline reads almost like common sense, which is the mark of an architecture worth having. Answers begin at a source your business controls. Retrieval is bound to that source, not to the model's general knowledge and not to the open web. Before anything is spoken, two checks run. Validation asks whether an approved, current answer exists: is it within its shelf life, and does it agree with the other approved sources? Authorization asks whether the system is permitted to say it, and with which qualifiers attached: exact price, starting-at price, or an honest explanation that this one takes a person. When both checks pass, the system answers with confidence, because it has earned it. When either fails, the system does the one thing it is always authorized to do: acknowledge honestly, capture what is useful, and escalate gracefully. Everything is logged, so the business can always see what was said in its name.

Part of this rests on published guidance, and it is worth being precise about which part. NIST's Generative AI Profile describes high-integrity information as linkable to original sources, carrying a clear chain of custody, and creating reasonable expectations about when its validity expires, which is why a two-year-old price sheet is a validation question rather than a trivia detail. The same profile lists grounding, retrieval-augmented generation, and documented business rules among suggested risk-management actions, and the framework's companion guidance on human and AI interaction emphasizes clearly defined human roles in decisions and oversight. The five-part taxonomy, the authorization gate, the escalation default, and the pricing rules themselves are Sherwood's engineering position, built on that foundation rather than prescribed by it.

One supporting observation on the escalation default: in consumer finance, the Consumer Financial Protection Bureau has documented what automated service feels like when there is no human path, including chatbots that get answers wrong and customers stuck in loops with no way to reach a person. Designing the handoff in from the start is both the safety measure and the better customer experience. Graceful escalation is not a weaker system. It is the version customers can trust, which is the version that actually gets used.

What this sounds like on a real call

Two fictional moments show the architecture earning its keep. A caller asks a dental office's system what a crown costs. The practice maintains an approved starting-at price, so the system quotes it instantly, keeps "starting at" attached, explains that the exact figure depends on the exam, and offers to book one against the real calendar. The caller got a real answer at nine at night, and the practice's pricing discipline stayed intact: both, not either.

A caller asks an auto shop's system to ballpark a transmission repair. No approved answer exists before a technician sees the vehicle, so the system says so in a human way and offers the diagnostic slot. Pressed harder, it stays warm and stays put, because the boundary is not the system's mood. It is the system's design. That caller was not turned away; he was routed to the one path that ends in a number the shop will actually stand behind.