AI is now everywhere.
It writes meeting notes. It drafts reports. It summarises complaints. It classifies defects. It fills in forms that nobody really wanted to complete in the first place. Used well, that is genuinely helpful. Used badly, it becomes something else. A machine for speeding up poor thinking.
That is the real issue in continuous improvement. Not whether AI is good or bad. Not whether AI will replace Lean. And not whether you should pick technology over capability. The better question is simpler:
What exactly are you asking AI to do?
Because in continuous improvement, some work should be automated. Some work should not. And right now, I fear we are treading a very dangerous path with how quickly it is growing. I teach people how to use AI effectively, and with it’s current plaguing of business systems, I fall back to a quote I love from Guthrie Govan: “I will show you this move, but know this: it will only be useful to you the day you can do it quicker than you can decide to do it.”
Use AI for the admin burden that adds no learning
Let us start with the part that is easy to say plainly. AI is great for admin. If your team is drowning in repetitive overhead, AI can help with the parts of the job that consume time without building much capability in the people doing them. That includes things like:
- Drafting reports
- Summarising meeting notes
- Formatting A3 updates
- Logging actions
- Cleaning up written observations
- Categorising comments or defect descriptions
- Pulling standard content into project documents
- Converting messy notes into a usable first draft
This is where I would actively encourage experimentation. Because this work is often necessary but low-value from a learning point of view. It needs doing. But it does not usually develop someone into a better problem solver. So if AI can remove some of that drag, good. Use it.
Automate the clerical load. Protect the human effort for understanding the problem. That distinction matters more than most teams realise.
Treat AI outputs as drafts that need expert review
There is another practical rule worth making explicit. AI outputs are drafts. They are not finished products. That applies whether the tool is drafting a report, summarising failure data, suggesting a root cause, or proposing a countermeasure. The speed can be impressive. The wording can sound polished. The structure can look convincing. But convincing is not the same as correct.
An AI answer is only as useful as the person reviewing it. If the reviewer lacks domain expertise, process knowledge, or critical thinking, they cannot reliably tell the difference between a strong draft and a confident-sounding mistake.
Teams sometimes assume the risk sits in poor prompts. It does not stop there. The bigger risk is poor judgement after the output arrives. So instead I encourage people to have a better mental model:
Treat AI like a junior analyst.
A junior analyst can be very helpful. They can draft quickly. They can organise information. They can pull themes together. They can save you time. But you would not let a junior analyst rewrite your process, declare the root cause, or trigger operational action without review from someone seasoned enough to challenge the work. I believe, the same applies here. Before anything is acted on, someone with real expertise should assess it against:
- The actual process
- The data and its operational definitions
- The operational context
- The known history of the issue
- The reality of work as done
- The practical constraints of the people doing the work
If that sounds slower, good. Some things should be slower. Because the purpose is not to admire and implement the draft. The purpose is to test whether it stands up in the real system.
Ask yourself:
- Does this output reflect the process we think we have, or the process we actually run?
- Does it use the measure correctly?
- Has it confused correlation with cause?
- Has it missed a local condition that anyone close to the work would spot immediately?
- Are we accepting this because it is good, or because it arrived quickly and sounds certain?
Speed without review is how confident nonsense becomes action that everyone gets fed up of. Use AI to draft or to prepare. Use it to reduce the admin load around improvement work, but keep human expertise in the loop.
Do not offload the thinking and call it improvement
Here is where many teams go wrong. They do not just use AI to tidy the paperwork. They ask it to produce the answer.
- “Find the root cause.”
- “Write the countermeasure.”
- “Tell us what process to change.”
- “Summarise the data and recommend the fix.”
That sounds efficient. It feels modern. It is also a trap. Because continuous improvement is not mainly about producing an output. It is not about having a root cause statement written on a slide. It is not about having a fishbone diagram completed. It is not about getting even to the perfect solutions. Those things are artefacts. They are evidence that thinking may have happened. They are not the thinking itself. The deeper purpose is capability development.
When I say Lean here, I do not mean the shallow definition people often repeat about waste reduction and value. Those matter, of course. But the stronger definition is this: Lean is about developing people into capable problem solvers– and that definition changes everything. If the AI does the thinking, who learned to define the problem? Who learned to distinguish symptom from cause? Who learned to test an assumption? Who learned to see the system more clearly?
Usually, nobody. And that means the organisation may get a faster answer today while becoming less capable tomorrow. It is hard to separate the short term benefits from long term sustainability. And when you excessively rely on AI. I would argue that is not improvement, that’s dependency.
Separate WAI from WAD before you automate anything
This is where the WAI vs WAD framing helps:
- WAI means work as imagined. This is how leaders, procedures, systems, or project plans assume the work happens.
- WAD means work as done. This is how the work actually happens in real conditions, with interruptions, workarounds, judgement calls, missing information, and practical constraints.
This is relevant because many automation efforts are built on WAI. The documented process. The approved workflow. The neat version in the SOP or the clean boxes in the process map. But the real work lives in WAD. So what happens if you automate before understanding that gap?
You scale the workaround. You lock in the defect handling loop. You speed up the hand off that should not exist. You make the bad measure easier to report. You automate the very friction that was telling you the system needed attention. That is the uncomfortable truth. AI can make waste travel faster. So I would always encourage… before you automate, go and look:
- Where does the work actually stall?
- Where do people re-enter data?
- Where do they bypass the system?
- Which steps exist only because an earlier step is unreliable?
- Which reports are being produced because trust is low, not because customers need them?
- What are people doing to keep the process afloat that the system never acknowledged?
Beware of automating waste, poor quality, and tampering
Many organisations say they are using AI to improve a process. Often, they are doing something narrower which is that they are making an existing activity faster. That can be useful, but speed is not the same as improvement. Are you improving the process, or just accelerating its current defects? I have seen teams automate:
- Repetitive data entry created by broken system design
- Daily reporting nobody uses to make decisions
- Escalation loops caused by unclear ownership
- Manual checking created by unstable upstream quality
- Approval chains that exist because trust and standards are weak
- Forecast updates based on noisy measures that should never drive action that frequently
The last point matters. Sometimes AI is used to generate fresh signals, predictions, or recommendations at high frequency. People then react constantly. Adjusting schedules. Chasing noise. Changing priorities. Intervening in a system that was already variable. In continuous improvement terms, that can become tampering.
By tampering, I mean reacting to normal variation as if it were a meaningful signal, and in doing so making performance worse. Deming warned about this long before AI existed. The principle still applies. If an AI tool gives you more prompts to intervene, that does not automatically mean you should intervene more.
More information can create more noise if your method for interpreting variation is weak. So before you automate or trigger action from AI output, ask:
- Is this process stable enough to automate?
- Is this a real signal or just common-cause variation?
- Are we removing waste, or just digitising it?
- Are we helping people see the system better, or pushing them to react faster without understanding?
Keep AI in the assistant role during problem solving
There is a better way to use AI in continuous improvement which is simply to use it as an assistant. Not as the thinker… which means AI can help you with the scaffolding around problem solving while the team still owns the reasoning. For example, AI can support by summarising interview notes before the team reviews them, grouping recurring issues from complaint text, drafting a first version of a charter or storyboard, turning raw notes into cleaner language or even maintaining logs, version history, and routine documentation.
That is useful because it removes drag without removing learning. But the team still needs to go to the process, observe the work, check the data and its operational definitions. Test cause-and-effect relationships, Involve the people doing the job, run experiments and reflect on what happened and why. This is the part some people want to skip. Understandably. Thinking is slower than prompting. But the thinking is the value. If you are serious about capability, you cannot outsource the core reasoning and then wonder why nobody grows.
As Taiichi Ohno is often quoted:
“No problem is problem.”
Useful words. But only if you apply them situationally. In practice, the challenge is not just spotting a problem. It is developing the discipline to understand it properly before rushing to a fix.
Remember that sometimes the manual effort is the intervention
I learned this lesson early. When I was younger in my training, I remember watching team leaders go out to their team members to gather data and information, then come back to a KPI board that was still paper-based and manually drawn by the team leader.
Coming from my early continuous improvement training, I challenged it. Surely this was waste. Surely this could be automated easily. Surely the manual collection and hand drawn board were just inefficient overhead. “What a waste of time” was my view. I was given a response I have never forgotten. It was not about the efficiency of data collection at all.
It was about forcing team leaders to go to the gemba… the place where the work happens, and where the information actually lives and stand next to their team members (What is Gemba really all about? | Syniad CI). It forced them to take ownership of the data and the problems behind it. There was no hiding. Full ownership. Full accountability.
It pulled them away from their desks. It made them see the reality of the work. It made them ask questions. It made them see and hear the friction in the process directly from the people living with it. And that changed how I saw the board. Because in reality, the manual board, the walk to the gemba, and the conversation with team members was the point. They were deliberately focusing on the behaviour first and only once that behaviour was embedded would they consider automating the data collection. Because if they had automated it too early, they would have automated away the very behaviour they were trying to build. The same logic applies to AI.
If you automate the thinking too early, you automate away the learning. If you automate the human connection to the work too early, you automate away the ownership. If you automate the observation too early, you automate away the chance to see the gap between WAI and WAD for yourself.
So yes, remove admin burden where it makes sense. But be careful. Sometimes the apparently inefficient step is carrying a deeper purpose. Sometimes the manual act is not there because the organisation is backward. Sometimes it is there because the behaviour has not been built yet.
Automate only after the behaviour and understanding are embedded. That is true for data collection and reporting. And it is just as true for AI in continuous improvement.
Use lean six sigma training to build judgement, not just tool usage
This is also why lean six sigma training still matters, even with far better AI tools now available. Not because people need more certificates or that even six sigma will ‘solve’ your operational issues. It matters because people need a method for thinking.
Good lean six sigma training should help people learn how to:
- Define a problem in operational terms
- Establish a trustworthy baseline
- Understand variation
- Distinguish signal from noise
- Explore causes without blame
- Test assumptions instead of defending them
- Involve the people closest to the work
- Build controls that sustain learning, not just compliance
Then AI can sit on top of that foundation. Without that foundation, teams tend to use AI in one of two weak ways; either they use it as a shortcut to answers or they use it to automate paperwork from a broken process. Neither builds an improvement culture and so we are responsible for building a better sequence which may look something more like:
- Teach people how to think about processes.
- Help them see work as done.
- Use AI to remove admin burden and support analysis preparation.
- Keep judgement, experimentation, and learning with the team.
That sequence protects the thing that matters most. Human capability.
The real point: improve the work and develop the people
This is the premise I am is pushing for, the point of continuous improvement is not to generate elegant outputs more quickly. The point is to improve the work while developing the people who do and lead that work.
That is why a straight answer matters here… Yes, AI is genuinely useful in continuous improvement. Yes, it can remove a lot of tedious overhead. No, it should not become a substitute for problem solving. And no, speeding up a poor quality process does not count as improvement.
If you remember only one line, make it this: Automate the admin. Do not automate the thinking.
Start there. Look at one live process. Find the burden that wastes time but adds no learning. Remove that first. Then stay close to the work, stay honest about WAI vs WAD, and keep building people who can solve problems without becoming dependent on a tool.
That is a far better use of AI in continuous improvement than asking it to think for you.
