How to govern Claude and AI agents in people ops

Governing AI in people ops comes down to four things: decide which data AI may touch, keep sensitive fields out of AI’s reach even when the person using it has full access, require a human yes before anything irreversible, and keep a log that shows what the AI did and why.

The first three volumes of our Claude for people ops series were about doing more with Claude: using it for people ops work, building skills, and turning them into agents that post to Slack and update employee records on their own. This one is about the question your CEO, your DPO (data protection officer), or an employee will eventually ask: is this allowed, and can you prove what it did?

It’s a practical guide for People Leads and founders at companies in the EU and UK. It isn’t legal advice. For anything with legal consequences, check with your employment lawyer or data protection advisor.

TL;DR

• Under GDPR you are the controller of employee data. Your AI tools and HR system are processors, and you need a DPA (data processing agreement) with each, including Anthropic
• Keep health data, social security numbers and bank details out of chat windows. Access them, if at all, through a permissioned system, not copy-paste
• An AI agent usually runs with the access of whoever set it up, and that’s often an admin. So protect sensitive data at the field level, keep each agent’s task narrow, and rely on approvals and logs as the safety net
• Decisions with significant effects on employees, such as pay, termination and performance ratings, need a human decision, not just a human click. GDPR Article 22 and the EU AI Act both point the same way
• Your audit log is your evidence. Every AI read and write should be attributable, explainable and reversible

Is it legal to use Claude with employee data under GDPR?

Yes, if you treat it like any other system that processes employee data. That means:

• Roles: your company is the controller, the party that decides why and how employee data is used. Anthropic (for Claude) and your HR system vendor are processors, which handle the data on your behalf. On Claude’s commercial plans (Team, Enterprise and the API), Anthropic’s commercial terms include a data processing addendum, and Anthropic doesn’t train its models on your data by default.
• Lawful basis: most employee data processing relies on the employment contract, a legal obligation, or legitimate interest. Using AI to process the same data for the same purpose usually doesn’t need a new basis, but document it in your record of processing.
• Transfers: Anthropic processes data in the US as well as Europe. That’s lawful with the right transfer mechanism (EU Standard Contractual Clauses or the EU-US Data Privacy Framework), but list it in your employee privacy notice.
• DPIA: if you’re introducing new technology that processes employee data systematically, such as an agent that reviews every leave request or evaluates performance data, a data protection impact assessment (DPIA) is often required. Many EU data protection authorities list employee monitoring with new technology as a DPIA trigger.
• Transparency: tell employees which AI tools process their data and for what. One paragraph in your privacy notice is usually enough for drafting and admin use.

The biggest GDPR risk isn’t using Claude. It’s employees using personal Claude or ChatGPT accounts with employee data, outside any DPA. Provision a company plan and make that the only approved route. Our guide to GDPR and employee data covers the wider rules on what you can collect, store and delete.

Which people data should AI never see?

Not all people data carries the same risk. Three tiers keep it simple:

The “keep out” tier overlaps with GDPR’s special categories of data (Article 9), which need an extra legal condition to process at all.

Why MCP (Model Context Protocol, the standard that lets Claude read and write your other systems) beats copy-paste: when you paste a salary spreadsheet into a chat, the whole file goes into the conversation, including columns the task didn’t need. When Claude queries your HR system through MCP, it gets only the fields the question needs, filtered by your permissions, and the access is logged. That’s data minimisation in practice.

How should permissions work for AI agents?

The principle: an AI agent can do whatever the person who set it up can do. Plan for that, rather than assuming it’s limited.

In practice:

• Interactive use (you, in Claude): Claude acts as you. Over MCP it sees what you can see in your HR system, nothing more.
• Agents: an agent usually runs with the access of the person who built it, and in people ops that’s often an HR admin. You can’t always narrow the agent’s account, so narrow what’s around it instead. If your HR system supports it, mark your most sensitive fields so AI never receives them, whoever is asking, and keep each agent’s instructions to one job. A probation tracker needs names, managers and dates. It doesn’t need salaries.
• Connect only what the job needs. An agent that drafts manager messages needs Slack. It doesn’t need your payroll export. In Claude.ai, that means only turning on the connectors a task needs. If you build agents with Claude Code or the API, list the exact tools each agent can use.
• Same rules everywhere. If a field is hidden in your HR system’s web app, it should be hidden in Slack and over MCP too. Check this with your vendor, because it’s not always the case.

Which people decisions need human approval?

Sort every AI workflow into three groups:

The right-hand column is where the law gets specific. GDPR Article 22 gives people the right not to be subject to decisions based solely on automated processing that significantly affect them. According to the EU data protection guidelines on automated decision-making, “the AI decided and a manager clicked approve without reading it” can still count as solely automated. The human has to actually weigh the decision.

AI can still help in the right-hand column: summarising feedback before a review, or drafting a termination letter after the decision is made. It just shouldn’t make the call.

What does the EU AI Act mean for AI in people ops?

The EU AI Act classifies several employment uses of AI as high-risk (Annex III): AI used for recruitment and candidate screening, decisions on promotion or termination, allocating tasks based on personal traits or behaviour, and monitoring or evaluating employee performance.

If you use AI in those ways, as a deployer (the company using the system, as opposed to the vendor that provides it) you’ll need to:

• Keep meaningful human oversight by someone with the competence and authority to override the AI
• Inform affected employees and their representatives before putting the system into use
• Keep the logs the system generates and monitor how it performs

The high-risk obligations were originally set to apply from August 2026. The EU’s Digital Omnibus on AI, published in July 2026, moved them to 2 December 2027. That gives you time to prepare, not a reason to wait. One obligation already applies: companies using AI must take measures to support AI literacy among the people who use it. The Omnibus softened the wording, so you don’t have to guarantee a specific level, but you do need to act on it.

The good news for most small people ops teams: drafting documents, answering policy questions, running reports and admin workflows like onboarding checklists generally fall outside the high-risk list. The line is crossed when AI starts evaluating people.

How do you prove what an AI agent did?

When an employee asks why their leave balance changed, or an auditor asks who accessed salary data, “the AI did it” isn’t an answer. Your audit trail should show, for every AI action:

1. Who or what made the change (which agent, acting for which person)
2. What changed (before and after)
3. When it happened
4. Why (the request or the agent’s reasoning)
5. How to undo it

Test this before you need it. Pick an agent action from last week and try to answer all five questions in under five minutes. If you can’t, fix the logging before adding more agents. If you’re building agents yourself (see Vol 3), this logging is your responsibility. Our guide to which employee records you’re legally required to keep covers how long to keep them.

How do you write an AI use policy for people ops?

A one-page policy covers most of what a small company needs. Use this prompt to draft yours with Claude, then review it with whoever handles data protection:

Draft a one-page "AI in people ops" use policy for our company.

Context:

- Company: [name], [headcount] employees, in [countries]
- AI tools we use: [e.g. Claude Team plan, Taito.ai agents and MCP]
- What we use AI for: [e.g. drafting documents, policy Q&A, onboarding tasks, monthly reports]

The policy must cover:

1. Approved tools (and that personal AI accounts must not be used with employee data)
2. Data tiers: what AI can use freely, what only through permissioned systems, and what is never shared with AI
3. Which tasks AI can do automatically, which need human approval, and which are human decisions only
4. Who owns each AI agent and reviews its output
5. How employees are informed, and how they can ask questions or object
6. Logging and audit: where AI actions are recorded and how long logs are kept
7. Review cadence: when the policy is reviewed

Write in plain language, for employees, not lawyers. Flag any point where local law in our countries may need specific wording, rather than writing legal text yourself.

Then run this nine-point check:

• Company AI plan provisioned, personal accounts banned for people data
• DPA in place with each AI and HR system vendor
• AI tools and transfers listed in the employee privacy notice
• DPIA done for any agent that systematically processes employee data
• Data tiers defined and shared
• Sensitive fields protected from AI at field level, regardless of who runs the agent
• Approval matrix agreed (auto / approve / human only)
• Audit log tested on a real agent action
• AI literacy covered for everyone who uses AI in people ops work

Apply the rules you already have

Good AI governance in people ops isn’t a separate project. It’s the same permissions, approvals and records you’d want for any people operations system, applied consistently to AI. Get those right and the question “is this safe?” has a concrete answer.

Taito.ai was built with this in mind. Field-level permissions apply the same way in the web app, the Slack agent and over MCP, so Claude and agents never see more than the role allows. Mark a field Restricted or Secret and the AI doesn’t receive its contents, even when an admin runs the agent. Every change to an employee profile is logged, including changes agents make, with the agent’s reasoning visible and the change reversible. Decisions about people stay with a person: when an agent prepares a salary change, it stops and routes it to someone to approve. Taito.ai is ISO 27001 certified, runs its main database in the EU, doesn’t train AI models on customer data, and publishes its full sub-processor list, including its AI providers, at trust.taito.ai. See how it works, or we can walk you through it in 30 minutes.