Most often, the problem is not the technology. The quality of AI models has grown so much in recent years that technical capability is rarely the limiting factor. Returns are lost in the solution selection, process, and implementation stages. Here are the most common reasons we observe in practice.
Starting with the tool, not the problem
The typical project initiation sequence is as follows: a fundamental decision is made that the company must start using artificial intelligence, and only then is a search made for where to apply it. This order essentially results in low returns, because the solution is implemented not where the greatest loss exists, but where the technology is easiest to apply.
Projects that deliver returns start in reverse – from a specific process that is already costing money. Sorting customer inquiries, verifying contracts, scanning data from documents, preparing reports from multiple systems. First, determine how many work hours the process takes and how many errors it causes per month, and only then decide whether AI is the right tool. It often turns out that a more suitable and considerably cheaper solution is standard process automation without any AI.
There is no metric by which returns are evaluated
If the time taken by the current process was not measured before the project, there will be nothing to compare it with after the project. Evaluation in such cases becomes subjective: the team mentions greater convenience, managers – a general impression of improvement, and the finance department only sees the invoice for licenses.
Before implementation, it is advisable to record at least a few simple metrics: average inquiry processing time, number of documents processed per month, error rate, employee hours involved in the process. These metrics will not be completely accurate, but they are sufficient to reasonably answer whether the investment paid off after three or six months.
Data is not of the quality that was assumed
This is the most common technical cause of failure. The company has data, but it is scattered across multiple systems, not standardized, partially filled, and important information is stored in free text comment fields or local files.
An AI solution does not solve this problem – it only reveals it. The result is forecasts and answers that are technically correct but practically inaccurate, so employees stop trusting them. In such cases, the greatest returns come not from AI, but from an earlier stage: data cleanup, system integration, and creating a single trusted version of information. It is precisely this work that is most often skipped, because its result is less visible within the company.
The solution is not integrated into the workflow
A standalone tool that requires separate login and separate data entry is rarely used in practice. After the first few weeks, employees return to their usual way of working because it requires fewer actions.
Returns appear when the AI function operates where the work is already happening – in the company management system, customer service platform, or document management solution. The difference between acquiring a tool and having a function operate within the existing process is usually the difference between zero and real returns.
Only implementation costs are evaluated, not operational costs
A pilot project often costs little, so the decision is made easily. However, the main portion of costs appears later: model usage fees proportional to volume, monitoring result quality, updates when processes change, support, ensuring security and personal data protection requirements.
When evaluating returns, it is necessary to calculate at least a three-year total cost of ownership. Some projects that appear profitable in the first months become loss-making over a longer period simply because cost growth with increasing usage volumes was not assessed.
Employee readiness is not evaluated
An AI solution changes work content – most often from execution to verification. This requires different competencies and a different distribution of responsibility. If employees are not explained how to evaluate the system's result, when it can be trusted, and who is responsible for errors, one of two extreme situations forms: either everything is checked from scratch and little time is saved, or nothing is checked and error risk increases.
Training, clear usage rules, and defined responsibility cost little but directly determine whether the solution will be used as planned.
Taking on too large a scale from the start
Attempting to restructure all customer service or all document management with one initiative results in a long project, a large number of participating parties, and delayed results. While the project is being implemented, both company priorities and the technologies themselves change.
In practice, the opposite logic works better: select one narrow, frequently recurring, and clearly measurable case, implement it within a few weeks, measure the result, and only then make a decision about expansion. This approach allows limiting the cost of potential errors.
What is advisable to check before starting a project
Before allocating a budget for an AI solution, it is useful to answer six questions:
What specific process are we improving and how much does it cost the company today?
What metric should the solution improve and what is its current value?
Is the data needed for the solution available, complete, and in one place?
In which system and at which point in the workflow will the employee use the result?
How much will the solution cost over three years, including usage and maintenance expenses?
Who in the company is responsible for verifying the result and its quality?
If there is no answer to at least several of these questions, the problem that needs to be solved first is likely not related to artificial intelligence.
The evaluation logic that is most often lacking
Investments in AI should be subject to the same criteria as any other investment in equipment or a new job position. In practice, this rarely happens: because the technology is new, the decision is often made based on a demonstration rather than numbers. If the service provider cannot specify which metric the solution will improve and how that improvement will be measured, this is sufficient reason not to start the project or to first agree on a smaller scope of work.
The second often-skipped element is a pre-agreed review point. Before starting work, it is advisable to set a date, for example, three months after launch, when one of three decisions will be made: expand, modify, or stop. It is precisely the absence of a stopping decision that is the reason why unsuccessful pilot projects continue in companies for a year or longer, accumulating license and support costs without any returns.