AI will not fix a broken process. It will just do the wrong thing faster and cheaper.

One sentence keeps coming up in board meetings, and it looks like strategy without being strategy: we need to deploy AI. A process is found for a model to plug into, a vendor is selected, a pilot goes live. Six months later the company owns a licence and the same numbers as before.

The reason is not weak models, it is the order of operations. Technology is an answer, not a question. The question is what stops work from moving through the business without stalling. If nobody asks it, AI simply speeds up the existing shape of the work, deformities included.

Automating an inefficient process without redesigning it is not an improvement, it cements a bad architecture of work. The wrong thing starts happening faster and more cheaply, which is worse than when it happened slowly and expensively. At least then it hurt enough for someone to notice.

Technology is not a strategy

In 1990 Michael Hammer wrote a line in Harvard Business Review that has not aged: heavy investment in information technology has delivered disappointing results largely because companies use technology to mechanise old ways of working. They leave the existing processes intact and use computers merely to speed them up. His conclusion was blunt: stop paving the cow paths.

In a study published in 2000, Erik Brynjolfsson and Lorin Hitt report that investment in computers without organisational change can cause significant productivity losses, because the negative interactions with existing practices outweigh the benefits. Not a zero effect, a negative one. On their account, the complementary organisational investment, meaning new processes and new skills, can be roughly ten times larger than the spend on the technology itself.

More recent numbers point the same way, although they should be read with a caveat. The GenAI Divide, a report published by the MIT NANDA project in July 2025, states that despite 30 to 40 billion dollars invested in generative AI, 95 percent of organisations see no return, and only 5 percent of pilots extract value in the millions of dollars. It rests on 52 interviews and 153 survey responses from the first half of 2025, the authors describe the findings as preliminary, acknowledge selection bias and have not released the underlying data. Treat it as an indication, then, not as a measurement of the market. The explanation matters more than the headline: projects do not fail on model quality or on regulation, they fail on brittle workflows and on a mismatch with day-to-day operations.

Draw the flow first, design the architecture second

Process redesign, meaning reworking how the work actually flows before any tool is chosen, starts out dull. You break a single process into four types of step. An input is the trigger or the data that enters the process. A decision is the point where options are weighed. An action changes state. An output is what falls out of the process for someone else to use. The aim is to separate the steps that create value from the ones that merely move information around.

Map reality, not the policy document. A manager will describe the approved procedure. The person who actually does the work will also show you the spreadsheet the team set up because the official system was not enough. Those workarounds are the best map of the design faults you will get.

What to look for in the flow

• Duplication. The same information is entered in several places, and each one is a fresh opportunity for the versions to disagree.
• Waiting. Work sits idle and nobody is touching it. It is usually the single largest item in the total elapsed time.
• Risk-free approvals. A signature that has never rejected anything is not a control, it is a ritual with a price tag.
• Manual transfer. Retyping from an email into a spreadsheet, exporting and importing, copying between systems.
• Steps with no reason. The report nobody reads. The copy for an auditor who stopped asking for it.

We rank the findings with a Cost of Friction formula: the time for one repetition times the frequency times the number of people involved times the hourly cost. A step that takes a moment but is performed daily by an entire team is usually more expensive than a large project handled once a year. Why most companies need less chaos rather than another tool is something we covered in Your company does not need more software. It needs less chaos.

The method: eliminate, simplify, automate, augment

The order is deliberately unforgiving. The next step may only begin once the previous one is finished, because each successive step is more expensive and harder to reverse.

Eliminate

The first question is not how to do this faster, it is whether it needs doing at all. A step that has been scrapped costs nothing to run, has a zero error rate and needs no maintenance. Skip this layer and you automate work that should never have existed.

Simplify

Whatever survives needs to get shorter. Fewer fields, fewer states, fewer exceptions, fewer levels of approval. Simplification cuts cost, error rates and training time all at once, without a single line of code. Skip it and you automate the exceptions instead, and every exception needs its own rule, its own test and its own maintenance.

Automate

Only now does a tool enter the picture. You automate what is repeatable, unambiguous and frequent, and most of this layer needs no AI at all. Jumping straight past it to a model is a mistake we see in brief after brief. The company points a model at a task a rule would have settled, and pays for uncertainty it never needed.

Augment

The final layer does not stand in for the person, it extends their reach. This is where summarising source material, drafting a first version of a text or sorting unstructured data belong, tasks with no single correct answer. Start straight in here and you get an impressive demo and no movement in the numbers, which is precisely the mismatch with operations described in the MIT report.

Hammer's Ford example shows the difference between automation and redesign. In the early 1980s the North American accounts payable department employed more than 500 people, and management expected new computer systems to cut headcount by around 20 percent. After the redesign, when three data items were matched instead of fourteen and the supplier invoice was eliminated altogether, Ford achieved a 75 percent reduction in headcount wherever the new process was introduced. Those two percentages are the distance between speeding up the old procedure and designing a new one.

When a rule is enough and when you need a model

Deterministic automation returns the same output for the same input every time. This is the territory of workflow automation: connecting systems, conditions, validations, document generation, notifications. It is cheap, it is testable, and when it fails it fails loudly and in a known place. A large language model is probabilistic. The same input can produce a different output, and the model has no reliable way of admitting that it does not know. What it does handle is language and unstructured input, which no rule can.

If the procedure can be written as a sentence along the lines of when A happens, do B, use a rule. If the task can only be expressed through examples, a model is the right call. And if the rule could be written but nobody fancies writing it, that is not an argument for AI, it is a decision being postponed.

In TheAgentCompany benchmark, built by researchers at Carnegie Mellon University to simulate the environment of a small software firm, the best agent tested completed 30 percent of tasks entirely on its own. This is a simulation, and the measure is fully autonomous completion, so the figure says nothing about how much an agent manages with a person on hand. The implication still holds: an agent sent into an untidied process will not finish most of the work.

Where the human has to stay

Human in the loop is a sound idea that is routinely abused as an alibi. In a peer-reviewed study, Ben Green examined 41 policies mandating human oversight of government algorithms. His finding is that people are unable to perform the oversight functions expected of them, and that oversight policies therefore legitimise the deployment of faulty tools.

European regulation acknowledges as much. Article 14 of the AI Act requires high-risk systems to be designed so that people can effectively oversee them, and it names automation bias explicitly, the tendency to rely automatically on a system's output. The operative word is designed. Oversight is a design requirement, not a patch stuck on after go-live.

So the human belongs wherever the decision is irreversible, wherever it carries legal or financial consequences, and wherever the case is an exception outside the normal run. Where the check would be purely formal, it is better not to automate the step at all.

Risks to settle before you go live

Hallucinations. An independent assessment by the Stanford RegLab team found that specialised legal tools with document retrieval hallucinated in 17 to 33 percent of cases, while the best of those tested answered 65 percent of questions correctly. Its vendor had promised zero hallucinations. The domain is US legal research, so do not carry the figures across mechanically. What does carry across is the conclusion: even a tool sitting on a verified database is wrong often enough that its output needs checking. According to Why Language Models Hallucinate, most of whose authors work at OpenAI, this is not a defect the next release will fix. Models guess because the way they are evaluated rewards guessing and penalises admitting uncertainty.

Privacy and data. Data governance, meaning the rules on what data enters the system and who is accountable for it, is not administrative decoration. Article 10 of the AI Act requires training, validation and testing data sets to be relevant, sufficiently representative and, to the best extent possible, free of errors. A model deployed on untidied data cements the mess and lends it the authority of machine output.

Access rights. An assistant that sees everything the company drive sees is a new surface for leaks. The model inherits whatever loose permissions are in place and makes it easier to search through what was meant to stay separated.

Auditability. Article 12 requires high-risk systems to technically allow for the automatic recording of events throughout their lifetime. The ability to reconstruct after the fact what the system did and on what basis has to be designed in from the start. It cannot be glued onto a process already in motion.

The American NIST AI RMF framework adds a step that is easily skipped: the output of risk mapping should be an initial decision on whether an AI-based solution ought to be built at all.

A worked example: from enquiry to quote

A hypothetical company sells made-to-order components. The current state:

1. An enquiry arrives in a shared mailbox.
2. An assistant retypes it into a spreadsheet and creates a folder on the drive.
3. The salesperson emails an engineer to check whether the specification is feasible.
4. The engineer replies when they have time.
5. The salesperson assembles the quote by hand and copies prices across from the price list.
6. A manager approves the quote, which in practice always happens.
7. The quote reaches the CRM whenever somebody remembers.

The naive fix sounds like this: deploy a language model that writes the quotes from the emails. The company gets its documents produced faster, while the wait on the engineer, the duplicate record keeping and the empty approval all remain. What emerges is a faster version of the same mess, plus a new category of errors nobody is checking.

A redesign along the method looks different. Eliminate: the retyping into the spreadsheet goes, and so does the approval that never rejected anything, replaced by a threshold. Simplify: enquiries arrive through a form that asks for the parameters needed to assess them, so the question to the engineer mostly falls away. Automate: the form deterministically creates the opportunity in the CRM, assigns a salesperson, assembles the quote from the price list and keeps an eye on deadlines. No model is needed here. Augment: only for non-standard enquiries does a model prepare a summary and a proposed solution, which the engineer confirms or rewrites.

Note the order. The biggest effect came from the first two steps, which cost almost nothing and needed no AI. A remark that is rarely made in our industry: a fair share of briefs like this are solved without any custom development at all, by scrapping steps, adding a form and using an off-the-shelf tool whose subscription is an order of magnitude cheaper than building software and maintaining it. Custom makes sense where the process is genuinely specific and where the friction outweighs the cost of both development and maintenance. When such an investment pays back is something we work through in A good internal system can pay for itself sooner than a new hire, and what a company built from scratch would look like in How I would build a company today that needs no army of admin staff.

Key takeaways

• Break a single process into input, decision, action and output. Map reality, not the policy document.
• Find the duplication, the waiting, the risk-free approvals, the manual transfers and the steps with no reason. Rank them by Cost of Friction: time times frequency times the number of people times the hourly cost.
• Hold the order: eliminate, simplify, automate, augment. The next step may only begin once the previous one is finished.
• Where deterministic automation is enough, a language model only adds uncertainty and cost.
• Before you go live, answer these: who checks the output, what data goes in, who has access to what, and how you can prove after the fact what the system did.