AI automation for business: what to automate, what not

The most common mistake in business AI is starting with the question of where to put a chatbot. The correct order, process first, technology second, is set out in our article AI will not fix a broken process, including the sequence Remove, Simplify, Automate, Augment.

This text begins one step later, at the point where you already know the process and have to decide who does what inside it: which tasks belong to a rule, which to a model and which to a person, how you set permissions and approval, and what you do on the day the model gets something wrong. More deployments fail on those three things than on the quality of the model.

Map the process before you choose a model

Tasks can only be divided once the process is mapped out: who creates the information, where it is re-entered, who validates it and what happens when something goes wrong. Without that you cannot tell whether a task belongs to a rule, a model or a person.

Many tasks that companies label as an AI project do not need AI at all. Moving a form submission into CRM or creating a task after an order status changes is deterministic automation, a sequence of rules that returns the same output for the same input every time. It is cheaper, more predictable and easier to audit.

The distinction is not merely terminological. Recital 12 of the European AI Act states that the definition of an AI system should not cover systems based on rules defined solely by natural persons. The key property of an AI system is the capacity to infer, that is, to produce predictions, content or decisions beyond basic data processing. In practice: if a task can be written as a rule, write it as a rule.

AI earns its place where the input is unstructured: emails, documents, calls, notes, images, or situations that require information to be summarised, classified or turned into a draft recommendation. Adoption reflects that. According to Eurostat, the most widespread AI technology in EU enterprises in 2025 was text mining, the analysis of written text, at 11.75%.

Which tasks belong to the machine and which to people

Instead of a list of fashionable use cases, three questions do the work.

What does an error cost? A poor internal note costs a minute, a badly sent proposal costs margin or a client. The higher the cost, the closer a person has to sit to the decision.
Can the output be verified faster than it could be produced? If so, it is a candidate for a model draft with human confirmation. If checking takes longer than the work itself, the model is only moving the effort somewhere else.
Is the action reversible? A draft, a classification or a summary can be discarded. A sent email, a changed price, a paid invoice or deleted data cannot.

The result is a split you can defend in front of the finance director and in front of the lawyer. The model owns interpretation and the draft, rules own everything unambiguous and repeated, and a person owns the decision that is expensive, irreversible or carries responsibility towards a third party.

Where to look for the first tasks is indicated by field research from the economists Brynjolfsson, Li and Raymond, published as a working paper by the American research organisation NBER. Across a sample of 5,179 customer support workers, a generative assistant increased the number of issues resolved per hour by 14% on average. For newcomers and less experienced staff it was 34%, while for experienced staff the effect was minimal, because the model spreads the practices of the best workers.

The conclusion is specific: AI raises the floor, not the ceiling. Look for the places with the widest quality variance between people, not the ones where performance is already excellent.

The highest-value AI is often invisible to the customer

Effective AI does not need an avatar on the homepage. In the background it can prepare context for a sales person before a call, draft a proposal, flag missing data in an order or turn a meeting into tasks. People then handle less administration and more of the work the company genuinely needs them for. How a company can be built this way from the start is covered in our text on building a company without an admin army.

In its economic index from September 2025, Anthropic reports on its own data that 77% of cases in the enterprise API showed automation patterns, compared with roughly 50% in the consumer application. Companies are not buying conversation. They are buying work inside a process the customer will never see.

An illustrative example. A manufacturing company receives enquiries by email as free text with PDF drawings, and an assistant re-enters them into CRM. The model reads the email, extracts the line items, marks the missing parameters and prepares a draft clarifying question. What it does not do: it does not send the email, it does not set the price and it does not change the status of the enquiry. This is an illustration of an architecture, not a client reference.

Reliable systems combine AI with deterministic controls

The safest architecture is not to let AI decide everything. The model interprets the input or prepares a draft, the workflow governs permissions and thresholds. The reason is not ideological, it is measured.

TheAgentCompany benchmark simulates the environment of a small software company and tracks how agents cope with a realistic work agenda. The most successful agent tested completed 30% of tasks autonomously. The tau-bench benchmark tests agents in conversation with a simulated user while domain rules have to be respected: leading agents succeeded on fewer than 50% of tasks, and when the same task was repeated, the pass^8 metric, meaning success across all eight attempts, fell below 25% in the retail domain. The model is therefore not only imprecise, it is inconsistent, and for process design that matters more than average accuracy.

For sensitive or external actions, that is, sending a proposal, changing a price, making a payment or deleting data, it has to be clear when human approval is required. That means three design decisions:

Separate reading from writing. The model gets broad read access to context, but writing goes through a narrow list of permitted actions with defined parameters.
Hard limits in code, not in the prompt. The maximum discount, the maximum amount or the list of permitted recipients belong in the workflow. A rule in a prompt is a recommendation, a rule in code is a constraint.
Idempotency and preview. A write action should be runnable as a dry run or be safely repeatable, so that two invoices never appear.

Access rights and the data the model does not need

With conventional software, a specific person clicks. With an AI workflow, access belongs to a process that runs unsupervised and fast. Stricter discipline therefore pays off.

A dedicated service identity for every workflow. Not a shared administrator account. When something breaks, you want to know which process did it and to switch that process off without taking down half the company.
The smallest possible slice of data. To classify a complaint you need its text and the product type, not the full payment history. Where identity is not required, replace personal data with a placeholder code.
A clear answer on where the data goes. Which supplier, in which region, how long it is retained, whether it is used for training. This is a contractual question, not a technical one.

This is not an academic worry. Among the companies that, according to Eurostat, considered AI and did not adopt it, 70.89% cited a lack of expertise, 52.52% cited unclear legal consequences and 48.83% cited data protection concerns. Two of those three barriers have nothing to do with the model and everything to do with process design and with contracts.

An unpopular note belongs here as well. If a task can be solved with a rule over your own database, that is almost always cheaper, faster and safer than calling a model. A supplier who sells you an AI project in that situation is solving their business, not your process. We make a similar argument in the article Your company does not need more software, it needs less chaos.

Human approval that is more than a click

In most designs, control is settled with a single sentence: a person will approve it. It is the weakest point of the architecture, because it is easy to write and hard to make work.

Article 14 of the AI Act describes what a person overseeing a high-risk system has to be able to do: understand the capabilities and limitations of the system, notice anomalies, remain aware of automation bias (the tendency to over-trust machine output), decide not to use the system or to override its output, and stop it safely. Most corporate workflows are not high-risk systems, but there is no better checklist for designing approval so far.

How easily this can go wrong is shown by an analysis by Ben Green in the journal Computer Law and Security Review. The author reviewed 41 policies requiring human oversight of algorithms in public administration and states that the evidence shows people are unable to perform the required oversight functions, and that such policies create a false sense of security. That is the position of the author rather than a consensus, but it is a healthy corrective.

Three practical consequences follow. The approval screen has to show what the model based its output on, what will change and what happens after a rejection. The rejection rate is a metric: if it sits at zero for months, either the check is not happening or it is not needed. And oversight needs dedicated time. Anyone approving hundreds of drafts a day alongside their normal work is performing a ritual, not a check.

What to do when the model gets it wrong

Not if, but when. Auditability is therefore not a topic for the legal department but for operations. Every run should record what the input was, which version of the instruction and of the model ran, which sources the system drew on, who approved the output and what action was executed. Without that, finding the cause is guesswork.

A switch at the level of a single workflow. One specific step has to be stoppable without bringing down the whole process.
A way back and a test set. For every write action you need to know in advance how it is reverted. You want to catch a change of model version on a set of real cases, not on a customer.
The point at which you switch a step off. The American NIST AI Risk Management Framework from January 2023 says it plainly: where the level of risk is unacceptable, development and deployment should cease in a safe manner until the risk can be sufficiently managed. Returning to a rule or to a person is a legitimate outcome, not a defeat.

Measure ROI at workflow level, not by prompt count

Before implementation, measure the current state: time per task, number of handoffs, error rate, response time and the number of unfinished follow-ups. After deployment, compare the same metrics. The number of generated texts is not a KPI, cutting response time from two days to two hours can be.

NIST admits that this is harder than it looks: managing the risk of systems that extend or replace human activity requires baseline metrics, and those are difficult to systematise, because AI performs tasks differently from people. Measure the outcome of the process, then, not the quality of the model output.

Costs include more than the price of tokens: integration, the time spent checking outputs, maintenance when the model changes and the time people need to learn the new way of working. If checking costs more than the original manual work, the step should be cancelled. That is more honest than spending six weeks tuning a prompt.

Expect the first months to look worse than they should. The economists Brynjolfsson, Rock and Syverson described this as the productivity J curve: general purpose technologies require extensive intangible investment, meaning process redesign and organisational capital, which is poorly measured. Productivity growth is therefore understated in the early phase. The cost arrives immediately, the return only after the process has been rebuilt.

A company ready for AI does not need ten new tools. It needs clear processes, trustworthy data and automation designed to take routine away from people without taking away control. Start with the five most expensive repetitive workflows and, for each one, decide what a rule should handle, what AI should handle and what has to stay with a person. If the answer somewhere is that the best move is to remove half the steps and deploy nothing, that is a good result. Value is created in the diagnosis, not in the purchase.

Key takeaways

If a task can be written as a rule, write it as a rule. Recital 12 of the AI Act itself distinguishes systems built on human-defined rules from AI systems.
Split tasks by the cost of an error, the verifiability of the output and the reversibility of the action. The model owns the draft, the workflow owns the limits, the person owns the irreversible decision.
Design human approval as a process, not as a button: it has to show both source and impact, have dedicated time and a monitored rejection rate.
Every workflow needs its own service identity, the smallest possible slice of data, a switch and a record of what ran and how it is reverted.
Measure ROI on the process: time, handoffs, error rate, response time. Count checking and maintenance as costs, and expect the return to arrive later.