Agree the etiquette for AI-written messages on your team

Example result.

1. Our organisation's AI policy comes first. These lines sit underneath it.
2. You own what you send, however it was drafted. Routine messages need no label.
3. Anything presented as your view, or feedback on someone's work, says so.
4. Thanks, apologies and difficult news: write them yourself.
5. Our phrase says what was checked, e.g. "AI-drafted summary — I've checked the dates against the call notes."
6. Client material only goes into the company AI account. Ask Morwenna if unsure.

1. Agree that the sender owns what they send

Settle this first, before anyone argues about labels. If your name is on a message, the content, tone, figures and promises are yours, whoever or whatever drafted them. Then check what your organisation already requires: any disclosure rule, approval step or approved account. Your norm sits underneath those and never over them.

Why this works: it changes the question from “is using AI acceptable?” to “when does the reader need to know?”, which has a different, easier answer for each kind of message.

What you should see: agreement in about a minute, and a short list of rules you can’t change locally.

2. Sort five messages into three buckets

Don’t do this in the abstract. Have five people each bring one message from last week, and sort them in the room. Use fictional or fictionalised versions where a message is private, and don’t ask anyone to bring an uncomfortable personal exchange.

• No need to say. Routine and functional, where the content is the point: invitations, status updates, documentation, a call summary whose facts are checkable against the notes. Nobody announces that they used spellcheck or last week’s template.
• Say so. Where a reasonable reader would want to know: your personal view or judgement, feedback on someone’s work, a customer-facing assessment of their situation, and the one teams miss — anything a reader might act on as if it had been verified, such as a summary full of dates and figures.
• Write it yourself. Where the writing is the point: thanks meant to land, an apology, difficult news for one person. Help with accessibility, translation or wording is fine here; the meaning has to come from the sender.

Expect an argument about the middle bucket. Settle it by splitting the message type rather than voting.

Why this works: real messages make the norm concrete, and the disagreement surfaces the rule your team already half-holds.

What you should see: every message in one bucket, and at least one message type split in two.

3. Pick one disclosure phrase that says what was checked

“Written with AI” is an origin story. The reader’s question is whether they can rely on the dates. Choose phrasing that answers it:

"Drafted with AI, checked by me."
"AI-drafted summary — I've checked the dates and figures against the call notes."
"AI summary, unchecked — treat as a starting point." (internal review only)

The third option matters more than it looks. Sometimes a rough summary today is more useful than a checked one tomorrow; without an honest way to say so, people either rush the check or imply they did it. Keep it for internal review, never for anything a client or decision relies on.

Pick one wording and use it consistently. Six variations read as six degrees of hedging, and colleagues will start interpreting the differences.

Why this works: a phrase about checking tells the reader what they can rely on; a phrase about origin tells them nothing they can act on.

What you should see: one agreed phrase, plus the unchecked variant if the team wants it.

4. Write the six lines, then look for the gaps

Six lines, in the place your team already looks: a pinned message, a team page or the top of your ways-of-working document. Longer than that and it becomes a policy nobody reads. Then ask an assistant to find what it doesn’t cover:

Here is our team's six-line norm for AI-written messages, and the message types we send most.

Name the three message types this norm does not clearly cover. For each, quote the ambiguous line and give the two possible readings.

Do not propose new rules, rewrite the norm or judge whether it is good. Only identify ambiguity.

[norm and message types]

[norm and message types] means the six lines and a plain list such as “weekly update, client call summary, proposal letter”.

Why this works: asked for an opinion, an assistant returns a longer, more corporate norm. Asked only for ambiguity, it does a useful proofreading job and you keep your own words.

What you should see: three message types, each with a quoted line and two readings. Decide the real gaps as a team; ignore any the assistant has invented.

Check the result

• Each of your five messages lands in one bucket from the six lines alone, without re-running the discussion.
• Line 1 points to the organisation’s policy, and line 6 names the account and the person to ask.
• The disclosure phrase says what was checked, not only that AI was involved.
• An apology or thank-you clearly falls under “write it yourself”.

The usual failure: the label passes and the message doesn’t. A summary carries “checked by me” while a proposed date has quietly become a firm one. Spot it by comparing every date and figure with its source before the label goes on.

Compare this summary with the source note. List every date, figure and commitment in the summary. For each, quote the source and say whether the source states it as confirmed, proposed or not at all. Flag any line where the summary is firmer than the source.

SUMMARY
[summary]
SOURCE NOTE
[source note]

[summary] is the AI-drafted message; [source note] is the notes, booking or email it was drafted from.

Fictional example. The conversation starts with one message: an apology to a client about a delayed report that read as unusually formal and listed three inconveniences the client had never mentioned. The account lead, Morwenna, raises it as a question, not a complaint, and the team brings five messages.

1. Weekly status update to the team
2. Internal call summary
3. Apology to a client about a delayed report
4. Proposal covering letter
5. Written feedback on a colleague's draft

Source note for the workshop prep summary:
Training room booked 14 October, 10:00–11:00.
Equipment delivery proposed for 13 October, not confirmed.

The sort. The update and call summary go into no need to say without argument. The apology goes into write it yourself, unanimously, and the conversation stops being awkward. Feedback resolves quickly as say so: it is presented as your judgement. The proposal letter splits: the descriptive sections need no label, but the paragraph giving a view on the client’s situation does, and perhaps should be written by hand.

The failure. Testing the norm on a real summary, the team finds: “Room booked 14 October, 10:00–11:00. Equipment arrives 13 October. Drafted with AI, checked by me.” The repair prompt flags the second line as firmer than the source. The fixed version reads: “AI-assisted summary. I checked the room date and time against the note. Equipment delivery is proposed for 13 October and still needs confirmation.”

• The fix restores the qualification. A larger AI label at the end would not have helped.
• Line 6 wasn’t in the plan. It arrived when someone asked where the apology had been drafted, and the honest answer was a personal account. The etiquette conversation turned out to be a data conversation wearing a hat. For what can go into which account, see what you can put into AI at work.
• The six lines in Example result are what they agreed.

Task kit for this job: Download (ZIP) · Reusable instructions

Go deeper

Sources

• Data, privacy and security for Microsoft Copilot: generated responses aren’t guaranteed to be factual, and users should use their judgement when reviewing output before sending it to others.