Opens in a new tab.
MenuClose

How to Brief an AI Trainer

An AI training brief template covering participants, desired change, tools, access, timing, constraints, practice and evaluation.

Building and teachingBy Ali Mustufa ShaikhPublished Updated 8 min read
Editorial illustration of an open navy folder containing organised briefing sheets, with section tabs, a pencil, and a ruler.

When you ask me about a workshop, tell me who’s coming, what they already do, where they’re stuck and what you want them to try. That gives me the context to suggest a format, flag conflicting needs and design exercises around their work. You don’t need to plan every slide.

What to put in the brief

  1. Audience. List the roles, approximate group size, experience, and differences that matter. If it’s a “mixed audience”, say who’s in the mix.
  2. Desired change. Complete this sentence: “After the session, participants should be better able to…” Name a decision or task, rather than a broad aspiration.
  3. Current situation. What prompted the request? Include existing tools, experiments, policies, recurring questions, or failed attempts. Leave out confidential details.
  4. Tools and access. Say which devices, accounts, repositories, datasets, and network access participants will have. Make clear what they must not paste into a third-party system.
  5. Practice. What could people make or review? It might be a pilot brief, an evaluation plan, a prompt with test cases, or a synthetic code change.
  6. Constraints. Include security, privacy, accessibility, procurement, recording, travel, time-zone, and language needs that affect delivery.
  7. Timing and format. Give the duration, delivery mode, room setup, breaks, and facilitation support. Be open to changing the plan if those conditions won’t support the work.
  8. Evaluation and ownership. Say what you can reasonably check at the end, who will take the next step, and when the organisation will review it.

Copy this AI training brief

Brief template

  • Organisation and context: [Why this request exists now]
  • Participants: [Roles, number, experience, locations, accessibility or language needs]
  • Desired change: [What participants should understand, decide, or do]
  • Current practice: [Tools, process, policy, and recurring difficulty]
  • In scope: [Tasks, systems, examples, and questions]
  • Out of scope: [Sensitive data, unsupported tools, decisions the session cannot make]
  • Access available: [Accounts, laptops, repository, sample data, network]
  • Practice artifact: [What people can make, test, or review]
  • Delivery conditions: [Date, duration, mode, room, breaks, facilitators, recording]
  • Evidence at the end: [Completed exercise, decision rationale, confidence check, or questions resolved]
  • Owner and follow-through: [Person responsible, next action, review date]

Share examples, not confidential information

A real workflow or redacted example helps the trainer adapt the session to your work. Remove personal data, credentials, unreleased code, contract details, and other restricted information before sharing it. If the material can’t leave your organisation, describe its structure and ask for a synthetic version.

Agree who can approve the examples and whether the trainer may keep participants’ work. Company material shouldn’t become a public demo or a future training sample without permission.

A fictional example: two hours with product managers

An enablement lead asks for “two hours on AI for product managers.” The template helps them make the aim more specific: “Participants can write a bounded pilot proposal and name the information it may and may not use.”

There are 24 people, no approved production data, and only browser access. A pilot worksheet using a synthetic support-triage scenario, followed by peer review, fits those conditions. A live connection to company systems doesn’t.

Decide what you’ll check afterwards

Attendance and satisfaction are easy to count, but they don’t show whether people can apply the material. After a workshop, review what participants made, ask them to explain their choices, and examine their plan for the next step. After a keynote, check whether they can use the ideas to make a decision and ask useful follow-up questions.

A short session can’t prove a long-term productivity or business result. If you want to check what happens later, put the person responsible and the review date in the brief.