TL;DR
- The core decision: Write the policy for the recruiter at 4pm on a Friday, not for the general counsel who will never read it again.
- When doing nothing is the right answer: If your team uses no AI, and no vendor touches hiring or people data, you can defer for a quarter. Anything beyond that's exposed.
- What has to be true: Your policy must be short enough to be remembered, specific enough to be acted on, and explicit about what staff may do without asking.
- How the options split: Most teams choose between a law firm template, an internal security draft, and an industry body template. Each fits a different starting point.
- Decision rule: If the policy has more than ten sections and no example, it will fail in practice.
- Outcome to expect: A document that survives contact with how people actually work, and a defensible answer when a customer or board asks how AI is governed.
Friday, 4:12pm, Two Resumes Open
Priya runs talent acquisition for a 380-person SaaS company. She has a hiring manager meeting in forty minutes and two finalist CVs to summarise before it. She opens the chatbot the company pays for, pastes the first CV, asks for a structured summary against the role spec. The tool works well. It saves her an hour. She doesn't think about it, because nobody has told her to.
But her colleague Marcus in L&D is doing something different with the same tool. He is feeding in performance notes from three underperforming account managers and asking the chatbot to draft a PIP. Nobody told him that was off the table either. He found the tool, used it, and assumed it was fine.
So the policy question isn't whether AI is being used inside HR. It's being used, today, by both of them, in two directions the company has not authorised and wouldn't have authorised. The real issue isn't what the policy forbids. The real issue is what it permits, how clearly, and whether anyone working under deadline can tell.
Best tools for AI in the Workplace
Who Can Honestly Defer
Not every HR team needs to ship a policy this quarter. Some genuinely don't, and pretending otherwise wastes the reader's time.
You're genuinely fine for now if AI touches nothing in your hiring or people workflows, no vendor in your stack claims to use AI, and your team hasn't asked for access to a tool. Picture a 70-person manufacturer with an HR function of two. The applicant tracking system is a shared inbox plus a spreadsheet. Payroll goes to a bureau that has sent the same file format for years. That company is fine, and it should still write one page: what isn't in use, who checked, when. The page turns a state of affairs into a claim somebody can be held to.
You have a soft deadline if AI is in use informally by individuals, or a tool with "AI" in the name has crept into a vendor you already pay for. An ops manager drafts job adverts in a chatbot on a personal account, because the company licence has a waiting list. Meanwhile the applicant tracking vendor ships an AI-assisted shortlisting toggle in a minor release, on by default. Neither is a crisis. Both are facts you'd rather learn now than during a customer audit. You've a quarter, not a week, and the work inside it is small: write down who uses what, then switch that toggle off until somebody decides otherwise.
You have a real deadline if a customer security questionnaire asks about AI governance, your board has asked, or a regulator in your market has live rules about automated decisions in employment. The questionnaire is the sharpest, because it carries a submission date and a deal behind it. Illinois HB 3773 took effect on 1 January 2026 and requires notice when AI is used in employment decisions, so a company hiring into Chicago sits inside a live regime rather than a forthcoming one. Take local advice on what that means for you. Ship something defensible this quarter, and accept that defensible is a lower bar than complete.
You have the edge case if you operate across borders, sell into the EU, or employ anyone in Illinois. Here a single domestic template stops being thin and starts being wrong. The EU AI Act's Article 50 transparency duties took effect on 2 August 2026. The high-risk obligations bearing on employment uses were pushed out to 2 December 2027 by the Digital Omnibus, which entered into force on 27 July 2026. Much of the template material now circulating predates that shift and still asserts the older timing. Check what dates a draft claims before anything else, then take advice in each market where you employ people.
Five Questions You Are Asking at 11pm
Who owns this? The Head of People, with the CISO as a reviewer. Ownership decides vocabulary, and vocabulary decides readership. Owned by Legal alone, it's written in risk categories and nobody in HR reads it. Owned by IT alone, it's written in data classifications and misses the people risks: the candidate never told, the manager who treated a generated summary as evidence. The real test isn't the name on the cover page. It's who answers when a recruiter asks something the policy doesn't cover. If nobody does, exceptions get granted by whoever is sitting nearest.
Ban or permit by default? Permit, with named exclusions. A ban is the more comfortable decision in the room and the worse one afterwards, because it doesn't stop the use. It relocates it. Work moves to personal accounts, where you have no retention control and no way to answer a candidate who asks what became of their data. Permit-first is harder, because you have to decide things. What may go into a tool the company pays for? Get that wrong in the restrictive direction and you find out when a subject access request lands and the conversation sits in a private chat history.
What about the tools staff already use? Audit first, then decide. Four places to look, none of them the survey you were about to send: expense claims for individual subscriptions, browser extension inventories from endpoint tooling, single sign-on logs for apps nobody remembers approving, and release notes from vendors you already pay. The list runs longer than expected and is mostly benign. Skip the audit and you write a policy describing a company that doesn't exist.
How often do we review it? Every six months, and after any incident. The reason isn't that policy ages on its own. It's that the tools move underneath a document that hasn't. A vendor ships a feature. A model gets swapped. A setting flips from off to on by default, and none of that triggers a contract review or a note to HR. A document that was right when it was signed is half-right two releases later. Reviews are also when to check the examples, which rot first, because they name tools and tools get renamed.
Does one policy cover every team? No, but the core principles should be one document. Recruitment and L&D fail in different directions. A recruiter's exposure is candidate data entering a tool that keeps it, plus a decision that later needs explaining. An L&D lead's exposure is performance notes about a named employee, written for one purpose, becoming the input to a document that reads as objective. Same tool, same afternoon, two different problems. Put both sets of rules in one long document and neither team finishes it. Split them completely and an auditor gets two answers.
The Three Approaches
The law firm template. Long, defensive, organised around risk categories the legal team understands and the rest of the company doesn't. What comes back runs to dozens of pages, structured by exposure type rather than by anything anyone does on a Tuesday. It's right when you need a defensible record and the company will pay for a second piece of work: a plain-English summary staff can use. That second piece is where most of these die. A Head of People preparing for a funding round commissions the template, files it, ticks the box in the data room, and a year later a recruiter still can't say whether a CV may go into the chatbot. The document was never wrong. It never reached anybody. The tell is the contents page: if it opens with definitions, closes with review cycles, and names no task in between, it was written for the file rather than for the floor.
The internal security draft. Tight, technical, written by people who think in access controls. It tends to be short, a genuine advantage, and it tends to reuse the data classification scheme the company already has, a bigger one. Staff who know what "confidential" means don't need a second vocabulary. It's right when your security team already governs AI through tooling rather than documents, and you want the HR rules to line up with controls that exist. It fails in a recognisable way. A CISO writes a clear rule that no personal data may enter an unapproved tool. The rule is correct. It also leaves a recruiter sitting in front of an approved tool with no idea whether summarising a CV inside it is permitted. The draft answers where data may go. It rarely answers what you may do once the data is legitimately there.
The industry body template. Pre-built, peer-shaped, often free, available this week. It's right when you want something live quickly and your sector has a body that genuinely speaks for firms like yours, at your size and under your regulator. It's the fastest honest route to a document that isn't embarrassing. The failure is quiet. A template written for every member covers the common case and, in detail, none of them. A healthcare provider adopts one and finds it thorough on clinical data governance and silent on the volume recruitment that is most of what its HR team does all year. Nobody notices, because an absence doesn't announce itself, and the drafting body had no way to know which member you are. Read it once with a specific question in mind: which of my three highest-volume workflows does this document never mention?
Five Questions to Self-Assess
Does anyone outside Legal know the policy exists? Don't ask this in a meeting, because you'll get a polite yes. Message three people in HR who weren't involved in writing it and ask them to send you the link. Give it a day. If they can't find it without asking somebody, the policy is a record rather than a control, and the fix is distribution before it's redrafting. Then ask whoever did find it where they looked first.
Can a recruiter describe, without looking, what they may and may not paste into a chatbot? Test it with a live case rather than a hypothetical. Take a CV that's actually in the pipeline this week and ask what they'd do with it under deadline. Listen for hedging. "I'd probably check with someone" means the answer either isn't in the policy or can't be found under time pressure, which amounts to the same thing on a Friday. Then ask a second recruiter. Two different answers is the finding.
Does the policy give explicit examples, not just principles? Count them. Open the document, count the prohibitions, then count the worked examples, and if the first number is more than double the second you have a principles paper wearing an operations title. "Don't input personal data" loses to "Don't paste a candidate CV into a public chatbot" because the second names the thing the reader has open in another tab. Check that at least one example names a tool you actually pay for.
Is there a single named owner for AI in HR, with time on their calendar? The name is the easy part. Check the calendar instead. Is there a recurring entry? Who answered the last question anybody asked about AI use, and how long did it take them? If the honest answer is that it went to a group chat and got settled by rough consensus, you don't have an owner. You have a committee that meets by accident. Owners appointed during a reorganisation often don't know they hold the job.
Have you audited what is already in use, including personal tools? An audit that opens as an investigation returns nothing useful. Open an amnesty window instead, say plainly that nothing surfaced in it will be held against anyone, then cross-check what you're told against expense claims and extension inventories. The gap between those two lists is the interesting number. You can't govern what you've not seen, and people show you only what feels safe to show. Run the cross-check again in six months, because extension lists move.
The Frameworks People Actually Build On
The NIST AI Risk Management Framework
A voluntary US framework organised around four functions: Govern, Map, Measure, Manage. It isn't a rulebook and doesn't claim to be. It structures the question so answers compare across a company, and the functions land on real HR work: Govern is who decides, Map is what we're using and on whom, Measure is how we'd know it had gone wrong, Manage is what we then do.
It earns a place because it's the vocabulary customers and auditors already recognise. When a questionnaire asks how you govern AI, an answer in these terms lands without translation.
It falls short because it gives no off-the-shelf answer for HR. Nothing in it says whether a CV may be pasted into a chatbot. A team that adopts it without doing the translation work ends up with a process diagram and a recruiter who still doesn't know.
ISO/IEC 42001
A certifiable AI management system standard, auditable by third parties. Unlike a framework you adopt privately, this one produces an artefact somebody else has signed.
It earns a place when a customer wants proof, not description. Procurement teams know what a certificate is. They can't check what your internal policy says, and won't try. If your buyers' security reviews are run by people who audit for a living, a certificate moves the conversation from trust to evidence.
It falls short because the effort is a programme, not a project. Certification means defined roles, documented controls, internal audit, and an external assessment body. Most of that sits outside HR, so a people team naming ISO/IEC 42001 as its answer has often handed the problem to a department that never agreed to take it. A certificate doesn't tell a recruiter what to paste.
The EU AI Act Article 50 Transparency Duties
Transparency rules that took effect on 2 August 2026, requiring notice when people interact with an AI system and labelling for AI-generated content.
They earn a place because they set a floor any honest policy must clear, and the floor translates well into an instruction. "Tell the candidate" is a sentence a recruiter can act on, which is more than most governance language manages.
They fall short because transparency isn't quality. Article 50 says nothing about whether the tool is any good or what happens to the people data going in. A disclosed bad process is still a bad process. One timing trap: the high-risk obligations bearing on employment uses moved out to 2 December 2027 under the Digital Omnibus, which entered into force on 27 July 2026, so a template asserting different timing predates that change. Take local advice on which parts reach you.
A Law Firm Template
The default starting point, drafted for risk and drafted to defend. Somebody in your network has one. It arrives quickly and gives the board something approvable.
It earns a place because the language holds up under scrutiny and the structure is familiar to anyone who's read a policy before. If you hire across regimes with different rules about automated decisions, you want somebody qualified to have written the sentences.
It falls short in a way that's easy to ignore. HR won't read it. Not won't read it carefully. Won't read it. The document is organised by risk category rather than by task, so a recruiter looking for guidance about a CV has to work out which category a CV belongs to before she can find her answer, and she can't, because that categorisation is the lawyer's model rather than hers.
An Internal Security Team Draft
A tight document written by people who think in access controls and data flows. Usually short. Usually built on the classification scheme the company already uses.
It earns a place because it matches controls that exist. There's no gap between what the document says and what the tooling does, which is rarer than it sounds, and it makes the rules enforceable, not aspirational.
It falls short because it treats AI as a data problem rather than a workflow problem. Security asks where information may travel. HR needs to know what a person may do with it once it has arrived. A draft like this says candidate data may only enter approved systems, which is correct on its own terms, while leaving open whether an approved system may rank those candidates against each other. The second question is the one that produces a complaint.
An Industry Body Template
A pre-built document from a sector association or peer group, written to be adopted rather than adapted, usually free.
It earns a place because it lands fast and carries peer credibility, which counts for more in a board conversation than it should. Saying a document follows the shape your sector uses answers a question that "we wrote it ourselves" does not.
It falls short because it covers the common case and quietly skips yours. The gaps aren't marked. A retailer running seasonal volume hiring adopts one and gets thorough coverage of employee monitoring, which its association's larger members care about, plus nothing about the automated sifting it runs twice a year. You won't discover which paragraphs are missing until something goes wrong in the space where they should have been. Read it against your own highest-volume workflow before anybody signs it.
The Decision Table
| Situation | Scale | Setup | Primary Pain | Recommended Starting Point |
|---|---|---|---|---|
| Customer security questionnaire asking about AI | Under 500 staff | No policy, some AI in use | Defensive posture, no record | Law firm template, then plain-English summary |
| Board asked for an AI policy | 500 to 2,000 staff | Ad hoc AI use across HR and ops | Cross-team consistency | Industry body template, then customise |
| Operates in the EU or hires in Illinois | Any | Partial policy, vendor use | Regulatory exposure | Law firm template plus local legal review |
| Lean team, no incidents, some informal AI | Under 200 staff | Personal tools in use | Visibility, not compliance | Internal security draft, two pages, named owner |
| AI already in vendor stack, no internal use | Over 1,000 staff | Vendor-managed AI, unclear scope | Audit trail, customer asks | Industry body template, vendor clauses reviewed |
| HR team pushing for clearer rules | Under 1,000 staff | Policy exists, nobody reads it | Practical adoption | Rewrite as workflow rules with examples |
| Cross-border hiring across three or more regions | Any | Multiple policies, conflicting | Coordination, not coverage | One principles doc, regional addenda |
| AI used in hiring decisions with candidates affected | Any | High-risk exposure | Bias, notice, record-keeping | Get legal advice, then a documented workflow, not a policy alone |
The Cost of Getting This Wrong
The invoice never shows up. A candidate learns their CV was scored by a tool nobody can explain, and posts about it. A recruiter pastes a personal data field into a public chatbot the day before a breach disclosure, and the deletion trail is messy. An auditor asks for the AI policy in a vendor review and the team produces a document written two years ago referencing tools nobody uses. None of this arrives as a line item, and all of it lands on the same week.
The first real cost is that people stop asking. A policy that can't answer an ordinary question teaches staff not to bring ordinary questions, and the only ones that keep arriving are safe. What disappears is the interesting traffic: the recruiter who has found a better way to screen and wants to know whether it's allowed. She won't ask now. She'll do it quietly or not do it, and neither shows up anywhere you're looking.
The second is credibility, a tax on everything after. Once the policy is understood internally as theatre, every governance request inherits that reading. Security training becomes a click-through. The vendor review becomes a form. The team that wrote the policy knows. The board that approved it knows. So the next genuine ask arrives pre-discounted, and you spend your credibility twice: once to be taken seriously, once to get the thing done.
The third is that good tools get blocked alongside bad ones. A company with no working way to assess an AI feature defaults to no, because no is defensible and yes takes a judgement nobody is authorised to make. So the shortlisting toggle stays off, and a competitor with a two-page policy and a named owner gets further ahead on the boring operational work. Nothing was decided. It was just never decided.
So the question isn't what a good AI policy looks like. It's whether the document you're about to write will be the one your team reaches for on a Friday afternoon, or the one they work around.
When You Are Ready to Go Further
If you've read this far, you're past the definition stage. You know the question. Which approach fits depends on your team's shape and what your customers and board are already asking. If a case study or a conversation with our research team would help you pressure-test the approach, the links below are the place to start.
Frequently Asked Questions
Who owns the AI acceptable use policy inside HR?
The Head of People, with a named delegate and the CISO reviewing security clauses. A policy owned by Legal alone is a record rather than a control; one owned by IT alone misses the people workflow: the candidate who was never told, the manager who treated a generated summary as evidence. The owner needs calendar time, not a title, because the document needs refreshing every six months and after any incident, and because somebody must answer what the policy doesn't cover. If nobody does, whoever is nearest the deadline improvises.
Should the default position be to ban or to permit?
Permit, with named exclusions and worked examples for the high-traffic cases. A ban is the comfortable decision in the room and the worse one afterwards, because it doesn't stop the use. It relocates it. Work moves to personal accounts, where you have no retention control and no way to answer a candidate asking what became of their data. Permit-first is harder because you have to decide things: what may go into a tool the company pays for, what may never leave the building. Those two sentences outperform ten pages of prohibition.
What do we do about the AI tools staff are already using?
Audit first, decide second. Look in four places before you send anyone a survey: expense claims for individual subscriptions, browser extension inventories from your endpoint tooling, single sign-on logs for apps nobody remembers approving, and release notes from vendors you already pay. The list runs longer than expected and is mostly benign. An audit you're nervous about running tends to find ordinary people solving ordinary problems under deadline. Open an amnesty window and say plainly that nothing surfaced will be held against anyone. Pretending the list is empty ages badly.
How often should the policy be reviewed?
Every six months as a standing item, and after any incident or tool change. The reason isn't that policy ages. It's that the tools move underneath it. A vendor ships a feature, a model gets swapped, a setting flips from off to on by default, and none of that triggers a contract review or a note to HR. A document that was right when it was signed is half-right two releases later. Review is also when to check the examples, which rot first, because they name tools and tools get renamed.
Does one policy cover every HR team, or do we need separate ones?
One principles document, with workflow-specific addenda for the parts that genuinely differ. Recruitment and L&D fail in different directions. A recruiter's exposure is candidate data entering a tool that keeps it, plus a decision that later needs explaining. An L&D lead's exposure is performance notes about a named employee, written for one purpose, becoming the input to a document that reads as objective. Same tool, same afternoon, two different problems. Put both into one long document and neither team finishes it. Split them completely and an auditor gets two answers.
What happens when someone breaks the policy?
The first incident is a training moment, not a disciplinary one, unless the breach was deliberate or reckless. A policy that jumps to termination on a first offence is one nobody will report breaches against, and unreported breaches are worse than no policy, because you lose your only early warning. State the escalation path, name who reviews the incident, say what gets logged. Then treat the first reports as intelligence about where the document is unclear, because a breach three people commit independently isn't an employee problem. It's a drafting problem.
Does the policy need to cover vendors, or only internal use?
Both. The customer and the auditor don't care whether the AI sat inside your company or inside a tool you paid for, because the exposure lands in the same place. The policy needs a clause on vendor due diligence for AI features, and a requirement that any new vendor with people-data AI capability gets reviewed before sign-off, not after. Add what most policies miss: a trigger for existing vendors, because AI capability usually arrives in a minor release long after the contract was signed. Ask who reads your suppliers' release notes.
How do we know the policy is actually working?
Watch the questions. If nobody in HR asks whether a specific use is allowed, the policy is too abstract or too long to consult under deadline, and silence is being read as permission. If the same question surfaces three times in a quarter, the policy has a gap exactly there, and the fix is a worked example rather than another paragraph of principle. Question volume is the leading indicator, incident reports the lagging one. You need both, because a quiet quarter looks identical to a policy nobody has opened.
HROpsLab is an independent review publication covering HR operations tooling. We don't sell software, consulting, or implementation services. We compare, and we tell you what we find.