Section 1
Myth: it replaces the team
The grain of truth is that specific tasks genuinely disappear, and the people who used to do them notice. What does not hold is the leap to headcount. In practice the work reshapes rather than vanishes. Production time becomes review time, and review requires judgment that a junior does not yet have. Companies that automate well tend to change what people do rather than how many they have, at least at small scale. The version worth taking seriously is subtler: if drafting is automated, the ladder juniors used to climb loses a rung, and nobody has replaced it yet. That is a real workforce problem and it is not solved by a tool. Start from [What Is AI Automation? A Plain-English Guide for Founders](/blog/what-is-ai-automation-a-plain-english-guide-for-founders).
Section 2
Myth: you need clean data before you can start
This one blocks more projects than any other, and it is half right. You do not need a clean database. You need the specific fields one workflow depends on to be trustworthy. That is usually ten or fifteen fields, and it is a week of work, not a data programme. The half that is right: if the fields the automation reads are wrong, the automation will be confidently wrong at speed, which is worse than the manual process it replaced. Scope the cleanup to the workflow. The companies that insist on fixing everything first are usually the ones that never ship, and the ones that skip it entirely are the ones who find out during an audit.
Section 3
Myth: a bigger model fixes a bad output
When output disappoints, the reflex is to reach for the more capable model. It occasionally helps. More often the problem is upstream. Bad outputs usually come from an ambiguous task, missing context, or an input the system was never shown during testing. A larger model gives you a more articulate version of the same misunderstanding. Diagnose in order: is the instruction unambiguous enough that a competent new hire could follow it, does the system have the information a person would need, and did this case appear in your test set. Model choice is the last lever, not the first, and it is the most expensive one to pull. See [Common Challenges in Implementing AI Automation (and How to Solve Them)](/blog/common-challenges-in-implementing-ai-automation-and-how-to-solve-them).
Section 4
Myth: a successful pilot proves it works
Pilots are run by motivated people on cases they chose, with attention that will never exist again. That is why so many of them succeed and so few of them scale. Three things break on the way to production. Volume, which turns per-run pricing into a real invoice and reviewer attention into rubber-stamping. Edge cases, which were absent from the pilot because someone unconsciously avoided them. And ownership, because the pilot had an enthusiast and production needs a maintainer. The stronger test is a fortnight of parallel running on unfiltered live volume, with disagreements between the system and the human logged. Boring, slower, and far more predictive.
Section 5
Myth: the vendor carries the risk
A contract can move liability. It cannot move accountability, and your customer will not be interested in the distinction. The four things NIST uses to frame AI risk, trustworthiness, design, evaluation and use, all stay with you. You decide what the system reads, what it writes, which decisions it is barred from making alone, and who answers when an error reaches a customer or an employee. The controls are unremarkable: minimise the data in every prompt, log decisions and escalations, sample outputs against known-good examples, disclose machine involvement, and keep a named person on decisions involving payments, employment, legal standing or safety. [Storytelling in the Age of AI and Automation](/blog/storytelling-in-the-age-of-ai-and-automation) covers how to explain this internally.
Section 6
Myth: progress means more automations
The count of live automations is the vanity metric of this field. It is easy to grow, it looks like momentum on a board slide, and it correlates with nothing. Measure the work instead: cycle time on the target task, rework rate, exception volume, cost per transaction, and whether the team would object if you switched it off. That last one is the most honest signal available and it costs nothing to ask. Retiring an automation should be a normal, unembarrassing event. A portfolio that only grows is not a portfolio. It is accumulation, and it eventually becomes the sprawl that made the manual process slow in the first place.