Why AI projects in companies fail and how to avoid it

Plenty of percentages about AI failures circulate online, often without a source or with an inaccurate description. The ones that can be verified measure different things, so they should not be compared directly.

They all lead to the same conclusion, though. The technology itself keeps getting better, yet most companies still cannot turn it into a measurable result. RAND, which interviewed experienced AI engineers, puts a poorly defined business problem first among the causes – not the choice of model.

For you, the definition of failure matters more than the percentage. Before you start, write down what will count as success: shorter handling time, fewer errors, fewer working hours. Without this, after a year nobody will be able to judge whether the project succeeded.

A provider can configure a tool, but it cannot change the process in your company. You need someone who knows the process, can make decisions and has regular time for the project every week. This is usually the manager of the department the project is for.

Without such a person, the project gets stuck on questions about exceptions and disputes over priorities. After a few months, someone says, “the technology is good, but it doesn’t fit our process”. Most often, this means nobody had time to change that process.

The signs below show that a process owner is missing. If you see two of them, put the start on hold and appoint that person first.

The company buys Microsoft Copilot or launches an AI assistant, but the team works exactly as before. Employees use the tool now and then, and after a few weeks they slip back into old habits.

Take a hypothetical company where AI prepares a draft quotation based on a customer’s enquiry. The salespeople do not trust the drafts, so they write every quotation from scratch and only glance at the draft. The tool works, but the time needed to prepare a quotation has not fallen.

The solution is to design the new way of working together with the tool. Decide which steps disappear, which ones a person checks and against what criteria. This is the part BCG describes as 70% of the effort in companies where AI pays off.

A project often starts with the words “we have lots of data”. A few weeks later it turns out that the same customer has three names in three systems, price lists exist in several versions and the categories in the order history changed every year.

Cleaning up the data then eats into the time and budget meant for the actual implementation. The company faces a choice: go over budget, or accept a solution that makes mistakes more often than promised.

Run a simple test before you sign the contract. Take 100 typical cases, e.g. requests for quotation, and have an experienced employee handle them by hand, noting where each piece of information came from. If they find it difficult, AI will not cope either.

The first project decides whether the company will keep investing in AI. Showy ideas are tempting, such as a chatbot for all customers or AI that prepares board reports by itself. These are usually the hardest tasks, and their mistakes are visible straight away.

A good first project is dull. It concerns repetitive work that is easy to measure, and a person checks every AI result before it goes any further. The table below helps you tell a good start from a risky one.

A project without clear rules can grind to a halt just before launch. Someone asks whether customer data may go into the AI model and who is responsible for a wrong answer, and nobody knows.

Meanwhile, employees are often already using free tools on personal accounts and pasting company documents into them. The rules do not need to be long. A few pages are enough: which tools are allowed, what data must not be entered into them and who approves new uses.

The AI Act does not require every company to write an AI policy. However, since 2 February 2025 it has required (Article 4) companies to build their employees’ knowledge of AI, and written rules plus training are the simplest way to show this. If AI talks to customers, from 2 August 2026 it must tell them they are not talking to a human (Article 50).

Experienced specialists appear at the sales meeting, but the project is then run by people doing a similar implementation for the first time. This is a common reason why a promising project goes off the rails along the way.

Before you sign the contract, ask the provider a few simple questions. Written answers tell you more about them than a presentation.

The first weeks of a project are spent describing the process, cleaning up data and testing. If the board asks about return on investment (ROI) before the solution is up and running, the team, under pressure, shows “something” and makes hasty decisions.

It helps to have one board member who understands what the project is for and defends it until the first measurement. A good test is simple: after a short conversation, they can say in their own words what problem the project solves and how you will recognise success.

Also agree checkpoints in advance. For example: after a pilot in one team, you compare the result with the measure written down before the start and decide whether to extend the project, improve it or end it.

The list below brings all the causes together in one place. If you do not have a good answer to three or more questions, it is better to postpone the start and fill the gaps first.

The answers usually take a few weeks of internal discussion. That is time well spent, because it can save months of work on a project that never had a chance.

Before you start a second project, analyse the first. Go through the seven causes described above and note for each one whether it occurred. Invite the people who were supposed to use the solution to the discussion, not just the project team.

If the cause was the process, the owner or the data, the next project can succeed even with the same provider. If the provider’s work fell short, change provider, but carry over to the new project what you have learned.