AI Training for Employees: Why One Track Never Fits a Whole Company

A full-day AI workshop for a large organisation usually gets booked as one event with one agenda. Then the room fills up.

In one recent series for a Czech infrastructure operator, fourteen people signed up. Some had never opened a terminal. One of them was already running an automated development pipeline in GitLab, with the agent doing analysis, planning, and a first self-review before a human ever looked at the change. Both of those people paid for the same day.

Run one track and you lose both. The beginner spends the afternoon watching someone else's screen. The advanced participant spends it answering questions the trainer should have handled. Nobody leaves with something they can use on Monday.

This is a field note on the format we ended up with, and on why the split matters more than the content.

When we mapped the AI use cases for that client before the workshop, we expected most of them to sit in software development. They did not.

Three business processes came out of the mapping: internal development, launching a new product, and sales support. Sales support alone covered opportunity discovery, matching prospects to existing products, customer communication, technical solution design, quotations, approvals, delivery, and upsell. Almost none of that is programming. Most of it is research, working with internal data, and preparing documents.

So the real audience for enterprise AI training is not "developers who need a new tool." It is two groups with genuinely different jobs, sharing one building and one set of security rules.

That reframing is what produces the format. Not the other way round.

The structure that works for us is one common morning and two parallel afternoon tracks.

The morning is for everyone. It covers how the tool actually works under the hood, the difference between a skill, a plugin, an agent, and plain instructions, and what happens when you connect the tool to an internal system. We keep the opening block to thirty minutes, then run two hands-on exercises of forty-five minutes each. One exercise builds a skill. The other plugs in an MCP server.

Both the skill and the MCP server are prepared in advance. This matters more than it sounds. A room of fourteen people cannot spend the morning debugging someone's local setup, and the exercise is about understanding what the connection does, not about typing it.

The afternoon splits. The business group takes the tool into their own work: competitor research, use-case discovery, describing an automation they want. The technical group goes to a second room and works on connecting internal systems, usually by building or wiring up an MCP server.

Two rooms is a logistics requirement, not a nice-to-have. Book them before you agree on the agenda.

The obvious failure mode of a split day is that the two rooms drift, do overlapping work, and produce two disconnected outputs.

We handle that in two ways. The groups check in with each other during the afternoon, and everyone reconvenes at the end to walk through what the other side built. The business group finds out that the automation they described needs a connector nobody has approved yet. The technical group finds out which of the tools they exposed is the one people actually wanted.

That closing session is where a workshop stops being training and starts being a plan.

Security is the first concern in every enterprise AI room we have been in, regardless of seniority. We wrote about what enterprise workshop participants actually fear about AI separately, and the short version is that it outranks productivity and cost every time.

The design consequence is that security belongs in the common morning, not in the technical track. If only the engineers hear the security block, the business group builds automations that the security team will later kill.

For the security-focused day in the same series, we opened with a short demo rather than a slide deck. Ten to fifteen minutes: prompt injection through an ordinary email, a PDF with white-on-white instructions, an image carrying a payload. The aim is not to frighten anyone. It is to give people enough of a mental model to make a qualified decision an hour later.

The afternoon then splits again, but along a different line. One track writes the governance documentation: how this organisation approves an MCP connector, what the audit process looks like, what happens during an incident. The other track builds a secure MCP server and covers what you can actually control today.

One exercise we keep reusing: one team designs the security steps for a new connector, the other team designs the adoption process for the same connector. Then they read each other's version. The gap between the two documents is the real state of AI governance in that company, and everyone in the room can see it.

Enterprises classify their data, and in regulated organisations the red category cannot leave the building. That constraint has to reach the exercise design, because the business track works with real material by default.

If competitor analysis and quotation drafting are the use cases, and quotations contain restricted data, the exercise needs a substitute dataset prepared in advance. We have used an export into a spreadsheet connected through an approved cloud drive as a stand-in for a direct CRM connection. It is a temporary answer, and we say so in the room, but it lets people practise the workflow without a compliance argument in the middle of the afternoon.

The unglamorous part of workshop design is the checklist that has to be closed a week earlier.

None of this is about AI. All of it decides whether the day produces working output.

The last thing a split-track day makes visible is that a single workshop was never the product.

Advanced participants who get a good day immediately ask for the next level. Beginners who get a good day want to bring their own team. Non-technical departments hear about it and ask whether there is a version for them, which is how legal, marketing, and back-office teams end up in scope. We ran that path all the way through at Heureka, where adoption reached 90 % across thirteen teams, and the same pattern shows up in our product, HR, marketing, and back-office adoption work.

If there is no next level ready, the energy from the good day drains out over the following month. That is one of the most common reasons AI fails to stick in a company: not a bad tool, but no path from the workshop to the day job.

So we structure training as levels rather than events. Fundamentals, then advanced practice, then the governance and integration layer that a platform team has to own.

Our current shape of that has four entry points. AI for IT Fundamentals is the technical starting line. AI for Product and Non-Technical Teams covers the business side. The Claude Cowork and MCP integration workshop is where the two tracks meet. The AI security, governance, and MCP workshop is for the day the security team joins.

Four things carry most of the result.

The rest is content, and content is the easy part. What decides whether a large organisation gets anything out of an AI workshop is whether the format admits that there were two rooms in there all along.

The workshop room is only one half of this. For the delivery-side counterpart, we wrote up how we roll out AI coding agents in large companies.