Guardrails for a customer-facing chatbot

Written By: BrainSoft In AI & Research

A chatbot that answers customer questions looks easy until it goes live. Then someone asks it about a competitor, someone else pastes a prompt injection, and a third person gets a confident answer about a refund policy that does not exist. The model is not the problem. The missing layer around it is.

Guardrails are checks placed before, during and after the model call: validate the input, restrict what the model can see, filter what it returns, and log everything. Below is the order we build them in for a customer-facing bot, from cheapest control to most involved.

1. Start with a fixed system prompt and a narrow job. The bot gets one role and one scope, written down and versioned in the repo. If it handles order status and returns, it does not discuss pricing negotiations or legal questions. Keep the prompt short enough that you can read it in a review.

   You answer questions about orders and returns only.
   If a request falls outside that, reply that a human will follow up
   and set escalate=true. Never invent policy details.

2. Screen the input before it reaches the model. Check length, strip control characters, and block obvious injection patterns. This will not stop a determined attacker, but it removes noise and keeps token costs predictable.

   if len(text) > 2000 or has_control_chars(text):
       return refuse("message_too_long")
   if INJECTION_RE.search(text):
       return refuse("blocked_input")

3. Scope retrieval to the customer's own data. If the bot uses a knowledge base or order lookup, filter by tenant and customer id at the query level, not in the prompt. A model told not to reveal other customers' orders is still a model that can be talked into it.

   docs = index.search(query, filter={"customer_id": user.id}, k=5)

4. Constrain the output shape. Ask the model for JSON with known fields instead of free text. Parsing a schema is a real check; reading prose and hoping is not. When parsing fails, fall back to a canned response rather than showing raw model output.

   {"answer": "string", "sources": ["string"], "escalate": false}

5. Run an output filter. Reject responses that contain PII patterns, competitor names or links outside an allowlist. Also check that every claim about policy cites a retrieved source. If the source list is empty and the answer states a policy, drop it.
6. Add a human handoff path. Escalation has to be a first-class outcome, not an error case. The bot should be able to say it does not know and open a ticket. Track how often that happens; it is the best signal you have for gaps in the knowledge base.
7. Log prompts, outputs and filter decisions. Store the request id, the retrieved document ids, the model version and which guardrail fired. Without this you cannot debug a complaint from three days ago, and you cannot tell whether a rule is doing anything useful.
8. Write an eval set and run it on every change. Twenty to fifty real questions with expected behaviour is enough to start. Include injection attempts and out-of-scope questions. Run the set before deploying a prompt change, same as you would run tests before a code change. If you want help setting this up alongside your deployment pipeline, our services cover both.

What these guardrails do not fix

None of this makes the model correct. A scoped, filtered, logged bot can still give a wrong answer from a stale knowledge base article. The guardrails limit the blast radius and make the failure visible; they do not remove the need to keep the source content accurate and to review transcripts regularly.

Frequently asked questions

#AI & Research