Guardrails the risk team can sign

A guardrail is a check, outside the model's own judgement, that inspects something entering or leaving the model and decides what happens next. Production systems use several, placed at different points: input rails on what the user sends (abuse, self-harm, injection attempts, personal data), retrieval rails on what evidence enters the context (untrusted sources, injected instructions), tool-call rails on what the agent tries to do (allow-listed tools, valid arguments, gated writes), output rails on what the user receives (groundedness, scope, leaked identifiers, unsafe advice), and dialogue rails that keep a conversation on its permitted topics. Each check is either deterministic (regex, schema, allow-list), a trained classifier (Llama Guard-style models, cloud content-safety APIs) or a model judge, and each has an action, not just a verdict. Guardrails are models too: they have false positives that frustrate users and false negatives that reach them, they cost latency and money, and they must be evaluated per language. The risk team wants to see the whole design on one page, with test results.

Key takeaways:

• Put deterministic controls first and strongest: tool allow-lists, schemas and parameter limits beat any classifier.
• Every guardrail needs an action and a user experience, not just a flag.
• Run independent checks in parallel; put cheap checks before expensive ones only when they can short-circuit.
• Evaluate guardrails with labelled data, per slice. Vendor accuracy claims do not transfer to your users.
• Guardrails reduce risk; they do not prove safety. Pair them with red-teaming and monitoring.