AI Policy for Employees: Rules That People Actually Follow

Most AI policies are written by legal or compliance teams, for legal or compliance purposes. They are long, formal, and full of conditions nobody reads past the first page. An AI policy for employees should be different: practical, plain English, aimed at helping someone make a better decision in the moment, not a document they sign once and forget. Get the format right and the policy actually changes behaviour. Get it wrong and you have a filed PDF that satisfies an audit checkbox and nothing else. The difference between the two isn't legal sophistication, it's whether the person reading it on a Tuesday afternoon can actually use it. Here is how to write the version that works.

Start with the three daily decisions

Most employees face the same three questions whenever AI comes up at work: can I use this tool, can I put this data into it, and do I need to tell someone I used AI for this. A policy that answers all three clearly, without jargon, gets followed. One that does not gets ignored, or worse, quietly worked around. Name the approved tools directly and link to them; do not write 'check with IT', because 'check with IT' means nobody checks. Make the data rule concrete: 'don't paste client names or email addresses into any AI tool' works; 'don't process personal data inappropriately' does not, because nobody agrees on what counts as inappropriate under deadline pressure. The ICO's guidance on AI and data protection is a useful sanity check for what actually counts as personal data. Make the disclosure rule specific to context too, rather than leaving it to individual judgement, which produces wildly inconsistent answers across a team.

Length: one to two pages, not ten

There is an inverse relationship between policy length and how often it gets followed. A one-page policy someone can read in under three minutes gets followed more reliably than a ten-page policy trying to cover every edge case, because the ten-page version does not get read past page two. Push the edge cases into a short FAQ document or a named contact people can ask, and keep the main policy to the rules that apply to almost everyone, almost every time. The goal is a document whose main points someone can repeat back a week later without looking it up. A remembered rule gets applied in the moment it is needed; a forgotten one, however carefully drafted, does not exist in practice.

Plain English over legalese

Write in the second person: 'you must', 'you can', not the passive, third-person voice most policy documents default to. Use short sentences. Skip defined terms unless they are actually load-bearing. If legal wants definitions and liability clauses, put those in an appendix and keep the main body readable by someone who is not a lawyer, because that is who has to follow it at 4pm on a Friday. Compare two versions of the same rule: 'Employees shall ensure that all processing activities involving AI systems are conducted in accordance with applicable data protection legislation,' against 'Don't paste customer data into an AI tool unless it's on the approved list.' Both say the same thing. Only one of them will actually change what someone does under deadline pressure. Write the second version, every time.

Does the policy need to be different for different departments?

Not a different policy, no, but different examples help. A 60-person accountancy firm found its one-size-fits-all policy technically covered everyone but landed oddly: the client-data rule that mattered enormously to the audit team barely applied to marketing, who instead needed guidance on AI-generated copy and disclosure the policy did not mention at all. The firm kept a single core policy but added a short, department-specific examples box, three or four scenarios each, for audit, tax and marketing. Same rules, no exceptions, no divergence in what is allowed, just examples that actually matched what each team ran into. That is the right level of customisation: one policy, one set of rules, tailored illustrations. A genuinely separate policy per department multiplies the maintenance burden and invites the teams' rules to quietly drift apart.

What happens if an employee ignores the policy?

Treat it like any other workplace policy violation, proportionate to what happened. Pasting a client's email address into an unapproved tool by mistake is a conversation and a reminder, not a disciplinary hearing. Repeated, deliberate use of unapproved tools with sensitive data after a documented warning is a different matter, and the policy should say plainly that repeated violations are taken seriously, without needing to enumerate every possible sanction. What matters most in practice is that the rule was clear and the person had actually acknowledged reading it, that is what an attestation record gives you, evidence the person knew the rule existed before they broke it, rather than a dispute about what they were supposed to know.

Make acknowledgement easy and automatic

Send the policy to every employee with a one-click acceptance mechanism, not a request to reply-all confirming receipt. Set an automatic reminder for anyone who has not acknowledged it within two weeks. When the policy changes materially, a new tool approved, a new data rule added, trigger re-attestation rather than assuming people will notice a quiet update to a shared drive document. This does not need to be a bespoke workflow built in-house. ModelCharter's policy generator handles generation, distribution and attestation in one place: set it up in a morning, and re-attestation on policy changes runs automatically after that, with a dated record for each employee you can produce on request rather than reconstruct from an email inbox.

Keep it current

Review the policy at least annually, and sooner if you approve a significant new tool or a regulation changes. The EU AI Act's Article 4 duty, in force since February 2025, expects organisations to ensure staff have a sufficient level of AI literacy; a policy that is two years out of date is weak evidence of that, however good it looked when it was written. See our guide to employee AI training requirements for what 'sufficient' actually means in practice. Treat the review as a fifteen-minute task tied to a calendar reminder, not a project: check whether the approved-tools list still matches what people actually use, whether any new regulation applies, and whether last year's examples still make sense. A policy that hasn't changed in two years despite three new tools being approved in that time isn't stable, it's stale, and staff will notice the gap before an auditor does.

Write it once, keep it alive

A policy people can recite beats a policy that is technically comprehensive. Start from the three daily decisions, keep it to a page or two, write it in plain English, and make acknowledging it a one-click action rather than an email nobody replies to. If you are starting from a blank page, see how to write an AI usage policy for the full walkthrough, and for the values statement that sits above the rules, our guide to writing a code of conduct for AI.