How do we tell the team whose work we're testing AI on?

A test on your team's own work can't stay quiet for long. Someone has to pull the finished documents, and the person who knows the work best is about to be asked to judge drafts of it. If the team first hears about the test from the copy request, the first thing they learn is that it was planned without them.

So tell people in a set order, close together, before anything moves. Acas, the UK's workplace advisory service, says an employer proposing contract changes must inform every affected employee, and warns of a risk of discrimination in overlooking anyone off sick, on parental leave, or needing the information in another form. A test is a smaller step, but the same care applies.

• The reviewer. The person on your team who knows this work best. The owner names them, but ask before announcing it: a reviewer who agreed to the role judges differently from one who was handed it.
• Everyone whose finished work is in the sample, including anyone away that week. Tell them together, then answer individual worries one to one.
• Their supervisor, and whoever covers the desk on busy days, so nobody learns about it second hand.
• IT and whoever looks after privacy, because they will be asked what left the building and why.
• A union or employee representative, where you have one, before the team meeting rather than after it. There is more on that below.

People fill any gap in an explanation with the worst version of it. Give the real reason: a backlog that keeps growing, a role you can't fill, errors that cost you with customers, or growth the desk can't absorb. If part of the reason is cost, say so; the team will work it out anyway.

Then say what the test is and what it isn't. It runs on copies of work the team already finished, sent only after an NDA is signed. Nothing logs in to your systems, and nobody's daily work changes while it runs. AI drafts the same documents again, and the reviewer puts each draft next to what the team did.

The UK government's AI Playbook (2025) asks departments adopting AI for a communication strategy that explains it to staff and reduces resistance to change. A small company needs one meeting and one page. The page matters most, because it is what people reread when a rumour starts: the reason, the dates, the reviewer's name and where to send questions.

The reviewer is not a note-taker for the vendor. Before the test, they agree the success criteria with the owner: which fields have to match, which differences don't matter, and which mistakes would end it. During the test, they score each draft against the team's finished work. At the end, their call decides whether the job goes any further.

That role needs time and authority to mean anything. For the systems it treats as high-risk, the EU's AI Act requires that the people assigned to oversee an AI system have the necessary competence, training and authority, and the support to use them. NIST's AI Risk Management Framework asks for processes for human oversight to be defined, assessed and documented (MAP 3.5). On a desk, that means writing down what the reviewer may decide alone and blocking out the hours in their week to do it.

Tell the team the reviewer can say no, and mean it. A reviewer expected to approve is a rubber stamp, and the people beside them will know it.

In the test, the documents your team already finished are the standard. Each AI draft is scored by how closely it matches what the team did on the same document. Say this early and more than once, because people assume the opposite: that somebody is quietly checking their work.

There is a real overlap to settle in advance. Comparing hundreds of fields will sometimes show that the team's own entry was wrong: a transposed digit, a missed discount, an old ship-to. Decide now what happens then, in writing. We suggest the reviewer marks it as a team error, the draft gets the credit if it was right, and nothing found in the sample goes into anyone's performance review. Without that line, people stop wanting their work in the sample, and the sample gets easier than the real desk.

Names on the documents follow the same logic. Initials in an entered-by field or an approver's signature tell the test nothing it needs, so black them out or swap them for stand-ins such as Clerk A.

While the test runs, nothing changes on the desk. If the reviewer says yes, the same job runs live for about 30 days, and a person on your team approves each item before it posts anywhere. Usually that person is the reviewer or someone else on the desk, so part of the work moves from keying documents to checking drafts of them.

Acas advises employers to consult employees and any representatives when AI is introduced, and notes that expecting certain roles to start using AI could mean a change to their terms and conditions. It also reminds employers that AI output has to be checked for accuracy, tone and bias. Both belong in what you tell the team: the shape of a job may change, and the checking is part of the new shape.

On jobs, say only what is true. If you have decided that nobody loses a job over this, say it and keep to it. If you haven't decided, say that, say when you will, and promise the team hears it from you first. Don't promise an outcome the test hasn't earned, in either direction: it shows whether drafts can be trusted on one job, not what the desk will look like in a year, and no vendor, us included, can promise that for you.

Give the team one place to raise concerns, a named person who answers them, and a way to raise something without their name on it. Then keep a short log: the objection, the answer, and whether anything changed because of it. NIST's framework asks for mechanisms that let the team deploying AI regularly fold adjudicated feedback into the system's design (GOVERN 5.2), and for documented practices that integrate feedback about positive, negative and unexpected impacts (MAP 5.2). Adjudicated is the useful word: each objection gets a decision, even when the decision is no.

Objections about the work are the best input the test will get. "It will never cope with the customer who sends three POs in one email" is a document for the sample, not a complaint to manage. Ask the team to name the hard cases, then make sure they are in.

In the US, objections raised together are protected. The National Labor Relations Board says employees covered by the National Labor Relations Act may join together to improve their wages and working conditions, with or without a union, and that an employer can't discharge, discipline, threaten or coercively question them for that protected concerted activity. When a group email asks what the test means for their jobs, answer it; don't look for who started it.

Where a union represents the team, talk to it first. The NLRB's page on bargaining in good faith says the employer's duty includes not making certain changes without bargaining with the union, and not bypassing the union to deal directly with the employees it represents. It also lists a duty to bargain over the effects of some changes even where the change itself isn't bargainable, and says which kind a change is may present a difficult legal question. A test on copies changes nobody's work, but a live run might, so raise both together.

In the EU, the AI Act requires an employer that puts a high-risk AI system into service at the workplace to inform workers' representatives and the affected workers beforehand. Whether a given system counts as high-risk, and from when, is a question for counsel; the habit is worth keeping either way.

None of this is legal or employment advice. If your team is represented, or you aren't sure what your contracts or local law require, ask your employment counsel before the first conversation.