ع
Learn Tracks Reference Guides Saved
For your team

People & HR with Claude: the operating guide

The playbooks show your team what to do with Claude. This is the guide that keeps it fair, confidential, and defensible while they do it — the operating model behind the people work.

11 min read · Updated 2026-06-24
People & HR with Claude: the operating guide

Your team has the People & HR playbooks — the worked systems for opening a role fairly, balancing a panel, rewriting a policy, running a review cycle, offboarding with dignity. Those tell people what to do. This guide is the layer underneath: the operating model that keeps the work fair, confidential, compliant, and defensible while they do it. It’s written for a People leader rolling Claude out across a team, not for a solo experimenter — because in HR, the cost of getting the operating model wrong isn’t a bad draft, it’s a leaked name, a biased decision, or a legal exposure.

The single mistake that turns an AI rollout into an HR incident isn’t a clumsy prompt — it’s the absence of a rule about people data, bias, and who actually decides. None of what follows is heavy process. It’s the handful of guardrails that let your team move fast because the boundaries — confidentiality, fairness, and the human-owns-the-call line — are clear.

The operating model: Claude drafts, your people decide

Start with the one principle everything else hangs off: Claude drafts; humans decide. It is the fastest junior HR partner you’ve ever had — tireless on first drafts, synthesis, and structure — and it has no judgment, no accountability, and a habit of stating a wrong comp number or a wrong legal entitlement with total confidence.

So the division of labour is fixed:

  • Claude does the zero-to-draft work: draft the inclusive JD, balance five interviewers into one fair read, rewrite the policy in plain English, synthesize the review inputs, structure the offboarding handover, draft the reorg runbook.
  • A person does the deciding: make the hire, set the rating, sign off the policy, approve the comp, press send on the sensitive message, and own the consequence.

A team that internalizes this gets the speed without the risk. A team that forgets it lets an averaged verdict make a hire, or ships a confident wrong entitlement in a policy. The playbooks are all built around this line — they take you to a strong, fair draft fast and then hand the people decision back to you on purpose.

What’s safe to share — and what isn’t

On Desktop, the folder is the boundary — Claude only sees what you open — and the “Ask permissions” prompt asks before each read. In HR the boundary matters more than anywhere, because the data is people. State it simply:

  • Safe to share: role-level material — job descriptions, your competency framework, policy text, anonymized survey themes, and the structure of any process. None of this names a real individual.
  • Keep in an approved workspace: anything that identifies a person — candidate names and interview notes, performance reviews, comp, PIPs, exit-interview notes, and any record with PII. This goes only into the workspace your company has approved for people data, and never into a general chat.

Two habits make this automatic. First, build with [placeholders] — design the JD, the offer, the onboarding plan, the review template against [name], [manager], [comp], and fill the real values only inside your approved HR system. Second, when a task genuinely needs the real data — synthesizing an actual panel, reading a real exit interview — keep the whole task inside the approved workspace and drop in only the files it needs. The interview-synthesis, performance-review-cycle, and engagement-survey playbooks each flag this at the exact step it matters — and the survey playbook adds the one HR-specific trap: re-identification, where a small segment plus a telling quote unmasks an anonymous respondent even with no name in sight.

The fastest way to turn an HR tool into a liability is to let speed skip the reviewer. So put one gate between draft and decision, and make it explicit. In HR it has two halves — fairness and law:

  • Fairness: ask Claude to flag bias as its own pass — “culture fit”, personality, accent, background, tenure-as-a-proxy-for-skill, anything not tied to the actual job. Then weight evidence equally and calibrate across people, so a rating or a verdict rests on the work, not on who wrote the most or shipped most recently.
  • Law: anything touching protected characteristics, employment law, comp, or a regulated entitlement clears a real person — HR and, where it has legal weight, counsel — before it lands, not after a complaint. Claude is not a lawyer, and it will state a wrong legal rule as confidently as a right one.

This isn’t bureaucracy bolted on — it’s a single named step in the workflow. The inclusive-JD and competency-framework playbooks build the bias scan into the artifact; the policy-rewrite playbook ends in a rule-by-rule diff plus a human sign-off precisely so a plain-English rewrite can’t quietly soften a legal rule; the org-change playbook puts HR, legal, and — regionally — the works council or labor authority on the runbook as named steps with owners and deadlines, because at enterprise scale what slips a rollout is an unsecured sign-off, not the copy.

Who owns what (a light RACI)

Speed dies in ambiguity about who decides. You don’t need a formal RACI matrix — you need four roles named for any piece of people work:

  • Drafts — the recruiter, HRBP, or manager running the playbook with Claude.
  • Reviews — HR owns fairness and process; the relevant expert owns the facts; legal owns anything regulated.
  • Approves — whoever can say yes to the decision: the hiring panel for a hire, the calibration room for a rating, legal for a policy, leadership for an org change.
  • Owns — a person makes the call, presses send, and can answer for it.

The point is that Claude is never any of these four. It’s the tool the Drafts role uses. Write these four names down once per workstream — hiring, reviews, comms, org change — and most “who signed off on this?” fire drills disappear.

Working in two languages: Arabic and English

For a MENA team, bilingual isn’t a translation step bolted on at the end — it’s a parallel track, and in HR the stakes are higher because the words land on a person. The rule that matters: adapt, don’t translate.

  • Author natively, don’t machine-translate. A JD’s coded language, a policy’s exact rules, and a sensitive message’s tone are all language-specific. Write the Arabic version natively — the inclusive-JD bias scan run in Arabic, the policy-rewrite diff run on the Arabic rules, the sensitive-comms draft adapted in register — not an English draft pushed through a translator.
  • The exception that proves the rule: policy translates faithfully. A reorg note you adapt for tone; a leave entitlement you translate exactly, because the rule must mean the same thing in both languages. Run the same rule-by-rule diff on the Arabic.
  • Same gate, both languages. Arabic content clears the same fairness and legal review — and regional compliance — as the English. Don’t let the second language skip the sign-off because nobody on the approval chain reads it; find someone who does.

Treated this way, Arabic is a first-class peer of English in your people work — which, in this region, is the difference between an employee experience that feels native and one that feels like a translated handbook.

The capability path: from one fair hire to a whole org change

The playbooks are arranged as a staged path, not a flat menu, because the later ones genuinely depend on the earlier ones. Run a team through it in order:

On the People & HR team hub the path is laid out stage by stage with a progress bar, and your team can mark each playbook done as they go — so “we’re upskilling the team” becomes a number you can actually see, not a hope. (Progress is tracked on each person’s device; a shared, manager-level team view is the natural next step once you’ve run the path.)

Rolling it out: a 30/60/90 plan

Don’t roll everything out to everyone on day one — that’s how rollouts fizzle. Stage it the same way the path is staged. Here’s the whole arc as a checklist you can copy into your own doc:

30/60/90 — rolling Claude out across a People & HR team

First 30 days — Foundations
- Pick 2–3 willing people across recruiting, HRBP, and ops.
- Build the foundation assets: a competency framework for one role family,
  and your inclusive-JD and sensitive-comms craft.
- Agree the one-page guardrail: what people data is safe to share, who signs
  off on fairness, and who signs off on anything legal.
- Each person runs their first real Stage 1 playbook end to end.

Days 30–60 — Repeatable systems
- Put the people-year engines on Claude: interview synthesis, onboarding,
  policy rewrites, the review cycle, the engagement survey, offboarding.
- Capture the prompts that work into a shared CLAUDE.md and slash commands.
- Name the four roles per workstream: drafts / reviews / approves / owns.

Days 60–90 — Orchestration
- Run one real hire from open to offer, and one real org change, end to end.
- Stand up the sign-off gates (HR, legal, works council / labor authority)
  as named runbook steps with owners and deadlines.
- Review the capability path: who's completed which stage, where the gaps
  are, and which seats to add next.

The urge to mandate it for everyone at once is the urge to resist. Adoption is a habit that spreads, not a switch you flip. Start a few people on the foundations, give them the source docs and a one-page rule, let them capture what works — and by day 90 you have a team that’s run a real hire and a real org change through the system, a path you can point to, and the proof you need to widen it. The general team rollout playbook goes deeper on the cross-role mechanics when you’re ready to scale it past People & HR.

Topics

Questions people ask

Is it safe to use Claude for HR work with employee and candidate data?
For role-level work — a job description, a competency framework, a policy rewrite — yes, that's everyday territory. The careful line is individual people data — names, interview notes, reviews, comp, exit reasons. That stays inside a workspace your company has approved for people data, you drop in only what a task actually needs through the Desktop file pane, and you approve each read in the "Ask permissions" prompt. Build templates with `[placeholders]`; apply them to real people only inside your approved system. Claude drafts; it never becomes the system of record for employee data.
Does this replace recruiters, HR business partners, or managers?
No. It removes the blank-page and synthesis tax — the first draft of a JD, the scatter of five interview notes, the wall-of-jargon policy, the brain-dump before someone leaves — so your people spend their time on judgment, fairness, and the human conversations that actually matter. Every hire, promotion, rating, and exit stays a person's decision. Claude is the fastest, most tireless junior on the team, not a replacement for the judgment of the senior ones.
How does using Claude make hiring and reviews more fair, not less?
By making the bar explicit and the evidence equal. A competency framework defines what each level looks like in observable behavior, so JDs, scorecards, and reviews all judge against the same thing. The synthesis playbooks weight evidence equally instead of by who wrote the most, keep real disagreements visible, and run a dedicated bias pass that flags "culture fit" and anything not tied to the job. Claude surfaces; the panel and the calibration room still decide.
How do we roll this out without it fizzling?
Start small and staged. Two or three willing people, the foundation docs (a competency framework and a brand of sensitive-comms craft), and a one-page confidentiality rule in the first month; the repeatable systems — interviews, onboarding, reviews, surveys — in the second; a real hire or org change run end to end in the third. Capture the prompts that work into shared files so wins compound. The 30/60/90 plan at the end of this guide is the whole arc.
Put it into practice
Take the guided course
Start