0. Introduction

Recently, even inside my company, “Let’s improve our work with AI!” has become a real trend.

In many AI improvement initiatives, what often happens is that people focus too much on “embedding AI into the workflow.”

  • “I want to put AI into this process!”
  • “I want to replace that task with AI!”
  • “With AI, you can do anything, right?! lol”

I’m not denying the value of using AI at all—but I don’t think AI-driven process improvement is only about “embedding AI into operations.”

In this article, I’ll organize my thoughts, including why I see it that way.

1. AI has things it’s not good at

LLMs (Large Language Models) are inherently non-deterministic systems.

What does “non-deterministic” mean?

Non-deterministic means that even with the same input, you can get different outputs each time.
For example, if you ask ChatGPT the same question twice, you’ll often get slightly different answers.
That behavior is exactly what “non-deterministic” means.

What does “deterministic” mean?

Deterministic means that the same input always produces the same output.
In real business operations, there are many tasks that should be processed deterministically.
A rule like “If the request type is A, route it to Department B” should yield the same result every time.

Where should AI be embedded?

In most cases, a single business process is made up of a combination of non-deterministic parts and deterministic parts.

If you embed AI into a part that should be deterministic, you introduce risks: unstable quality, unexpected behavior, and even increased complexity.

That’s why I believe the key question is not simply “Should we embed AI?” but rather:
Does this step need deterministic processing, or does it require non-deterministic interpretation?
Being able to distinguish that is critical.

2. Where to start

First, map the entire workflow

Based on that line of thinking, when I actually work on AI-driven process improvement, I start by organizing the entire business workflow.

Instead of jumping straight into implementation, I first take a bird’s-eye view of the whole process and decide exactly where to improve.
In my experience, choosing the target accurately often leads to faster results in the end.

  • For each step in the workflow, which parts are deterministic and which parts are non-deterministic
  • The INPUT/OUTPUT of each step (task)
    • I clarify this upfront so that if we replace part of the process, it can still connect cleanly with the steps before and after it.
  • How much effort (time/cost) each step currently takes
    • You can calculate this from the time you spend daily. If that’s too much work, rough estimates are still fine.

Identifying the improvement target

Once the workflow is organized, I pick the steps to improve.
The two axes I focus on are current effort (time cost) and implementation difficulty.

<Current effort (time cost)>
This is the time spent on each step as identified in the mapping. High-effort steps tend to have high potential impact and can be good first targets.


I evaluate difficulty along two dimensions:

  • Can the workflow be predefined (fixed), or does it change flexibly depending on context (dynamic)?
  • How heavily does the process rely on an LLM (frequency / complexity)?
Process improvement difficulty matrix
Process improvement difficulty matrix

The best “first target” is: Fixed workflow × No LLM interpretation.
Within that zone, I start with items that deliver the biggest reduction in time cost.

Even if the time saved looks small in this pattern, it adds up.
For example, saving 10 minutes a day becomes 200 minutes per month (20 workdays), and 2,400 minutes per year (40 hours).
I use that time to challenge the next level—this is the approach I take.

Also, across all patterns, for the “design” and “implementation” parts of building workflows, I use coding agents like Codex or Claude Code to speed up and streamline development.

3. Let’s think through a concrete example

For example, imagine a process like this:
“A user submits a request for access permissions, and an administrator grants the required permissions.”

Pattern A: Let AI do everything

The LLM interprets the request content, dynamically generates the workflow itself, and decides which permissions to grant.
Dynamic workflow × Heavy LLM interpretation = the hardest

It certainly sounds cool, and if it works, it looks like full automation.

But every time the LLM’s judgment drifts, there’s a risk of granting the wrong permissions.
And permission management is directly tied to security—so I think it’s dangerous for that to be unstable.

Pattern B: Use AI for the “building” part

First, you organize a mapping table between request patterns and the required permissions.
You use the LLM for “discovering the patterns” and “reviewing what permissions are needed for each pattern.”
(This is an area where it’s okay to fail repeatedly.)
You also use AI to help design and implement the workflow.

Then the system you build processes requests deterministically based on that mapping table.
Fixed workflow × No LLM interpretation = the easiest

How I think about system design

This is my personal view, but in systems, we should aim for 100% accuracy wherever we reasonably can.
In other words, if something can be implemented deterministically, I believe it’s better to push it in that direction as much as possible.

It often makes implementation and testing (validation) easier as well.

My approach is: first pursue whether we can do it without non-determinism.
And only after that, delegate the minimum unavoidable area to an LLM—then design the improvement around that.

4. Summary

In AI-driven process improvement, what matters is not “how to embed AI,” but staying focused on the goal and deciding where to use AI—and where not to.

You think about process improvement with AI as a technology in mind, and you also use AI during the improvement process.
Even if the final solution doesn’t embed AI directly, I still think that counts as “AI-driven process improvement.”

I’m still in the middle of lots of trial and error myself, so I’d genuinely appreciate comments like “Here’s another way to think about it,” or “I disagree with this part.”

Let’s keep pushing forward on “AI process improvement” together!!