Guardrails and Safety Filtering roadmap

The controls that sit around a model to catch what it shouldn't accept and what it shouldn't emit. Useful, cheap, and routinely asked to do a job they cannot do.

Deep dive6 stages98 topics

All roadmaps
0 of 98 done
Essential, don't skip Recommended, skip only with a reason Optional, awareness is enough Course on PracticAI

Six sections, and section 1 is the load-bearing one. Guardrails are classifiers, classifiers are evadable, and a determined attacker gets through. They reduce accident rate and add defence in depth. They are not a security boundary - that's capability restriction, which lives in the AI security roadmap.

1

What Guardrails Are For

The framing that prevents the most common mistake: asking a filter to be a security boundary.

              2

              Input Controls

                          3

                          Output Controls

                                      4

                                      Implementation

                                                  5

                                                  Evasion and Limits

                                                          6

                                                          Measuring

                                                          Most teams collect the catch rate and never the false-positive rate, which is how guardrails quietly ruin products.

                                                                  Adding a guardrail well

                                                                  Every guardrail costs latency, money and some rate of wrongly blocked legitimate use. Earn each one.

                                                                  1. Name the specific harm. Not "unsafe output" - a concrete failure with a concrete consequence you have actually seen or can reasonably expect.
                                                                  2. Check whether design solves it instead. Restricting a tool, requiring approval, or narrowing scope removes the risk rather than filtering for it.
                                                                  3. Try the cheapest mechanism first. Schema validation, a regex, a blocklist. Reach for a classifier only when structure can't express the rule.
                                                                  4. Measure both error rates. How often it catches the harm, and how often it blocks legitimate use. The second number is the one teams never collect.
                                                                  5. Decide the failure behaviour. Block, warn, log, or route to review. Silent blocking produces a confusing product and no diagnostic signal.
                                                                  6. Make it observable. Every trigger logged with the input, so you can see whether it's working or just annoying people.
                                                                  7. Re-test after every model change. A guardrail tuned to one model's output distribution drifts when the model does.

                                                                  An over-blocking guardrail is a real product failure, not a safe default. Users route around a tool they can't rely on.

                                                                  Guardrails move the failure rate; they don't set it to zero. Design the system so that what gets through is survivable, and treat the filter as the second line rather than the first.