Artificial intelligence in HR: what it can do today and where its limits are

Repetitive work with text and data. Everything artificial intelligence handles reliably in HR today falls into that category — read a document, pull the details out of it, build a new one from a template, compare two sets of information, and flag what falls outside the pattern.

Six areas, specifically. In recruitment, résumés get processed: the details are pulled out of a PDF or Word file, filed under the candidate and compared against the criteria for the role. With documents, a template gets built, a document for a specific employee gets filled from it, and wording that no longer matches current legislation gets flagged.

With reviews, the groundwork gets prepared, a structured conversation is run and a write-⁠up comes out of it. Internal documents can be queried in plain language — the answer is found in the policies and handbooks the company uploaded. In attendance data, anomalies get found: late arrivals, overtime above the limit, records that clash with the shift. And in reporting, an overview for a period gets compiled and what is out of line in it gets explained.

What they have in common is that the output is groundwork somebody reads. Not a decision.

In four things, and they are worth naming before you run into them yourself.

Decisions about people. Models can rank candidates by how well they match criteria. What they cannot judge is whether those criteria are the right ones, whether they carry bias from past hiring, and whether the person who scores lower would turn out well on the team. Deciding who gets a job or what review they receive is a judgment, not a calculation.

Attrition prediction without good data. The promise that a system will spot who is about to resign rests on data most companies do not have — a long history, consistently completed reviews, measured performance. Without it, the model returns correlations on noise.

"We will deploy AI and save X hours." A figure without a methodology is just a figure. Only one in five AI initiatives delivers measurable returns, and more than 40% of agentic AI projects are expected to be canceled by the end of 2027. What makes that interesting is that it holds at a time when 82% of HR leaders plan to deploy agentic AI within twelve months. That gap is the whole story of this chapter.

The difference between a tool that advises and a tool that does the work. Most of what is sold as AI in HR can answer a question. Only some of it does the work — builds the document, starts the checklist, fills in the review. It is a difference you will not spot from a website; it shows up in a demo, on one specific task.

A copilot answers what you ask. An autopilot does the work and hands the result over for approval. It is the only distinction that means anything when you are choosing a tool — most of the rest is describing the same thing twice.

A copilot helps when you know what you are looking for: where the policy is filed, whose probation is ending, how much vacation is left. It saves the search, not the work. An autopilot makes sense for things that repeat in the same shape: a contract from a template, an onboarding checklist, the write-⁠up of a review conversation. That is where the part that eats the most time gets saved.

A third category — a system that acts without confirmation — makes no sense in HR, and in recruitment and reviews regulation actively does not want it. A sensible setup is simple: the agent may read on its own, and write only after a person confirms.

So ask specifically when you evaluate. Not "does it do AI", but "what exactly does the system do when I give it this task, and what of that does it save without my confirmation".

Using AI in recruitment and employee evaluation is high-⁠risk under the EU AI Act (Annex III, point 4). The deadline for full compliance is December 2, 2027.

Three requirements follow from that in practice, and they belong in the decision when you pick a tool. Human oversight: the system's output has to be the basis for a person's decision, not the decision itself. Explainability: for every output it has to be traceable what it was based on. Records: what the system did and when has to be reconstructible afterwards.

The obligations land on the employer using the system, not only on the vendor who built it. That is the most common misunderstanding: buying a tool does not transfer the responsibility.

This chapter is a summary, not a legal opinion. The specific obligations depend on how you use the system and belong in a conversation with a lawyer.

Five questions that separate a tool with a label from a tool that does something:

In three steps, and the first one is the one most often skipped.

Name the specific repetitive work, not "deploy AI". Filling contracts from a template. Assembling the monthly overview from exports. Retyping a review conversation into a form. A project that starts with the technology and then looks for a use for it ends up in that statistic about canceled projects.

Measure how much of that work there is today. A rough estimate of hours per month is enough, but it has to exist before you deploy anything. Otherwise you will not be able to tell six months later whether anything changed — and you will have nothing to show leadership either.

Start with one area and verify it on real data. Not on a demo with prepared samples. Take ten of your own résumés, three of your own templates, your own policy. Most of the differences between vendors only show up there.