Why AI Alone Won’t Fix Legacy Workflows

Imagine a purchasing team adds AI to read supplier documents. The extraction works, the demo looks good, and each document takes less time to review. Yet the supplier still waits days for an account to become active. The request is sitting in an approval queue, and someone must copy the result into another system.

This is an illustrative scenario, but it captures a useful question for any AI project: how much of the customer’s wait does the improved task actually explain?

Camunda’s September 16 recap of its NYC Roadshow describes a September 10 discussion about redesigning processes around AI. Participants highlighted change management, fragmented ownership, and the need for an open foundation. Our practical reading: review the entire route from request to completed outcome before choosing where AI belongs.

What the research tells us

In research commissioned by Camunda, 72% of surveyed decision-makers reported process-related AI initiative failures. Meanwhile, 79% said adding AI to existing processes met less internal resistance than redesign. Sapio Research surveyed 1,000 decision-makers and 5,000 employees at organizations with at least 1,000 staff across the US, UK, Germany, and France in July–August 2026.

These are self-reported findings from a vendor-commissioned study; they do not mean that 72% of all AI projects fail. For a project team, they provide a reason to investigate process constraints alongside model performance.

Find the waiting time before automating the work

Return to the supplier example. Suppose document review falls from 30 minutes to three, while the request still spends two days awaiting approval. Those invented numbers illustrate the measurement problem: the team saved 27 minutes of effort, but the main source of delay remains.

Track a sample of real requests from arrival to completion. For each one, record when work starts, when it stops, why it waits, and who can move it forward. Include returned requests and abandoned cases; looking only at successful completions can hide the hardest work.

Then choose the intervention that matches the delay. Missing information may call for a clearer intake form. Repeated checking may call for a shared record. A queue with no accountable owner needs an ownership decision. AI document analysis becomes a stronger candidate when reading and interpreting documents is itself a material constraint.

Our guide to process discovery and mapping offers a starting point for documenting that flow.

Design the handoff as carefully as the AI task

For the hypothetical supplier process, we would define four things before expanding the pilot:

1. What the AI produces. Extracted fields should include references to the source material and an explicit indication of missing information.
2. What permits the next step. Define the required checks and approvals in the process. A plausible generated answer alone should not authorize supplier activation.
3. Who receives an exception. Assign a review queue, a responsible role, and a response deadline. Give the reviewer the original documents and the reason the case needs attention.
4. How completion is confirmed. The process ends when the supplier record is successfully created and the requester is informed. A generated recommendation is an intermediate result.

Test the awkward cases early: contradictory documents, an unavailable reviewer, and a system that times out after receiving an update. Before retrying a write, establish whether the first attempt succeeded so that recovery does not create duplicate records.

For the review step, human-in-the-loop governance provides more detail on authority and escalation.

Make future changes possible

The Roadshow’s emphasis on open standards is a useful design prompt. For this supplier workflow, we would use a BPMN process model to make the sequence and exception routes explicit, and define a separate input and output contract for the AI task.

That separation gives the team a concrete change to test: replace the document model while keeping the approval requirements intact. Check the replacement against the same examples, including missing fields and contradictory evidence, before putting it into use.

Also document the parts outside the diagram: integrations, identity permissions, stored data, and recovery behavior. A standard process model is only one part of a migration. Assess the effort of moving those dependencies when selecting an orchestration platform such as Camunda.

Turn the next 90 days into a measurable experiment

Here is a suggested plan for one bounded workflow. The timing is a planning frame; access to systems and the complexity of the process will determine what is feasible.

• Days 1–30: establish the baseline. Select a process owner, inspect real cases with the people doing the work, and measure completion time, waiting time, rework, and effort per completed case. Choose one bottleneck to address.
• Days 31–60: build and exercise the revised path. Connect the necessary systems, define the AI task, and test approvals, failures, and recovery. Let the operational team review the work they will actually receive.
• Days 61–90: run a limited pilot. Compare similar cases with the baseline. Track the median and slower cases as well as correction rates and cost. Agree in advance what results justify expansion or another design iteration.

At NG Workshop, our recommendation is to bring one concrete process to the first conversation: its desired outcome, a few representative cases, and the places where people currently intervene. That makes it possible to discuss a useful scope and a credible measure of success.

Talk to us about redesigning a process for AI