A Generic Demo Teaches the Wrong Lesson
People learn very little from watching someone else ask a model to plan a vacation.
The demo may be polished. The room may laugh at the answer. Then everyone returns to work and faces a harder question: can this help with the client brief, policy comparison, account plan, or weekly analysis sitting on my desk?
A useful AI lab gets close to real work. A safe lab does that without inviting people to paste confidential material into the wrong tool or treat a fluent answer as a verified one.
Those goals aren't in conflict. They require a better room design.
The basic unit is one workflow, one prepared input set, one quality bar, and one explicit human review point. The lab should leave behind an artifact the team can use again, not a chat transcript that disappears after lunch.
Choose the Workflow Before the Tool
Start with a task the group already recognizes.
Good lab workflows happen often enough to matter, take long enough to feel the difference, and produce something the room knows how to judge. Examples include turning interview notes into themes, drafting a client recap, comparing policy language, preparing a meeting brief, or checking a document against a standard.
Avoid tasks with no shared definition of good. "Brainstorm innovative ideas" is hard to evaluate. "Produce five campaign concepts that each use one approved message, name a specific audience, and avoid these three claims" gives the room a quality bar.
Choose the workflow before choosing Claude, Copilot, ChatGPT, or another surface. Tool-first sessions turn into feature tours. Workflow-first sessions create a method that can survive a tool change.
Write the current path on one page. Name the trigger, inputs, decisions, output, reviewer, and risk. That becomes the lab brief.
Prepare Inputs That Are Real Enough
The safest option isn't always fake data. Completely generic material strips away the context that makes the work difficult, so the exercise teaches a toy version of the task.
Prepare one of three input sets:
Sanitized real examples. Remove names, account details, contract terms, personal data, and anything covered by policy. Keep the structure, edge cases, and messy formatting that make the work real.
Synthetic examples shaped like real work. Build a fictional account, project, or document with the same fields and failure modes the team sees. Ask subject-matter experts to make it plausibly difficult.
Approved low-risk live work. Use an actual internal task only when the tool, data classification, access, and policy all allow it. Say that approval out loud. Don't make participants guess.
Label the input set at the top of every lab document. Include what people may paste, what they may not paste, which tool and account to use, and who to ask when uncertain.
This prevents the safety slide from becoming a disclaimer everyone forgets once the exercise starts.
Put Governance Inside the Exercise
Governance works better as a move people practice than a list they acknowledge.
Build required checks into the lab:
- Identify the source for every factual claim
- Mark assumptions separately from evidence
- Remove restricted information before the model sees it
- Use the approved account and model
- Stop before an external send, publication, or system change
- Name the human who owns the final decision
Give each table a short stop card. It should say when to pause, what to inspect, and where to escalate a question. If the company's policy is still unclear, make that visible too. "Do not use client material until legal confirms the approved path" is more useful than pretending the answer exists.
Run one planned failure. Seed an unsupported claim, an outdated source, or a piece of restricted data in the exercise. Ask the room to catch it. People remember the review move because they used it.
This is the practical difference between guardrails in a deck and review points in a workflow. The broader case for observable review is in A Track Record Beats a Wall of Guardrails.
Give the Room Roles
Hands-on sessions drift when everyone opens a laptop and works alone.
Use groups of three or four with named roles:
- Driver: Works in the approved AI tool
- Context owner: Decides which information and examples the model needs
- Reviewer: Checks the result against the quality bar
- Recorder: Captures the steps worth turning into a reusable artifact
Rotate roles after the first attempt. The confident user shouldn't drive the whole session. A reviewer learns different things than a prompt writer, and the room needs both.
Mixed-seniority groups can work well if the quality criteria are explicit. Junior participants often notice process friction. Senior participants know where an apparently good answer would fail in the real business. Give both observations equal space in the readout.
For mixed functions, group people by workflow when possible. A shared tool does not create a shared lab. Finance, legal, sales, and operations can learn the same method through different input sets and review bars.
Use a Tight Run of Show
A practical 90-minute lab can follow this shape:
10 to 15 minutes: Concept and boundaries. Explain the workflow, approved tool, input rules, quality bar, and stop conditions. Show one short example, including the review step.
30 to 45 minutes: Two working rounds. Teams run the workflow once, compare the result with the bar, then change one thing. The change may be better context, a narrower instruction, a different source, or a clearer output format.
10 to 15 minutes: Failure review. Teams look for unsupported claims, missing context, unsafe inputs, and hidden review work. This is part of the lab, not a cleanup after it.
10 to 15 minutes: Readout and handoff. Each table shares what changed, what still failed, and which steps belong in the reusable artifact.
Leave buffer for access problems. Verify accounts and approved tools before the room arrives. A session can survive a weak model answer. It rarely recovers from 25 people resetting passwords for half an hour.
Turn the Winning Path Into an Artifact
The lab is not done when the group gets a good answer.
Capture the repeatable method in a format the team can find next week. That might be a Skill, a short workflow card, a template, an AGENTS.md instruction, a review checklist, or a request form for new use cases.
The artifact should include:
- When to use the workflow
- Required inputs and approved sources
- The main steps
- The expected output shape
- The quality check
- The human review point
- The owner and next review date
Include one example that passed and one that failed. A perfect example teaches the destination. A failed example teaches judgment.
Don't publish every draft artifact as a company standard. Mark it as a pilot, name the team using it, and set a review date. Shared methods earn permanence through use.
Measure the Lab After the Room Leaves
Don't use applause, survey enthusiasm, or completed exercises as the main result.
Choose a 30-day follow-up. Ask whether the workflow was used on real work, whether the artifact helped another person, where the review caught problems, and what prevented reuse.
Track one performance measure and one safety measure. For example: time to a reviewed brief, plus the percentage of factual claims linked to a source. Or correction rounds, plus completion of the required approval step.
How to Measure AI Adoption Without Inventing ROI includes the before-and-after card for that follow-up.
Bring the artifact back to the original table. Revise it with evidence from real use. If it only worked in the workshop, find out which condition disappeared: prepared inputs, facilitator help, protected time, access, or a clear reviewer.
Make Safe Practice Normal
One lab won't create an adoption system. It can create the first reliable unit of one.
The team has seen a real workflow improve. It has practiced where to stop and review. It has a shared artifact instead of private prompting tricks. A manager has evidence for the next decision.
Repeat the format with another workflow only after the first one survives real use. Keep the inputs explicit, the quality bar visible, and the human decision in the loop.
Safe AI practice isn't a generic warning wrapped around a feature demo. It is a room where people learn how useful work, good judgment, and clear boundaries fit together.