How to set workshop ground rules for an AI workshop

Use workshop ground rules to give people explicit permission to question an AI proposal, describe its consequences, and leave disagreement on the record. Agree on how people will contribute, what information they may share, and who will make the decision. For an AI-adoption workshop, start with rules covering objections, data boundaries, participation, and approval, then assign the facilitator responsibility for enforcing them.

The practical output should be a decision record with unresolved concerns and named owners. Treat every proposed AI use as a hypothesis to test, with a human owner deciding whether the evidence supports the next step.

Give the facilitator authority to protect the discussion

Priya Parker describes generous authority as the host’s responsibility to protect people, reduce status differences, and connect them in The Art of Gathering: How We Meet and Why It Matters. Apply that idea by authorizing the facilitator to interrupt a dismissive response, redistribute speaking time, and ask the sponsor to clarify an ambiguous promise. Explain this authority before the substantive discussion begins.

Separate facilitation authority from decision authority. The facilitator should control the discussion process, while a named decision owner accepts or rejects the proposed next step. Ask technical and risk approvers to specify which questions require their review before work proceeds.

Parker also proposes temporary, explicit rules that make different behavior possible within a defined period, as described in her book on purposeful interaction. For this workshop, make the temporary permission specific: anyone may challenge the proposed AI scope, including a proposal supported by their manager. Keep normal confidentiality and access requirements in force.

Write down what the facilitator should do when that permission is tested. A useful intervention is: “Please keep the objection open while we identify the affected action and the evidence we need.” Ask the sponsor to agree publicly that this intervention applies to their contributions too.

A workshop ground rules template for AI adoption

Use the following six rules as a starting proposal. Adapt the wording to the decision and ask the group which rule needs changing before work begins. Keep the agreed version visible in the shared document.

• Challenge the proposed behavior. Describe the output, access, or action that concerns you. Keep judgments about another person’s competence or motives out of the discussion.
• Label evidence and uncertainty. Identify whether a statement comes from an observed process, a documented requirement, or an assumption. Record an unknown as a question requiring investigation.
• Allow a pass and a written contribution. Give everyone an opportunity to contribute before returning to repeat speakers. Permit people to decline speaking and submit a concern through an agreed alternative channel.
• Keep restricted information out of the exercise. Use only material approved for the workshop and its tools. Stop the exercise if a proposed example requires information outside that boundary.
• Record disagreement before deciding. Preserve each unresolved objection in wording its contributor accepts. Ask what evidence or scope change would address it, without requiring an immediate solution.
• Require explicit decisions and ownership. Record approval, objection, abstention, or required review separately. Assign an owner to the next action and state what remains unauthorized.

The data boundary and decision-record requirements above are proposed adaptations for an AI-adoption workshop. Treat them as working instructions and revise them if they fail to support the task.

Avoid asking people to approve a vague promise of confidentiality. Specify who can read the notes, whether attribution is necessary, where the record will be stored, and whether recording or AI processing is permitted. Refer unresolved questions to the appropriate internal owner before collecting sensitive contributions.

Put the rules into practice before evaluating AI options

Prepare a one-page brief with the proposed operational perimeter, the decision requested, and the decisions excluded from the workshop. For example, authorize a discussion of draft recommendations while excluding approval for automated writes. Ask the sponsor to confirm that boundary before circulating the brief.

Prepare contributions and agree on the rules

Send a short intake asking for a current process problem and a concern about the proposed AI use. Allow contributors to flag material that needs a private conversation. Ask for professional observations they are authorized to share, and make personal disclosure optional.

At the opening, explain the decision and invite amendments to the proposed rules. SSWM recommends discussing and agreeing on ground rules, keeping them visible, and revisiting rules that are repeatedly broken in its guide to setting ground rules. Follow that approach with an explicit check of agreement, including a written response option.

Separate clarification from objection

Begin with clarification of the proposal. Ask what information would enter the system, what output it would produce, and what action a person or system would take afterward. Mark missing answers before opening the evaluation.

Give objections their own discussion period. Use a shared record with fields for the proposed action, concern, consequence, evidence needed, owner, and decision status. Require the contributor’s confirmation before treating a paraphrase as an accurate account of their concern.

For the handoff beyond the workshop, use the same questions to frame AI governance responsibilities. Ask the decision owner to distinguish the evidence needed for a limited test from the evidence needed for a production release. Record the approval boundary for each.

Assign evidence before closing a concern

Give each unresolved concern an owner and an observable next action. “Review privacy” is too broad for this record. Ask for a specific deliverable, such as a documented data path reviewed by the designated privacy owner.

Use four statuses: resolved, test required, approval required, or outside the proposed scope. Keep “outside scope” items visible with a destination and owner. Do not use that label to close a concern about an action still included in the proposal.

Worked pattern: AI-assisted routing of internal requests

Take a proposed use in which AI would classify internal requests and suggest a destination queue. Frame the first question narrowly: should the team test routing recommendations for a defined category of requests? Leave automatic reassignment outside the proposed test.

Use a process sketch to identify the inputs, suggested classification, reviewer, and possible next action. Ask operations to describe a misroute and the work required to correct it. Ask IT to identify the proposed data path and risk reviewers to identify which request categories need separate review.

Give job concerns an explicit place in the same record. Ask the sponsor to state whether staffing changes are part of the decision, excluded from it, or unresolved. If they are unresolved, assign an owner and a separate decision process, and avoid offering reassurance the sponsor cannot substantiate.

Translate the discussion into proposed test boundaries. Use approved, genuinely de-identified examples, keep destination changes disabled, and have a named reviewer assess each recommendation. Include an ambiguous request and a request that should receive no routing recommendation among the proposed test cases.

Record each objection with its corresponding condition. A concern about restricted request content should lead to a data-path review before that content enters a new processing path. A concern about wrong routing should lead to a defined failure test and correction procedure.

End this pattern with a limited decision: authorize preparation of the bounded test after the required reviews, or defer it until the missing evidence is available. Keep production access and automatic changes unauthorized. Have the decision owner confirm those limits in the record.

Handle the trade-off between candor and closure

An unresolved objection needs a defined treatment before the workshop ends. Give it enough attention to establish its consequence and next action. Set a separate review when the evidence cannot be assessed within the remaining time.

Use this proposed decision rule: if an unresolved objection concerns authorization to use data, permission to take an action, or responsibility for handling failure, withhold approval for that part of the scope. Continue only with a narrower path that excludes the unresolved dependency. Ask the decision owner to document why the remaining path can proceed.

For a testable performance concern, propose a bounded test with acceptance criteria. For a policy question, refer the decision to the designated policy owner. For a staffing decision, require an accountable executive response and an explicit communication plan.

Keep silence distinct from agreement in the decision record. Request a response from each required approver, and mark missing responses as pending. Permit other contributors to abstain or state that they lack enough information to assess the proposal.

Turpin Communication argues that facilitators should take responsibility for relevance and engagement, and cautions against rules or exercises that put learners on the spot in its critique of conventional ground rules. Apply that caution by allowing a pass and offering a written route for concerns. Invite questions about the proposal without asking anyone to explain their feelings about AI in public.

Test AI assistance separately

A hypothesis worth testing is whether AI can help prepare a disagreement map from approved written contributions. Limit the proposed output to stated positions, conflicting definitions, and missing evidence, with links back to the authorized source text. Prohibit inferred motives and require the facilitator to verify the map before sharing it.

Compare the draft with the original contributions and record omitted or incorrectly combined objections. Keep the decision about which issues to raise with the human facilitator. Before using any such tool, review the processing path and its limits using system-specific trust questions.

Frequently asked questions

What are some important ground rules for Zoom meetings?

Agree on one speaking channel, a method for requesting a turn, and a written contribution route. For sensitive AI discussions, state whether recording, transcription, and AI note processing are authorized before enabling them. Enabling Change recommends rehearsals and a co-host for online workshops in its online facilitation checklist. Assign the co-host responsibility for technical interruptions and contributions in chat.

What activities are done in a workshop?

For an AI-adoption workshop, choose activities that produce evidence for the stated decision. Use individual written input, process mapping, objection review, and failure-case definition where each serves that purpose. Finish with a decision record and confirmed next actions, leaving time to check unresolved concerns.

What are team ground rules?

Use team ground rules as working agreements for recurring collaboration, including how to raise concerns and record decisions. SSWM recommends displaying agreed rules whenever the same group meets and revisiting them when needed in its ground rules guidance. Specify which workshop rules expire and which the team proposes to retain.

What are some tips for facilitating a workshop effectively?

Define the decision, prepare a contribution route, and agree on intervention authority before evaluating proposals. Ask contributors to distinguish observations from assumptions and confirm how their objections are recorded. Reserve closing time for required approvals, unresolved dependencies, and the next action’s owner.

Choose the next authorized step

Before scheduling the workshop, ask the sponsor to confirm the decision owner and the scope that remains unauthorized. Put those names and boundaries at the top of the working document. If the next step requires a custom production system, bring the agreed perimeter and unresolved conditions to a discussion about enterprise AI implementation.