Guardrails

What guardrails are

Guardrails are fixed rules around an AI system that constrain its output. The term comes from road construction and the metaphor fits: the point is not to set direction and destination but to catch a mistake before it does damage. A language model cannot guarantee a rule, because it produces probabilities. The guarantee therefore has to sit outside the model.

Where the rules apply

• Input check: Whether the request is answered at all. Topics outside the purpose are declined instead of forcing an answer.
• Data filter: Which content may enter the context. Confidential data does not belong in a request to an external service.
• Response check: After the answer, whether it breaks rules, such as forbidden commitments, prices from unreliable sources or statements that amount to legal advice.
• Action limit: What the system may do itself. The most important point, because real damage happens here.

The action limit is decisive

The difference between a system that answers and one that acts is larger than any difference in answer quality. A chatbot announcing an order instead of placing it causes confusion. A system that changes prices, cancels orders or issues refunds on request can cause damage in minutes that costs weeks to clean up.

The usual tiering is therefore: reading always allowed, suggestions always allowed, execution only after human confirmation, and automatic execution only for actions that can be undone. Anyone separating those four levels cleanly has already handled the largest risk.

How rules become effective

The most common mistake is a rulebook on paper. A rule not enforced in the system is a recommendation. The second mistake is a rule that only applies at the end, meaning after the output. Anyone not constraining the input receives answers on topics outside the purpose and has to intercept them afterwards.

The third mistake is missing logging. For every blocked output it should be visible which request was made and which rule took effect. Without that log it cannot be determined whether the rules prevent the right thing or merely something by accident. A look at the most frequent triggers also shows where the prompt or the data source needs improvement.

A fallback belongs alongside. If the service fails or does not respond in reasonable time, the system must move into a safe state, meaning a generic answer or a handover to customer service, instead of waiting. Usability and safety are not in conflict here, because an honest fallback answer beats an invented one.