What are guardrails in AI?
Your support bot quotes a refund policy you retired last year, and nothing in the system was watching the answer on its way out.
Guardrails
Guardrails are checks that run around a language model rather than inside it. One set inspects the request before the model sees it. Another inspects the reply before a person does, then allows it, blocks it, or rewrites it to fit a policy.
There are two halves, and teams usually build only the first. Input guardrails read the request, strip personal data, refuse off-topic questions, and catch attempts to talk the model out of its instructions.
Output guardrails read the reply. Is it about our product? Does it quote a real document? Did it promise a discount nobody authorised? That second half is where the money is, because a bad answer only costs you once it has been shown to somebody.
The model is not the part you control
You cannot patch a model. When a reply goes wrong, there is no line of code to fix, and the same prompt may behave differently tomorrow. Guardrails give you somewhere to put the rule.
That somewhere is ordinary software. A check that a cited document id exists is a database lookup. A check that no bank detail appears in an answer is a pattern match. Both are testable, and both keep working when the model version changes underneath you.
- 01Prompt rules bend under pressure. Code outside the model does not.
- 02A blocked answer can be logged, counted and reviewed next week.
- 03Swapping model providers leaves your checks intact, because they never lived in the prompt.
- RequestArrives from a person.
- Input checkStrip, refuse or allow.
- ModelThe part you cannot inspect.
- Output checkVerify before anyone reads it.
- DeliverOr block, and log why.
Only the last station decides what a customer actually sees. Teams that build the first three ship the risk anyway.
Related questions
01Do guardrails stop prompt injection?
They raise the cost of it without closing it. An input filter catches the obvious attempts, but instructions can arrive inside a document, a web page or a support ticket the model was asked to read. The durable defence is to limit what the system is allowed to do, so a successful injection reaches nothing valuable.
02Should guardrails be a model or plain code?
Use plain code wherever the rule can be written down. Checking an amount against your database is exact, fast and free. Keep a second model for judgement calls, such as whether an answer stayed on topic. That classifier has its own error rate, so it is a check that needs checking.
03How strict should a guardrail be?
Strict enough that the failures you block outnumber the good answers you lose. Every filter has a false-positive rate, and a system that refuses ordinary questions gets abandoned by staff who then work around it. Measure both sides before tightening a rule.
