AI Workshops at Work: Why Most of Them Fizzle Out — and What One That Works Looks Like
Most AI training ends in enthusiasm and no change. Why that happens, how role-specific programmes for agencies, SMEs and engineering teams need to be built, what has to be on the table at the end of the day — and how to measure the effect.
The most common mistake in AI training isn't the choice of tools, it's the assumption that everyone in the room needs to learn the same thing. Half a day of tool demos for the whole workforce reliably produces enthusiasm — and reliably produces no change. If you want a team to genuinely work differently afterwards, you need three things: role-specific content, real tasks instead of demo data, and artefacts that outlive the workshop day.
We train teams in agencies, SMEs and software engineering, and the patterns repeat with remarkable consistency. This piece describes why the usual formats fail, what a programme per role looks like, what has to be on the table at the end — and how to measure the effect instead of guessing at it.
Why most AI workshops change nothing
Four mistakes explain almost every ineffective session. They rarely appear alone.
| Mistake | What happens in the workshop | What happens afterwards |
|---|---|---|
| Tool tour instead of task | The trainer shows what the tool can do, using the trainer's examples | Participants can operate the tool but can't solve their own work with it |
| One session for every role | Content is generalised until it is concrete for nobody | Every role waits for "their" part, which never comes |
| No artefacts | Lots of experimenting, nothing saved | On Monday everyone starts from zero again |
| No follow-up | The day ends with "get in touch if you have questions" | The first real questions appear in week two — and go unanswered |
There is a fifth pattern that gets named less often: the unanswered data question. If nobody says definitively which customer data, contracts or HR files may go into which tool, every individual decides for themselves — the cautious ones don't use AI at all, the bold ones upload whatever is open. Both are expensive; the second is also risky.
AI workshops by role: agencies, SMEs and developers
Language models are general-purpose tools. The work isn't. An order-processing clerk, a creative director and a backend engineer need the same foundation — how models work, where they invent, which data may go in — and after that completely different applied skills. That's why we work with three programmes.
AI for agencies: volume without losing your signature
In creative and performance teams somebody is almost always using GenAI already, but without shared standards. The result is copy that sounds generic and gets rewritten from scratch in editing, and creatives that are technically clean and still interchangeable. The leverage isn't in better prompts, it's in a system.
| Module | What actually gets produced |
|---|---|
| Content production with GenAI | A brand-voice prompt per client, built from real reference texts instead of adjective lists |
| Ad creation & performance creatives | Systematic derivation of angles, hooks and test variants from an offer |
| Creatives, image & motion | Consistent series across formats, plus clarity on image rights and disclosure |
| Creative systems | Prompt library, brand kit with no-gos, pipeline from brief to asset |
| Quality control & approvals | Review gates before client approval, fact-checking routine, handling hallucinations |
The most common worry in this programme is the loss of signature — and it is justified as long as tone of voice exists only in the senior copywriter's head. Once it exists as a system the effect inverts: the first draft already sounds like the brand and gets sharpened rather than rescued. Details in the programme for agencies.
AI for SMEs: the hours that disappear into small work
In SMEs the potential rarely sits in a big project. It sits in the fifty small steps per day: copying quotes together from old documents, forwarding enquiries by hand, retyping receipts, answering the same question for the twentieth time, pulling numbers for a meeting out of four systems. Each case looks too small to solve; together they add up to days per month.
| Module | What actually gets produced |
|---|---|
| Process automation | Two to four working automations, with an approval step in the right places |
| Lead generation & outbound | Ideal customer profile, enrichment, prioritised list, personalised first contact |
| AI assistant on your own knowledge | An assistant on price lists, manuals and minutes — answering with sources |
| Customer service | Automatic triage, reply drafts, a clear rule for escalating to a human |
| Analytics & reporting | Monthly reporting that comes together without manual work and prepares a decision |
The sequencing mistake is especially expensive here: many teams start with the most visible use case rather than the most worthwhile one. A sober inventory — frequency times duration times error rate — almost always reorders the priority list. Details in the programme for SMEs and in our piece on how much time AI really saves.
AI for developers: the bill arrives at review
Engineering teams don't need a programme that explains AI to them — they have been working with it for a long time, just at very different levels. The typical patterns: prompts written for older models that now cause over-verification and bloated diffs; sessions with a context so full that quality tips over; and generated code that looks plausible, misses edge cases and eats the time at review that was saved up front.
| Module | What actually gets produced |
|---|---|
| Coding efficiently and cost-consciously | Model and effort choice per task type, context discipline, cost per task |
| Verification loops & tests | Checks the model runs itself: test suite, build, linter, comparison script |
| Designing complex systems | Specifications that are implementable; a planning step before implementation |
| Deployment & infrastructure | IaC and pipelines with AI, incident triage — with hard guardrails for secrets and permissions |
| Agents & security | Recurring work captured as automation, plus prompt-injection and licensing questions |
That AI doesn't automatically make experienced developers faster isn't an opinion: in a randomised study by METR on large open-source repositories the participants knew well, experienced developers took about 19 % longer with AI assistance — while estimating they had been roughly 20 % faster. That gap between feeling and measurement is exactly why this programme looks at review time, error rate and cost per task instead of impressions. Groundwork in Prompting Claude Code properly, details in the programme for developers.
How to structure an AI workshop that works
The structure is unspectacular, but the order and the time split decide the outcome. As a rule of thumb: around 70 % of the time is practice on your own screen.
| Phase | Share | Content |
|---|---|---|
| Preparation (before the day) | – | Short interviews, task inventory, prior-knowledge survey, collecting cases |
| Fundamentals | ca. 15 % | How models work, where they invent, how a good prompt is built, guardrails |
| Application on real tasks | ca. 55 % | Work on the cases people brought, in small groups, with support |
| Systematising | ca. 20 % | Saving results as templates, setting up the prompt library, defining review steps |
| Agreeing | ca. 10 % | Who owns what, what gets tested by when, when the review happens |
| Follow-up (after 30 days) | – | Compare the metrics, sharpen the prompts, pick the next candidates |
Two details matter disproportionately. First: the cases come from the participants, not the trainer. A task somebody already finds tedious is the best entry point — especially with sceptics. Second: whatever is created in the workshop gets saved immediately. A good prompt that doesn't land in a shared library is lost by Friday.
What an AI workshop has to deliver as a result
A workshop without artefacts is an event. This list is our minimum:
- A prompt library in one place everyone can reach, with a short note on what each prompt is for.
- Two to four working workflows or automations — in production, not as a sketch.
- Guardrails on one page: which data goes into which tool, who checks, who approves, what doesn't belong in external tools at all.
- Review and approval steps for the tasks where a mistake would be visible to the outside.
- Ownership: one or two people per team who act as the point of contact and onboard new colleagues.
- A date for the 30-day review, in the calendar, with names on it.
AI training as an obligation: AI literacy under Article 4 of the EU AI Act
Alongside the business case there is a regulatory reason for structured training. Article 4 of the EU AI Act requires providers and deployers of AI systems to ensure a sufficient level of AI literacy among their staff — applicable since 2 February 2025. The regulation's scope doesn't stop at the EU border: it can cover Swiss companies that place AI systems on the EU market or whose output is used there.
The regulation prescribes no particular form of training, no certificate and no number of hours. What it requires is a level of competence that fits the role, prior knowledge and the risk of the system in use. In practice: document who took part, what was covered and when; keep the content role-specific; and repeat it for new systems and new staff. Some AI Act deadlines are currently being adjusted through the so-called Digital Omnibus — check the current status for your specific case. More in our pieces on the EU AI Act for SMEs and on AI and data protection in Switzerland.
Measuring the success of AI training
Feedback forms on the workshop day measure mood, not effect. Record a small number of metrics beforehand and again after 30 days:
| Metric | How to record it | Why it matters |
|---|---|---|
| Duration per task | For three to five concrete tasks, estimated or timed before and after | The most direct translation into time and money |
| Frequency per week | From the system or with a tally sheet | Automating a rare task rarely pays off |
| Rework rate | Share of output that has to be revised | Shows whether quality holds or work was merely displaced |
| Active workflows | How many of the workflows built are still running after 30 days | The most honest adoption indicator |
| Users per workflow | Number of people actually using it | Separates "one person tinkers" from "the team works this way" |
| Cost per task | For engineering teams: token cost per ticket | Turns model and effort choice into a deliberate decision |
Even the pre-workshop measurement has an effect on its own: it forces prioritisation and stops the most visible use case from crowding out the most worthwhile one.
Common mistakes when planning AI workshops
| Mistake | Better version |
|---|---|
| All departments in one generalist session | Fundamentals together, application split by role |
| A workshop on the trainer's demo data | Cases from your own business, collected beforehand |
| Inviting only the enthusiasts | Deliberately include sceptics — with a task that annoys them personally |
| Settling the data question "later" | Fix the guardrails definitively during the workshop |
| No date after the workshop | A 30-day review fixed in the calendar, with metrics |
| One big day for 40 people | Groups of 4 to 12, and more sessions instead |
| Training once | Repeat for new systems and new staff |
Conclusion
An AI workshop that works differs from one that fizzles out not through better slides or a more modern tool. It differs because participants work on their own tasks, because every role gets what it actually needs, because prompts, workflows and guardrails are on the table at the end of the day — and because somebody checks in 30 days what of it is still running.
The shortest test for any proposal you request: ask what the team is holding in its hands at the end of the day. If the answer is "presentation materials", keep looking.
Wondering which programme fits your team? An overview of the three programmes is at AI workshops & training — or talk to us directly.
Sources
- EU AI Act, Article 4 – AI literacy – obligation for providers and deployers, applicable since 2 February 2025.
- European Commission – AI literacy: questions and answers – interpretation of the obligation, no prescribed form of training.
- METR – Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity – randomised study, roughly 19 % longer completion times despite the opposite self-assessment.
- FDPIC – The revised Data Protection Act – obligations when processing personal data in Switzerland.
- Anthropic – Best practices for Claude Code – verification, context management and the planning step in AI-assisted development.
Frequently asked questions
- What does an AI workshop actually achieve?
- That depends almost entirely on whether the workshop works on real tasks. A tool demo produces enthusiasm and no change: two weeks later the team works exactly as before. A workshop where participants work on their own tasks and leave with finished prompts, two to four working workflows and a playbook changes daily work from the next day onward. The decisive difference isn't the quality of the slides, it's whether something that runs is on the table at the end.
- How long should an AI workshop be?
- A fundamentals workshop needs half a day, a full role-specific programme a whole day. For larger teams, series of two to four sessions across a few weeks work better than one long day, because people practise in between and the real questions only surface in daily work. Beyond roughly six hours of workshop time per day there is, in our experience, no additional learning effect.
- What should AI training for employees cover?
- Four blocks: first, fundamentals — how language models work, where they are reliable and where they invent; second, role-specific application on real tasks from participants' own work; third, guardrails — which data goes into which tool, who checks, who approves; fourth, transfer — prompt library, workflows and ownership that keep running afterwards. Skip the fourth block and you have run an entertaining day and nothing else.
- Is AI training for employees mandatory?
- For companies within the scope of the EU AI Act, yes: Article 4 has required providers and deployers of AI systems to ensure a sufficient level of AI literacy among their staff since 2 February 2025. The scope reaches beyond the EU and can cover Swiss companies that place AI systems on the EU market or whose output is used there. No particular form of training is prescribed — but it should be demonstrable, so participants, content and date belong in a record.
- How do you measure the success of AI training?
- Not with feedback forms. Before the workshop, record for three to five concrete tasks how often they occur, how long they take and how often the output needs rework — then measure the same things again after 30 days. Add two adoption metrics: how many of the workflows built in the workshop are still running, and how many people use them. Satisfaction on the day says nothing about effect; that curve almost always drops in week two.
- Should we train everyone together or split by role?
- Fundamentals together, application separately. An accountant, a creative director and a backend engineer need the same grounding in reliability and data protection, but completely different applied skills. In practice a shared morning on fundamentals and guardrails plus a role-split afternoon works well — except for automations that cross departmental boundaries, which are worth tackling together on purpose.
About the author
Tenzin Langdun
AI Expert & Marketing Lead at Hierarchy
Tenzin is an AI expert and marketing lead with an MSc in Artificial Intelligence from the University of Bath and over 10 years of marketing experience across strategy, paid acquisition, and SEO. He has held roles at leading organisations including KPMG, EY, Siemens, and Adnovum — with expertise in AI, cybersecurity, audit and consulting, and the insurance sector. Together with Martin Oswald, he co-authored an award-winning research paper on AI-based cancer detection, published in Nature and recognised with the National Siemens Excellence Award and the Lab Sciences Award.