Your Process Model Is an AI Opportunity Map

Most AI programmes start the same way. A workshop, a wall of sticky notes, forty use cases, a vote. Three months later there is one pilot, it works in a demo, and nobody can say where it fits in how the company actually runs. The ideas were real. They were just floating.

The fix is not a better brainstorm. It is a different starting point. A process model gives an AI idea three things a sticky note never has: a location (the exact step where AI would act), context (what flows in and out, who is accountable, what happens next), and a baseline (the approved way of working you will measure the change against). Once an opportunity has those three, it stops being an idea and becomes a design.

This post is about reading AI opportunities straight off a BPMN model. No new tooling, no AI maturity assessment. Four questions you ask of every diagram, and a small grid that turns the answers into build-ready patterns.

Start at the gateway

Look at any process model and find the gateway where a person reads the situation before choosing a path. Which engineer gets this ticket. Whether this refund is fine. Whether the vendor response is good enough to proceed. For twenty years that diamond was the hard edge of automation: rules engines could follow criteria someone wrote down, RPA could copy what was already decided, and neither could take a judgement call. Language models can. Every gateway with human judgement behind it is now a design question, which makes decision points the richest vein in any process landscape.

That is the pattern worth generalising. A BPMN construct maps to a capability that automation never had. Four constructs cover almost everything in knowledge work:

Walk a model against these four and the candidate list writes itself. No voting, no sticky notes, and every candidate is already attached to a step with an owner and a volume.

Then decide who holds the pen

Finding the step is half the job. The other half is deciding how much the AI gets to do there, and the model can carry that decision too. Three autonomy modes, each a gateway shape you draw:

Four constructs by three modes gives twelve patterns. Each is specific enough to hand to an engineering team with the model as the spec.

Two rules make the grid safe to use. Every candidate starts in the left column. And moving right is a decision taken after a measured delta, never a feature switched on. Do that across a whole process landscape and the grid becomes a heatmap: count the candidates per cell and you can see where AI value sits in the organisation, and how much of it is still waiting for a human to approve each case.

If you have seen the consultancy versions of this, six AI types by six autonomy levels and thirty-six cells, the lineage is the same. The rows here align with Gartner's use-case families and the columns are the familiar human-in-the-loop, on-the-loop and out-of-the-loop split. The difference is that every row and column is something you can point at in a diagram.

Run it in one session

This works as a 90-minute session per process, with the people who actually run it in the room. The output is an approved as-is model, a to-be model with the AI steps drawn in, and one candidate ready to build.

1. Model the happy path as it runs today. Twenty elements or fewer. Depth comes later, and only where a candidate sits.
2. Add the exceptions. Three questions get you there: where does it break, where does work wait, where do you ask someone. Every answer is an event or a gateway.
3. Walk the four rows over the model and mark every candidate. Do not evaluate yet. Marking is cheap, debating is not.
4. Attach four numbers to each candidate: volume per month, cycle time, error or rework rate, accountable owner. Estimates from the room are fine for a first pass. Those four numbers are the business case.
5. Draw the to-be. Give the agent its own lane, convert the chosen steps to AI tasks, pick a column for each.
6. Approve both models and read the delta. Pick the one candidate with the best ratio of volume to risk and hand it to the build team.

The agent lane in step 5 matters more than it looks. An agent is a participant like any other: it receives something, returns something, and hands back at a defined point. Drawing the lane forces those three definitions, and most stalled pilots stalled because nobody wrote them down.

Step 6 is what turns a workshop into a programme. The model is the specification the engineering team builds from, and the approved baseline is what the result gets measured against. Without the baseline there is no delta, and without a delta the second deployment never gets funded.

What to pick first

A high-volume internal step in the human-approves column. It proves the loop, produces a measured delta nobody can argue with, and builds the trust you need before anything moves into framed autonomy. Customer-facing steps and anything hard to undo come later, however tempting the demo.

Three things to avoid, because they are where we see programmes die:

• Starting from a vendor demo and looking for a process to fit it. The process comes first; the capability is matched to a step.
• Replacing a gateway with AI before the decision criteria are written down. If nobody can say how the decision is made today, the model cannot be checked tomorrow.
• Automating a rework loop that should be removed. Loops signal a broken process, not a candidate.

None of this needs a transformation office. It needs a process model that people trust, a room with the people who do the work, and the discipline to approve the baseline before drawing the future. That is also, not by accident, what Crismo is built for: model in minutes, mark the opportunities, approve both versions, and let the agents read the approved process instead of guessing at it.

If you want to try the grid on one of your own processes, start with the one your team complains about most. It will have the most gateways.