What Enterprise Workshop Participants Actually Fear About AI

The question that opens almost every enterprise AI workshop we run is some variation of the same theme: what happens to our data? Not "can AI write code?" That one was settled in 2024. The 2026 question is whether a security lead can sleep through the night after their engineering organisation has started using agents.

Over the past months we have run AI workshops across a Czech telco, a regional bank, a retail chain, an insurance group, a national media outlet, and a developer-tools company. The skill levels in the room have ranged from senior engineers to executives who have never touched a terminal. The single most consistent signal across all of them is that security ranks first. Productivity, cost, and even quality come after. This article is a field report: what participants actually ask, what is underneath those questions, and what changes the mood in the room.

These are ranked by how often we hear them, not by how often the participants think they should rank.

1. Security. Where does the data go, who can see it, and what jurisdiction holds it. The most common follow-up at a recent workshop with fourteen mixed-seniority participants from a Czech infrastructure operator was about data centre location and GDPR exposure. Prokop Simek, who leads enterprise sales and ran that workshop, summarised the recurring thread:

The same question gets asked at every workshop. It is also the most fixable one. Showing the architecture — where the model runs, what is logged, what is purged — usually moves the conversation forward within minutes.

2. Loss of control. Even when security is satisfied, participants worry about auditability. Who-did-what when an agent merged a pull request. Whether the code review trail is real or a rubber stamp. Whether the agent identity is distinguishable from a human user in audit logs. This is the question security teams ask after they have stopped asking about data residency.

3. Change management. Often phrased as "our developers will hate this" or "our developers will love this too much." In practice the split is not equal. Junior engineers tend to adopt AI quickly and use it a lot, even if they do not always fully understand the implications. The scepticism comes more from the senior side: they worry about getting AI-generated output that passes CI but just creates rework. Leadership worries no one will agree on what good looks like once an agent is in the loop.

4. Vendor lock-in and cost runaway. This is where licensing comes in. Participants want to understand what they are signing up for before they commit. The Claude Enterprise plan starts at 150 licences with a $40-per-user minimum spend, billed per token from there on. GitHub Copilot's pricing structure changed twice in 2026. Cursor reached a $3 billion valuation and is reportedly subject to acquisition rumours. None of this looks like a stable supplier landscape, and enterprise procurement teams know it.

5. Shadow IT. The quiet one. Developers are already using AI tools, with or without approval. The choice is rarely "block versus allow." It is "ungoverned versus governed." A workshop is often the first room where this conversation can be had honestly, because nobody is being interrogated about their personal Claude subscription.

KPMG's deployment of Claude across 276,000 employees in mid-2026 made one thing visible to every enterprise buyer: the framing for AI rollout has shifted from "which model" to "which trust architecture." Human-in-the-loop, agent identity separated from user identity, audit trail by default, sandbox-first rollout. Whether or not KPMG's specific implementation lives up to the marketing, the framing has stuck.

In the workshop room, this framing works because it gives participants a coherent narrative to take back to their security teams. It is also the framing that maps cleanly onto our own thinking around MCP governance. What participants want is not vendor reassurance. They want a checklist they can argue with internally.

Matyáš Křeček, who has led MCP governance work across several of our enterprise engagements, frames why a single-vendor governance story is increasingly hard to sell:

The point that lands in the room is the second half. Once a workshop participant realises that AI tooling is going to spread beyond the engineering org — to marketing, sales, legal, finance — the single-vendor story stops being attractive. Vendor-portable governance becomes the only architecture they can defend internally.

The fear does not disappear because we say "trust us." It moves when participants see something concrete that demonstrably solves their problem. Prokop puts it simply:

In practice, four things change the mood of the room reliably:

What does not work is more abstract architecture diagrams. The participants who matter — security leads and engineering managers — have seen all of them. They need the specific.

This is the topic that almost never makes the agenda but always surfaces in the second half of the workshop. Developers in the room have personal Claude or ChatGPT subscriptions. Some of them have been using Cursor against private codebases for months. Some have configured Copilot extensions that the security team has not approved.

The framing that lands here is not "stop doing that." It is: you already have AI in your codebase. The only question is whether it is governed. When that lands, the workshop tone shifts from defensive to collaborative within minutes. A security lead who came in to enforce a ban often leaves with a draft of an internal AI policy that enables what is already happening, with controls attached.

A practical version of this argument, which we have explored in more depth in From AI Assistants to AI Agents, is that the agent-versus-assistant distinction is more useful here than tool-by-tool restriction. Assistants suggest; agents act. The governance question is about what an agent can do, not what an assistant can suggest.

The next-most-common technical question after security is about agent topology. Should the team build one agent that does everything, or many agents with narrow skills? Jakub Vacek, who has been working on agent setups for an enterprise classification system, reflects the direction we see in the room:

This is not just an engineering preference. It maps onto the audit question from earlier in the workshop. A single monolithic agent is hard to govern because the scope is too broad. Many narrow agents with explicit skills are easier to log, easier to review, easier to revoke. The trade-off is operational complexity, and that is the part that tends to surprise leadership.

Workshop participants do not need a roadmap. They need four moves they can make this week.

The format that has worked for us is ninety minutes of structured conversation, not slides. We open with the participants' actual questions — written on cards before we start — and use the room's own concerns as the running order. The same skeleton works whether the audience is fourteen mixed-seniority participants at a telco infrastructure office, a security and architecture board at a national bank, or an engineering offsite at a retail chain.

We run these workshops as part of our enterprise AI adoption work. When the room is ready, the same conversation continues into a proof-of-concept around MCP governance and agent identity. When it is not, we leave behind the four Monday-morning moves above and check in a quarter later. Most rooms are readier than they think.

The fear about AI in enterprise is real and well-founded. It is also, in our experience, fixable within a single afternoon, provided the conversation is honest, the demos are concrete, and the framing maps onto what the security team actually has to defend.