How to write and enforce AI guardrails
A guardrail is a governance decision made executable. How to get from policy intent to rules that act on live traffic, what belongs in a guardrail versus a policy document and why the enforcement record matters as much as the enforcement.
How do you write AI guardrails that actually get enforced?
Start from the risks you have already assessed rather than from a blank page, because a guardrail is a control made executable and controls should follow from findings. Write each guardrail as a specific, testable rule about traffic or actions, covering what may not go into a model, what may not come out and what an agent may not do. Keep the policy document for intent and the guardrail for the rule, since "staff must not share personal information with AI tools" is policy while "detect and redact Australian PII in prompts to these systems" is a guardrail. Then put the rules where the traffic is, at a gateway or enforcement point in the request path, version what is deployed so you can say what was enforced when, and keep the record of every intervention, because a control you can show firing is worth ten you can only describe.
Most organisations that have done any AI governance own a policy that says what people must not do with AI. Almost none of them own anything that stops it happening. The distance between those two states is the distance between a document and a guardrail, and closing it is less about technology than about writing rules that can be enforced at all.
What a guardrail is
A guardrail is a governance decision made executable, meaning a specific rule about AI traffic or agent actions, applied at request time. What may not go into a model, meaning personal information, credentials, client data or material outside a system’s approved purpose. What may not come out, meaning content that fails your standards for the context it ships into. What an agent may not do, meaning tools it may not call and actions beyond its approved scope.
The test of whether something is a guardrail is whether a machine could apply it to a single request. “Staff must exercise care with confidential information” fails the test and belongs in the policy. “Detect and redact Australian PII in prompts to these three systems” passes. Both have a job, and confusing the two is how organisations end up with policies that pretend to be controls.
Start from assessed risk, not a blank page
The tempting way to write guardrails is to brainstorm everything that could go wrong and block it all. The result is a wall that teaches people to route around it, and a rule set with no connection to any finding, which makes every rule equally arguable. The better path runs through work you have already done. Each risk assessment finding that calls for a control is a candidate guardrail, scoped to the systems the finding concerns. The connection matters twice over. It keeps the rules specific enough to live with, and when someone asks why a rule exists, the answer is an assessment rather than an opinion.
Write each rule with its scope, its action and its owner, naming which systems and agents it applies to, whether it blocks, redacts, constrains or flags for review, and who answers for it. A guardrail without an owner is a rule nobody will defend when it inconveniences someone senior.
Enforcement lives where the traffic is
A rule enforced nowhere is a policy with better formatting. Enforcement means the request path, so a gateway or enforcement point that AI traffic passes through, where the rule can act on each request as it happens. If your organisation already routes AI traffic through a gateway, the right move is usually to compile your rules to the enforcement points you have rather than adding another. What matters is that the deployed rules are versioned and attributable, so at any later date you can say which rules were enforced on which systems, in which versions, when. An unversioned enforcement point enforces whatever it enforces, and you will not be able to prove what that was.
Agent guardrails deserve their own attention, because for a system that acts, the consequential rule is not about words but about actions, meaning which tools the agent may call, what scope its actions may have and what happens when it exceeds them. The guide on governing AI agents covers the wider practice.
The record is half the value
Every intervention should leave a record of what fired, on which system, under which rule and version, and when. Partly this is operational, because firing patterns tell you which rules are working, which are too broad and where unmet demand is pooling. Mostly it is evidentiary. The difference between a control that exists on paper and a control with a record of operating is the difference between asserting your governance and demonstrating it, and everyone who ever assesses your organisation knows which one they are looking at.
Where Aicura fits
Aicura runs this whole arc. Suggested guardrails are drawn from your assessments, so the rules follow from findings. Rules are authored as guardrail sets against your registered systems and agents, compiled into signed bundles and enforced through Aicura’s AI gateway or your own, with input and output scanning and agent runtime constraints applied in the request path. Every intervention is recorded as an enforcement event against the system it concerned, and the deployed bundles are versioned, so what was enforced when is always answerable. Authoring starts at Essentials and runtime enforcement is part of Pro.
Aicura provides guidance, not legal advice, and does not certify, audit or issue a compliance verdict. Which rules to run and how strict to be are decisions your accountable owners make with the risk picture in front of them.
Common questions
Are guardrails the same as an acceptable use policy? No, and the difference is the point. A policy states intent and relies on people having read it. A guardrail is a rule enforced on traffic whether or not anyone read anything. You need both, with the policy explaining why and the guardrails carrying the rules that must hold even on a bad day.
Won’t guardrails just get in everyone’s way? Badly written ones will. The failure mode is guardrails written from fear rather than from assessed risk, blocking broadly and teaching people to route around them. Guardrails that follow from real findings, applied to the systems the findings concern, tend to be specific enough that people rarely meet them.
Where should enforcement actually happen? In the request path, at a gateway or an enforcement point the traffic already passes through. Enforcement at the edge of the conversation, in training decks and policy PDFs, is not enforcement. If you already run a gateway, compile your rules to it rather than adding another hop.
What records should enforcement produce? What fired, on which system or agent, under which rule and rule version, and when. The record is what turns a guardrail from an asserted control into a demonstrated one, and it is the first thing worth showing anyone who asks whether your controls operate.
A note on this page
This guide describes an approach to writing and enforcing guardrails, and the right rules for your organisation depend on your systems, your obligations and your risk appetite. It is general information, not legal advice, and rules that touch monitoring of staff activity should be checked against your own workplace and privacy obligations first.
Related guides
- AI controls — The wider controls picture guardrails sit inside.
- How to run an AI risk assessment
- Governing AI agents
From decision to enforcement in Aicura
Aicura suggests guardrails from your assessments, compiles rules into signed bundles, enforces them through its AI gateway or yours and records every intervention as an enforcement event. Authoring starts at Essentials and enforcement is part of Pro.