FROM AI DEMOS TO REAL BUSINESS RESULTS: MIKHAIL STEPNOV ON TESTING, COSTS AND IMPLEMENTATION

Artificial intelligence can produce an impressive demonstration in minutes. Turning that demonstration into a reliable business tool is a different challenge.

Companies need to identify the right process, prepare accessible data, define who is responsible for the business outcome, test the technology in the environment where it will actually be used and calculate the full cost of every accepted result.

Mikhail Stepnov has worked across analytics, data science, AI research, product development, consulting and business education. His experience includes Publicis, Sber AI, MTS, MTS Travel and Beeline Cloud.

Throughout that journey, one question has remained central to his approach: what decision will someone make better, or what work will they do faster?

In this conversation, Mikhail discusses how medium-sized businesses can begin using AI, how buyers can distinguish a useful solution from an impressive demonstration, why employee adoption often fails, and what Georgian technology companies should consider when preparing to operate in Uzbekistan.

  1. Can you describe the project that first made AI's practical business value clear to you?

One early example I would point to is our work on advertising budgets at Publicis, well before the current wave of generative AI. We built models to understand how advertising contributed to sales and how a company could allocate its budget across channels.

The business question was very concrete: where should the next unit of spending go? Answering it meant understanding the data, separating the effects of advertising from other factors, and giving the decision-maker a way to compare options. That connection between modelling and an actual management decision was what interested me.

I still approach AI through the same question: what decision will someone make better, or what work will they do faster? If we cannot answer that, I think we need to spend more time understanding the problem.

  1. What experience led you to focus your career on this work?

It was a gradual progression: analytics and data science at Publicis, then Sber AI, R&D at MTS, and data and product work at MTS Travel. Today I work on AI at Beeline Cloud, alongside consulting and teaching.

What interests me is the whole journey from a technical capability to something people actually use. You can build a strong model, but then you have to get it into a product, fit it into someone's work and make the economics work. There is a lot to solve there.

That also explains my interest in business education. AI adoption requires decisions from managers: choosing priorities, assigning people and changing processes. When a manager understands the technology's capabilities and limits, we can have a much more useful conversation about implementation. For me, engineering, management and education are closely connected.

  1. Which resistance has been hardest for you to overcome when a team adopts new technology?

I would single out the situation where everyone agrees in meetings, but nothing changes in their daily work. An explicit objection gives you something to discuss. Formal agreement can hide a problem for quite a long time.

And the employee may have perfectly reasonable concerns. The tool adds extra steps. They remain responsible for mistakes. Someone else gets the benefit. Or they are told that AI will save time, without any explanation of how their responsibilities will change.

My starting point is the person's actual work: what takes time, what we propose to change and how they can check the result. They need to try it on their own tasks and influence the improvements. If implementation leaves people running two processes in parallel, we should examine the implementation itself. Training alone will not fix that.

  1. Which task would you start with when introducing AI to a medium-sized business in Uzbekistan?

I would look for a recurring task where manual work is piling up. For a trading or service company, handling incoming customer requests could be a good candidate. Employees read messages, extract details, check documents and prepare replies.

A first version could gather information from a request, find the relevant product or service information and prepare a draft response. The employee checks it before sending. You can then measure handling time, the amount of correction needed and the share of requests the assistant can genuinely help with.

For a particular company in Uzbekistan, I would also check the languages people use, the quality of its reference data and the systems already in place. The starting point needs to be a real process with accessible data and a manager who wants to improve it.

  1. How can a buyer distinguish a solution suited to its workflow from an impressive demonstration?

Ask to see it work on your data, through the whole process. Where does the task come from? Where does the system get its information? Where does the result go? Who checks it, and what happens when it is wrong?

Bring ordinary cases, including awkward ones: an incomplete document, an ambiguous request, an outdated record. Look at how much work remains for the employee. If someone has to collect context from several systems and then check everything from scratch, that effort belongs in the evaluation.

I would also ask the supplier to describe the limitations and agree on how to test them. A specific discussion about errors and how they are handled tells me more than a promise to automate everything.

  1. Who should be accountable for the business outcome of implementation?

The person who owns the business process. If we are improving sales operations, we need a manager who is responsible for that work and has the authority to change it. They must be able to assign people, agree on new working practices and accept the result.

IT and the provider still have clear responsibilities: technical reliability, integrations, agreed quality levels and support. But a provider cannot independently decide how the client's department should work or how it should use the time that has been freed up.

Before starting, I want to know who will accept the outcome and against which criteria. If the answer is “everyone together,” I want to understand who will actually make the decision when there is a disagreement.

  1. How would you calculate the full cost of one automated task?

I would calculate the cost of an accepted result: for example, a customer request handled correctly. Include development or subscription fees, integrations, data preparation, infrastructure, model usage, maintenance and the time people spend reviewing and correcting outputs. Spread the one-off costs over a realistic period and workload.

Then divide that total by the number of tasks that meet the agreed quality standard. Failed attempts and retries cost money too. So does an employee's time spent checking the answer.

Compare that with the current process at a comparable quality level. And separately ask what happens to the time saved. Faster work does not automatically mean lower expenditure. It may let the company handle more requests or improve service. Those are useful outcomes, but their economics are different and should be described accurately.

  1. When is buying an existing service better than building an in-house solution?

For a standard task, I would start by testing existing services. If one meets your requirements for quality, access, integration and cost, building your own needs a clear justification. You will also have to maintain it.

Custom development makes sense when the process is unusual, data constraints are substantial, or the scale changes the economics. It can also make sense when the capability is central to the product's competitive advantage. Each of those arguments needs to be tested against the actual use case.

There are plenty of options between buying a finished service and building everything from scratch. You might use an existing model and build the integrations, business rules and interface around it. I would compare the full cost and the ability to change the solution later. Wanting “our own AI” is not enough of a business case.

  1. What should a pilot test on real work in Uzbek or Georgian?

It should test whether the task gets done correctly in the language people actually use. I would collect real requests, documents or call recordings, including difficult examples, and involve reviewers who understand both the language and the business domain.

For Uzbek, that could include Latin and Cyrillic writing, mixed Uzbek and Russian, and different spellings of names, wherever those occur in the company's work. For Georgian, test Georgian script, industry terminology, names and addresses. A voice system also needs testing with different speakers, speaking speeds and background noise.

Measure whether the meaning is correct, whether important fields are extracted accurately, how long human review takes and what happens when the system makes a mistake. A fluent answer can still contain the wrong contract number or delivery condition. Agree on the acceptance criteria first, then test on fresh work as well as the initial sample.

  1. Can you describe a pilot that failed to become an everyday work tool?

I can describe a case where the first version was not suitable for normal use in the intended environment. In a project for a lighting manufacturer, we developed a tool for collecting contacts at trade shows. It included QR scanning, a contact form and voice input.

At an actual event, voice input struggled with the noise, and our scanner did not recognise the organisers' QR codes. The working environment and compatibility with another system turned out to be critical.

That first version could not support the task reliably at the event. The person at the stand needed to capture a contact quickly and continue the conversation. A tool that gets in the way of that needs to change. It is a useful reminder to test the whole situation in which a product will be used.

  1. What did that case change in your own approach to implementation?

It reinforced the importance of testing in the actual working environment early. The later you discover those constraints, the more you have invested in something you may need to rework.

For that kind of pilot, I would now ask about the device, connectivity, surrounding conditions, external systems and the time the user has to complete each action. Then I would test the complete sequence, including errors and a way to fall back to manual work.

I would also agree in advance on the decision we will make after the pilot: launch, revise or stop. Discovering that an approach does not work is a useful pilot result if it happens before a large commitment. The team needs to be able to say that clearly.

  1. From your area of expertise, what one first step would you recommend to a Georgian technology company preparing to operate in Uzbekistan?

Start with one potential customer and a detailed review of one process. See how the work is done today, who makes decisions, what data and systems exist, and where the constraints are. Then discuss a proposal and a pilot.

For an AI project, I would pay particular attention to who will support adoption on the customer's side and how local specialists will be involved. Translating the interface is only part of the work. You need to understand the terminology, approval process and user expectations.

My experience here is in AI and business education, so I would not present this as a universal market-entry formula. But working through a real task together gives a technology company a concrete basis for deciding what to offer, how to deliver it and what it will cost.

  1. In one project, how did actual costs differ from the plan?

One example I can discuss is a tender-document system where the scope expanded during delivery. It involved document recognition, search and data collection from external sources. We ended up building more parsers than originally planned, and search and document verification required additional work.

I would check the project accounts before quoting a financial variance. A wider scope does not, by itself, tell us how much expenditure increased or who paid for it. What the example does show is the need to track changes to the original task and the additional obligations the team takes on.

In an estimate, I would make integrations, data work and acceptance conditions explicit. When new requirements appear, their effect on time and cost needs to be discussed openly. Otherwise, the customer and the provider can keep using the same project name while referring to different amounts of work.

  1. How should responsibilities be divided between the client's IT team and an external provider?

The client's IT team is responsible for its infrastructure, access, data sources, security requirements and how the solution fits into existing systems. The provider is responsible for the agreed development, its part of the integrations, testing, documentation and handover.

I would turn that into specific assignments: who prepares test data, grants access, checks quality and investigates an incident? The business process owner must also be involved. Two technical teams can build a working system without anyone being in a position to accept it from a business perspective.

Agree on life after launch as well: where the code and documentation are kept, who changes settings, how data is updated and who provides and pays for support. That gives both sides clear obligations and lets the customer manage the solution over time.

  1. Which practical case supports that recommendation?

I would return to the tender-document project. Our team handled development: document recognition, search, parsers and the interface. The customer brought the infrastructure, employees and the actual requirements of tender work.

We handed over an MVP on the customer's infrastructure, together with documentation and access. That handover is a deliverable in its own right and needs to be planned. A working prototype does not automatically settle who will administer it, verify documents or respond to problems.

The practical lesson is to agree on the handover and the responsibilities afterwards before reaching that stage. I would also distinguish the handover itself from evidence of daily use or economic benefit. Those are further outcomes, and they need to be checked separately.

THE REAL TEST OF AI IS NOT THE DEMONSTRATION, BUT THE WORK THAT HAPPENS AFTER IT

Mikhail’s experience points to a practical distinction that matters for companies in both Georgia and Uzbekistan: a technically impressive AI solution is not necessarily a useful business tool.

The value becomes clearer when the company begins with a real process, defines an accountable business owner, tests the technology on its own data and measures results against agreed quality standards.

For companies buying AI solutions, this means evaluating the full workflow rather than a controlled demonstration. The calculation should include integrations, data preparation, infrastructure, maintenance, human review, failed attempts and the work required after launch.

For Georgian technology companies preparing to operate in Uzbekistan, the recommended starting point is equally concrete: work with one potential customer, study one process in detail and test a proposal through a focused pilot. Local language, terminology, approval processes and employee expectations should be considered part of the product rather than an additional translation task.

The wider lesson is that a pilot does not need to produce a launch to be useful. A decision to revise or stop can protect a company from making a larger investment in an approach that does not work in the real operating environment.

We are grateful to Mikhail Stepnov for sharing his experience and practical guidance on moving from AI experimentation to accountable business implementation.