Drafting an AI policy: a framework you can use today

Most AI policy documents we see are legal essays: ten pages on liability and risk classification, written to reassure a lawyer and ignored by everyone who has to work with it daily. This is not an essay. It is a framework you can fill in today and put on the wall tomorrow.

We wrote earlier about what an AI policy is and why short beats complete. This piece is the fill-in exercise that goes with it.

Why most policy documents never get read

A policy document written with a lawyer is written to cover every scenario. That makes it complete and makes it unreadable for the person who should use it: the employee wondering whether they can paste a customer question into a language model.

A policy that works answers three questions and no more. What is allowed, what is not, and who you tell when in doubt. Everything above that is theory nobody reads at the moment it matters, which is right before someone types something into a tool.

Checking off a checklist. Four blocks, each half a day of work.

The framework in four blocks

Fill this in for your own company. Each block is half a day of work, not a project.

Block 1: what is allowed without asking. Name the tools you already permit and for what. This is usually shorter than expected: a language model for draft text, a tool for summarising your own documents. Be specific about what may not go in: customer data, personnel files, financial figures not yet public.

Block 2: what always needs consultation. Anything touching a decision about a person belongs here. Assessing a candidate, preparing a performance review, justifying a dismissal. This is also exactly where the AI Act weighs heaviest, see Annex III.

Block 3: what is never allowed. Short and hard. Emotion recognition in the workplace, untargeted collection of biometric data, and for most companies: putting customer data into a free, public tool whose data handling you do not know.

Block 4: who to call when in doubt. One name, no committee. An employee who doubts and has nowhere to turn decides on their own, and that is exactly where it goes wrong.

Writing something down. One name to call in doubt, not a committee.

Why this is not optional

An AI policy feels like something for companies that want to "do things properly", but there is a hard obligation underneath. Article 4 of the AI Act requires you to demonstrably support AI literacy, and a policy is exactly the document that shows it. Without a policy you have no basis to show what is and is not allowed, and therefore no basis to demonstrate Article 4.

That does not mean the policy should be built around the law. It means a good policy happens to do two things at once: it stops someone pasting customer data into the wrong tool, and it is exactly the piece of evidence a regulator would ask for. You do not need to build separately for it.

A filled-in example

To make this less abstract, a filled-in example for a fictional company of a hundred and twenty people in services.

What is allowed without asking: a language model for draft text and internal notes, a tool for summarising your own non-confidential documents. Never customer names, contract amounts or personnel data in there.

What always needs consultation: any output directly affecting a decision about a candidate, employee or customer. A draft email to a customer may get AI help; the decision to reject a quote may not.

What is never allowed: facial recognition for anything other than access security with explicit consent, and using free, public AI tools for anything containing customer or personnel data.

Who to call: the HR manager, with a named substitute for when they are on holiday. Review date: every quarter, tied to the team meeting.

That is the complete policy. No sub-clauses, no appendices.

Writing something down. One name to call in doubt, not a committee.

Four mistakes that make a policy useless

The policy was written before it was discussed. A policy imposed top-down without input from the people who have to use it misses exactly the situations that come up in practice. Discuss the draft with three people who work with it daily before finalising it.

It only lives on a shared drive. A document nobody stumbles across exists in theory and not in practice. Print it, put it up, or turn it into a tile on the intranet everyone sees.

It names no concrete examples. "Use AI responsibly" is not a rule, it is a wish. "Never paste a customer name into a public chatbot" is a rule. Specific beats general.

There is no owner. A policy with nobody responsible for review ages silently. Assign one name, not a department.

A template you fill in today

The last row is skipped most often and matters just as much as the first five. A policy with no review date is, in a year, a document about tools nobody uses anymore.

Where the line between block 1 and block 2 often goes wrong

The hardest part is not writing the blocks, it is the line between what needs no consultation and what a human must see. Two rules of thumb help.

Does the output affect a person in a decision, or only text? A draft email is text. A score weighing whether someone gets hired is a decision. That second category always belongs in block 2, even if a human makes the final call, because the advice itself already colours that choice.

Is the output legible to whoever uses it? A summary of a document you can check yourself against the original. A risk score coming out of a model with no explanation you cannot check, which means a human has to know what did and did not weigh into that score before it gets used.

When in doubt, push it to block 2. An extra consultation costs a quarter of an hour. A wrong decision nobody saw costs much more.

Why short beats complete

A two-page policy gets read. A twenty-page policy gets flipped through once and never opened again. The entire value of a policy sits in what people do when nobody is watching, and that is decided by what they remember, not by what is written down somewhere.

This is the same reason we argue in AI literacy for a quarter-hour every quarter on a real case, instead of an annual course. Policy and training work on the same principle: short, repeated and concrete beats complete and one-off.

What to do with this

Turn this framework into half an A4 page, print it, and put it up where people work. Not in a folder on a shared drive nobody opens.

Discuss it once with the team, with real examples from your own company. Review it every quarter with the same people already maintaining the AI literacy habit, because that is exactly the same meeting.

About this page

This framework is our own approach, based on what we see working in projects at companies of fifty to three hundred and fifty people. It is not legal advice and not a substitute for a lawyer in complex situations. This is the state of play on 18 August 2026.