AI and automation: what to automate first, and what to leave alone

A services company installs an artificial intelligence assistant to answer its customers’ frequent questions. It answers quickly, in good Spanish, twenty-four hours a day. Three months later the customer service team still has the same workload. The assistant handles the easy questions well, which the help page already resolved, and when a hard one arrives it hands it to a person along with a prior conversation that has to be read. In half the cases, the team now works a little more than before.

Nobody did anything wrong, except choose the task. And choosing the wrong task weighs far more on the outcome than choosing the tool, which is where almost the whole conversation goes.

Automating is not always adding artificial intelligence

A good share of a mid-sized company’s repetitive work is solved with a fixed rule, an integration between two systems or a form that avoids retyping, with no model of any kind. That costs less, explains itself and does not fail in strange ways. Artificial intelligence is needed when the task requires interpreting something that does not fit in a rule, such as reading documents that arrive in a different format each time or understanding what a customer wrote.

Three questions for choosing the task

• How many times a month does it happen? A task that happens four times a month does not justify a project, however annoying it is.
• Can the rule be written down? If two people do it differently and both are right, automating before writing it down is automating the disagreement.
• What does a mistake cost in the worst case? Misclassifying an email costs a minute. Wrongly releasing a shipment costs a truck.

Start where volume is high and mistakes are cheap: sorting incoming email, extracting data from documents, drafting a first reply that someone then adjusts. These are tasks nobody proposes in a committee, and the person who does them every day identifies them in one conversation, if asked what they do every day that they feel they should not be doing.

Before starting, write down which indicator the chosen task will move and what it is worth today: hours, errors or cycle time. Without that measurement, the result is compared against a memory, and memory always favours the project.

Chatbot, assistant and agent are not the same

The difference is not sophistication but what each is authorised to do. A chatbot answers with information that already exists. An assistant prepares work for a person, who approves it. An agent carries out steps towards a goal and decides along the way. A chatbot that gets it wrong gives a bad answer; an agent that gets it wrong does something: it creates an order, writes to a customer, releases a shipment. That is why, faced with an agent proposal, the useful question is not what it can do, but what it cannot do and how it is prevented from doing it.

How much autonomy to give it

A 2025 Stanford University study surveyed about 1,500 workers and experts on how much human involvement they want to keep across 844 tasks in 104 occupations. The middle level of the scale, where the system and the person work together and neither decides alone, was the level workers preferred in 47 of the 104 occupations (Stanford, Future of Work with AI Agents). The main barrier they reported was not fear of replacement but lack of trust that the system does the task well, at around 45%.

Almost every commercial proposal aims for the system to act alone, because that is where the saving that can be promised lies. Starting at the middle level and moving up with evidence is cheaper than starting at the top and coming down after an incident.

What has to be settled before it goes live

Data sets the reach. If information is spread across systems that do not talk to each other, or nobody is accountable for its quality, the model works on that disorder and repeats it faster. Reviewing the data, the process and who answers for each source costs far less before building than after.

Security and continuity are designed in from the start. Decide which company information may go out to the model, how an incorrect recommendation is caught before it reaches the operation, and what the department does if the system fails. In an operation that cannot stop, the fallback procedure is part of the design, not an appendix.

Where the effort really goes

Boston Consulting Group proposes a split known as 10-20-70: about 10% of the effort in the algorithms, 20% in technology and data, and 70% in people and processes (Forbes, on BCG’s principle). A supplier’s proposal covers the 10% and the 20%. The 70% is hours from your own people: writing the rule, reviewing the output in the first months, learning, and changing the department’s procedure until they trust what the system delivers. If nobody budgets for them, they do not happen.

And before signing, ask about the cost in year two. When pricing is based on usage, a project that works costs more: the pilot ran on a hundred documents a month, and in production it is four thousand.

Also ask what happens if the supplier raises the price, changes the model or stops providing the service. The rules, the data and the configuration have to belong to the company, and the architecture has to allow a change of model without rebuilding the project. An artificial intelligence strategy that only works while market enthusiasm lasts is not a strategy.

The hard decision is not which model to buy. It is how much to let it decide and how to sustain it once the enthusiasm fades, and both are settled before signing.