The biggest mistakes companies make when implementing AI
Almost no AI project fails because of the model. It fails on the choice of problem, on messy data, and on people who were never brought along.
The pattern of failure
After following a handful of AI projects in companies of very different sizes, the pattern is monotonous: the model is almost never the problem.
It fails in the choice of problem, in the data, in the integration with the system that already exists, and in the people who would have to change their routine. Eight mistakes, in order of frequency.
Mistake 1: starting with the showcase project
The first project is usually chosen for visibility — something that looks good in a board presentation. A chatbot on the homepage, an internal assistant "that answers anything about the company".
Those are precisely the cases with undefined scope, whose success nobody knows how to measure. The project ships, everyone finds it cute, nobody uses it after three weeks, and the conclusion becomes "AI does not work here".
The right way: a first case chosen by pain, frequency and measurability. Ugly and useful beats pretty and vague.
Mistake 2: ignoring that the data is a mess
"Let's use AI on our data" presupposes that usable data exists. In most companies, what exists is five systems that do not talk to each other, spreadsheets holding the real truth, scanned PDFs, and one Excel file in finance that is the only reliable source of anything.
No model fixes that. It will answer confidently on top of the wrong data — which is worse than not answering.
The right way: measure data quality before promising results, and accept that a good share of the budget goes into fixing it. It is the boring part that decides the project.
Mistake 3: automating the broken process
Automating a bad process produces a bad process faster — and one that is harder to fix, because now it has software on top of it.
The right way: design the process as it should be before automating. Frequently, in doing that, you discover half the steps existed for a reason that no longer does.
Mistake 4: not defining who owns it
An AI project that stays only with IT dies from lack of business knowledge. One that stays only with the business area dies from lack of maintenance. A project with no named owner simply stops existing when the initial enthusiasm fades.
The right way: one person from the area that feels the pain, with time genuinely allocated, responsible for the metric.
Mistake 5: skipping measurement
"It improved customer service" is not a result. Without a number from before, there is no number from after, and the project becomes a matter of faith — which guarantees it gets cut at the first budget squeeze.
The right way: two or three indicators measured before starting. Average time, resolution rate, cost per contact, hours spent on the task.
Mistake 6: underestimating the change in routine
The technology arrives in weeks; the behaviour change takes months. A team that did not understand why the thing exists finds creative ways not to use it — and if they think the tool is the beginning of their own redundancy, they sabotage it competently.
The right way: involve the people who do the work from the design stage, be explicit about the effect on jobs (the truth, whatever it is), and train properly, with the person's real use case.
Mistake 7: handling sensitive data carelessly
Pasting a client contract, personal data or strategic information into a free tool, with no contract and no non-training clause. This happens in every company that has not given a clear guideline — and the absence of a guideline is what pushes employees towards their personal tool.
The right way: a written policy, short, saying what may go where; and a corporate tool good enough that nobody needs to work around it.
Mistake 8: too much autonomy, too soon
Letting the system decide on its own, in front of the customer, with financial effect, without a shadow period. The first public mistake costs more than the whole project saved.
The right way: copilot before autopilot, always. Autonomy is earned with a measured track record.
If I could give a single piece of advice: start small, measure, and only scale what proved itself. It is the opposite of what the board's impatience asks for — and it is what makes the second project happen.
The sign that it is going well
A healthy AI project looks boring: narrow scope, a clear indicator, a named owner, a modest and verifiable gain, and a queue of next cases learned from the first.
A project that looks too exciting in the presentation is usually the one that will not survive contact with operations.
Get the next articles
No spam. One message when a new article is out, with an unsubscribe link in every one.
