Run a 90-minute practical AI workshop for your social service team

What this workshop is for

This is a workshop, not a talk with a few questions at the end. In 90 minutes, participants will inspect a flawed AI draft, write a better instruction, compare an output with its source and choose one small experiment for their own team.

It is designed for 8 to 24 people working in social work, programme delivery, fundraising, communications, operations or volunteer management. No technical background is needed. One facilitator can run it; a second person helps with groups larger than 16.

The session fits an introductory AI workshop for charities or practical AI training for social workers. It does not certify anyone as competent to use AI with client data, and it does not approve a tool for agency work. NCSS separates foundational digital skills for everyone from specialised governance and advanced technical skills. Its current training page also points SSA staff to a Data and AI Literacy ePrimer.[1] Treat this workshop as a shared first practice session, then connect it to your agency's own policy, supervision and role-specific training.

What participants should leave with

By the end, each participant should be able to:

• describe one task an AI tool may help with and one task that needs to stay with a person;
• give a tool a clear purpose, source, constraints and output format;
• check a fluent draft for invented facts, missing qualifications and unsuitable tone;
• recognise when information should not be entered into the tool; and
• frame a small test with an owner, a quality check and a stop rule.

NCSS's Social Services Digitalisation Playbook recommends role-appropriate skills, a user-centred view of service and attention to data governance, cybersecurity and change. It also treats AI use cases as part of a wider digital strategy rather than a purchase on its own.[2] The workshop follows that logic: begin with work, practise review, then decide whether a tool deserves a limited test.

Facilitator preparation

Prepare this at least two working days before the session.

1. Confirm the room and group. Seat people in tables of three or four. Ask for a mix of frontline, programme and support roles at each table where possible.
2. Choose the mode. For live-tool mode, confirm the exact agency-approved AI account, settings and login method. For paper mode, print one fictional source pack per table, one prompt worksheet per pair, one participant handout and experiment card per person, and enough Output A and Output B sheets for each pair to compare them. Keep the answer key with the facilitator. Paper mode is a proper version of the workshop, not a fallback that needs apology.
3. Check access. Test Wi-Fi, projector, font size and the approved tool on the device you will use. Do not ask participants to create personal accounts during the session.
4. Name the escalation route. Write the name or role of the person who handles AI-use, data-protection or information-security questions in your agency. If no route exists, write: Pause and ask your supervisor before using real agency information.
5. Set up the board. Make three columns: Useful, Needs a person, and Do not enter. Leave space for one final experiment card.
6. Prepare pairs. Pair participants in advance if access needs or confidence levels make this helpful. Nobody should have to type quickly in front of a group.
7. Rehearse the clock. Read the fictional source pack and both outputs. Decide which questions you will cut if discussion runs long. Do not cut the output-checking exercise or the final experiment.

Bring a visible timer, sticky notes, thick pens, one printed pack per table, spare paper and a slide or poster showing the working boundary. If participants use devices, ask them to close email, case-management systems and other screens that could lead to accidental copying.

00:00-00:08 | Open and set the boundary

Say this in your own voice:

Today we are going to practise on invented material. We are not testing whether AI is good or bad in general. We are testing whether we can give it a bounded task, notice where it fails and keep responsibility with a person. Please do not use a real client, colleague, donor, volunteer or internal document in any example.

Point to the escalation route. Ask for a show of hands: who has used a generative AI tool at work, outside work, or not at all? Do not ask people to justify their answer.

Give everyone one sticky note. Participant instruction: Write one repeated task that takes time. Describe the task, not the tool you want. Keep out names and case details. Examples include reformatting a public event description, turning approved bullet points into a staff announcement, or drafting questions for a meeting. Put the notes under Useful for now. They will be screened later.

00:08-00:18 | Demonstrate the difference a boundary makes

Display this fictional task: Write a reminder for a community workshop.

First show the vague instruction:

Write a friendly reminder for our workshop.

Then show the bounded instruction:

Using only the event facts below, draft a plain-English reminder for registered participants. Keep it under 90 words. Include the date, time, venue, what to bring and the cancellation contact. Do not add a fee, eligibility rule, transport advice or promise. If a required fact is missing, write [CHECK] instead of guessing.

Ask participants what the second instruction makes easier to review. Listen for: a defined reader, a source boundary, an output length, required facts, prohibited inventions and a way to show missing information.

Make one point and move on: a better prompt can reduce avoidable ambiguity, but it cannot make checking optional. IMDA's voluntary starter kit identifies hallucination and inaccuracy, bias, undesirable content, data leakage and adversarial prompts as five risks for LLM applications. It recommends identifying relevant risks and thresholds, testing, and assessing results.[4] This short workshop only practises a small part of that work: checking a text output against a supplied source.

00:18-00:33 | Exercise 1: catch the confident mistakes

Give every table the source pack and the draft below. They have eight minutes to mark it, then four minutes to agree on their three most serious findings. Keep the final three minutes for a quick report from each table.

Participant instruction:

Compare every statement with the source. Circle anything invented or changed. Underline anything important that is missing. Put a question mark beside wording that could mislead or exclude someone. Decide whether you would use, edit or discard the draft.

00:33-00:40 | Debrief 1: build the check together

Ask these questions in order:

1. Which error would be easiest to miss on a quick read?
2. Which error could cause the most trouble for a participant or colleague?
3. Did the confident tone make any unsupported statement feel more credible?
4. What did the draft leave out?
5. Would editing this draft be quicker than writing a new reminder from the source?

Write the group's answers as a five-part check:

• Facts: Can each name, date, number and offer be traced to the source?
• Meaning: Did the draft preserve uncertainty, conditions and who said what?
• Missing: Did it omit something the reader needs to act safely or correctly?
• Fit: Is the language suitable for the reader, channel and agency voice?
• Decision: Will a named person use, edit or discard it?

Do not turn the debrief into a catalogue of everything AI might do wrong. The useful lesson is narrower: review against a source and make a decision.

00:40-00:45 | Take a real reset

Give people five minutes. Put the prompt worksheet on screen before they return. If the room is running late, take three minutes and remove two minutes from the later group reports. Keep the hands-on writing time.

00:45-01:00 | Exercise 2: write a bounded prompt

Pairs will use the same fictional source pack. Their task is to request a reminder that can be checked quickly.

Copy this worksheet:

PURPOSE: Draft a [document] for [reader] so they can [action].

SOURCE: Use only the facts between SOURCE START and SOURCE END.

MUST INCLUDE: [required facts].

MUST NOT: [invent, infer or change these things].

MISSING INFORMATION: Write [CHECK] rather than guessing.

FORMAT: [length, structure, reading level or channel].

REVIEW AID: After the draft, list each factual claim and the source bullet that supports it.

Participant instruction: Write the prompt first. Do not submit it yet. Swap with another pair. The other pair has two minutes to find one ambiguity, one missing constraint and one review step that would make checking easier.

A workable version might ask for an email of 80 to 120 words for registered participants; require date, time, room, address, activity, what to bring, access and cancellation details; prohibit claims about cost, available places, food certification, childcare, translation and transport; and require [CHECK] for any missing fact. Participants can improve that version rather than trying to invent a clever persona or complicated prompting formula.

01:00-01:10 | Compare and verify

In live-tool mode, pairs submit only the fictional source and their final prompt to the approved tool. In paper mode, give half the pairs output A and half output B below.

Participant instruction:

Use the five-part check. Mark every factual claim against the source. Choose use, edit or discard. Be ready to name the evidence for your decision.

Debrief questions for the comparison

Ask:

• Did the claim-check line make output B more trustworthy, or did you verify it independently?
• What does output A still need before sending, such as an agency template, sender name or communications approval?
• Which output is faster to review? Why?
• When would you discard both outputs and write the message yourself?

The facilitator should not crown one prompt as perfect. Different prompts can produce usable drafts, and the same prompt can produce different outputs. The stable skill is checking.

01:10-01:20 | Choose a small use case

Return the opening sticky notes. Each table chooses one candidate and works through four questions.

1. Consequence: If the draft is wrong and a reviewer misses it, what happens? Avoid service eligibility, safeguarding, risk assessment, diagnosis, allocation, disciplinary matters and other decisions that could materially affect a person.
2. Information: Can the test use public, fictional, synthetic or approved non-sensitive material? If real personal or confidential information is required, the candidate does not move forward from this workshop.
3. Review: Can a named person compare the output with a reliable source quickly? If review takes longer than doing the task properly, choose another candidate.
4. Reversibility: Can the team discard the draft and use the existing process without disrupting a service?

Move unsuitable notes to Needs a person or Do not enter. That is progress, not failure. PDPC's July 2026 advisory guidelines apply the PDPA to personal data used in generative AI models and systems.[3] This workshop does not replace an agency's assessment of purpose, notification, consent or other applicable basis, protection, retention, access, transfer and vendor arrangements. Keep the workshop decision modest: suitable for a synthetic test, unsuitable, or needs review by the agency's designated person.

01:20-01:28 | Write a seven-day experiment card

Each table fills in one card. If no suitable use case survives the screen, the experiment can be to map the task and its information instead of using AI.

Copy this card:

TASK: For seven days, we will test AI only for...

MATERIAL: We will use only...

TOOL AND ACCOUNT: The approved tool is... / Approval must be confirmed by...

OWNER: The person responsible for the test is...

REVIEW: Before any output is used, this person will compare...

MEASURE: For up to 10 examples, we will record preparation time, review time, factual errors, material omissions and whether the draft was used, edited or discarded.

STOP RULE: We will pause immediately if...

FALLBACK: We will return to...

REVIEW DATE: We will discuss the results on...

A sensible first experiment might use public programme facts to draft internal variations of an event reminder. A stop rule could be: Pause after any repeated invented date, offer or eligibility condition, any use of unapproved information, or any output sent without the named review.

Keep the sample small. The point is to learn where effort moves and which errors recur. Do not report only the time taken to generate a draft. Include preparation and review time.

01:28-01:30 | Close without a grand promise

Ask each table to complete one sentence: Before we use an AI draft, a person must...

Collect the experiment cards. Name who will confirm tool approval and who will convene the seven-day review. Put the date in the calendar before people leave.

Send participants the fictional pack, prompt worksheet, five-part check and their own experiment card. Do not send a generic list of 50 AI tools. The workshop should end with one bounded piece of learning, not a new shopping list.

Facilitator notes for common moments

Someone says the exercise is too basic. Ask them to find every unsupported claim in output B and explain the review evidence. Then invite them to improve the stop rule. Speed with a tool is less useful than disciplined checking.

Someone wants to use a real case because it is more realistic. Thank them and hold the boundary. Use an invented example that preserves the structure of the task without preserving a person's circumstances.

Someone says their team has no approved tool. Run paper mode. The learning is prompt design, source checking and use-case screening. Tool access can follow governance, not precede it.

The live tool refuses the prompt or produces a strange result. Capture the behaviour as a finding. Move to the supplied outputs and keep the session on time.

People disagree about whether a task is low consequence. Ask who could be affected, what a missed error could change and whether the ordinary process remains available. Put the note under Needs a person if the answer is uncertain.

The group asks for legal advice. Point to the agency's data protection officer or designated reviewer. This article is practical training material, not legal advice.

A one-page participant handout

Copy this section into your handout.

Before using a tool

• Use the approved tool and account for an approved task.
• Use fictional, public or specifically approved material.
• Send only what the task needs.
• Know who will review the result.

Give a bounded instruction

• State the reader and action.
• Identify the source and tell the tool not to go beyond it.
• List required facts and prohibited inventions.
• Ask for [CHECK] where information is missing.
• Specify a useful format.

Check the result

• Facts: trace claims to the source.
• Meaning: preserve conditions and uncertainty.
• Missing: look for omitted information.
• Fit: check the reader, tone and channel.
• Decision: use, edit or discard.

Stop and ask

Stop if the material contains personal or confidential information, the tool or purpose is not approved, the source is unreliable, the output could affect a consequential decision, or nobody can review it properly.

After the workshop

Within one working day, send the agreed experiment card and the no-real-data boundary to participants. Within seven days, the owner runs no more than 10 synthetic or approved examples and records every result, including discarded drafts.

At the review, ask:

1. Where did the tool save time, and where did it create preparation or checking work?
2. Which errors repeated?
3. Did reviewers use the source, or approve from fluency?
4. Did anyone feel tempted to use information outside the agreed boundary?
5. Should the team continue, change the task, use ordinary automation, or stop?

Record the decision and reason. If the team wants to move beyond fictional or public material, or use outputs in live service delivery, begin the agency's formal data, professional, security and governance review. A lively workshop is not evidence that a use is safe.

About the author

Darren writes for Social Tech Guild about practical, responsible uses of technology in Singapore's social service sector. This article provides a workshop plan; it does not claim that he has delivered this session.