An AI policy blueprint for People teams

An AI policy for People teams works when it is short, specific, and written from the inside of the work: one page that names the approved tools, names the forbidden uses by category, says where AI use gets logged, and carries a named owner and a review date. Everything else is decoration. The long, defensive, principle-heavy document that most functions publish is not a policy. It is a liability blanket, and the team stops reading it the day after it ships.

I have watched the expensive version of this play out more than once. A People function, nervous about the EU AI Act and a candidate complaint, commissions a fourteen-page policy. Legal writes most of it. It lists values, cites regulation, and forbids "the unauthorised use of generative AI tools." It goes into a Notion page. Onboarding links to it. And then nothing. The recruiters keep pasting candidate summaries into ChatGPT because the approved tool is slower. The HRBP keeps drafting a sensitive exit note in Claude on her personal login. The risk the policy was meant to remove did not go away. It went dark. Legal now believes the problem is handled, which is worse than knowing it is not, because the real exposure, someone's performance review sitting in a consumer chatbot's history, is still happening and is now invisible.

That is the failure this blueprint is built to avoid. It is the document layer. The behavioural layer underneath, the four boundaries the team actually has to live with, sits in AI governance for People teams. This piece is about the artifact: how to write one that enables instead of strangles, and survives contact with Monday morning.

Why most AI policies fail on day two

The failure is almost never a missing clause. It is the posture. A policy written to protect the organisation from its own people reads like a threat, and people treat threats the way they always have: they comply on paper and route around it in practice. The policy that works starts from the opposite assumption, which is that your team has real work to do and will use whatever tool gets it done fastest. Your job is to make the safe path the fast path.

Two things separate the policies that hold from the ones that get ignored. The first is who wrote it. If Legal drafts it alone, it describes a workflow that does not exist, because Legal does not sit in the recruiting queue or the ER caseload. The second is length. A policy you can read in ninety seconds gets read. A policy that opens with a page of principles gets skimmed to the "can I use it" line and closed.

The test I use is simple. Ask the team when anyone last opened the policy on purpose, not because onboarding forced them to. If nobody can answer, you do not have a policy. You have a document. The rest of this blueprint is how to build the first thing rather than the second.

What to sort out before you draft a word

Most bad policies are bad because someone started writing before they understood the ground. Do four things first. They take a fortnight, not a quarter, and they are the difference between a policy that fits your function and a template you found online with your logo on it.

The one people skip is the last. If the approved tool is slower, uglier, or worse than the free consumer version the team already knows, you have not written a policy, you have written an invitation to ignore it. The approved path has to actually compete on the thing people care about, which is getting the work done. This is the same logic as setting up your AI workspace: the workspace and the policy are one decision, not two.

Score the tool before you approve it

Tool approval is where policies leak. A vendor demo looks fine, someone says yes, and six months later you discover the tool was training on every prompt your recruiters typed. Run every candidate through the same small matrix before it goes on the approved list. This is genuinely tabular, so treat it as a grid, not a paragraph.

A tool that clears this table can go on the page by name. A tool that does not gets a fast, honest "no, and here is why," which is far better for trust than a vague ban. Tools like n8n sit on the green side of every row here: SOC 2 and ISO 27001 compliant, self-hostable so the data never leaves your tenancy, and roughly £20 per builder seat per month, which is what an enterprise-grade tool that competes with the consumer alternative actually looks like. Name the ones that pass. The naming is the enablement.

The one-page AI policy for People teams

Now write the thing. The whole policy is a set of decisions, not principles. If a line does not tell someone what they can or cannot do on Monday, cut it. Here is the minimum viable version, and I mean minimum: if you cannot fit it on a page, the team will not read it, and a policy nobody reads governs nobody.

The forbidden line deserves care, because it is the one clause that genuinely matters. The hard boundary is any consequential decision about an individual without a human in the loop: hiring, termination, performance ratings, compensation, discipline, reasonable adjustments. The model can draft, summarise and suggest on all of them. It never gets the final call. A named human does, every time, and the log proves it. Everything else, the drafting and the research and the summarising, you can be generous with, because that is where the hours actually get reclaimed.

Alongside the page, two supporting artifacts do real work. A short data protection impact assessment, covering purpose, lawful basis, the risks to individuals and the mitigations, who has access and how data is deleted. And a transparency note to staff: how their data might touch an AI tool, and a clear statement that no automated system makes a consequential call about them without human review. That transparency is not a compliance tax. It is part of the trust contract, and it is cheap to give.

Shadow AI is design feedback, not the enemy

Every honest policy has to reckon with shadow AI, because it is already happening in your function right now. In survey after survey, most employees admit to using AI tools their employer never approved. The figure people quote is around 71%. Pretending otherwise is the fastest way to write a policy that fails on day one.

The posture that works: assume it is happening, find out what is being used and why, and treat that as design feedback for your approved offering. Every unapproved tool in use is a vote against your current approval process. That is uncomfortable, and it is also the most useful signal you have.

So do the opposite of banning. Run an anonymous survey: which tools are you using, approved or not, what for, and what stopped you using an approved alternative. Offer a fast-track approval path with a two-week SLA and a default-yes for low-risk drafting and research. When you do forbid a specific tool, the very next line names the approved alternative and how to get it. And never punish disclosure, because the person who tells you they used a shadow tool is doing your risk assessment for you. Reprimand them and the next person stays silent. You can find the shadow workflows the same way you find any hidden work, with the automation audit playbook: follow the manual steps and the personal logins, not the org chart.

Do you actually need a DPIA

Short answer, in the UK and EU: almost certainly yes for any People process running AI on personal data, and unambiguously yes for anything that resembles automated decision-making. In the US it varies by state and by sector, and the ground is still moving.

The smarter framing ignores the jurisdiction question. Run a DPIA-equivalent regardless of where you sit, because the exercise itself forces the right design conversations. Working through purpose, lawful basis, the risks to individuals and the honest assessment of whether the approved tools actually meet the need surfaces the problems while they are still cheap to fix, before the tool is live and before a complaint makes them expensive. A DPIA you run because the law demands it is a form. A DPIA you run because it makes you design better is an asset.

Keep it alive, or it is already dead

A policy is not a document. It is a system, and systems that are not maintained rot. The version that stays useful has four moving parts, and none of them is heavy.

• A quarterly review by the working group. Tools change, vendors change, regulation changes, your team changes. A quarter is about the longest a policy stays true.
• Monthly metrics. Adoption, incidents, exceptions raised, tools requested, tools approved or rejected. The exceptions and the requests are the interesting numbers, because they tell you where the policy is fighting the work.
• A public log. One internal page listing currently approved tools, currently forbidden uses, recent additions and removals. Visible to the whole company. The log is what turns the policy from a rule into a live service.
• A named owner. One person accountable for the policy, usually the Head of People Ops or a dedicated AI lead inside the function. Without an owner, every part above quietly stops happening.

The through-line of the whole blueprint is this: the policy is only ever as good as the habit around it. That habit is what separates a governed function from one that merely wrote something down. If you want to see how the artifact fits the wider operating picture, it lives under the AI workspace for People Ops, and before you draft a line it is worth knowing where your function actually stands, which is what the Readiness Assessment is for.