What Should You Decide Before an LLM Replies to a Customer?

Customer service pages used to sit still. A support rep wrote a help article, a lawyer reviewed it, and the page answered the same question the same way for two years. If a shopper wanted something specific, they filled out a form and waited for a human. Slow, yes, but auditable. Somebody wrote the answer, somebody approved it, and nobody was inventing a return window on the fly.

Now a language model sits on that same page, writing fresh sentences for every visitor. Speed is the obvious win. The change that gets less attention is that nobody reads most of those sentences before they ship. Sooner or later the model produces a confident wrong answer, and the customer, along with a growing number of tribunals, treats that answer as something the business said.

What Does a Confident Wrong Answer Actually Cost?

Air Canada already lost this argument. A grieving passenger asked the airline's chatbot about bereavement fares, the bot described a refund process that did not exist, and the Civil Resolution Tribunal held the airline responsible for what its chatbot said. The airline tried to argue the chatbot was a separate entity. That defense did not survive the negligent misrepresentation standard, which asks whether the seller took reasonable care that its representations were accurate.

The reputational hit lands before the legal one. Trust in AI support is thin, and a single bad interaction tends to close the door for good. If the first wrong answer a customer sees is also their last interaction with the brand, the model has cost more than it saved.

What Is the Model Allowed to Answer in the First Place?

Scope is the first decision, and most teams skip it. The instinct is to deploy a general assistant and let it handle whatever walks in. The safer design is narrower: a list of question types the model is permitted to answer, and a default refusal for everything else.

Decide which categories are in bounds before you write a single prompt. Order status, shipping windows, product specifications already published on the site. Decide which categories route to a human: anything involving a price not already listed, a legal commitment, a medical or financial recommendation, a refund decision outside the published policy, or anything a regulator cares about. DEV.co's guide to the predictable ways an LLM feature fails on a client site is a useful walkthrough of where the scoping conversation usually breaks down.

The hardest part of scope is holding it. Product teams will push for more capability every quarter. Each expansion is a new failure mode, and each one deserves its own review.

Where Should the Answers Actually Come From?

A model asked to recall facts from its training will confabulate. A model asked to summarize a specific document you handed it will mostly stay honest. That is the case for retrieval: the model answers from a passage your system pulled from a source you control, not from memory.

Grounding takes real work. Someone has to decide which documents are canonical, keep them current, and version them so you can prove what the model saw on a given day. A few habits that pay for themselves quickly:

• A single source of truth per topic. The returns policy lives in one place. If two documents disagree, the model will cheerfully quote the wrong one.
• Freshness checks. Stale policy pages are the most common source of a technically-grounded wrong answer. Tie document review to a calendar, not to someone noticing.
• Citations in the response. When the bot answers, it should show the customer which document it drew from. That gives your support team a thread to pull on when something looks off.
• A refusal path. If retrieval returns nothing relevant, the model should say so and hand off, not improvise.

The OWASP project maintains a Top 10 list of risks specific to language model applications, and misinformation sits alongside prompt injection and improper output handling for a reason. These failure modes compound. A model vulnerable to injection will happily be talked out of its grounding.

What Should Never Reach the Page?

Output guardrails are the layer between the model and the customer. They are unglamorous, and they are what saves you from the headline. Treat the model's draft the way you would treat anything a user typed into a form: untrusted.

• Hard filters on commitments. Any response that contains a dollar amount, a refund promise, a delivery guarantee, or a legal term should be blocked or routed through a template with pre-approved language.
• Policy and classifier checks. A second model, or a rules layer, reads the draft and decides whether it violates a published policy, invents a product, or contradicts the retrieved source.
• Confidence thresholds. When the model's own signals or the retrieval score are weak, the response gets suppressed in favor of a handoff.
• Clear disclosure and an exit. Customers should know they are talking to AI and should usually have a visible way to reach a person. That is both an ethical baseline and a trust lever.

The teams that get this right settle the hard questions before launch: what the model is allowed to say, where its answers come from, and what gets blocked on the way out. The teams that skip those decisions end up making them anyway, in public, after a screenshot goes around.