How to Tell If AI Shifted Work to a Colleague Checking It

A visible checker is a clue, not a transfer finding

When a colleague checks AI output, you can conclude that a review step exists, but not that it is new, takes more effort, or moved to that colleague. They may have checked comparable work before AI, or the workflow may have changed another way. To test for transfer, compare representative work before and after under the same quality bar: who produces, checks, repairs errors, handles exceptions, and signs off, and how much effort each spends through completion. Keep case types and acceptance standards comparable, and count work across handoffs, including correction and accountability. The result describes task allocation in that workflow; it does not establish that anyone’s job is at risk.

What did the revised field experiment actually find?

The version matters. The November 2025 revision of “Shifting Work Patterns with Generative AI” (NBER Working Paper 33795) reports both time savings and no detected change in the broad quantity or composition of tasks. The May 2025 abstract did not include that no-shift sentence. A summary based on the earlier abstract cannot be used to erase a result that appears in the current record; equally, the revised result should not be backdated to the earlier version. The finding here is the one reported by the current November 2025 record.

The study followed 7,137 knowledge workers in 66 firms over six months. Workers were randomly assigned access to a generative AI tool integrated into applications for email, meetings, and writing. Random assignment concerned access: it did not mean every worker used the tool in the same way or amount. That distinction matters when reading the result. The study speaks to what happened under an offer of individual access in these firms, while actual use varied among workers. It is not a controlled assignment of particular review tasks to a second colleague, and access should not be treated as proof that every treated person adopted the tool.

For workers who used the tool, the current NBER record reports less time spent on email and less work outside regular hours. It also reports no detectable shift in the quantity or composition of workers’ tasks from individual-level access over the study period. These findings can coexist: time devoted to some activities can fall without a detected change in broad task patterns. The task result is meaningful counterevidence to a sweeping claim that giving an individual access necessarily changes that person’s overall task mix. It does not demonstrate that access had no effect on any task, nor that every local workflow remained unchanged.

The unit and measures set the boundary. Broad task quantity and composition are not the same outcome as the minutes a named colleague spends checking a particular class of AI-generated output, repairing it, resolving exceptions, or accepting sign-off responsibility. A narrow review duty could be difficult to distinguish in broad measures; that is a limit on what this study can answer, not evidence that such a duty was transferred. The paper therefore cannot decide whether a particular checker in a particular team gained work. That question requires a comparison of the local workflow and the people who own its steps.

The disciplined reading is two-part: the revised randomized study detected no broad task-pattern shift from individual access in its setting, so access alone does not establish broad redistribution. Its outcomes do not settle whether a specific colleague took on new or heavier checking. The study’s scale does not turn broad measures into a local audit, and the local possibility does not invalidate its result. Treat it as relevant counterevidence with a defined scope; tie workplace conclusions to observed ownership and effort.

The paper also discloses that some authors were employed by Microsoft, which made the studied tool. That relationship is relevant context for readers assessing the work, but it is not by itself a reason to dismiss the randomized design or its reported outcomes. The appropriate limit is already visible in the question the study measured: its broad individual-level task result helps test a general claim about access, while it cannot substitute for evidence about one team’s assignment of review and repair.

Sources: Shifting Work Patterns with Generative AI (NBER Working Paper 33795; current record revised November 2025)

Where can human oversight enter an AI workflow?

Checking can happen before a draft is finished, while it is being refined, and during a later review; it is not necessarily one final inspection. In “Episodic oversight in generative AI workflows: A nine-step protocol for preserving human agency (OP-9),” a qualitative interpretive case study of two early-adopting German technology firms describes work organized around drafting, refining, and reviewing episodes. The study drew on 15 semi-structured interviews, three internal AI-use documents, 17 annotated workflow screenshots, and six live demonstrations. It offers a close view of how oversight can appear in work as people use generative AI, rather than a measure of how often any pattern occurs across employers.

Here, an oversight episode means a point in the workflow where a person shapes or evaluates AI-assisted work, contributes context, or helps decide what should happen next. In the study’s drafting episodes, human involvement could shape the request and the emerging material rather than wait for a finished output. During refining, a person could add domain context, adjust wording or substance, and check whether the response fit the task. In reviewing, a person could verify claims, coordinate acceptance, or decide that the material needed another pass. These are distinctions in where oversight occurs; the case study does not establish that every workflow contains each activity as a separate stage or that a named coworker took it over.

Feedback can send work back toward an earlier episode. Review may expose a missing source or mismatch with intended use, prompting refinement, a changed instruction, or another draft before review resumes. Coordination can cross these moments when readiness depends on information or agreement elsewhere. Generation, interpretation, correction, and renewed evaluation therefore connect in loops. A map showing only final approval misses earlier interventions and returns, even when approval is easiest to observe.

This process model changes what a local observer should look for, without deciding whether work shifted. A person might supply context, check a claim, coordinate sign-off, or return an item for correction; these are distinct kinds of oversight with potentially different owners. Their presence does not show they are new, take more time, or belonged to another worker before the change. The cases describe possible process structure, not episode frequency, checking minutes, or individual workload changes.

The two-firm process model is a useful lens for choosing what to observe: follow work through drafting, refinement, review, and return loops rather than treating checking as a single endpoint. Its scope matters. These were early adopters in two German technology firms, not a representative sample of occupations or organizations. The cases cannot show that all teams use these episodes, that each adds labor, or that a task moved between colleagues. A local comparison must establish those points from its own cases and baseline.

Sources: Episodic oversight in generative AI workflows: A nine-step protocol for preserving human agency (OP-9)

Why can faster production coexist with a different checker workload?

A higher producer output rate can coexist with a checker spending more time on verification, because output and reviewer effort are different measures. “Generative AI at Work” (NBER Working Paper 31161) studied a staggered introduction of a conversational assistant among 5,179 customer-support agents. It reported an average 14% increase in issues resolved per hour. The reported productivity measure is an output rate: issues resolved relative to hours worked. It says what happened to that measured production outcome in the studied rollout; it does not, by itself, describe every person’s contribution to each resolved issue.

The average also concealed variation across workers. The study reported larger gains for novice and lower-skilled agents, with minimal impact for experienced and highly skilled agents. This heterogeneity is part of the result, not a detail that can be replaced by the overall average when considering a particular team. It signals that the same assistant and rollout did not produce an identical measured gain for every group in that setting. It does not tell us that experienced agents became checkers, that novices received more oversight, or that either group spent more time repairing outputs. Those are separate workload claims, and the reported issues-per-hour outcome does not establish them.

This is a limit of the metric, not a defect in the study. Issues resolved per hour measures an output rate but not who verified, corrected mistakes, or handled exceptions. The result supports its productivity finding, but cannot show how checking was allocated, whether it grew heavier, or whether team effort rose or fell. The evidence summarized here does not isolate a checker, review minutes, or repair workload.

For a local comparison, keep producer output and checker effort alongside one another. Record volume and active effort in production, review, correction, and exception handling, then assess quality against the same standard on comparable work. Drafts per hour without checker effort can show faster production while leaving review demand unknown. Checker time alone cannot show whether the team completed more work or reduced effort elsewhere. Ask what each measure captures and leaves out instead of making one rate stand in for the workflow.

For illustration, imagine a tool helps a producer complete more first drafts while another person checks some. Drafts per hour cannot establish checker time; checker minutes cannot show whether added drafts changed completed output or displaced other work. The example assumes no outcomes. Both sides need observation: measured output may rise while reviewer effort remains unknown.

The rollout therefore provides a bounded productivity result and a reminder to match claims to measures. Its one-firm setting and specific assistant do not establish the same effect elsewhere, and its average does not erase the reported differences by experience and skill. Issues resolved per hour is not another colleague’s verification burden. A local handoff assessment also needs evidence about checking and repair effort, alongside producer output and quality.

Sources: Generative AI at Work (NBER Working Paper 31161)

What can an occupation exposure estimate tell you about a local handoff?

No occupation exposure score can establish that review work moved at a particular employer. Occupational exposure is a modeled estimate of how much an occupation’s documented tasks could be affected by a technology under stated assumptions. It can help a reader decide which recurring task to inspect first; it does not record who at a workplace used a tool, checked its output, or inherited responsibility.

The International Labour Organization’s 2025 report, “Generative AI and Jobs: A Refined Global Index of Occupational Exposure (ILO Working Paper 140),” builds its index from tasks rather than treating a job title as indivisible. Its methods draw on a Polish occupational classification of 29,753 tasks and a survey of 1,640 employed people across one-digit ISCO-08 groups. Respondents supplied 52,558 data points on perceived automation potential for 2,861 tasks. Researchers combined these with expert survey and Delphi-style discussion, then used an AI assistant to predict scores for remaining task documentation. This structured estimate of task applicability is not an observation of a specific employer’s work allocation.

The report groups results into four gradients of exposure, from minimal through low and medium to high. The gradients describe modeled potential exposure, not a ranking of workers who will lose jobs or colleagues likely to become reviewers. The ILO’s interpretation is that transformation is more likely than full automation. That finding is useful for framing a local question: if a role contains recurring information tasks with plausible AI applicability, which of those tasks should the reader trace through production, checking, repair, and sign-off? The broad estimate offers a starting point for selecting a task, while the workflow itself supplies the evidence about its owners.

A high category cannot tell whether a tool has been adopted in the reader’s team, how often a documented task occurs there, whether its outputs meet the team’s standard, or who handles exceptions. Two people with the same occupational classification may do different mixes of work, and a task described in a classification may not map neatly to a team’s actual unit of work. Even where the tool appears in a familiar task, its presence does not identify whether a producer checks their own output, a colleague reviews it, or another role owns final approval. Those are assignment facts that an occupational index does not measure.

This boundary does not make the ILO index useless. It helps prioritize an inquiry when the reader faces many possible tasks: begin with repeated work that the index identifies as plausibly exposed, then test the local handoff for that specific work. Keep the index as context for why the task merits attention, not as proof that responsibility changed. The local comparison in the next section addresses that different question by recording what happened to the same kind of work and who contributed at each step.

Sources: Generative AI and Jobs: A Refined Global Index of Occupational Exposure (ILO Working Paper 140)

How do you compare the work before and after AI?

A useful local comparison follows comparable work through the process, keeps the quality standard steady, and records ownership and active effort at each step. It is a practical diagnostic, not a validated instrument. Choose inspectable cases from defined periods before and after the workflow change. State how they were selected, what periods they cover, and what work may be missing; describe a small traceable sample without implying it represents every case.

Define the unit before counting: one document, customer query, analysis, or other completed item, with enough detail to distinguish routine work from exceptions. For each unit, record whether AI was used if that is known, then identify the producer, checker, repairer, exception owner, and sign-off owner. One person may fill several roles; record that rather than treating role labels as separate people. If ownership is unclear, mark it unknown and note what record or conversation could resolve it. This makes a change in responsibility visible without assuming that a tool’s presence explains how the work was assigned.

Track active effort by person for production, checking, repair, exception handling, and sign-off. Keep waiting time separate from time spent working: a case waiting for approval may affect turnaround but does not, by itself, show how many minutes the checker worked. Use the same time unit and practical boundary in both periods, such as active minutes through an agreed completion point. If exact time is unavailable, a consistent qualitative record can still show who participated and where effort appears to have changed, but it cannot support a precise time comparison. Do not silently convert estimates, elapsed time, or queue delay into labor time.

For quality, record the acceptance threshold used and the result against it: accepted, repaired, returned, escalated, or still unresolved, as applicable. Keep the criterion as stable as possible across the before and after cases. A change in the standard can make review appear heavier simply because reviewers are now asked to catch more, or make it appear lighter because less is being checked. Record output count for each period too, along with work removed, deferred, or newly created. More review effort per item can coexist with a higher volume of items; the total workload and the per-item burden answer different questions.

Compare like with like: unit type, complexity, quality threshold, and completion boundary. Lay case sequence beside owner and effort records. Ask whether checking existed at similar effort, whether one person’s responsibility became new or materially heavier, and whether their other work was reduced or displaced. Note volume and repair or exception rates too: a single total can hide a transfer, while rising minutes for one person may overstate team change if another task disappeared.

For example, if a producer uses AI for a first draft and a colleague checks it, more review effort per item could coexist with fewer other steps or a different output volume, leaving combined workflow effort lower. If review per item stays the same but more items arrive, total checking effort could rise because volume grew. These are hypothetical patterns the comparison can distinguish, not observed outcomes; presume neither before examining cases.

Use four labels for the conclusion. Continuity means the review responsibility and effort look materially similar to the baseline. Augmentation means AI changed or added to the process, while the observed pattern includes other work, output, or effort changing too; describe those dimensions rather than compressing them into a simple faster-or-slower verdict. Transfer means the comparison supports a newly assigned or materially heavier review, repair, exception, or sign-off responsibility for someone, considered with that person’s workload and any corresponding relief elsewhere. Unresolved means the sample, ownership, effort, quality standard, or baseline is too incomplete or unlike the comparison to support one of those readings.

A small sample may miss rare but costly exceptions or ordinary variation. It can still support a bounded account if the reader states the selection, period, and gaps, and avoids extending a few cases to every workflow. The protocol can show a before-and-after pattern; by itself, it cannot prove that AI alone caused it when staffing, policy, demand, or standards also changed. The most useful finding is therefore specific about the cases observed, the people and effort recorded, and what remains unknown.

What makes a review assignment defined enough to evaluate?

A review assignment is evaluable when the worker can see the standard, inspect the needed evidence, and has authority and time to respond when output falls short. The National Institute of Standards and Technology’s “Appendix C: AI Risk Management and Human-AI Interaction (NIST AI RMF 1.0)” is voluntary guidance, not a law, outcome study, or instruction to put a person in every workflow. NIST describes roles from autonomous to manual, with the appropriate role depending on context. Ask locally what must be checked, against what material, by whom, and what happens if it fails.

Start with the acceptance standard. Can the checker identify what counts as correct, complete, safe, or ready for the intended use? Is that criterion written down or available from a responsible owner, and does it remain stable across the cases being compared? A vague instruction to “review the AI” offers no consistent boundary for effort: one person may check only obvious factual errors, while another may be expected to verify every source, implication, and edge case. If expectations changed when the tool arrived, record that change separately from any change in the work itself. Otherwise a higher bar can look like more work even if the underlying output burden is similar.

Next ask whether the reviewer has access to the evidence the standard requires. A person cannot reliably verify a claim against source documents they cannot open, compare an answer with customer context they never received, or check a calculation without its inputs. Missing access can turn a short inspection into searching, repeated requests, or guesswork. Record which materials are available at the point of review and what has to be fetched from another person or system. Distinguish time spent applying a standard from time spent reconstructing the evidence needed to apply it; both can matter to workload, but the second may be a process dependency rather than an inherent property of checking AI output.

Define the cases in scope before assigning responsibility. Does review cover every item, a sample, high-impact cases, unfamiliar outputs, or exceptions flagged by the producer? Who decides which cases qualify, and can the checker return an item outside that boundary? The answers affect both what the reviewer is accountable for and how much work arrives. A reviewer named as responsible for “quality” may have a broad expectation that bears little relation to the actual queue or sampling rule. State what is included and excluded, then compare like cases over time; without a clear scope, a difference in review effort may reflect a change in which cases reach the reviewer rather than a heavier assignment on comparable work.

Authority and repair ownership matter as much as the act of noticing a problem. Can the checker reject or pause an output, request a source, escalate a consequential uncertainty, or only leave a comment? Who corrects the draft, resolves an exception, and decides whether a repaired version meets the standard? Who gives final sign-off, and can that person see the earlier review record? If the checker identifies failures but another role must authorize every correction, the checker may carry detection and coordination work without controlling resolution. Map these responsibilities separately rather than treating “human oversight” as a single task or assuming that a reviewer who can flag an issue also owns the repair.

Finally, ask whether review has capacity. What work is reduced, delayed, or reassigned as review expands? Is there time for difficult cases, and what happens when the queue exceeds it: sampling, escalation, delay, or pressure to work faster? NIST supports differentiating human roles but does not establish that an arrangement improves outcomes. A nominal reviewer without a standard, source access, repair path, or capacity is not evidence of an effective control; the title alone cannot show how much work shifted.

Specialist accounts help explain why those arrangements depend on infrastructure and resources. “The Impact and Opportunities of Generative AI in Fact-Checking (FAccT 2024)” reports semi-structured interviews with 38 participants from 29 fact-checking organizations in 19 countries across six continents. The paper describes varied contemplated or existing AI uses and technical, organizational, and value-related challenges. Its purposive and snowball sample gives qualitative accounts from a specialized verification field; it does not estimate how common those barriers are among knowledge workers, quantify review hours, or show that AI transferred work between colleagues. Its contribution here is narrower: verification is situated in tools, organizational conditions, and professional standards, so the local checker’s access and authority belong in the account of the assignment.

The practical test is not simply whether a person appears in the process. Identify the standard and source access, cases covered, reviewer authority to reject or escalate, repair and sign-off owners, and workload capacity. If a new review duty lacks needed evidence or authority, describe its constraints rather than implying effective oversight. An unchanged, adequately resourced arrangement is useful baseline context. A review label is meaningful when the worker’s decision, inputs, and capacity are specified.

Sources: Appendix C: AI Risk Management and Human-AI Interaction (NIST AI RMF 1.0); The Impact and Opportunities of Generative AI in Fact-Checking (FAccT 2024)

When is the evidence strong enough to call it a transfer?

Call a pattern a transfer only when a comparable before-and-after record supports a newly assigned or materially heavier checking, repair, exception, or sign-off responsibility for a particular person, and the record shows no equivalent relief for that person elsewhere. Keep that person-level finding separate from the team’s total effort and output. Review minutes may rise for one colleague even while another step shrinks or the team completes a different volume of work; those observations can coexist. The label should report the supported change in responsibility, not imply that total labor rose, that a job disappeared, or that AI alone caused the change.

Continuity fits when review existed before the workflow changed and remains similar in ownership and effort for comparable cases. A reviewer appearing in the new process may already have performed the duty. Compare case type, quality criterion, and completion point. If a title or written role predates adoption but actual work is undocumented, report the formal role as known and effort as unresolved; a job description is not a record of work.

A mixed pattern should stay mixed. If review effort grows while another task recedes, report both the heavier review responsibility and the offsetting change in that person’s workload; do not collapse them into a single verdict that the person simply gained or lost work. If output volume rises, distinguish effort per item from total effort across the period. If the quality bar changes, state that alongside the review result, because a stricter standard may explain additional checking without proving that the AI output itself became harder to handle. These cases fit augmentation or mixed allocation when the comparison documents multiple dimensions, rather than a clean transfer claim stripped of its context.

Before-and-after records can coincide with unrelated changes in staffing, demand, case complexity, or policy. A pattern beginning after adoption is associated with the new workflow, but timing alone does not show AI caused it. Narrow the wording to the observation: “In the sampled cases after the workflow changed, this colleague handled newly assigned review and repair work; other staffing and demand changes mean the tool’s independent contribution is unclear.” A comparison group, stable rollout, or clearer assignment record could test the explanation more strongly.

Use unresolved when the comparison cannot distinguish among these readings. Missing baseline effort, unclear ownership, unlike cases, an undocumented quality bar, or an unknown change in volume can each prevent a defensible transfer classification. Name the missing comparison that would change the call: earlier records of who checked similar cases; a consistent sample under the same acceptance standard; effort by person and step; or a record of work removed or deferred. Unresolved is not a finding that nothing changed. It identifies which part of the decision the available evidence cannot settle and directs the next observation toward that gap.

There is no universal number of extra minutes or cases that defines transfer. Evidence may range from reliable time records and stable case types to a documented comparison of responsibilities and sequence. Match precision to comparability. Report the unit and period, added or heavier responsibility, equivalent relief, team output and effort separately, and known competing changes. Preserve ambiguity where these do not align.

Start with one traceable case and one owner

Ask for one representative AI-assisted case and one comparable case from before the workflow changed. You could say: “Could we identify who produced, checked, and repaired each case, note the acceptance standard, and clarify who owns review and repair now? When can we revisit the comparison?” A named owner and date make the follow-up concrete. The aim is to understand these cases and the assignment, not infer a wider workforce change from one example.

If you cannot access the cases or do not have authority to request them, record that specific gap and ask who owns the process decision or can arrange a suitable comparison. Missing records do not establish that work transferred, and they do not establish that nothing changed; they leave the question unresolved until someone with access can check. A useful next step may simply be identifying that person and asking what evidence can be reviewed, rather than claiming a result the available information cannot support.

If this comparison raises a separate question about your own career choices, the optional paid career roadmap compares scenarios against your constraints and builds a 30/60/90-day plan; it does not guarantee employment or income. For a free first look at your own tasks, the checker at [/ai-job-risk-checker](/ai-job-risk-checker) reports transparent task-level change-pressure signals, not a validated probability of displacement. Neither tool determines what happened to a colleague in a particular workflow.

Questions readers ask