Deciding to automate with AI seems straightforward. Who would decline the opportunity to reduce the time and manual intervention required for specific tasks? Or to scale and consequently improve certain parts of a process?
Naturally, when we accelerate specific stages of our workflows, we assume we are improving them. Artificial intelligence reinforces this assumption, but reality often tells a different story.
Executing a task faster does not necessarily equate to a more efficient process. Sometimes, the problem we set out to solve does not disappear; it simply shifts elsewhere and often becomes harder to detect. This is neither the first nor will it be the last time in history this has happened.
A lesson from the 19th century
Let us go back to England in 1865, when economist William Stanley Jevons described a contradiction at the heart of industrialisation in his book The Coal Question. At the time, it was assumed that improving the steam engine and using coal more efficiently would reduce overall consumption.
Jevons observed the opposite. As steam engines became more efficient, they also became more economical to use. More and more industries adopted them, expanding their use and, in turn, increasing demand for coal.
This became known as the Jevons paradox: greater efficiency in the use of a resource can lead to an increase in its total consumption rather than a reduction. This does not mean that improving efficiency is pointless. It simply reminds us that a local improvement can change the behaviour of the entire system. What looks like a saving when we examine one machine in isolation may no longer look like one when we widen the scope of our analysis.
Bringing this back to the present day and artificial intelligence, we can see the implications of this paradox from two perspectives.
The first, and the one most closely related to Jevons’ original idea, concerns technology consumption. Even as the cost of using AI falls, total expenditure will not necessarily decrease, because AI is being used more frequently and applied to increasingly complex problems and processes.
The second perspective concerns the processes themselves. Even if AI enables us to complete a task much faster, that does not necessarily mean the end-to-end process has improved.
Different effects, but the same warning: efficiency in one part does not guarantee efficiency across the whole.
From local efficiency to overall inefficiency
An example makes this easier to see. Imagine an AI system that produces reports from multiple sources. At first glance, the task appears to have improved because drafting takes far less time. But the analysis needs to go further. Is the underlying data reliable? Who validates its quality, and how much time does that review require? What happens when the automation encounters a case it cannot handle?
Answering these questions may reveal that the process has not actually been optimised. Instead, effort has shifted from a visible activity to another that is harder to measure.
The same applies to software development. Accelerating one part of the process, whether code generation, testing or documentation, does not necessarily improve productivity. There is much more to consider, including integration, oversight, rework and corrections. Then there are the costs: licences, model usage, infrastructure, training and governance.
Gains in one stage can be lost if they create more work further downstream. Looking only at the automated task therefore gives us an incomplete picture.
Automating a poorly designed process
Stable, repetitive and well-defined tasks are usually the best starting point for automation because they are easier to control, particularly when their inputs are consistent and their outputs can be validated.
Problems arise when we try to automate tasks that are poorly designed in the first place. If a corporate documentation assistant works with outdated or inaccurate documents, it cannot improve organisational knowledge.
This is an important principle to keep in mind when automating: AI does not fix the system. It amplifies it, whether that system is well designed or not. And when the underlying system is confusing, AI can simply create more confusion faster.
How do we know whether we are actually optimising?
We have established that automation should start with a well-defined process. We also need to look at the process as a whole. But how do we know whether we are actually improving it?
We need to assess the end-to-end process by answering five questions:
- What are we trying to improve? This needs to be clear from the outset. Using artificial intelligence is not the objective; it is a means to an end. Are we trying to reduce lead times, costs or errors? What specific friction are we trying to remove?
- What is our baseline? We need to know where we started so that we can make a meaningful comparison once automation has been introduced.
- Where has the effort we saved gone? We need to examine other parts of the process that may have been affected by the change: production, review, exception handling and so on.
- Is quality being maintained? Moving faster achieves little if it results in more errors and lower overall quality.
- What is the total cost of achieving the outcome? This means considering the full cost of the process, including the technology itself, integration, maintenance, oversight, training and governance.
Answering these questions shifts the focus from activity to outcomes. There is little value in an automation producing thousands of documents or lines of code if we do not know how much of that output ultimately becomes useful product, at what level of quality, at what cost, or with what impact on the business.
Governed Automation
The question is not whether to automate with AI, but where to introduce it and on what basis. We need to understand what the technology can solve, what boundaries need to be established and where human judgement remains essential.
A better approach is to start with a clearly defined use case supported by well-defined metrics. Begin with a pilot that allows you to validate the results and measure the total cost. With that evidence, you can then decide whether to scale, adjust or stop the initiative.
The difference between automation and optimisation lies in being able to demonstrate that the end-to-end process delivers more value at a lower cost, with the same or better quality and an acceptable level of risk.
As Jevons showed us, improving efficiency in one part does not necessarily improve the whole. So before automating the next task, there is one question we should ask about those we have already automated:
Are we eliminating an inefficiency or simply shifting it to a task we are not yet measuring?
At LedaMC, we help you answer that question with data by analysing the end-to-end process, whether you have already introduced AI into your operations or are still deciding where to start.
