By 2026, “we should do something with AI” has become a standing item in nearly every board meeting. The market has responded with hundreds of training offers, most of them focused on teaching teams how to use ChatGPT or Microsoft Copilot. These have their place. But they don’t answer the question leadership is actually asking: which process should we change, and what would it take to start?
A strategic AI workshop is built for that question. Done well, it ends with a concrete decision: the process (or a few processes) worth piloting in the next four to six weeks, or a deliberate “not yet” with a clear reason. Done badly, it ends with a roomful of inspired executives who, by Monday morning, don’t know what to do next.
The difference between the two outcomes comes down to what’s actually on the agenda. If you’re evaluating workshops for your leadership team, we’ve prepared a checklist to bring to that conversation.
Read on to see the six elements that separate a workshop that produces a project from one that produces a feeling. Skip any of them, and the team either leaves without a decision, or with one that won’t survive the first board meeting.
1. A grounded view of where AI actually delivers value
A lot of AI workshops still work the same way: a tour of the latest models, ChatGPT demos, case studies from Forbes or McKinsey reports. Participants leave informed, sometimes inspired. They still can’t say where AI would actually pay off for their own organization — and that’s the only question that matters.
A more useful starting point is one simple test: where do you do the same kind of work over and over? That’s where AI usually helps.
The workshop’s job is to apply this filter to the room’s own work. Not “AI in financial services,” but “your compliance team runs the same six steps every time, and four years of past requests sit in SharePoint.” That’s the kind of process where AI can take days of work down to hours — and where a pilot has a real chance of paying off.
2. A readiness check before anyone talks about tools
Most AI projects don’t fail because the technology doesn’t work. They fail because the company wasn’t ready to use it. We covered the most common reasons AI projects fail in a separate article, but the pattern repeats: the build works, the demos go well, and six months later nobody is using the system.
To avoid this scenario, when we score processes for pilot readiness, we look at four things. Any one of them missing will sink the project:
Data quality and accessibility. Does the data this process depends on exist in a usable form, and can the people who’d use the AI actually get to it?
Team openness. Is the team that owns this process willing to change how they work, or will they resist it?
Available tools. Does the market already offer something close to what’s needed, or does this require a custom build?
Financial impact. What’s the realistic effect on revenue or cost if this works, in numbers the business already tracks?
Honest answers are often uncomfortable. That’s exactly why they’re worth getting early. It’s much cheaper to find out your data isn’t ready during the workshop than three months into a paid development project.
So what happens once those four questions get answered? If the boxes look reasonable, the workshop moves on to the hands-on part: working on the actual processes. If they don’t, the most useful outcome may be a different one. A clear list of what to fix first before any AI conversation is worth having.
3. Hands-on work on the company’s own processes
This is the part of the workshop that turns a conversation into a decision. It’s also the part most providers skip, because it’s harder to run than a presentation. A panel discussion about “applying AI to your business” isn’t hands-on work. Sitting the leadership team down and writing the specifics of a few real processes is.
Whatever structure the workshop uses (a scoring matrix, a value-vs-feasibility map, a written brief per process), what matters is that it forces specifics onto the page. For example, this is how we approach it: each candidate process gets walked through our AI Opportunity Canvas, a one-page form. Its sections include, for example:
The process
A specific, named workflow the team is considering for AI, described in enough detail that someone outside the room would understand it. Categories like “documentation” or “reporting” don’t work here. The answer should be concrete, for example: “the quarterly compliance report the operations team writes every December.” Vague answers block everything that comes next.
The owner
A specific person in the company who is accountable for how this process runs today. Not a department, not a role, an actual name. If nobody can answer this, the project has no internal sponsor and will stall the moment the workshop ends.
The cost
What this process costs the company today:
How many people work on it?
How many hours does each cycle take?
What happens when it goes wrong (missed deadlines, regulatory fines, customer complaints, weeks of catch-up work)?
Without these numbers, ROI calculations later in the workshop are guesswork.
The data
Where the documents and information this process depends on actually live, for example:
In paper files
On a shared drive
In a specific system like SAP or SharePoint
Scattered across email inboxes
This determines whether a pilot is technically possible at all, and how long it would take to get started.
The measurable goal
A concrete number that should change in 4–6 weeks if the pilot works, defined in advance, for example:
Hours saved per week
Error rate
Response time
Throughput
The metric has to be something the business already tracks, otherwise nobody will trust the result.
The minimum pilot
The smallest version of the process you could realistically run with AI and learn from. Not “automate the entire compliance process,” for example, but “have AI draft the first section of one type of report and measure how much editing it needs.” A smaller pilot fails faster and cheaper, which is what you want from a first project.
How our client used this in practice
Recently, one of our clients saw exactly how this works in practice. During a workshop, they needed to evaluate four candidate departments for AI pilots. We scored each one against the same four criteria: data accessibility, team openness to change, available tools on the market, and realistic financial impact.
Three passed. The fourth was set aside, not because AI couldn’t help, but because the work in that team rarely repeated. Every project was different, so there was no pattern AI could learn from. Leadership left with three pilot candidates ready to move forward, and a clear understanding of why the fourth wasn’t.
The format isn’t what matters; the discipline of writing it down is. By the end of this section, the leadership team has a small set of processes scored against the same criteria. They also have a written record they can take back to the board or hand to the team that’ll run the pilot.
4. A clear framework for responsibility and risk
Most AI conversations skip the risk part because it’s uncomfortable. Productivity gains are easier to talk about than who’s accountable when the AI generates a report with a wrong number in it. But the questions don’t disappear when they’re not asked. They just get answered under pressure, after the pilot is already running.
A workshop that takes this seriously puts three questions on the table before anyone debates which model to use:
Who approves what the AI produces? AI can draft, summarise, classify, and recommend. It shouldn’t be the final approver of anything that matters. Naming the human in the loop is a decision the leadership team should make in the room, not something to delegate later.
What happens when the AI gets it wrong? Not in the abstract, but specifically. If the system misclassifies a contract, who notices, who fixes it, and who explains it to the client or regulator? If the answer is “we’ll figure that out later,” the pilot isn’t ready.
Where does the data go, and who can see it? A pilot that quietly sends sensitive data to a third-party API without anyone signing off is a compliance problem waiting to happen. The data path needs to be drawn before the first prompt is written.
In practice, these questions translate into specific contractual mechanisms. In one of our recent engagements, we structured a 12-month warranty for everything our team builds around the AI model, with a separate 90-day warranty for the AI-generated outputs themselves. When a model gets deprecated by its provider, we have a 14-day notice mechanism to inform the client, followed by a scoped migration to a new model as a separate engagement. For clients who can’t tolerate this kind of model churn at all, we move them to local models from the start, where the infrastructure stays under their control.
There’s more to the risk picture than these three questions. We covered the broader pattern in our piece on the key risks of implementing AI. The point of raising them in a workshop isn’t to scare the room away from AI. It’s the opposite: when the pilot launches, nobody is improvising answers under pressure, because the answers were already on a whiteboard six weeks earlier.
5. An honest framework for cost and ROI
The leadership team needs to leave with a realistic sense of what an AI pilot actually costs and what kind of return is plausible. This is the section where most workshops fail in one of two directions. The first is unhelpful in the abstract: “AI will transform your business,” no numbers attached. The second is unhelpful in the specific: vendor-supplied ROI projections that read like they were generated by the vendor’s own marketing team.
A useful workshop sits in between. It explains what a typical first pilot includes:
A defined scope: One process, one team, four to six weeks. Not a transformation programme.
A working prototype: Connected to real data, not a sandbox demo.
A measurement phase: Against a baseline the company already tracks.
A go/no-go recommendation: Written, with reasoning, at the end of the pilot.
It also explains what’s usually in the budget (discovery, development, integration, model costs, internal time) and what isn’t (full deployment, change management, ongoing licences). The room shouldn’t leave thinking a pilot is the same thing as a finished product, and they shouldn’t leave thinking it costs ten times more than it does, either.
One thing easy to overlook is the cost of keeping the system current as AI models evolve. Models get released faster now than they did even a year ago, and each major change may require some work to keep the system performing the way it did at launch. As a rough order of magnitude, expect that maintenance to run somewhere between 1% and 10% of the original project value per year, depending on how the system is built.
The harder conversation is about ROI. A first pilot rarely pays for itself in its first cycle, and any workshop that promises otherwise is selling rather than advising. What a pilot actually produces is information about whether the process is suitable, whether the data holds up, and whether the team will use the tool. That information is what makes every project after it cheaper and faster. Framing the pilot as a learning investment is the difference between leadership setting realistic expectations and feeling let down six weeks later.
6. A decision at the end
The deliverable of a strategic workshop is a decision. Not a feeling, not a follow-up email, not “let’s reconvene in a month.” The deliverable is a written decision on each process discussed during the session.
In practice, the decision falls into one of three categories.
Go: One to three processes worth piloting, each with a named owner and a measurable goal for the next four to six weeks. The workshop ends with the team committing to a first step, with a date.
Not yet: The process is worth doing, but a specific gap blocks it: usually data quality, process documentation, or unclear ownership. The output is a written list of what needs to happen before the pilot makes sense, with someone responsible for each item.
Not here: AI isn’t the right answer to the problem on the table. The honest answer is “no,” and recognising that in a workshop is a far better outcome than discovering it nine months and a six-figure invoice later.
All three are valuable. The only outcome that isn’t is the room leaving with a vague sense that “we should do more with AI” and no agreement on what that actually means. If a provider can’t tell you in advance what kind of decision their workshop is designed to produce, you’re booking the wrong workshop.
Interested in Running an AI Strategy Workshop This Way?
If this approach makes sense for your leadership team, we’d be glad to walk you through it. We design these sessions around your processes, your data, and the decisions you actually need to make: not a tour of generic tools.
A good first step, if you want to see how it works before committing to anything, is to download the AI Opportunity Canvas and fill it in for a process you’re already considering. It’s the same form we use during sessions. If you’d like us to take you through the rest, contact us.Artykuł 6 Key Elements a Strategic AI Workshop Should Include in 2026 pochodzi z serwisu DLabs.AI.