An enterprise AI guardrail checklist

1. Write every rule as a refusal

Not always be on-brand but never publish a hex outside the token sheet. Not be accurate but never state a price that does not trace to the authority file. The difference is not tone. A refusal is testable. You can hand the system a request it must decline and watch what happens, and the acceptance test for every install I ship includes questions where the correct answer is a refusal, because proving a system declines cleanly is harder and more useful than proving it produces.

2. Move the rule from the document into the pipeline

A reminder depends on a person remembering it. A gate does not get tired, does not skim, and does not decide the deadline justifies an exception. So the house style becomes a regular expression with a non-zero exit behind it, and the banned terms become a list the build refuses to ship. The migration is the work: every time a rule fails in prose, it graduates to code.

3. Make the gate answer with an exit code, not an opinion

An agent reporting that it checked something is not a signal. A deterministic scan exiting non-zero is. One client system runs a 381-line pre-delivery scanner that codifies their entire output checklist: banned terms, name rules, phone formats, style. A checklist a person runs is a checklist a person skips on a Friday. An exit code has no Fridays.

4. Keep a scrub list for what must never ship

Confidential names, deal detail, people, credentials, internal addresses: a literal list of terms, checked against every output file before anything publishes. This site runs one, because it publishes rebuilt versions of confidential systems, and a careful copy-paste is not a control. The useful discipline is the response to a hit: if a term fires, the fix is to say less, not to loosen the term.

5. Widen the scope until nothing is exempt

This site's scrub gate was wrong twice, and both faults had the same shape: the gate read a narrower thing than the output. It scanned only HTML while a forbidden term shipped inside a CSS comment. It stripped script blocks before checking, which exempted the riskiest content on the site. Both times it reported clean, and I believed it, because I wrote it. The fix was not patching the two known holes. It was widening the scope until there was nowhere left to hide: every text file, read raw, before anything is stripped.

6. Negative-test every control before trusting it

The most dangerous state a safeguard can be in is not absent. It is present, broken, and reporting clean, because an absent control at least leaves you appropriately nervous. So every gate gets the same ritual before it is trusted: plant a violation, run the build, and watch it die. Then remove the plant and watch it pass. A control nobody has watched fail is a belief, not a control.

7. Verify in a different head than the one that produced the work

Both of the scrub gate's faults were found by an independent audit, not by me. That is the argument for adversarial verification in one sentence: I wrote the gate, I believed it worked, and I was the last person who was ever going to discover otherwise. In my systems the rule is literal: verifiers run in fresh contexts, never shown the worker's reasoning, because a model shown its own reasoning nods along with it. The finder's enthusiasm and the judge's skepticism have to live in different heads.

8. Give every refusal an escape hatch

A system that refuses without a path forward trains people to route around it. So a refusal names the rule that fired and the way through: if the claim is real, add its source to the facts layer with sign-off, and the system will use it everywhere it fits. The refusal becomes a to-do instead of a wall, and the guardrail earns tolerance instead of resentment.

9. Reserve hard failure for what is never acceptable

Errors stop the line. Warnings print and ship. The split is deliberate and it is the difference between a gate and an alarm fatigue machine: a gate that fails builds over things which are actually fine is a gate people learn to override, and the next time it fires on something real they will override that too. Scope every control to exactly what it protects, and keep the fatal category small enough that nobody ever argues with it.

Why any of this matters

Adoption is a trust problem. People stop using a system the first time it confidently does something wrong, and they do not come back. Guardrails are not there to constrain the AI. They exist so a human can send the output without re-checking everything, which is the entire value of having the system. In the Company OS these controls carry a collective name, the Gates, and they are built in as a component rather than added as a review step. The checklist above is how that trust gets built mechanically, one gate at a time, each one tested by watching it fail.