Ask workers where the AI moved the work

A support team pilots an assistant that drafts replies. The demo is convincing: a case enters, a polished answer appears, and the agent only has to approve it.

The live workflow tells a different story. Straightforward cases move faster. Ambiguous cases now arrive with confident drafts that take longer to verify than to write. Senior agents inherit more escalations because junior colleagues cannot tell whether a plausible answer is grounded. Supervisors add spot checks. Someone starts retaining prompts for quality review, creating a new store of customer and employee data. The product manager reports time saved at the drafting step.

Nobody records where the work went.

This is the adoption review many AI programs miss. They ask whether people use the tool, whether output quality is acceptable, and whether the business case works. They do not inspect how the intervention redistributes judgment, interruption, exposure, and accountability across the people doing the process.

Before scaling an AI workflow, run a work-delta review with the people who will operate it. The question is not whether they like AI. It is: what work disappears, what work appears, and who inherits each part?

The demo follows the happy path

A model demonstration usually starts with a clean input and ends with a usable output. Operations live in the space between those points.

Workers see missing context, damaged source records, policy exceptions, inaccessible interfaces, unusual customer needs, and outputs that are almost right. They know which error can be corrected quietly and which one creates a contractual, safety, privacy, or reputational problem. They also know which informal steps keep the existing process functioning even though those steps never made it into the process map.

That knowledge is not merely “change feedback.” It is deployment evidence.

The NIST AI Risk Management Framework says deployment context should be informed by end users, impacted communities, domain experts, and others outside the team that built or deployed the system. It connects that engagement to finding real-world constraints, defining human oversight, testing assumptions, and identifying both beneficial and harmful impacts NIST AI RMF Core.

A launch team cannot collect that evidence by showing a finished tool and asking for reactions. It needs to let operators challenge the workflow while there is still time to change it.

Draw the work that changed hands

Put the old and proposed workflows side by side. Do not stop at the main task. Trace five kinds of work:

Work type	What to look for	A question for operators
Primary work	Drafting, searching, classifying, deciding, recording, sending	Which step actually gets easier?
Review work	Verification, source checking, correction, approval	What must a reviewer now notice?
Exception work	Escalations, appeals, unusual inputs, tool failures	Which cases become harder or more frequent?
Control work	Access administration, sampling, logging, monitoring, incident response	Who performs the control, and what evidence do they need?
Recovery work	Correcting records, contacting affected people, reverting to a fallback	Who repairs the outcome when the AI step fails?

Then assign each changed task to a role. “Human in the loop” is not a role. Name the person or team, the decision they make, the time and information they need, and what happens when their queue is full.

The resulting artifact can be short:

Change	Receiver	Operating condition	Decision
Drafting decreases	Support agent	Approved cases only	Keep
Source verification increases	Support agent	Source links shown beside draft	Redesign interface
Policy exceptions concentrate	Senior support	Escalation queue has a named owner	Measure during pilot
Prompt samples are retained	Quality team	Restricted access and deletion period documented	Privacy review before launch
Incorrect saved replies require repair	Support operations	Original sources and editor identity remain available	Add recovery procedure

This example is hypothetical. Its purpose is to make the transfer explicit. A claimed saving in one row is not a workflow saving if another team absorbs more work, more risk, or both.

Consultation is design work, not rollout messaging

There is a weak version of worker consultation: announce the system, explain that it assists rather than replaces people, collect questions, and proceed with the design unchanged. That is communication. It may be necessary, but it is not consultation.

Useful consultation gives participants a real decision surface. Show the intended use, data access, output destination, review rule, performance evidence, known limits, and proposed measures. Then be explicit about which parts can change. Operators should be able to narrow the eligible cases, reject an unusable review step, add an escalation, identify training needs, or show that the non-AI process is the better alternative.

OECD workplace case studies show why this changes the design. In one insurer, claims workers challenged the precision and practical productivity of an AI estimate. The company used repeated discussions to address the discrepancies and adjust usability. In a bank, consultation clarified how duties would change and how staff should interpret the system’s judgments. The same report adds an important warning: reassurance about job stability may be short-lived when workers have heard similar promises before OECD workplace case studies.

Do not turn those cases into a universal claim that consultation guarantees adoption or productivity. A later OECD laboratory experiment in three German manufacturing firms found that workers, managers, and works council representatives could agree on altered designs they judged to preserve productivity gains while improving job quality. The study itself calls for broader research across more settings OECD experiment on worker consultation.

The practical conclusion is narrower: the people closest to the work can expose design variables that a project team may otherwise miss, and a consultation that cannot affect those variables is unlikely to find them.

Ask about the uncomfortable transfer

The meeting earns its time when it surfaces issues that a product demo avoids.

Ask operators:

• Which cases should never enter this workflow?
• What knowledge does the proposed review require, and who actually has it?
• Which errors will look plausible enough to survive a quick review?
• Who receives more interruptions, appeals, or emotionally difficult cases?
• Does the tool reduce discretion, or make someone responsible for a decision they can no longer explain?
• What interaction data could be used to monitor employee performance, even if that is not the launch team’s intent?
• What accessibility needs or working conditions does the design assume?
• If the tool is unavailable or wrong, can the team still complete the work?
• What would make an operator pause the workflow, and are they authorized to do it?

Run an exception walkthrough as well as a happy-path walkthrough. Use synthetic or safely prepared cases so the session does not spread personal, confidential, or regulated data. Give people a private reporting route for concerns they may not raise in front of managers, especially when the system could influence workload, performance evaluation, scheduling, promotion, or job security.

Do not use consultation notes as a new employee-monitoring dataset. Record the workflow finding and design decision, not a dossier of who expressed doubt. Limit access, set a retention period, and separate operational research from individual performance management.

Know when information is a legal floor

For organizations operating in the European Union, worker involvement can also be a scoped legal obligation rather than only a good operating practice.

Article 26(7) of the EU AI Act says that, before an employer puts a high-risk AI system into service or uses it at work, the employer must inform workers’ representatives and the affected workers, following applicable Union and national rules and practices Regulation (EU) 2024/1689. The obligation is tied to high-risk systems; it is not a claim that every workplace assistant falls into that category. “Inform” in this provision also should not be stretched into a claim that the AI Act itself requires the work-delta consultation described here.

Employment, privacy, collective bargaining, works council, health and safety, and sector rules may impose other duties. Have qualified legal and employee-relations teams determine what applies in the relevant jurisdiction. A voluntary workshop is not a substitute for a required information, consultation, assessment, or negotiation process.

That legal distinction improves the operating model. Compliance sets the minimum procedure. Workflow consultation tries to produce a system that people can operate safely and effectively. Treating one as a substitute for the other weakens both.

Decide with the delta in view

End the review by changing something or recording why no change is needed.

The workflow owner should accept, mitigate, reassign, or reject every material transfer. If review work rises, budget capacity and test whether reviewers have enough context. If exceptions concentrate, set an escalation owner and service expectation. If monitoring expands, narrow the data or complete the appropriate privacy and worker review. If accountability moves to someone without authority or expertise, redesign the decision boundary.

Sometimes the result should be no rollout. That is reasonable when the process is too variable, reviewers cannot reliably detect important errors, the organization cannot support the exception queue, the data boundary is unacceptable, or the people held responsible cannot inspect or contest the system’s contribution. A deterministic rule, better search, a simpler template, staffing, or process repair may solve the actual problem with less hidden work.

Small, private experiments using public or synthetic information may not need a formal workshop. A short walkthrough with the people performing the task can be proportionate. High-impact workflows affecting employment, access to services, safety, finance, or legal rights need specialist assessment and formal procedures beyond this review.

Connect the result to the existing operating system. Put the new effort and risk into the workflow scorecard. Add the changed responsibilities to the decision-rights record. Train people on the exceptions they will actually handle instead of counting course completion as proof of AI literacy.

Run the work-delta review again when the model, vendor, input data, eligible cases, monitoring or retention practices, escalation load, or applicable rules change. A review that described the pilot may no longer describe the operating workflow.

An adoption program should be able to say more than “the tool saved time.” It should know whose time, at which step, under what conditions—and where the rest of the work went.