A useful AI deployment begins not with choosing a model, but with identifying an operation that needs to work better. In company interviews described in the World Bank’s October report, a financial institution in Georgia said its chatbot handled around 70% of interactions without escalation. A large group in Kazakhstan used AI to translate more than 20,000 documents in two months.
These figures describe individual businesses, not average AI performance in either country. They also measure different things: a share of interactions and a volume of documents. They cannot establish a universal saving on payroll. What they do show is where a tool becomes part of a business process rather than an isolated employee experiment.
Independent FinFly analysis drawing on World Bank (2026), Making AI Work: Jobs, Firms, and Productivity, ECA Economic Update (October 2026). FinFly’s interpretations are not endorsed by the World Bank. DOI · CC BY 3.0 IGO.
First, do familiar work faster
Drafting a document, searching an internal knowledge base and initially classifying enquiries need not require redesigning the whole business. Their outputs can be checked: was the correct clause found, was the topic classified properly, and how much correction was needed? This makes bounded support tasks a useful starting point.
Accelerating the first step does not necessarily accelerate the entire process. If checking an automatically generated document takes longer than preparing it previously did, the advantage disappears. Measurement should cover input preparation, processing, review and correction. Errors that average speed can conceal need their own assessment.
Second, give employees new capabilities
At a Georgian retailer, a business analyst without a conventional software-development background built internal applications that replaced complex Excel workflows. This changes who can perform a task. It does not remove the need for maintenance, data protection or accountability for results.
For a smaller business, this route can shorten the journey from an idea to a working prototype. But a prototype and a system used every day require different levels of reliability. Someone must own the process: checking calculations, restoring service and noticing when a change in input data has broken the result.
Third, undertake work that was previously out of reach
Another Georgian case describes a tool for reviewing all sales calls, rather than the roughly 5% previously checked by a team leader each month. An Armenian agrifood case uses sensors and analysis to provide information on individual animals. The value is not just replacing manual work; it is obtaining observations at a scale the organisation did not previously have.
This is a more demanding form of adoption. It requires usable data, a connection between findings and decisions, and the ability to change operations in response. Producing more reports does not generate revenue by itself. If employees do not act on the findings, better monitoring may remain merely extra information.
How to test whether a pilot helps
For an Azerbaijani company, a sensible first experiment is a repeatable, bounded process with a clear output. Before deployment, record completion time, error frequency and rework. After deployment, compare similar operations—not the new system’s best demonstration with the old system’s most difficult case.
The calculation needs to include licences, integration, data preparation and the labour of people reviewing results. Customer-facing and financial workflows particularly need a clear handover for difficult cases. The share resolved without escalation is useful only alongside resolution quality and repeat contacts; it is not itself a customer-satisfaction rate.
The Bank’s synthesis of the interviews points to scale, actionable data and management’s ability to reorganise work as conditions for deeper change. That is the practical test: start with a verifiable task whose improvement helps the company operate better, rather than a promise that AI will replace a department.
