House Rules for AI That Can Only Ever Tighten

Every company that writes an internal AI policy writes the same document. It runs to four pages, it says be careful with confidential information, it asks people to use approved tools, and it is read once on the day it is circulated and never again.

The problem is not that the advice is wrong. It is that a policy which lives in a document has no connection to anything that actually runs, so nothing changes on the day it is published.

A rule is worth more than a policy, and a rule has to attach to something.

Rules that attach

The version that works looks less like a document and more like a line item: when an automation does X, it must have Y.

When it touches client data, a named person must own it. When it acts without a human in the loop, it needs an audit log. When it sends anything to someone outside the company, there must be a way to stop it inside a minute. When it goes anywhere near payroll or HR records, two people sign off rather than one.

Each of those is checkable. You can look at any given automation and say yes or no, which is exactly what you cannot do with "staff should exercise appropriate judgement when using AI tools".

Policy Studio, inside abi. Governance, is where those rules live against the register rather than in a document: add a rule, and every agent it applies to picks up the requirement.

The rule about rules: they can only tighten

This is the constraint worth copying whether or not you use any tool at all.

Your own rules should only ever be able to make the standard stricter. Raise how seriously something is treated, add a control, require something your industry expects. They must never be able to lower a bar or remove a requirement.

The reason is a failure mode that shows up in every permissions system ever built. Once an exception can be granted, exceptions get granted, usually under deadline pressure by someone senior enough that nobody argues. Six months later the baseline is decorative, because half the estate sits under an exemption that made sense on a Tuesday in March and has never been revisited.

If tightening is the only available direction, the worst case is that you are stricter than you needed to be. That is an annoyance. The other failure mode is a Friday afternoon nobody enjoys.

Simulate before you publish

The mistake that follows a good rule is publishing it against everything at once.

A rule saying "anything touching client data needs a named owner" sounds unarguable, until it lands on eighty automations and sixty of them have no owner, and now sixty things are failing a check on a dashboard on a Monday morning. What happens next is not sixty owners being assigned. What happens is that people learn to ignore the dashboard, and the rule has actively made things worse.

So before a rule goes live, run it across what you already have and count what it would catch. If the answer is four things, publish it and fix them this week. If the answer is sixty, you have not found a rule, you have found a project, and it needs staging: apply it to new automations from today, and work the backlog on a schedule somebody has agreed to.

Being able to see the blast radius before publishing is the difference between a rule that changes behaviour and a rule that trains people to ignore alerts.

Publish it, then leave it alone

Once a rule is published it should be fixed. If you need it to say something different, retire it and publish a new one, so the history shows what was required at the time.

That sounds bureaucratic for a company of fifteen people and it takes about ten seconds in practice. The value shows up exactly once, when somebody asks what your standard was in March, and you can answer without reconstructing it from memory and a chat thread.

Start with three rules. Not fifteen. Three that you can enforce, attached to things that actually run, applied to new work from today. That is more governance than most companies your size have, and unlike the four-page document, it will still be true next year.