Writing a One Page AI Use Policy Your Team Will Actually Follow

Your company probably has an AI policy. Ask three colleagues what it says and you will likely get three shrugs. A one page AI use policy works because people can hold it in their heads, and a policy nobody remembers changes nothing about what happens on a Tuesday afternoon.

The trick is to build it from prohibitions rather than principles. "Use AI responsibly" is not a rule anybody can follow. "Do not paste customer data into a tool the company has not approved" is.

Why long policies fail

A twelve page document is read once, during onboarding, by someone thinking about their laptop setup. After that it lives in a folder.

Long policies also try to cover every case, which makes them vague where it matters. The more situations a sentence has to cover, the less it says about any of them.

And they age badly. Tools change every few months. A short policy can be updated in an afternoon; a long one needs a review cycle nobody schedules.

Build it from things people must not do

Four or five prohibitions, written plainly, beat two pages of guidance. People remember prohibitions because they are concrete and because breaking one is a specific act rather than a matter of judgement.

Start by asking what would actually hurt. Not theoretically, but in your business. The answers are usually about data leaving, decisions being made without a person, and output going out unchecked, so it pays to be specific about what an agent should never be allowed to email.

A policy people can recite from memory changes behaviour. A policy people have to look up does not. If your rules do not fit on one page, they are not rules yet, they are a document.

A template to adapt

Copy this, then rewrite every line for your own business. It is a starting shape, not a legal document, and anything with regulatory weight should go past your own advisers before it goes on the wall.

What this covers. Any AI tool used for company work, on any device.

The rules.

• Do not put customer data, personal data, financial records or unpublished company information into a tool that is not on the approved list.
• Do not send anything an AI tool produced to a customer, client or partner without reading it fully and taking responsibility for it.
• Do not use AI output as the reason for a decision about a named person's pay, performance or employment.
• Do not describe AI generated work as your own when accuracy matters to the reader.
• Do not turn off, bypass or shorten an approval step because the queue is long.

What you can do. Everything else. Draft, summarise, rewrite, brainstorm, explain, translate, check your own work.

The approved list. Named here, with the person who maintains it.

If you are unsure. Ask this named person. Asking is never the wrong answer.

If something goes wrong. Tell this named person the same day. Nobody is punished for reporting a mistake quickly.

That is the whole thing. One page, five prohibitions, two names.

The two lines people forget

The last two sections carry more weight than they look.

A named person to ask means the policy has an owner. Without one, edge cases get resolved by whoever is most confident, which is not a control.

A no blame reporting line means you hear about problems while they are small. If admitting a mistake is expensive, people hide it, and you find out from a customer instead.

Making it stick

Write the rules for the situations people actually meet. Test each line against a real moment: somebody pasting a spreadsheet into a chat window, somebody forwarding a generated email at five to six. The same instinct applies to the tools, which are worth testing before they touch live records.

Keep the language plain. If a sentence needs a second reading, rewrite it.

Put it where the work happens rather than in a policy library. One page in the tool people already have open beats a link in an induction pack.

Review it every few months. Note the date on the page so people can see it is current.

Where the tooling can help

A policy is easier to follow when the system supports it. If approval steps are built into the workflow rather than bolted on, the rule about not bypassing them stops being a matter of willpower. Which shape to build depends on the work, and there are approval patterns that hold up under regulation.

SicherOne works this way: a human approves agent output before it ships, and project management, HR and AI agents run on one set of records so it is clear what an agent saw when it produced something. Private models can be self hosted where the rule about data leaving your environment needs to be enforced technically rather than in writing.

Start this week

Write your five prohibitions on one page. Show it to four people who do the work and ask which line they would break first without noticing. Fix that line. Then publish it, name an owner, and put a date on it.

A short policy that people follow beats a thorough one they never read.