AI doesn't make a broken process better. It makes it broken faster. That isn't a slogan against AI — it's an observation from the field: a language model, an automation workflow, an assistant — they all reliably do exactly what the process beneath them dictates. If the process is clean, AI speeds it up. If it's unclear, half-documented, full of silent exceptions, then AI speeds up precisely that. With more confidence and fewer traces for anyone to reconstruct later what actually happened.
The pressure running through mid-market IT right now is real. Management comes back from a trade fair, a competitor posts about its 'AI transformation', the advisory board starts asking questions. And in the middle of it sits the IT lead, who knows the ERP is ten years old, that three process-critical Excel files carry half of sales, and that the same delivery address is spelled differently in two systems. Now they're supposed to deliver AI. Before the problem has even been defined.
What AI really does: amplify, not repair
It helps to picture AI not as a tool but as an amplifier. An amplifier turns a good signal into a louder good signal and noise into louder noise. It holds no opinion about what sounds right. A model behaves exactly the same way towards a process: it makes assumptions, fills gaps, resolves borderline cases — and wherever the underlying workflow is unresolved, it decides somehow anyway. Sounding plausible, at full speed, without the hesitation an experienced person would have at exactly that point.
A person operating a shaky process has a built-in brake. They pause when something's off. When in doubt, they make a quick call to accounting. They spot the edge case because they've seen it three times before. This brake is documented nowhere, it's in no manual, it is experience. When AI takes over the step, it takes over the speed — but not the brake. And that brake was often the only thing holding the process together.
AI amplifies good systems. It doesn't repair bad ones.
A project where this became visible
In one of our projects, an assistant was meant to pre-qualify incoming orders automatically: identify the customer, match the items, check the delivery address, wave the simple cases straight through, hand the tricky ones to a clerk. On paper, a clean use case. And it ran in the demo too — on twenty hand-picked records. Then we looked at the process in front of it, instead of just the wish behind it.
The order data came from three sources: the ERP, an Excel list grown over years, and PDFs from a mail inbox. Three sources that contradicted each other in customer numbers, item descriptions and even the spelling of delivery addresses. Around 18 per cent of the records didn't line up cleanly. Nobody knew this precisely, because two experienced colleagues had been quietly correcting the discrepancies in their heads for years. They never reported 'there's a conflict here'. They simply resolved it, every day, without anyone noticing.
Had we put AI on top of that state, we wouldn't have automated the order process. We'd have automated the chaos. Faster, with more throughput and without the two people who had until then noticed when something was wrong. The errors wouldn't have disappeared — they'd just have become more invisible, baked into a machine that gives no outward sign that it's computing on a false assumption.
We didn't cancel the project. We flipped the order. First one unambiguous source per data field, a defined reconciliation, a clearly named case: 'unclear — goes to a human'. Only then the assistant. The AI part turned out to be the smallest piece of the work. The largest was writing down and clarifying what two colleagues had simply known for years.