Just under half of organisations expect to use AI in HR this year. Among those that have already deployed it, most cannot say what it produced. SHRM’s 2026 research found that 56% of HR professionals do not formally measure the success of their AI investments at all, and only 16% apply a return-on-investment metric of their own.
That second figure is the more interesting one. Adoption is no longer the open question in most HR functions. Whether adoption produced anything is, and a majority of teams have no way to answer it.
The variance is visible even without formal measurement. Some organisations report faster hiring cycles and meaningful reductions in administrative load. Others have licences, enthusiasm, and a service desk that looks much as it did two years ago. The tools involved are broadly the same in both cases, which locates the explanation somewhere other than the technology.
What follows examines where AI is producing useful results in HR today, how it is changing the shape of HR work, why outcomes differ between teams running similar tools, and what the organisations getting returns appear to be doing differently.
The short version of the argument: access and usage are the easy parts. What separates results from activity is capability, and capability is something HR can see, build, and measure.
Where AI is working in HR
SHRM assessed 138 use cases across 16 HR practice areas to establish where AI has actually landed rather than where it might. The distribution is narrow, and it clusters in four places:
- Recruiting (27%). Resume parsing, interview scheduling, job ad programming, and further down the list, candidate-job matching. The highest-volume screening work in the function.
- HR technology (21%). Employee-facing assistants that answer policy questions before they arrive as service tickets, plus document and knowledge retrieval.
- Learning and development (17%). Personalised learning recommendations, AI-generated scenarios and quizzes, and content production that previously consumed weeks of instructional design time.
- Employee experience (14%). Routine query handling and pattern detection across employee feedback.
Inclusion and diversity, compliance, and C-suite support each register at 2% or below.
The pattern holds well enough to be useful. AI has taken hold where work is high in volume, structured, repeatable, and expensive mainly in hours. A recruiter reviewing four hundred applications is doing something a model does well and does identically on the four hundredth as on the first. Screening consistency alone is a real gain, given what fatigue does to the last hour of a review session.
Two further signals point the same way:
- The Josh Bersin Company’s 2026 research estimates that 60–70% of the work currently done by L&D teams could be automated through continuous, AI-generated learning delivery. That describes automatable work rather than work already automated, but the direction is not seriously contested.
- Scale correlates with adoption. 60% of employers with 5,000 or more staff have implemented AI in HR, against roughly a third of small and midsize organisations, and the largest employers are more likely to be using it in learning, talent analytics, and talent management.
None of this is trivial. Administrative load is what most HR functions are genuinely short of relief from, and AI has delivered against it faster than most previous waves of HR technology.
The complication is that these gains have a natural ceiling. Once the repeatable work is absorbed, what remains is the work that was never repeatable, and the question shifts from whether the technology can do the task to whether the people around it can do what the task becomes.
How AI is changing HR roles
Where AI has been deployed, the effect on jobs has been redistribution rather than removal. HR professionals report shifting responsibilities and upskilling far more often than displacement — SHRM’s data puts responsibility shifts at roughly five times the rate of job losses.
What that looks like inside two familiar roles:
The recruiter
- Less of: first-pass screening, interview scheduling, initial candidate research
- More of: calibration conversations with hiring managers, interpreting talent market data, candidate strategy and relationship work
The L&D lead
- Less of: content production, course administration, programme coordination
- More of: identifying which capabilities the business actually needs, designing interventions, measuring whether capability moved
The work moves up a layer. That sounds like straightforward good news and mostly is, with one qualification worth stating plainly: time released is not automatically time redirected. In many organisations the hours freed from screening are absorbed by more requisitions rather than better ones.
The more consequential point is the nature of the work that replaces it. Deciding which capabilities a business needs over the next two years is a harder task than building a course on a topic someone else selected. Calibrating a role with a hiring manager holding unrealistic expectations demands judgment that screening never asked for.
So the constraint moves. It stops being whether people have access to the tools and becomes whether they can do the work that access creates.
Why results vary between teams
Two people with identical licences can produce very different work from the same tool. The mechanism is worth being precise about, because it determines where enablement money should go.
An AI model returns fluent output regardless of who prompts it. What differs is what happens on either side of that output:
- Framing the request. Knowing which constraints matter, what context the model needs, and what a good answer would even look like.
- Judging what comes back. Recognising that a compensation benchmark is drawn from the wrong market, or that a policy summary omits the clause that matters.
- Knowing when not to use it. Some tasks are worse with AI, and identifying them requires knowing the task well.
- Fitting it into real work. Output that doesn’t connect to an actual workflow stays a demo.
Each of these depends on domain knowledge the person already had. Which means AI tends to widen the distance between strong and weak performers rather than close it. The experienced compensation analyst gets a faster draft. The inexperienced one gets a confident answer they have no basis to challenge.
The evidence points the same way. Section’s AI Proficiency Report finds that while most of the workforce now uses AI, only around 5.5% meet its bar for proficiency, with roughly three-quarters using it for basic, one-off tasks. The most common application it recorded is looking things up. Even inside SHRM’s data, HR professionals at director level and above reported meaningfully greater gains than individual contributors using the same tools.
This is not an argument that employees are unprepared or resistant. McKinsey’s research found nearly half of employees want more formal training and consider it the best route to adoption, which is a request rather than an objection.
The practical reading is that capability is the multiplier on AI investment, and unlike the tools themselves, it varies enormously across an organisation. It is also the one variable in this equation that can be deliberately built.
What makes AI adoption work
The organisations getting returns are not running different tools. What they have in common is that they treated four things as separate problems rather than one: whether people have access, whether they use it, whether they use it well, and whether the work improved. Most adoption programmes collapse all four into a single word.
They know what their people can already do
Most HR functions hold a great deal of data about their workforce. Engagement scores, performance ratings, training completions, tenure, mobility history. Very little of it describes capability.
That gap becomes visible the moment someone tries to plan AI enablement, because the planning questions all require a baseline:
- Which roles are most exposed to the shift in responsibilities?
- Who already works at a level where AI adds leverage?
- Where would foundational support change something, and where would it be wasted?
- Which capabilities matter enough to build deliberately rather than hope for?
Without an answer, the default is to buy training for everyone and hope it lands where it’s needed. It usually doesn’t, and the spend is difficult to defend afterwards because nobody established what it was meant to move.
Organisations getting results establish a role-level view of capability first, and treat it as infrastructure rather than a project. It’s the same foundation that supports workforce planning and internal mobility, which is why it tends to pay for itself beyond the AI question. Our guide to skills management covers how that baseline is built.
They aim enablement where it changes something
Open enrolment has a selection problem. The people who sign up for optional AI training are disproportionately those already curious, already confident, and often already competent. The sessions fill, the feedback is positive, and the capability distribution barely moves.
Meanwhile the employees whose work would change most tend not to volunteer. Not out of resistance, but because someone who isn’t sure what AI is for is unlikely to nominate themselves for an hour of it.
Routing enablement by gap rather than by invitation changes what training does:
- Content is specific to what the role actually requires, not general AI literacy
- Delivery is targeted at the people whose capability is furthest from what their work now demands
- Proficiency is defined in levels, so progress is legible rather than binary
This is the practical use of a capability baseline: it tells you which fifty people to reach rather than which five thousand to invite. Skills data can be mapped to roles at that level of detail without a manual mapping exercise.
They connect new skills to what comes next
Tool-specific training has a short shelf life. The interface changes, the model changes, and the course is stale within a year. What survives is the underlying capability: evaluating machine output, structuring a problem well, knowing where judgment still has to sit.
That distinction matters for how the learning is positioned. “Learn our new AI tool” is an instruction. “This is a capability your next role requires” is a reason.
Employees make rational decisions about where to spend discretionary effort, and capability development competes against delivery work that is already being measured. When new skills connect visibly to internal opportunities, role progression, and development conversations, the investment makes sense to the person making it. When the connection is absent, enthusiasm generated in a workshop decays quietly over the following quarter.
They equip managers before teams
Adoption spreads unevenly across an organisation, and the boundaries usually follow reporting lines rather than functions. That points at managers, who determine several things no policy document can:
- Whether spending time experimenting looks legitimate or looks like avoiding real work
- Whether someone who used AI well gets recognised for it or quietly resented for it
- Whether “I’m not sure how to use this” is a sayable sentence in a one-to-one
- Whether new capability shows up in how work is assigned
Gallup’s research has consistently found that most employees don’t strongly agree their manager supports the team’s AI use. That’s rarely obstruction. Managers are being asked to encourage capability they can’t observe, in tools they may not use heavily themselves, without any view of where their team actually stands.
The fix is unglamorous. Managers need to see the capability distribution on their own team, know which two or three people the next enablement round should reach, and have something concrete to discuss beyond general encouragement. A manager who can say “this specific skill is where the gap is for you, and here’s what it opens up” is running a different conversation from one who forwards a training invitation.
They measure capability, not licences
Most AI dashboards report licences assigned, weekly active users, logins, and prompts submitted. These metrics are not useless. They answer a real question: did people access the technology? That question matters in the first quarter after rollout, when the alternative explanation for flat results is that nobody opened the tool.
The problem is that the metric stops being informative exactly when the interesting questions start. Usage is an activity measure. It tells you something happened. It doesn’t tell you whether anything got better.
The distinction shows up clearly when adoption numbers look healthy and outcomes don’t move. Seventy per cent weekly active usage can describe an organisation where a small group has redesigned how they work and the majority are using a very good search engine. Both groups appear identically on the dashboard.
Better questions to put on the same slide:
- Has capability changed since the baseline, and in which roles?
- Is proficiency concentrated in a few teams or distributed across the function?
- Which tasks are now being done differently, rather than just faster?
- Where are gaps closing, and where have they stayed open despite training?
- What proportion of the work that was manual two years ago still is?
None of this requires abandoning usage reporting. It requires recognising that usage answers the entry-level question, and that most organisations have been treating the answer as if it settled a much larger one.
This is also where the earlier findings connect. If a majority of HR teams don’t formally measure the success of their AI investments, and the ones that do mostly measure activity, then the widespread uncertainty about AI’s return is at least partly a measurement problem rather than a technology problem.
How Nestor helps
This section describes our own product. Everything above stands without it, but if the capability layer is what’s missing, this is where we fit.
The method in this article has a dependency. Four of the five points assume you can already see capability at role level, and most organisations can’t. That’s rarely a decision — it’s that building the baseline manually takes months of interviews and validation workshops, and by the time it’s finished the roles have moved.
Nestor is an AI-native workforce intelligence platform built to remove that constraint.
| The method requires | What that takes | How Nestor does it |
|---|---|---|
| A capability baseline | Role-level skills mapped across the organisation | AI generates skills, roles, and career paths from workforce data; managers validate what their roles actually require |
| Targeted enablement | Knowing who is furthest from what their work now demands | Skills profiles hold proficiency against current and target roles; gap analysis runs at role and org level |
| Skills connected to what’s next | A visible line from capability to opportunity | Career paths show the specific gap to a target role; AI matches people to internal projects, gigs, and open roles |
| Managers who can coach it | Team-level capability visibility, without added admin | Managers see their team’s skills and gaps; AI agents absorb much of the surrounding administrative work |
| Capability measurement | Proficiency tracked over time, not usage | Skills held with proficiency levels and reassessed, so movement is visible independently of licence data |
Where the AI does the work
- Skills discovery. Capability inferred from workforce data rather than assembled through interview cycles, drawing on a library of more than 20,000 skills with AI-generated suggestions.
- Role and career path generation. Structures that previously took weeks of design work produced as a first draft for managers to correct.
- Smart matching. People connected to internal opportunities on the basis of skills rather than who a hiring manager already knows.
- Agents in everyday HR workflows. Administrative and team-management work handled in the background, which is what keeps the development conversation feasible for a manager with eleven direct reports.
There’s a symmetry worth naming. This article argues that AI delivers where work is high-volume and repeatable, and that the return depends on what people do with the time it frees. Skills mapping is exactly that kind of work. Automating it leaves the judgment — which capabilities matter, and who needs them — with the people who should be making those calls.
See how skills management works in Nestor
Starting points
If you take one thing from this, make it the baseline. Establish where capability actually sits before the next wave of licences, because every other decision in the method depends on knowing:
- Which roles have already changed shape
- Where the gaps are, and how far they run
- Who needs foundational support and who is ready for more
- Which capabilities are worth building deliberately
Delay makes this harder in a specific way. Once tools have been in place for two or three years, low usage in a team has too many possible explanations. The tool might not fit the workflow. The manager might not be sponsoring it. The people might lack the underlying skills. Or the work might genuinely not benefit. Without a baseline taken beforehand, those look identical from a dashboard, and the enablement budget gets spent guessing between them.
Which returns to where this started. Two organisations buy the same tools, run comparable rollouts, and end up with different results. The variable that most reliably separates them isn’t the technology or the change programme around it. It’s what each one knew about its own workforce before it began, and whether it did anything with that knowledge.
