Nobody at your company decided to adopt AI in HR. It arrived as a product update.
Rippling, HiBob and every serious HRIS shipped assistants and agents into platforms you already pay for. Your ATS added ranking. Your meeting tool added notetaking. None of it went through a vendor review, because none of it was a new vendor. “We don’t use AI in HR” stopped being true the day those features launched, and the honest version of the sentence is now “we haven’t inventoried what’s on.”
Three things changed at once, and the third is the one that bites.
- Capability arrived by default. Features enabled themselves, or a well-meaning admin switched them on during a slow Tuesday.
- Regulators got specific. California, Illinois, Colorado, New York City and the EU now ask about notice, human review, testing and records rather than intentions.
- Diligence started asking. “List the AI systems touching employee data, and show your controls” is now a standard data-room request.
At 25 to 250 people this is two weeks of work rather than a program. What happens if you skip it is rarely a fine. It is being unable to answer a simple question in front of someone who matters.
Permissions are the whole ballgame
A general-purpose chatbot is easy to govern: do not paste employee data into it. Embedded HRIS AI is harder, and more useful, because it needs no pasting. It already holds the data, and it enforces your existing permission model at the data layer.
That sounds reassuring until you remember how permission models get built. They accrete over years, get cloned from whoever joined last, and are never tested. A manager who could technically pull a report showing peer salaries probably never did, because it took eleven clicks and they did not know it existed. Now it takes one sentence, and the answer is fluent, confident and instant.
AI did not create the exposure. It removed the friction that was hiding it.
So the first governance task is not writing a policy. It is auditing who can see what, field by field and role by role. Two rules follow. Audit before enabling any embedded AI feature, using real accounts rather than admin accounts, because admins see everything and testing as one proves nothing. Then re-test quarterly and after every reorg, because permission drift is silent and org changes are what cause it.
The four decisions
Make these and the policy writes itself. Skip them and you get a document nobody follows.
1. Allowlist or guardrails? An allowlist is a named register of approved tools where everything else is unapproved. It is enforceable and it produces the artifact diligence asks for. Guardrails (“use good judgment with sensitive data”) are unenforceable and produce nothing. We recommend the allowlist at every size, because the register is the deliverable.
2. Where is the line on people data? A four-class scheme works: public, internal, confidential people data, restricted. General-purpose tools get the first two. Confidential people data stays in the systems that already hold it. Restricted material, meaning health, leave, immigration and investigations, needs a written exception or nothing.
3. What does human review actually mean? Not a signature. The standard worth adopting has three parts: the reviewer understands the output, genuinely reviews it rather than rubber-stamping, and holds authority to override. This mirrors California’s automated-decisionmaking standard and is worth adopting even if you do not employ there, because it also describes a decision you would be willing to defend.
4. Who owns it, by name? Usually the Head of People, with a named security contact and named counsel. Below 100 employees that is often one internal person plus fractional counsel, which is fine. What matters is that the names are real, the owner can suspend a tool unilaterally, and decisions get written down.
What you have to be able to produce
Every regulator and diligence team asks the same question in the end: show me. Six artifacts answer it.
| Artifact | The question it answers |
|---|---|
| AI register | What AI touches your employee data? Every tool and embedded feature, its scope, its owner, when it was last reviewed |
| Vendor file | What are your vendors contractually allowed to do with it? DPA, no-training clause, SOC 2 or ISO, subprocessors, any bias testing they have done |
| Notice records | Did you tell candidates and employees? Proving notice after the fact is impossible, so capture it as you go |
| Decision log | How was this decision made? Tool, output, named reviewer, whether they overrode it, outcome |
| Testing and audit | How do you know it is not doing harm? Permission-audit results, and bias testing of anything decision-adjacent, coordinated with counsel |
| Enablement log | What was running in March? Which features were switched on or off, by whom, and when, including the ones you deliberately left off |
Four years is a sensible retention floor for all of these except contracts, which you keep longer. Confirm against your own jurisdictions with counsel, and revisit annually rather than assuming today’s dates still hold.
Thirty days, then enforcement
Every company adopting an AI policy already has shadow AI. The only question is whether you find out during an amnesty or during an incident. So the first month is an inventory exercise, and enforcement starts the day after it ends.
- Week 1, amnesty opens. Anyone using an AI tool with company data discloses it. No fault, no consequence, explicitly including tools bought on a personal card.
- Weeks 1 to 2, inventory. Disclosures, plus an audit of AI features already switched on in existing systems. This is where the surprises live.
- Weeks 2 to 3, permission audit. Before enabling anything further, test what real accounts can actually see.
- Weeks 3 to 4, resolve and publish. Each disclosed tool is approved with a scope, replaced, or discontinued with a date. Policy adopted, one-pager circulated, training booked.
- Day 31, enforcement begins.
The five failure modes
The unread policy. Written for lawyers, filed in a wiki. Fix: a one-page version in plain words, circulated separately.
The fictional register. Populated once at adoption, never updated, silently wrong within a quarter. Fix: name an owner and a review cadence inside the document itself.
The standing exception. A temporary carve-out that never ends. Fix: time-box every exception. A permanent one is a policy change, so make the change.
The silent feature launch. A vendor ships new AI capability and it is live before anyone notices. Fix: new features start unapproved by default.
Punishing the reporter. Someone pastes the wrong thing into the wrong tool, panics, and says nothing for six weeks. Fix: make reporting explicitly consequence-free, say so in the one-pager, and mean it the first time it is tested.
Govern the permission model, keep the six records, and let people use the tools. That is the whole program.
Start with the permission audit rather than the policy. If you want the audit run against your own HRIS before its AI is switched on, book a 20-minute call.
This is practitioner guidance rather than legal advice, and the policy language itself should go through your counsel.
Download this guide
Take the whole thing with you.
The whole guide as one PDF you can send to your team. We email it over.
One email, with the PDF attached. Nothing else.
Common questions
We don't use AI in HR — does this apply to us?
Almost certainly yes. Nobody decided to adopt AI in HR; it arrived as a product update. Rippling, HiBob and every serious HRIS shipped assistants into platforms you already pay for, and your ATS and meeting tools added ranking and notetaking. None of it went through a vendor review because none of it was a new vendor. The honest version of the sentence is usually "we haven't inventoried what's on."
Where do we start?
An inventory, not enforcement. A 30-day amnesty gets you an honest picture of what is actually switched on and who is using it — which is the input to every decision that follows. A policy written before the inventory governs a company you are guessing about.
What do we have to be able to show a regulator or an acquirer?
Six records: an AI register, a vendor file, notice records, a decision log, testing and audit results, and an enablement log covering what you switched on and when. Four years is a sensible retention floor for all but contracts, which you keep longer. A policy that cannot produce records is a memo.