guardrails in production

An LLM will, given the right nudge, produce something off-topic, unsafe, or malformed. Guardrails are the runtime checks wrapped around each model call that catch those cases before they reach a user — like the railings on a mountain road. They sit on the input, what we let reach the model, and the output, what we let leave it, turning a model that is mostly well-behaved into a feature that is safely well-behaved.

Input guardrails screen for prompt injection, off-topic or disallowed requests, and personal data that should not be sent. Output guardrails validate structure — does the JSON parse and match the schema? — check for toxic, off-brand, or policy-violating content, verify claims against retrieved sources, and can block or regenerate a response that fails. These checks are built from cheap classifiers, rules and regular expressions, schema validators, and sometimes a second model acting as a critic. When a check fails, the system retries, falls back to a safe canned answer, or escalates to a human.

Guardrails are essential precisely because the core model is probabilistic and can be manipulated, but they are a layer of defence, not a guarantee — classifiers miss things and clever attacks slip through. They also add latency and cost, so teams balance how much to check against how much risk a given feature carries. The goal is defence in depth: assume the model will sometimes misbehave and design the surrounding system to contain it.