How to Write HR Policies Using AI That Employees Actually Read

Why AI policy drafts read badly

AI policy drafts read badly because the model is copying the wrong genre. Decades of published HR policy were written to defend an employer in a dispute, not to explain a rule to a person. Ask for a policy and you get that voice back, amplified.

You can see it in the first line. Here is the same rule, written twice.

The second version carries the same rule and the same limit. It just explains the why, which is the part that stops the clarification emails. Getting there is not a matter of asking nicely. It is a matter of telling the tool which genre you want before it starts, and that is what the gates are for.

Most people operations leads will tell you the real cost of an unreadable policy is not legal exposure at all — it is the standing queue of “does this apply to me?” messages, and the managers who invent their own answer rather than ask. A policy that nobody finishes reading is a policy that gets enforced inconsistently, which is the exact risk the legalese was supposed to prevent.

How to write HR policies using AI

The short version: how to write HR policies using AI is a four-stage sequence, not a single request. Guard your account, ground the draft in your real facts, grade the language down to something readable, then gate it behind a named human reviewer. Each stage fixes a failure the previous one cannot.

1. Guard — set up the right account before any internal text goes near a chat box.
2. Ground — give the tool your company facts, your non-negotiables, and your real edge cases.
3. Grade — cut the draft down to plain English and strip the threat language.
4. Gate — run an assumption audit, then hand it to a named reviewer before publish.

The sequence matters more than the individual prompts. Ground before you Guard and you have already pasted your headcount into the wrong account. Grade before you Ground and you have polished a draft that describes a company you do not work at.

Gate 1: Lock down your account

Before any internal text goes into a chat box, work out which account you are typing into. This is the one stage where getting it wrong cannot be undone by a better prompt, and it is the stage almost every guide skips. Once a paragraph containing a real salary band has been sent, no amount of deleting the chat afterwards puts it back.

Here is the rule that matters, and it is not the one most people assume. The line is not free versus paid — it is personal account versus work account. A personal subscription is still a personal account. Paying twenty dollars a month buys you more capacity, not a different data posture.

Business and enterprise workspaces sit on the other side of that line by contract. OpenAI’s enterprise privacy documentation states plainly that data from its business products is not used to train models by default, and Anthropic draws the same boundary between its consumer plans and its commercial terms. If your organisation has a work account, use it and stop reading this section.

If it does not, you have two moves: turn model training off in your own settings, and strip the document before it goes anywhere. Both, not either. The same reasoning runs through our guides on whether ChatGPT is safe to use at work and Claude’s workplace privacy settings.

One more thing worth knowing if you sit inside Microsoft 365: a work Copilot account can see documents you already have permission to open, and your administrators can see rather more than most staff assume. Our breakdown of what Copilot can see and who can see you covers the tenant boundary properly.

Gate 2: Give it your real context

Grounding is where a generic draft becomes yours. The tool needs four things before it writes anything: who you are, who the policy covers, the rules you will not soften, and the format you want back. Everything else is decoration.

The difference this makes is not subtle. Compare what comes back from a topic versus what comes back from a briefing.

Those four layers are the Logic System wearing HR clothes, and the middle two are where most drafts fail. If the context layers are new to you, our guide on giving AI context that makes output specific unpacks them properly. SHRM’s prompting guide for HR policy creation lands in the same place from the professional-body side.

You are an HR communications specialist writing for employees, not for a courtroom.

COMPANY FACTS
- Organisation: [industry], [headcount] people across [locations].
- This policy covers: [permanent staff / all workers / a named team].
- This policy does NOT cover: [contractors, interns, or whoever is excluded].

THE POLICY
- Topic: [e.g. hybrid and remote working].
- Non-negotiable rules I already enforce: [rule 1], [rule 2], [rule 3].
- Real situations we have argued about before: [edge case 1], [edge case 2].

WRITE IT LIKE THIS
- Sections: Purpose, Who it covers, The rules, Exceptions and how to request one, What happens if something goes wrong, Who to ask.
- Around [700] words total. Short paragraphs. Active voice.
- Explain the reason behind each rule in one sentence.
- Do not cite any law, statute, or regulation. If a rule normally depends on local law, write [CHECK WITH LEGAL] instead of naming the law.

Gate 3: Cut it to plain English

Grading is a separate pass, and it has to be. Ask for a grounded draft and readable language in one breath and you get a draft that is neither. Write first, then cut. This is the stage where how to write HR policies using AI stops resembling any other drafting task — you are deliberately degrading the register of a document that most of your profession has spent a career elevating.

The instruction that does the heavy lifting is a reading level plus a banned-word list. Naming a target reading age gives the tool a measurable objective instead of a vague adjective, and banning specific constructions stops the boilerplate creeping back in on the rewrite. It is the same technique as using negative constraints in your prompts — telling it what not to do is often sharper than telling it what to do.

Rewrite the policy below so a new starter could read it once and know what to do.

RULES FOR THE REWRITE
- Target reading age: 13 to 14.
- Active voice throughout. Second person ("you"), not "the employee".
- Ban these words and constructions entirely: shall, herein, aforementioned, pursuant to, is prohibited from, up to and including termination.
- Replace every threat with a consequence written calmly and factually.
- Keep every rule and every limit exactly as it is. Change the language, never the substance.
- Any sentence over 25 words gets split.

Then list, separately, anything you softened so I can check I still agree with it.

[paste the draft here]

That last line is the one people leave out. A rewrite pass will quietly blur a rule to make it sound friendlier, and you want a list of what moved rather than a diff you have to hunt for yourself.

If your tool offers a side-by-side editing panel, this is the pass where it earns its keep — you can watch a paragraph change rather than scrolling through a fresh copy of the whole document each time. Working across several existing documents at once is a related job, covered in our guide to synthesising multiple documents into one brief.

Gate 4: The human legal review

Gate 4 is not optional and it is not a formality. An AI-drafted policy is a draft until a qualified human has read it and put their name to it. Your organisation carries the legal liability either way, and no amount of prompt craft transfers that.

The failure mode to watch for is confident invention. A model predicting text will produce a statute number that looks exactly like a statute number, because statute numbers have a shape and shapes are what it learned. Our explainer on why AI hallucinates and how to stop trusting the wrong outputs covers the mechanism; here is the practical guard.

Audit the policy below before it goes to review. Do not rewrite it.

Return four lists:
1. LEGAL CLAIMS — every sentence that asserts a legal requirement, entitlement, or protection.
2. NUMBERS AND DEADLINES — every figure, notice period, or timeframe stated.
3. ASSUMPTIONS — anything the text takes for granted about how we operate that I never told you.
4. GAPS — situations a manager could plausibly face that this policy does not answer.

For each item, quote the exact sentence. Do not judge whether it is right.

[paste the policy here]

Turning a policy into manager tools

A published policy is not the finish line. Most of the confusion that lands back in your inbox comes from managers who cannot find the relevant rule at the moment they need it, so build the tools while the document is still in front of you and the context is still loaded in the chat.

This is the part that separates a one-off drafting exercise from a system. The same grounded source document can produce three or four downstream assets in the same sitting, and they will stay consistent with each other precisely because they came from one place.

Managers need a decision aid, not a copy of the policy in smaller type. Ask for the rules they enforce daily, the escalation path, and the line where it stops being theirs.

Turn the approved policy below into a one-page manager quick reference.

Include, in this order:
1. The five rules managers enforce day to day, one line each.
2. What to do when someone asks for an exception — the exact steps and who decides.
3. Three sentences a manager should say, and three they should not.
4. The point where this stops being a manager decision and comes to HR.

Keep it under 350 words. Use short headings and bullets, no paragraphs.

[paste the approved policy here]

The rollout email decides whether anyone opens the policy at all. Lead with what changes for the reader, not with the fact that a policy has been updated.

Write a short internal email announcing this policy to all staff.

- Open with what actually changes for the reader, in one sentence.
- Then three bullets: what stays the same, what is new, what you need to do.
- No more than 150 words before the link to the full policy.
- Warm and matter-of-fact. No corporate throat-clearing, no "we are pleased to announce".
- End with where to ask questions and who owns the policy.

[paste the approved policy here]

The four prompts above are worth more together than separately. Save them once with your company facts already filled in and the next policy takes a fraction of the time. Our guides on writing internal announcement emails and handling unapproved AI tools at work pair well with this one, particularly if the policy you are drafting is the AI acceptable-use policy itself.

When AI policy drafting goes wrong

Five failures account for nearly everything that goes wrong here, and each has a specific cause rather than a general one. The fix is almost always a missing input, not a smarter tool.

Two of those are worth verifying rather than trusting: any number and any claim about entitlement. Our walkthrough on fact-checking AI output before you put your name on it is the checking routine to run before the document leaves your desk.

What AI still cannot do here

Honesty is the whole reason this method has four gates rather than one prompt. There are parts of policy work that no tool touches, and pretending otherwise is how HR teams get into trouble.

There is also a question worth answering before someone else asks it: will people know AI helped write this? Increasingly, yes — and it matters less than you think, provided the document is accurate, readable, and reviewed. What damages trust is not the tool. It is a policy that reads like nobody involved had met the people it applies to.

Start with one policy that is genuinely overdue rather than the whole handbook. Run it through all four gates, keep the prompts you end up with, and the second one will take you an afternoon instead of a fortnight. That is the whole of how to write HR policies using AI: the tool handles the blank page and the register, and you handle everything that carries consequences.