ProcessPeople & Organizational Performance

Assessing AI's impact on jobs in your organization, one task at a time

Headline studies of AI and jobs rate whole occupations across an economy. They cannot tell you what will happen to the claims handlers, analysts or schedulers in your own teams. This method works below the job title: inventory the tasks, classify each one against written rules, filter for data, error tolerance and regulation, estimate the capacity shift as a range, and turn the result into redeployment, reskilling and a pilot sequence.

Reviewed 8 min read

On this page
  1. Why occupation-level exposure scores do not transfer to your teams
  2. The assessment pipeline from task inventory to pilot plan
  3. Five steps to a defensible task-level assessment
  4. Classification rules for automate, augment, unchanged and new tasks
  5. Feasibility filters that move a task to a more cautious category
  6. Consultation and trust before any pilot starts
  7. Hypothetical example: a claims operations team
  8. Questions and answers
  9. Sources

Why occupation-level exposure scores do not transfer to your teams

Published exposure studies usually start from a national occupational database, score each listed task for how much an AI model could help with it, and average the scores up to the occupation. That describes an economy reasonably well. It is a poor basis for decisions about your own people, for three reasons.

First, your version of a job is not the average one. Two insurers can employ claims handlers whose days look nothing alike, because one has digitized intake and the other still keys data from paper. Second, exposure is not feasibility: a task can be technically suited to automation and still be blocked by missing data, a regulator's expectations or the cost of a wrong answer. Third, an exposure share hides time. A role in which AI could help with half the listed tasks may barely change if those tasks take an hour a week.

The method below keeps the useful part of the research, which is thinking in tasks, and replaces the averages with evidence from your own processes. It puts into practice a principle from the people and organizational performance capability: every AI deployment should come with an assessment of what it does to the work and a plan for the people doing it.

The assessment pipeline from task inventory to pilot plan

01Task inventory02Classify each task03Feasibility filters04Capacity ranges05People pathways06Sequenced pilots
  1. Task inventory

    List the tasks in each role from job descriptions, process maps and interviews.

  2. Classify each task

    Label each task automate, augment, unchanged or new using written criteria.

  3. Feasibility filters

    Test data access, error tolerance, oversight needs and regulation.

  4. Capacity ranges

    Estimate the time released or added per role, with a low and a high case.

  5. People pathways

    Decide whether each role is redeployed, reskilled, reshaped or left alone.

  6. Sequenced pilots

    Order the first deployments so people moves and system changes line up.

Conceptual pipeline of a task-level AI impact assessment. Each stage feeds the next; the diagram shows no measured results.

Five steps to a defensible task-level assessment

  1. Build the role-and-task inventory

    Start from current job descriptions, then correct them against process maps, process mining output where it exists, and short interviews with people in the role and their managers, because written descriptions lag the real work. Express each task as a verb and an object, such as 'check a claim form against the policy schedule', and record roughly how much of the week it takes. O*NET task statements help with wording and with spotting tasks people forget to mention1.

    Output
    Task inventory per role, with time shares
    Owner
    Workforce planning lead with process owners

  2. Classify each task

    Apply the rules in the table below to every task. Have two people classify a sample independently and compare the results; where they disagree, the rule is too vague and should be rewritten before you go further.

    Output
    Classified task list
    Owner
    Assessment team

  3. Apply the feasibility filters

    Move a task to a more cautious category when the data is out of reach, when errors are costly and hard to reverse, when a person must stay accountable for the decision, or when regulation requires human involvement. Note the reason for each move, because many of them can be fixed later.

    Output
    Filtered classification with reasons
    Owner
    Data, risk and process owners

  4. Estimate the capacity shift as a range

    For each role, add up the time spent on tasks that will be automated or augmented, apply a low and a high assumption for how much time the tool really saves, and add the time new tasks will need, such as reviewing output and handling exceptions. Keep the assumptions beside the figures so anyone can challenge them.

    Output
    Capacity range per role, with assumptions
    Owner
    Finance partner and workforce planning

  5. Design the people pathways

    Decide, role by role, whether to redeploy released capacity to unmet demand, reskill people for the augmented version of the job, reshape the role around new tasks, or leave it as it is. Link each pathway to the skills it needs, using the identifiers from your skills taxonomy.

    Output
    Pathway per role and a reskilling backlog
    Owner
    HR business partners and line leaders

Classification rules for automate, augment, unchanged and new tasks

CategoryThe task qualifies whenEvidence to look forWhat happens to the time
AutomateOutput can be checked by rule or sampling, inputs are structured or reliably extractable, and a wrong result is cheap to catch and reverseStable inputs, few exceptions, an existing quality check further down the processReleased for redeployment once the system is stable and monitored
AugmentA system can draft, search or summarize, but a person must judge, approve or adapt the resultVariable inputs, judgment calls, accountability to customers or regulatorsPartly released; some is reinvested in review and in harder cases
UnchangedThe value lies in physical presence, relationships, negotiation or accountability that cannot be delegatedFace-to-face work, conversations that depend on trust, formal sign-offsStays with the role, and may grow as other tasks shrink
NewThe task exists only because a system was introducedReviewing outputs, working exception queues, maintaining prompts, rules or evaluation setsAdded to the role, and must be staffed before any benefit is counted

When a task fits two categories, use the more cautious one until a pilot produces evidence.

Feasibility filters that move a task to a more cautious category

  • If

    The data the task needs sits in documents or systems the tool cannot reach.

    Then

    Classify the task as augment at most, and log the data fix as a prerequisite with an owner.

    Planning around access that does not exist yet produces capacity that never appears.

  • If

    An error would be expensive, hard to detect or hard to reverse.

    Then

    Keep a person reviewing every output, and move to sampling only after monitored results justify it.

    Tolerance for error, more than model capability, usually sets the ceiling.

  • If

    The task produces a decision with legal or similarly significant effects on a person.

    Then

    Keep a person with real authority in the decision.

    The GDPR restricts decisions based solely on automated processing in these cases, and the EU AI Act lists many employment uses as high-risk23.

  • If

    The task depends on trust built over time, such as handling a distressed customer.

    Then

    Leave it unchanged and protect the time it needs.

    Removing it to save minutes can cost the relationship the role exists to maintain.

Consultation and trust before any pilot starts

An assessment that looks like a headcount exercise will be treated as one. Publish the method before the results, explain that it produces ranges and pathways rather than redundancy lists, and say who will see role-level findings.

Where employees are represented, consultation is often a legal duty as well as good practice. In Germany, the employer must inform the works council in good time about planned work processes that include the use of AI4, and the works council may bring in an expert when it has to assess AI5. Across the EU, Directive 2002/14/EC sets a general framework for informing and consulting employees about decisions likely to change work organization6, and employers deploying a high-risk AI system must inform workers' representatives and affected workers before it is put into service at the workplace3.

Trust also depends on what happens to released capacity. If the plan for it is vague, people assume the worst, and the most capable leave first.

Hypothetical example: a claims operations team

Questions and answers

How often should a task-level AI impact assessment be repeated?

Revisit it whenever a significant system goes live or a pilot finishes, and at least annually for roles where AI tools are changing quickly. The inventory and rules are reusable, so a refresh means updating the classifications that new evidence has changed rather than starting again. Pilots are the most useful trigger, because they replace assumed time savings with observed ones.

Who should own the assessment: HR, IT or the business?

The business owns the result, because line leaders decide how work changes and are accountable for the people affected. HR or workforce planning usually runs the method and maintains the inventory, IT and data teams supply the feasibility evidence, and risk and legal review the filters. Handing it to IT alone tends to produce a technology plan with a people appendix.

Can a language model classify the tasks for us?

It can draft classifications quickly, which is a reasonable way to start a large inventory. Treat its output as a first pass: models tend to rate tasks by how they are described rather than how they are actually done, and they know nothing about your data access or controls. Keep the human classifiers, the written rules and the disagreement check from the second step.

How should roles that AI creates be handled?

Name and staff them early. Review, exception handling and evaluation work often lands informally on the most experienced people, who then have less time for complex cases. Give each new task a home in a role profile, define the skills it needs and count its time in the capacity range before claiming any benefit from the deployment.

Sources

  1. O*NET Resource Center: overview of the O*NET program and content model — National Center for O*NET Development, sponsored by the US Department of Labor · checked 10 October 2026
  2. Regulation (EU) 2016/679 (General Data Protection Regulation), Article 22 — EUR-Lex · checked 10 October 2026
  3. Regulation (EU) 2024/1689 (Artificial Intelligence Act), Annex III and Article 26 — EUR-Lex · checked 10 October 2026
  4. Betriebsverfassungsgesetz (Works Constitution Act), § 90 — Federal Ministry of Justice (Germany) · checked 10 October 2026
  5. Betriebsverfassungsgesetz (Works Constitution Act), § 80 — Federal Ministry of Justice (Germany) · checked 10 October 2026
  6. Directive 2002/14/EC establishing a general framework for informing and consulting employees — EUR-Lex · checked 10 October 2026

More in People & Organizational Performance

Back to People & Organizational Performance

Next step

Plan the workforce assessment for your next AI rollout

Tell us which roles a planned AI deployment touches and how current your process maps are. We will suggest how to scope a task-level assessment and which evidence to collect first.

Scope a workforce assessment