This is the complete guide, with article-by-article legal detail. If you’d rather start with the short, practical version, read AI Agents in HR: What They Can Do Alone (and What the Law Doesn’t Allow).
A chatbot answers you. An AI agent, on top of that, can read your HR system, cross-reference data across your workforce, draft a notice and send it to 300 people without anyone reviewing it first. That difference —from «responding» to «acting»— is exactly what the law cares about. And it’s the one thing almost nobody stops to check before rolling out an agent.
At Humano (humano.io) we work every day with HR teams at companies with operational, distributed workforces: factories, warehouses, farms, retail floors. More and more of them ask us the same thing: «Can we put an AI agent in charge of scheduling, first-line payroll questions, or incident alerts?» The short answer is yes —on one condition: you design it knowing exactly which legal obligations it triggers.
This article is not a legal treatise and does not replace advice from a lawyer for your specific case. It’s a practical guide so that, as an HR, technology or compliance lead, you know what questions to ask before giving the green light.
The law doesn’t look at the label, it looks at the function
Call it an «agent», an «assistant» or a «bot» —it makes no difference. Neither the GDPR nor the EU AI Act regulate based on what you name the system. They regulate based on three things:
- What it does: does it inform, does it prepare a draft for a person to review, or does it directly execute an action with real effects (changing a record, sending a communication, triggering a payroll change)?
- What data it uses: does it handle employees’ personal data? Special category data (health, union membership, ethnic origin)? Data of minors, in the case of interns?
- What consequences it has: does the action affect a right or a working condition of a person (schedule, pay, evaluation, continuity of contract)?
The higher the reading on these three axes, the greater the legal risk and the more obligations apply. A system that only reads and summarizes publicly available company information is not, in the eyes of the law, the same as one that decides whose contract gets renewed.
Who is liable: the technology provider and the company that uses it
A common mistake is to assume that if the agent fails, the fault lies «with the AI» or with whoever built it. European regulation splits responsibility between two distinct roles, and in almost every project they coexist:
- The technology provider (whoever develops or sells the model or the agent): is responsible for the system being safe, documented and —if it’s high-risk— compliant with the AI Act’s technical requirements. Under data protection law, it normally acts as a data processor.
- The company that uses it with its employees (the «deployer» under the AI Act, and the data controller under the GDPR): is responsible for how it configures it, what it’s used for, what data it feeds it, who supervises it, and which decisions it leaves in its hands. This responsibility cannot be transferred to the provider by contract.
In practice: if you buy or license an AI agent for HR, you remain responsible for how you use it inside your company, even though a third party built the underlying system. Your contract with the provider should make clear who does what (data processing agreement, security measures, sub-processing) —but that doesn’t exempt you from your own obligations as a company.
Four levels of autonomy, four levels of scrutiny
Before getting into the regulatory detail, it helps to have a clear map of which tasks an agent can take on, and how closely each needs to be watched. It’s the first question we ask any Humano (humano.io) customer considering automating an HR process:
- Low. Search, summarize documents or conversations, answer employees’ frequently asked questions. It doesn’t decide or execute anything affecting a person.
- Medium. Prepare documents or communications, update administrative records (e.g. an already-approved vacation date), draft text that a human reviews before sending. Requires oversight, but the risk is moderate if that oversight is real.
- High. Recommend hires, evaluate employees’ performance, calculate incentives or variable pay, prioritize candidates in a selection process. This is where GDPR Article 22 comes into play, and very likely the «high-risk» category under the AI Act. It demands reinforced human oversight, traceability, and almost always a prior impact assessment.
- Not authorized (without real human intervention). Disciplining, dismissing, or making any legally relevant decision about a person without a human reviewing and genuinely deciding. Using AI to support these decisions isn’t off-limits; the point is that the final decision, the one that produces effects, can’t rest solely on the system.
This ladder is a useful first filter: the higher you climb, the more of the obligations below get triggered at once.
GDPR applied to an agent: eight questions to resolve before switching it on
The GDPR isn’t a box you tick once. For an agent that touches employee data, you need to resolve, at minimum, these eight points:
- Purpose. What exactly will the agent be used for? «Improve HR» is not a valid purpose; «resolve first-line payroll questions» is. The specific purpose determines which data it may touch and which it may not.
- Legal basis. What legitimizes processing that data with the agent? In an employment context, it will usually be performance of the employment contract or the employer’s legitimate interest, and sometimes a legal obligation; an employee’s consent is a poor sole basis, because in an employment relationship it’s rarely freely given.
- Minimization. The agent should only see the data it needs for its task, not the person’s entire history «just in case.» If it only needs this week’s shift, don’t give it ten years of files.
- Access. Who can see what the agent produces, and who can review what it consults? An agent connected to payroll or health data shouldn’t be accessible, even indirectly, to just any middle manager.
- Retention. How long are conversations, prompts and the agent’s outputs kept? You need a defined retention period and a deletion criterion, same as with any other HR data.
- Vendors. If the agent runs on a third-party model (OpenAI, Anthropic, Google, etc.), that third party is a data processor and you need a proper data processing agreement (DPA), plus clarity on where and how it processes the data.
- International transfers. If that provider processes data outside the European Economic Area (typically the US), you need a valid safeguard: adherence to the EU-US Data Privacy Framework, or standard contractual clauses. Don’t assume «it’s in the cloud» means «it’s in Europe.»
- Model training. You need contractual assurance that your employees’ data is not used to train or improve the provider’s model, unless you’ve expressly decided to allow it and have a legal basis for doing so. Most serious providers offer this guarantee to enterprise customers, but it needs to be verified, not assumed.
Automated decisions and GDPR Article 22
Article 22 of the GDPR gives every person the right not to be subject to a decision based solely on automated processing (without meaningful human intervention) when that decision produces legal effects or similarly significantly affects them. In HR, this covers recruitment, performance evaluation, promotion, and dismissal.
There are exceptions (the decision is necessary for the contract, authorized by law, or based on explicit consent), but even then the GDPR requires minimum safeguards: the person’s right to obtain human intervention, to express their point of view, and to contest the decision. If your agent can, for example, automatically reject applications or flag someone for non-renewal without anyone reviewing that outcome before it’s communicated, you’re squarely in the territory this article regulates.
Impact assessment (DPIA) when there’s high risk
When processing —by its nature, scope or purpose— entails high risk to people’s rights, the GDPR requires a Data Protection Impact Assessment (DPIA) before the processing begins, not after. This typically applies when the agent carries out systematic evaluation of people based on automated processing with significant effects, or processes special category data at scale.
In practice: if you’re going to use an agent to systematically evaluate performance, prioritize candidates, or make decisions about working conditions, commission the DPIA before deployment, not as paperwork afterwards. It’s also your best line of defense if someone files a complaint.
High-risk AI in recruitment, evaluation or workforce management
The EU AI Act explicitly classifies as high-risk systems those used for: recruitment and selection (including targeted job ads, filtering applications, or evaluating candidates), and for decisions on the terms of the employment relationship —promotion, termination, task allocation based on behavior or personal traits, and performance evaluation.
If your agent falls into this category, obligations include: a risk management system, governance of training data, technical documentation, event logging, effective human oversight, and adequate levels of accuracy, robustness and cybersecurity. One obligation that’s frequently overlooked: the AI Act (Article 26(7)) requires informing affected workers and their representatives that they will be subject to a high-risk AI system, before it’s put into use —not after.
Transparency: making sure people know they’re talking to an AI, and what its limits are
If an employee writes to an agent believing they’re talking to a person in HR, that’s a transparency problem. European regulation requires informing people, unless it’s obvious from context, that they are interacting with an AI system. And it’s not enough to say «this is a bot»: it helps to explain, in plain language, what it can do well (answer common questions) and what it can’t (make final decisions, replace a human manager in complex or sensitive cases).
This isn’t just a legal requirement: it’s what stops an employee from entrusting an important matter —a medical leave, a conflict with a colleague— to a system that isn’t built to handle it.
Real human oversight: an «approve» button is not enough
This is one of the points where most companies fail without realizing it. Putting an «approve» button in front of an AI-generated decision is not human oversight if the person clicking it doesn’t have the time, information, or standing to genuinely question the outcome. If a manager approves twenty performance reviews in three minutes because «the system already analyzed it,» that click isn’t a review —it’s a formality.
Real human oversight means the reviewer: has access to the information the agent’s conclusion was based on (not just the conclusion itself), has the competence and time to question it, and has genuine authority to change the outcome without friction or pressure. Designing the workflow so this is possible —not just theoretically possible— is the company’s responsibility, not the AI provider’s.
Minimum permissions: separating read, write, send, delete and execute
The same agent shouldn’t automatically have permission to do everything just because it has access to a system. The principle of least privilege, applied to an AI agent, means clearly separating:
- Read: what data it can consult.
- Write: what records it can create or modify.
- Send: whether it can communicate directly with employees, customers or third parties.
- Delete: whether it can erase data or records.
- Execute: whether it can trigger actions with real effects (approve, pay, deactivate, change a shift for good).
An agent that only needs to read time-tracking incidents to draft a summary doesn’t need permission to send mass communications or write to payroll. The more of these permissions it accumulates without genuine need, the larger the surface for error —and for manipulation.
Logging and traceability
You need to be able to reconstruct, after the fact, what data the agent consulted, what it produced and why, and who approved it. Without this record there’s no way to defend yourself against an employee complaint, a labor inspection, or a GDPR audit —nor to catch a systemic failure in time. For high-risk systems, the AI Act itself requires keeping this kind of automatic logging for a set period.
Cybersecurity: prompt injection, improper access, leaks and malicious commands
An agent capable of acting is, by definition, also a new attack surface:
- Prompt injection: malicious instructions hidden in a document, email or message the agent processes, designed to make it act outside its remit (for example, leaking data or sending something it shouldn’t).
- Improper access: if the agent’s credentials are over-provisioned (more permissions than necessary) or poorly protected, a single failure or leak becomes an open door to the whole system.
- Leaks: employee data leaving your perimeter through the AI provider itself or a poorly configured third party.
- Malicious commands: someone —inside or outside the company— trying to trick the agent into executing a harmful action disguised as a legitimate instruction.
The practical defense combines what’s already been said —minimum permissions, human oversight on sensitive actions— with technical measures: validating actions before executing them, rate and volume limits, and periodically reviewing what the agent can actually do versus what it needs to do.
Labor rights and informing workers’ representatives
Beyond data protection, Spain’s Workers’ Statute recognizes workers’ legal representatives’ right to be informed about matters affecting working conditions. Since 2021, Spanish law expressly adds the right to know the parameters, rules and instructions behind any algorithm or AI system that may affect decision-making impacting working conditions, access to and continuity of employment, and profiling (a rule that emerged from the so-called «Rider Law,» but isn’t limited to delivery platforms).
If your agent allocates shifts, prioritizes tasks, evaluates performance, or influences work assignment, this obligation to inform workers’ representatives kicks in even if the system never gets close to a dismissal decision. It’s a step many companies skip simply because they don’t know it exists.
Training users and supervisors
No agent is safer than the person using or supervising it. Whoever reviews an agent’s output needs to understand what can go wrong (hallucinations, bias, outdated data), when to escalate a decision, and what legal implications come with rubber-stamping an automated recommendation. This isn’t a one-off course: it’s training that needs to keep pace as the agent’s capabilities change.
A prohibition that’s often overlooked: emotion recognition at work
The EU AI Act generally prohibits AI systems that infer a person’s emotions in the workplace —from tone of voice, facial expression or behavior patterns—, with narrow exceptions for medical or safety reasons (for example, detecting fatigue in safety-critical tasks). An agent that analyzes employees’ «mood» from their messages or calls for general people-management purposes falls squarely within this prohibition, not in a gray area.
Examples applied to HR
- An agent that summarizes the week’s time-tracking incidents for the shift manager to decide → low level, still a support tool.
- An agent that drafts an internal notice that HR reviews and sends → medium level, perfectly manageable with real oversight.
- An agent that prioritizes applications in a selection process based on CV data → high level: a high-risk system under the AI Act, requiring meaningful human oversight, traceability, and advance notice to candidates.
- An agent that decides and directly communicates to an employee that their contract won’t be renewed, without human review → not authorized: an automated decision under GDPR Article 22, without the required safeguards.
The design principle we apply at Humano (humano.io)
The agent can search, explain, summarize, calculate and prepare drafts. It cannot autonomously adopt or execute decisions that produce relevant employment-related, financial or legal effects on a person. Those actions require review and explicit confirmation from an authorized user.
This isn’t a line written for a privacy policy nobody reads. It’s a design principle: it shapes how we build every AI feature at Humano (humano.io), starting from the first sketch.
And here’s the point that actually matters: compliance isn’t solved with a disclaimer. Writing «AI can make mistakes» in fine print protects no one —not your company, not your employees— if underneath, the system can write, send or decide without anyone stopping it in time. Responsibility isn’t delegated to a disclaimer: it’s built into the product. In practice, that means:
- Role-based permissions. Not everyone needs the agent to be able to do the same things: a shift manager shouldn’t be able to grant it access to payroll; an administrator shouldn’t be able to delegate a dismissal decision to it.
- Access to strictly necessary data. The agent sees what it needs for the specific task, not a person’s entire history «just in case.»
- Confirmations. Before any action with a real effect on a person, someone with authority and context must explicitly say «yes, go ahead» —not as a rubber stamp.
- Reversible actions. Whenever possible, what the agent does can be undone. If it can’t be undone, it isn’t automated without prior human confirmation.
- Logs. There’s a record of what data the agent saw, what it proposed, and who approved it. Without this, there’s no way to defend against a claim or to learn from a mistake.
- Isolation between companies. Each customer’s data and actions live in their own compartment. A failure or manipulation at one company can’t leak into or affect another.
- Effective human oversight. Not an approve button clicked out of habit: a person with the time, information and real authority to change the outcome.
This is, in essence, what the GDPR calls «data protection by design» (Article 25) and what the AI Act requires as effective human oversight for high-risk systems: not something bolted on at the end, but something decided before the first line of code is written.
The practical rule we take away
Design the agent’s autonomy from the outside in: start by defining which decisions it must NEVER make alone (those affecting a person’s rights or working conditions), and from there decide what can be automated without oversight. It’s much easier to expand the autonomy of an agent that was born cautious than to rein it in after an incident.
Not all AI applied to HR is «high-risk» by default: it depends on its purpose, the data it uses, and the real consequences of what it does. But when it is, the difference between a prepared company and an exposed one isn’t found in a vendor’s marketing —it’s in whether that design principle can be verified, line by line, in the product they actually use.
At Humano (humano.io) we build internal communication and HR tools designed precisely so a person stays at the center of the process: visibility into what’s communicated, who approves it, and what gets logged.
Want to see how we apply this in shift scheduling, internal communication and HR processes? Talk to our team and we’ll walk you through real examples.
This article is a practical, informational guide, not individualized legal advice. For your specific case, consult your legal advisor or compliance department. Sources: EU AI Act (Regulation (EU) 2024/1689), GDPR (Articles 13, 14, 22, 25, 28, 32 and 35), guidance from Spain’s Data Protection Agency (AEPD), the Spanish Workers’ Statute, and European Commission documentation.