A team AI agreement should say which work AI can assist, which tools and information are allowed, who checks the result, and what happens when someone is unsure. Write rules a colleague can use on a real piece of work. “Use AI responsibly” leaves too many decisions to the person holding the draft.
Start with your organization's existing policy and approvals. Then agree how your team will work inside those boundaries. A marketing manager can assign someone to check a catalogue description; a team vote cannot approve a new service for confidential author manuscripts.
The people and change guide covers the wider adoption effort. This article helps you make one team's expectations specific enough to discuss, test and revise.
Separate company permission from team practice
Bring the current tool list, data rules and relevant approval contacts into the conversation. Link to their maintained locations rather than pasting copies that will quietly go out of date. Where a rule is unclear, name the person who can resolve it and keep the affected use out of the agreement until they do.
Published policies show why this distinction matters. HURIDOCS' internal AI framework assigns tool evaluation to named governance roles while also providing guidance for different teams. That is one organization's approach, not a universal policy. The useful pattern is that local working practices sit alongside a defined approval process.
An agreement also needs to respect the destination of the work. For example, Taylor & Francis' AI policy distinguishes permitted author assistance from restrictions on peer reviewers uploading unpublished manuscripts. A team's preference does not settle what another organization will accept.
Before the meeting, separate three things:
- Established requirements. Rules the team must follow, with a link and an owner for questions.
- Local choices. Review responsibilities, shared conventions and ways of asking for help that the team can agree.
- Unresolved requests. A desired tool, data use or automation that needs a decision elsewhere.
That separation makes room for useful discussion without asking colleagues to negotiate permissions they do not control.
Cover the decisions that recur in real work
Use the following fields to draft an agreement for a named workflow. You can keep several workflow entries on one maintained page. Avoid building a separate approval ritual for every spelling correction if your existing rules do not require one.
| Agreement field | What to record | A useful test |
|---|---|---|
Task and limits | What AI may help produce, who receives it and what stays outside scope | Would a new colleague know which requests to decline? |
Tools and inputs | The approved service, account and permitted source material | Can the worker identify the exact information they may supply? |
Human decisions | Who remains responsible for choices and final release | Is a draft clearly separate from an authorized action? |
Review standard | Named role, source checks and conditions for acceptance | Can two reviewers explain what they would check? |
Handoff and disclosure | What the recipient needs to know, following applicable rules | Can the next person see what was checked and what remains uncertain? |
Problems and exceptions | Stop conditions, contact and a usable fallback | Can someone raise a concern without silently shipping the result? |
Learning and maintenance | Help route, agreement owner and review triggers | Will an error or changed tool lead to a decision about the rule? |
The review row deserves particular care. “A human checks it” does not tell the reviewer whether to read for tone, verify every number or test the behavior of a program. Name the checks that protect the task's purpose, and give the reviewer access to the evidence needed to perform them.
In a public Reddit account, a self-described engineering manager described agreeing on a common AI environment, sharing instructions and holding a weekly discussion to refine workflows. The manager also acknowledged that odd output sometimes reached proposed code changes; the team's normal review process remained in place. This is one unverified account, but its practical detail is useful: the agreement concerned shared work and review, not just permission to use a tool.
Another Reddit user raised a caution: reviewing generated code might not build the same understanding as developing it. The commenter presented that as a concern based on personal experience, not a measured result. For your agreement, ask whether the responsible person can explain the output and its limitations, as well as approve its appearance.
Make the agreement concrete for one publishing task
Suppose a book publisher's marketing team wants AI help drafting short catalogue descriptions. Its organization has approved a writing service for public material. The team chooses already published book descriptions and the public catalogue as inputs, leaving unpublished manuscripts and private author correspondence outside this workflow.
Jamie, a marketing editor, drafts a description for a paperback edition. Claire, the catalogue editor, checks the book title, author, edition, publication date and factual claims against the current catalogue record. Claire also checks that the draft has not invented an award or attributed another edition's features to this one. The usual publishing approval still applies.
Their agreement can now say something useful:
The handoff should point to the source record and identify any unresolved claim. Apply the publisher's disclosure rules for the actual destination; the team should not invent a universal public label or quietly waive a required one. Internally, the recipient needs enough context to review the work without repeating the whole investigation.
If Claire is unavailable, the draft waits or another qualified editor takes the check. That is a real capacity decision. It belongs beside the agreement, with time for learning and review, rather than being left as an invisible extra task.
Test the rules with the people doing the work
Discuss an acceptable draft and a difficult one before calling the agreement finished. Atlassian's AI Working Agreements play recommends co-creating expectations around actual uses, responsible practice and shared learning. It offers a facilitation method, not evidence that a particular document will improve your team's results.
For the publishing team, the difficult case might be a convincing award claim with no supporting catalogue entry. Ask the author of the draft, its reviewer and its eventual recipient what they would do. If their answers differ, the sentence needs work or the team needs an external decision.
Run the discussion in this order:
- Walk through the permitted input. Show what the worker would supply and confirm that it fits the existing approval.
- Inspect a plausible mistake. Ask the reviewer to demonstrate how they would find it using the source material.
- Try the exception route. Identify who decides when the draft cannot pass, and how the work gets finished meanwhile.
- Revise the wording. Save the resolved decision, its owner and the date. Keep unresolved permission requests separate.
Invite concerns from people who receive or repair the output, including colleagues who are less enthusiastic about AI. A fast drafter and an overloaded reviewer can experience the same workflow very differently. An agreement that only reflects the drafter's convenience has missed part of the job.
Keep a route for learning and revision
Put the agreement where the team already finds its working instructions, and include it in onboarding. Give it a named maintainer and a planned review date. Also revisit it after a changed tool, a new recipient, a failed check or a proposed move from drafting to automatic action. Those changes may affect the permission as well as the local rule.
Use your regular team review to discuss a small number of actual cases. Look for unclear checks, repeated rework and work that had to stop. Ask what the agreement helped someone decide and where they still had to guess.
The next step is one tested workflow entry. Choose a recurring task, bring its worker and reviewer together, and resolve one awkward case. Expand the agreement when the team has another real decision to capture.
Questions about team AI agreements
How is a team AI agreement different from company AI policy?
Company AI policy sets organizational requirements, such as approved tools, permitted data and approval responsibilities. A team AI agreement explains how a particular group follows those requirements in its work, including who reviews a draft and what they check. Start by separating requirements, local choices and unresolved requests. If a proposed practice needs new permission, ask the policy owner before adding it as an allowed use.
Should a team disclose every use of AI?
A team should follow the disclosure rules that apply to its organization, recipient and type of work. Its agreement should make those rules easy to apply and specify the internal context a reviewer needs. Do not substitute a percentage threshold or a blanket label for that decision. In the catalogue example, the recipient needs the source record and unresolved claims so they can check the description; any additional external disclosure follows the publisher's requirements.
What if team members disagree about an AI rule?
Test the disagreement on a concrete task and identify the decision it affects. A concern about confidential inputs belongs with the relevant policy owner; a concern about review effort may require a different workflow or more capacity. Keep the uncertain use on hold while that decision is unresolved, with a way to complete necessary work. Agreement should make objections actionable, not require everyone to have the same enthusiasm for AI.
