In this guide · 7 sections
Short answer
AI guardrails are rules and filters around a chatbot that control what goes in and what comes out: allowed topics, checks for harmful or sensitive content, rules like "only quote prices from the price list", and hand-over to a human when unsure. They reduce risk but don't remove it, so test them before launch.
What AI guardrails are
A language model on its own has no idea what your business sells, what it is allowed to promise or when it should stop talking. Guardrails are the layers you add around it. Most chatbots use several at once:
| Guardrail | What it does | Example |
|---|---|---|
| System instructions | Tell the model its role, scope and tone | Only answer questions about our cleaning services |
| Grounding | Make answers come from your own documents | Answer only from the FAQ and price list provided |
| Input filter | Check what the user typed before the model sees it | Block attempts to override instructions; flag NRIC numbers |
| Output filter | Check the answer before the user sees it | Remove personal data; block harmful content |
| Hand-over rule | Pass the conversation to a person | Complaints, quotes, anything the bot is unsure about |
No single layer is enough. Instructions can be talked around, filters miss things, and grounding only works if the documents are right. Together they make bad answers much rarer.
The risks guardrails are meant to stop
IMDA's Starter Kit for Testing LLM-based Applications for Safety and Reliability, version 1.0 from January 2026, focuses on five key risks. For a customer chatbot they translate like this:
- Hallucination and inaccuracy: inventing prices, policies or opening hours. See our guide to AI hallucinations as a business risk.
- Bias in decision making: treating customers differently, mostly relevant if the bot screens or ranks people.
- Undesirable content: rude, harmful or off-brand replies.
- Data leakage: revealing personal data, internal documents or the bot's own instructions.
- Vulnerability to adversarial prompts: users tricking the bot into ignoring its rules. Our guide to prompt injection explains how this works.
OWASP's Top 10 for LLM applications covers the same ground from a security angle, including prompt injection, sensitive information disclosure and misinformation.
Guardrails for prices, promises and hand-over
For most small businesses, the most expensive chatbot mistakes are about money: a discount that doesn't exist, a wrong price, a refund promise. These rules address that directly.
Answer prices only from the price list
Instruct the bot to quote prices only when they appear in the price list document, word for word, and to say it will check otherwise.
Ban promises it can't keep
No discounts, refunds, delivery dates or exceptions unless they appear in your policies. Say so in the instructions in plain terms.
Define the allowed topics
List what the bot covers (services, hours, booking, policies) and tell it to decline anything else politely.
Set hand-over triggers
Complaints, custom quotes, legal or medical questions, angry customers and any question not covered by your documents go to a person.
Keep the bot from acting alone
If it can book, cancel or issue codes, require confirmation steps and limits. Read-only bots are much safer.
Show a short disclaimer
Tell users they are talking to an AI assistant and that a person will confirm prices and bookings.
Input and output filters
Filters are separate checks that run before or after the model. IMDA's starter kit describes input filters as checking for attempts to make the bot leak data and for unnecessary sensitive data in what users type, and output filters as checking replies for sensitive data that shouldn't be shown. It names open-source tools such as Microsoft Presidio and LLM Guard as common ways to build them.
For harmful content, vendors offer ready-made classifiers. OpenAI's moderation guide says its moderation endpoint classifies text and images for harmful content and is free to use.
Filters are good at
- Catching NRIC, phone and card numbers by pattern
- Blocking obviously harmful or abusive content
- Spotting known prompt injection phrases
- Logging what was blocked for review
Filters struggle with
- Polite but wrong answers, such as a made-up price
- Clever rewording of a blocked request
- Languages they were not tuned for
- Blocking legitimate questions (over-refusal)
Testing guardrails before launch
IMDA's kit recommends testing before going live, using both prepared test sets and red teaming, where people deliberately try to break the bot. A small business version takes an afternoon:
Pre-launch guardrail test
The language check matters. In one case study in IMDA's kit, guardrails passed in English but failed in Chinese. If your customers write in Chinese, Malay or Tamil, test in those languages too. IMDA says the kit's tests are being made available progressively on Project Moonshot, the AI Verify Foundation's open-source testing toolkit.
Do it yourself or get help?
Most chatbot platforms let you write instructions, upload documents and set hand-over rules without code. Doing the pre-launch test above, and repeating it after every content change, catches most problems. Model choice matters too; our guide to the best LLM for a customer service chatbot compares published benchmarks.
Our AI Website Assistant (S$790) is trained on your website, FAQ and documents, includes guard-rails so it only answers about your business, captures leads to your inbox and hands over to WhatsApp or email, with a usage report after the first 30 days.
Frequently asked questions
Guardrails are the rules, filters and checks wrapped around an AI model to control what it receives and what it says. They include system instructions, grounding answers in your own documents, input and output filters, topic limits and rules for handing a conversation to a person. They reduce the chance of harmful, wrong or off-topic answers.
Give it a single current price list and instruct it to quote prices only from that document, and to offer to check with a person otherwise. Forbid discounts and promises not in your policies. Anything that costs money, such as codes, bookings or refunds, should be confirmed by code or a person, not left to the model.
No. Guardrails make problems much rarer, but users can sometimes word requests to get around instructions and filters, and a polite but wrong answer can pass every filter. That is why testing before launch, monitoring conversations after launch and handing difficult questions to a person all matter alongside the guardrails.
A set of voluntary guidelines from Singapore's IMDA, version 1.0 published in January 2026, for testing applications built on large language models before launch. It covers five risks: hallucination and inaccuracy, bias in decision making, undesirable content, data leakage and vulnerability to adversarial prompts, and explains benchmark testing and red teaming.
Yes, even a simple one. Without them, a language model will answer questions outside your FAQ by guessing, may discuss competitors or invent policies, and can be tricked into ignoring its instructions. At minimum, limit topics, ground answers in your documents, refuse prices not in your price list and hand over anything it can't answer.