Term: Guardrails
~6 min read
Estimated time: ~6 min read — for the in-app brief plus opening the primary source.
What this is
Guardrails are the controls that limit unsafe, off-brand, or disallowed behavior — written rules, technical blocks, permissions, and human escalation.
Everyday example
A finance copilot can draft a commentary but cannot send a payment. A customer bot cannot invent a refund. Those limits — technical and policy — are guardrails.
Guardrails are the limits around the model — what it may see, say, and do.
- Examples: data classes, blocked topics, spend caps, tool permissions, human approval.
- They live in product settings, prompts, and process — not only in a policy PDF.
- Evals tell you whether guardrails actually hold.
- Customer-facing and HR tools need tighter rails than a private draft box.
Next action: List the three hard “must not” rules for your most visible AI tool and who enforces them.
What changes in how you lead
How decision rights, process, and ownership should change.
- Guardrails have an owner and a test, or they are decoration.
- Risk reviews the rails the same way it reviews other automated controls.
Compare related ideas
Guardrails vs System prompt
The system prompt is one written control. Guardrails are the whole set: prompt, filters, permissions, logging, and who can override.
Open System promptGuardrails vs Eval
Guardrails are what you put in place. Evals test whether those controls actually hold on real tasks.
Open EvalDeep dive
Block highly confidential data from consumer tools; provide an approved alternative.
Force a human for refunds, medical, employment, or credit decisions.
Constrain customer bots to approved knowledge only (grounding + system prompt + permission).
Agents need a kill switch and an action log. Copilots need a review step before send.
A policy PDF with no enforcement is not a guardrail.