AI Adoption in Business in 2026: Why Nine Pilots in Ten Never Reach Production

What people call "AI adoption" — and why it means three different things

When an executive says "we've adopted AI", it usually refers to one of three fundamentally different stages. Confusing them is the source of both inflated expectations and the failure statistics.

An assistant subscription. The company bought access to GigaChat, YandexGPT or ChatGPT, and staff use it to draft text and summarise documents. Useful, but unrelated to any business process: the assistant knows nothing about your counterparties, stock levels or contracts. Nothing is automated — people just type faster.

A pilot on one process. A specific task was picked — parsing inbound email, drafting review replies — and tested on a sample. This is the right stage, but it is also where roughly 40% of projects die.

Production operation. The agent has access to the systems where the data actually lives, runs on a schedule without reminders, and writes results back into the system of record. Only this changes headcount hours.

The market counts all three as "adoption". Hence the gap: according to Sber, 97% of large Russian companies have adopted or plan to adopt AI — while more than 90% report no systemic return from it. There is no contradiction; the two figures count different stages.

If you are still choosing a class of solution, start with our overview of AI for business — this article is about what happens after that choice.

Why nine pilots in ten never reach production

This is the question integrator playbooks avoid. Five causes, each with a symptom you can check against your own project.

1. The pilot ran on an export, not live access

The most common scenario. To show results fast, someone exports an Excel file from 1C or MoySklad, feeds it to the model and gets a clean analysis. The demo lands beautifully. Then it turns out that weekly operation requires someone to produce that export by hand — and the project dies not from poor AI quality, but because a new manual step ate the hours it saved.

Symptom: the pilot description contains the words "exported", "prepared a file", "loaded data for the period".

2. The data was dirty

A model does not repair what is broken in your bookkeeping. Duplicate counterparties, one product under three SKUs, backdated entries, stock items maintained differently in two branches — AI will faithfully reflect all of it in the report, and the report will be wrong. One such incident in front of a finance director shelves the project for a long time.

Symptom: before the pilot, nobody in the company could quickly say how many active counterparties or SKUs you have, because the number depends on who counts.

3. The agent had no write permission

Out of caution the company grants read-only access. The agent reads, analyses, proposes — and a human still carries the result into the system. Hours are not saved, they are reallocated: instead of "think and do", the employee now does "read someone else's proposal and do". No saving, plenty of irritation.

The right answer is not "grant everything" but to separate operations by risk: reading and calculations the agent does alone, changes to the system of record go through confirmation, and irreversible actions stay with a human. We covered this logic in detail in our piece on AI agents for business.

Symptom: after the pilot, staff still open 1C and key in whatever the agent calculated.

4. Success was measured by demo effect

"Look, it wrote an email in three seconds" is not a metric. A metric is month-end close time, the number of errors in acts, the share of reviews answered within a day, hours spent assembling the weekly report. If no baseline was recorded before launch, then two months later there is nothing to prove value with, and next year's budget cannot be defended.

Symptom: asked how much better it got, the team answers with adjectives rather than numbers.

5. The process had no owner

IT runs the pilot because "it's about technology". The result is needed by finance, sales or the warehouse. IT cannot decide which report is correct, and the business unit does not consider the project theirs. It stalls between them and quietly closes at the first budget review.

Symptom: nobody whose actual working week is consumed by this process attends the pilot meetings.

Where to start: four steps instead of an "AI strategy"

A year-long AI strategy is a poor first purchase. The reverse order works.

Step 1. Pick a process with measurable routine. A good candidate repeats at least weekly, consumes a known number of hours from a specific person, and produces a verifiable result. A bad candidate is "improve customer experience".

Step 2. Connect the system where the data lives. Not an export — the system: 1C, MoySklad, Bitrix24, amoCRM, a marketplace back office, telephony. If it emerges at this step that access cannot be granted or the API is closed, it is far better to learn that in week one than in month three. What connects and how is collected in our integrations catalogue.

Step 3. Define the autonomy boundary. In writing: what the agent does alone, what it shows for confirmation, what it never does. This same document later serves as the operating rules the law now requires you to maintain.

Step 4. Measure one metric for four weeks. One, not eight. Record the baseline before launch.

Which processes move to AI first

Practice shows a stable pattern: the processes that migrate successfully first are those with high repetition, data already in a system, and an easily verifiable result.

How this looks on specific systems is covered in our walkthroughs for Bitrix24, amoCRM and MoySklad. Calls are covered in the piece on speech analytics, closing documents in the one on acts and documents.

The legal layer: what changed in summer 2026

Until this year, choosing an AI service was a matter of taste and price. It now has a legal frame, and it is worth understanding before the pilot rather than after.

The AI regulation law. Passed by the State Duma on 8 July 2026 and approved by the Federation Council on 17 July. The main provisions take effect on 1 September 2026, selected provisions on 1 March 2027, and the transition period for systems already in operation runs to 1 September 2032.

An important detail lost in most retellings: the law applies only to large foundation models — one billion parameters and up. Narrow ML models, computer vision and specialised algorithms fall outside it. If you forecast demand with a classical model, the law does not directly concern you.

The law introduces two statuses. A sovereign model requires a Russian legal entity under Russian control, a full development cycle inside Russia, and guaranteed reproducibility of training. A national model requires a Russian developer but permits foreign open-source components. Both categories must process data on Russian servers.

For a business user, the obligations come down to four things: inform users about rights to AI output, take organisational and technical security measures, maintain technical documentation, and define operating rules for the model. Labelling of AI content remains optional, governed by agreement between parties and platform rules.

The law does not regulate personal data — the general requirements of Federal Law 152-FZ apply. Those became markedly harsher in 2026: a mass breach (over 100,000 subjects) exposes a legal entity to 10–15 million roubles, and a repeat breach triggers a turnover fine of 1–3% of annual revenue, with a floor of 20 million and a cap of 500 million roubles. It is this exposure, rather than the AI law itself, that makes "where does our data go" a practical question.

Hence four questions worth asking a vendor before the pilot:

1. Where are the data and the agent conversation physically stored?
2. What of our data reaches the model, and is it used for training?
3. Is there an entry in the register of domestic software — and will we need one (phased trusted-software requirements for public procurement begin on 1 September 2026)?
4. Which actions can the agent take without confirmation, and how are they logged?

Our answers are set out on the security and data page.

In-house, via an integrator, or with a ready-made agent

Three routes, each with an honest price.

Your own stack on open models. GigaChat has been open-sourced; T-Pro and T-Lite from T-Bank, Saiga and others are available. Full control over data, nothing leaves your perimeter. The price is an engineering team and infrastructure: someone must deploy, fine-tune and maintain it. Justified when perimeter requirements are strict and in-house development already exists.

A turnkey integrator. Discovery, specification, development, rollout. You get a solution shaped to your processes, but the cycle is long and the budget starts in the hundreds of thousands. The main risk lives here: a meaningful share of the failed projects in the statistics are exactly these, where discovery took months and the process had changed by launch.

A ready-made agent with integrations. Fast and predictable on cost, but you work within the connectors that exist. If your system is not on the list, or your 1C carries heavy custom objects, that surfaces in week one.

It is also worth separating an AI agent from a connector layer. Albato, Make, n8n and ApiX-Drive move data on an if-then rule and make no decisions; a useful tool, but not AI adoption. We covered the difference in our comparison of an agent against no-code platforms. A survey of Russian options is in our roundup of AI assistants for business.

Samreshuuu belongs to the third type: it connects to 1C, MoySklad, Bitrix24, amoCRM, marketplace back offices and telephony over official APIs, keys are never exposed to the agent, writes into your systems go through confirmation, and every step is logged. That addresses the first, third and fourth failure causes above — but not the second: dirty data still has to be cleaned, and that is your team's work.

Cost and payback

Computing "340% ROI" is meaningless — the number says nothing without a baseline. A simpler calculation works.

The first quantity is routine hours. Take the process, multiply frequency by duration by the loaded hourly cost. A weekly report an analyst assembles in four hours is roughly 200 hours a year.

The second is the cost of an error. A late act, an uncaught duplicate payment, a SKU that sold below cost for two weeks because the repricer did not know your margin. These sums are usually larger than the hours but harder to forecast — so count actual incidents from the past year.

If the two together do not exceed the subscription cost several times over, the process was chosen poorly; pick another. Our plans and limits are on the pricing page.

A 12-point adoption checklist

Work through it before the pilot, not after.

1. The process repeats at least weekly.
2. A baseline metric value was recorded before launch.
3. The process has an owner in the business unit, not only in IT.
4. Data sits in a system that can expose API access.
5. Duplicate counterparties and SKU inconsistencies have been checked for.
6. It is defined what the agent does alone, what needs confirmation, and what it never does.
7. Write permission has been granted for at least some operations — otherwise there is no saving.
8. It is known where data is stored and what reaches the model.
9. Whether you need a domestic software register entry has been checked.
10. There is an action log open to review.
11. The pilot has an agreed duration — four weeks suffices for most processes.
12. The criterion for declaring the pilot a failure and stopping it was decided in advance.

The twelfth point matters more than it looks: projects without a stop criterion do not close, they smoulder, consuming the team's attention.

Frequently asked questions

How long does a pilot take? For a single process with ready integrations, four weeks: one to connect and set boundaries, three to accumulate statistics. If your system needs modification, that work sets the timeline, not the AI.

Do we need a developer? For a ready-made agent with connectors, no — you need someone who knows the process and can grant access. For your own stack on open models, absolutely.

Our 1C is heavily customised. Is that a problem? Not always, but check in week one. Standard objects are read through the official API; custom ones need separate configuration. This is precisely the question that is cheaper to answer immediately.

Can we start without write permission? Yes, and for the first week that is sensible. But leave it that way permanently and you get an adviser rather than a doer, and you save no hours — this is the third most common cause of failure.

What about customer personal data? The AI law does not address this; 152-FZ does. In practice: find out where data is stored, minimise what you transmit, and confirm that agent conversations do not feed a third party's training.

How does an AI agent differ from a connector like Make or n8n? A connector executes the rule you defined and makes no decisions. An agent breaks down the task, chooses its own steps, and can handle a case you did not anticipate. For rigid scheduled transfers a connector is cheaper and more reliable; for analysis and non-standard situations it does not apply.

Where should a small business with no IT department start? With one process where the routine is obvious: review replies, the weekly sales report, preparing closing documents. Not with an "AI strategy".

Do we have to do something by 1 September 2026? If you are a user of an AI service rather than a developer of a large foundation model, your direct obligations are limited: maintain documentation and operating rules, and inform users about rights to AI output. The bulk of the burden falls on model developers.

---

If you want to examine a specific process before spending budget on it, book a demo: we will show on your own data what the agent closes by itself and what needs fixing in your bookkeeping first.