Writing an Internal AI Policy People Follow

Nearly every internal AI policy fails in the same way: it is correct, comprehensive, and impossible to apply at the moment somebody is standing in front of a text box with a document in their clipboard. Followability is a property of individual sentences, and it is testable.

The test each rule has to pass

Three conditions. A rule that fails any of them will be ignored — not out of defiance, but because it cannot be used at the moment of decision.

• 1. Decidable in ten seconds, alone. The reader must be able to apply it to the thing in front of them without asking anyone, looking anything up, or making a judgement about “sensitivity” in the abstract. If applying the rule requires a conversation, the rule is a process, and processes are skipped under deadline.
• 2. Checkable afterwards. Somebody must be able to tell whether the rule was followed. Not to punish anyone — because a rule nobody can check is a rule nobody can improve, and you will never learn which of your rules are wrong.
• 3. It has an exit. Every rule needs a named place to go when it does not fit the situation, with a response time. Without one, the first genuinely awkward case teaches everyone that the policy is advisory.

Run the test over your existing draft before writing anything new. Most drafts lose half their sentences, and the half that survives is the policy.

Six rules, rewritten

The left column is what these clauses usually say. The right column is the same intent, made decidable.

Two things happened in each rewrite. A category judgement was replaced by a list the reader can look at, and a universal was replaced by a scope. The last row is the exception to the ten-second rule and is worth the cost: it is an enumerated list rather than a principle precisely because the stakes make a judgement call unacceptable, and because those categories are where an explanation may be legally required.

The classification it rests on

Every workable rule above points at a data classification. If you have one, use it and change nothing. If you do not, make one with three tiers — not seven, because a scheme people cannot recall is a scheme they will not apply.

PUBLIC       already outside the company, or could be
             -> any tool

INTERNAL     ours, not secret, no personal data
             -> approved tools only

RESTRICTED   personal data, customer data, credentials,
             anything under a confidentiality obligation,
             anything special-category
             -> approved tools only, and only where the
                data-flow page for that use case says so

The single most useful sentence you can add is a worked example under each tier drawn from the reader’s own work: a specific document type per tier, named. Abstract tiers get argued about; a named example settles ninety per cent of the cases without anybody asking.

Note that the Restricted tier does not say “never”. A blanket prohibition on restricted data is the rule most likely to be quietly broken, because it forbids things the company has already approved elsewhere — a vendor with a signed data processing agreement and an approved data flow is a legitimate destination for exactly the data that flow describes.

The one page

AI USE — ONE PAGE

WHAT THIS COVERS   Any tool that sends text, code, images or audio
                   to a model. Including tools inside products you
                   already use.

APPROVED TOOLS     <list, with a link>  Updated within 5 working
                   days of a request in #ai-help.

DATA               PUBLIC     any tool
                   INTERNAL   approved tools only
                   RESTRICTED approved tools, approved use cases

NEVER              Credentials, keys, or anything from the
                   Restricted list into an unapproved tool.
                   Granting an app access to your mailbox, drive,
                   chat or repositories without a review.

BEFORE IT LEAVES   Read anything customer-facing in full. You are
                   the author; the output is a draft.

DECISIONS          A model output is never the sole basis for
                   <the enumerated list>.

WHEN IN DOUBT      #ai-help. Answer within 2 working days. Asking
                   is never the wrong move.

WHY                <three sentences: the contract obligations we
                   have, the retention question, and the fact that
                   a fluent answer can be wrong>

One page, and the WHY block at the bottom rather than the top. People read the rules and skip the preamble, but they read the reasoning when they disagree with a rule — which is exactly when you want it available. If your policy runs past one page, the extra pages belong in the longer policy document with the reasoning behind each rule, and this page stays the thing people are actually asked to follow.

Exceptions, and what they mean

The exceptions process is not an administrative afterthought; it is the mechanism that keeps the policy true. Three rules make it work.

• A response time, published. Two working days for a simple tool question, longer for anything that needs a data-flow review. A process with no clock is a process people route around.
• The same exception twice is a policy bug. If two teams need the same carve-out, the rule was wrong. Amend it rather than granting a third exception, and date the amendment.
• Exceptions expire. Six months, then re-asked. This is what stops the policy becoming a historical document with a parallel reality of standing carve-outs nobody remembers granting.

Finally, publish the change log. A policy that visibly changed three times in a year because people pointed out problems is one people believe is maintained — and belief that the rules are maintained is what makes asking, rather than guessing, the default behaviour.