AI governance for People teams

AI governance for People teams is not a forty-page policy. It is a short set of decisions, made once and written down, about what the model may never do, plus the habit that keeps those decisions attached to what the team actually ships. Most of what gets filed under governance is the document. The document is the easy part and the least useful part. It sits in a page nobody opens after the day it was written, while individuals make the real calls about what AI does in the function, alone, one prompt at a time. That gap, between the policy and the work, is the thing worth governing.

What AI governance for People teams actually is

Start with a definition you can act on, because the fuzzy ones are exactly why this work stalls.

AI governance for a People team is the set of boundaries you decide in advance, the sign-off that holds them, and the log that proves they held. Everything else is paperwork.

Here is the position most compliance-led framings would argue with: governance is not a document handed down from legal, and it is not compliance's job to author on the function's behalf. It is operating hygiene, and it belongs inside the People team, owned by someone who runs the work. The reason is simple. A model touches candidate data, grievance notes, salary bands and performance history. The person who understands what a wrong call costs there is not sitting in a risk committee. They are the ops lead who has watched one bad reference letter turn into a two-year rebuild of trust.

The second thing others would argue: the policy is the least important artefact. A team can have a beautiful forty-page document and no governance, because nobody has changed a single thing about how the work happens. And a team can have governance with almost no document, because four decisions are written on a one-pager and the workflow logs itself. If you only have time to build one, build the second. This piece is about that operating posture. For the written artefact that sits on top of it, see the AI policy blueprint for People teams.

Steer, don't brake

The instinct, especially under regulatory pressure, is to treat governance as a brake. Slow things down. Add approvals. Require sign-off on everything. The result is predictable: the work routes around the policy. People still use AI. They just stop telling you about it, and now you have shadow usage with no logging, which is the worst of both worlds. You have taken on all the risk and kept none of the visibility.

Good governance asks a different question. Where, in this function, does AI need to be in the loop? Where does it need to be only in the loop, with a human deciding? Where is the line, and who holds it? Those are steering questions. They point the work rather than stopping it, and they are answerable in an afternoon.

There is a version of this that goes wrong in the other direction, and it is just as common. A team buys tools faster than it governs them. Seventeen tools. No strategy. Every hire has a favourite assistant, every vendor demo lands a free trial, and six months later nobody can list which tools touch employee data. That is not freedom, it is an ungoverned surface, and it is more fragile than the over-braked version because you cannot even see it. Steering means the function moves fast on purpose, on a small set of approved paths, not fast by accident on a sprawl nobody mapped.

The four boundaries that matter

Four boundaries carry more weight than everything else in a People-function AI policy combined. Get these right and the rest of the document is just paperwork. Get them wrong and no amount of paperwork saves you.

Read the table down the "may never" column and you have the whole risk surface of AI in a People team. Read it down the "how you enforce it" column and you have the actual work, because a boundary you cannot enforce is a wish. Let me take each one at the level a person actually implements it.

Decisions a model never makes alone. Hiring. Termination. Performance ratings. Compensation. Reasonable adjustments and accommodations. Discipline outcomes. Six places where the consequence of a wrong call is high, the data is messy, and the bias risk is concentrated. The model can prepare, summarise, suggest, draft. It never decides. A named human does, always. Write that list of six at the top of your policy. Everything else is detail.

Data the model never sees. Health information. Disability status. Salary tied to a name. Grievance content. Anything in the GDPR special category. Anything under an NDA. This boundary is almost never enforced by trusting people not to paste. It is enforced by configuration: approved tools routing to enterprise endpoints with training switched off, workflows that strip identifiers before the model gets them, a short provider list rather than a long one. Model choice is part of this decision, not separate from it, which is why choosing AI models for HR work and drawing the data boundary are the same conversation held once per tool.

Outputs the human must always check. Anything that reaches a candidate. Anything that reaches a regulator. Anything that enters an employment record. Anything that becomes a written commitment. A model's draft becomes the deliverable only after a human has read it and signed off. That review is what makes the speedup safe, and it is cheap: reading and approving a good draft is minutes, and it is the minutes that keep you out of a tribunal.

Logging that actually exists. If the team uses AI in the work, you should be able to answer four questions in under five minutes: which workflows use a model, which model and where it runs, where the prompt and output history lives, and who is accountable for each workflow. Most teams can answer the first two instantly and fail on the third. They can name the workflow and the model, then nobody can produce a log. If you cannot, you do not have governance. You have aspirations.

What good governance looks like from inside the team

Governance shows up in the daily texture of a team long before anyone rereads a policy doc, and the two versions are easy to tell apart once you know what to look at. The theatre version is loud on paper and invisible in the work. The real version is quiet on paper and visible everywhere in the work.

The single sheet matters more than it sounds. It is usually a one-pager, not a deck: every AI workflow the team runs, its owner, its model, the data it touches, and whether it is in pilot, live or retired. It is maintained by the people who run the workflows, which is the only way it stays true. A central register that a coordinator updates once a quarter is already wrong by week two.

The review matters as much. Monthly or quarterly, short, and deliberately dull. Owners walk through what their workflow did, what it nearly got wrong, and what they are changing. New workflows get added, old ones retired. The near-miss culture is the part that takes longest to build and pays the most. The first time someone says "I almost let the model send that" and gets thanked rather than investigated, the system starts to actually work, because now the failures surface while they are still near-misses instead of after they have become incidents.

The five-minute test: do you actually have governance?

Here is how you find out where you stand without a consultant and without a review cycle. Time yourself against these. If you can answer all of them cold, in five minutes, from memory or from one sheet, you have governance. If you stall on any of them, that stall is your diagnosis, and it tells you exactly what to build first.

This test is deliberately harder than reading your policy back. A policy tells you what you intended. The four questions tell you what is true. When an external audit or a tribunal comes, they do not ask to see your intentions. They ask you to produce the log, name the owner, and explain the decision, which is why the same four questions are the ones worth rehearsing now. If you want a structured version that scores the whole function rather than one workflow, the Readiness Assessment runs the diagnostic across four capability layers in about ten minutes.

The trade you are making

Governance done well is a small tax on speed in exchange for a large reduction in tail risk. Inside a People function that trade is almost always worth taking, and the reason is what is at stake. The risk here is not mainly cash. It is trust. A People team that loses the company's trust because the model said something it should not have, or saw something it should not have, spends years rebuilding it, and no efficiency gain from AI is worth that.

There is a second cost people miss. Ungoverned AI does not just risk a bad output. It quietly makes the function unauditable, and unauditable is a state you cannot exit cheaply. The team that logs from day one can answer a data-subject request, a works-council question or a regulator in an afternoon. The team that did not spends weeks reconstructing what happened, if it can reconstruct it at all. That reconstruction cost is invisible right up until the day you need it, at which point it is the only cost that matters.

The teams that move fastest with AI are not the ones that governed least. They are the ones that decided early, in writing, what they would never let the model do, and then stopped worrying about the rest. The boundary is what lets you go fast. When the six decisions and the data lines are settled, everyone knows where the edges are, so nobody has to pause and check on every prompt. Governance, done right, is what removes the hesitation. This is the same logic that keeps AI pilots from stalling at production: a pilot proves a model can do a task, and governance is part of proving the organisation can absorb the consequences.

The first move

You do not need a policy project to start. You need four boundaries on one page. Write down the six decisions the model never makes alone. Write down the data it never sees. Write down the outputs a human always checks. Write down the four logging questions and make sure you can answer them. That fits on a single sheet, it takes an afternoon, and it is more governance than most functions have after a quarter of committee time.

Do that this week. Then build the review that keeps it attached to the work, and put one named person in charge of the hygiene. That is the whole operating posture, and everything in the AI workspace for People Ops pillar sits more safely on top of it once it is in place. The document can come later. The boundaries cannot.