AI agent implementation: which processes to hand over first and where the agent breaks

Implementing an AI agent means moving one of the company's working processes onto a system that receives its task in plain words, goes into your data on its own, and changes its state: opens a request, places a reservation, reschedules an appointment. The work consists of choosing the process, describing the procedure and the limits of autonomy, integrating with the systems of record, running a pilot on a limited scope, and operating it continuously with an owner and a metric. Buying a subscription to an assistant does not count as implementation: nothing changes inside your systems there.

Below: the signs by which the first process is chosen and which processes are handed over too early, how a pilot that proves something is built, and most importantly, where an agent breaks inside a working company. Invented answers on non-standard requests, no handover to a human, integration with 1C, the accounting and ERP platform most Russian companies run on, and CRM as the bulk of the effort, responsibility for a mistake in front of the customer, and the requirements of Federal Law 152-FZ, Russia's personal data protection law, once personal data ends up inside a request.

Where does implementing an AI agent begin?

Short answer: with choosing one process and appointing an owner, not with choosing a model or a platform.

This year's numbers from the Russian market explain why the order matters more than the tool. The consultancy Intellektualnaya Analitika surveyed about 50 of the largest companies in IT, industry, financial services, public administration, transport and logistics. The survey ran from December 2025 to February 2026. What became of the pilots launched in 2025:

The third row is part of the second, not a separate group. Separately, in the same survey, half of the executives pushed their implementation deadlines into the second half of 2026.

"What was launched were not practical IT projects but loud initiatives whose strongest effect was on the companies' own marketing strategies" — CNews, March 24, 2026, translated from Russian.

Demand, meanwhile, has not gone anywhere. According to a study by SberAnalytics and Sber Business Soft (survey of November 2025, 559 respondents), "39% of organisations already use AI agents and AI assistants for various tasks" (summary on ComNews, January 22, 2026). The gap between "already using" and "brought to an effect" is what this article is about.

Which processes should be handed to an agent first?

Short answer: the ones with many repetitive cases, a written procedure, a tolerable cost of error, and a measurable result.

The four signs work together, and weakness in any one of them moves the process to the back of the queue.

1. Volume of repetition. Measured as operations per month and minutes per operation. A small flow will not pay for its own upkeep, however irritating it is.
2. A written procedure or knowledge base. Price list, terms, answers to frequent questions, the order of actions including exceptions. If the process lives in one employee's head, it gets described in words first. An agent will not reconstruct logic that is not on paper — it will invent it.
3. Cost of a mistake. A wrong answer about opening hours costs an apology. A wrong discount calculation costs money and surfaces months later.
4. A metric. Share of requests closed without a human; time to first response; number of manual operations per month. A process with nothing to measure cannot be formally accepted.

What most often passes on all four:

The structure of demand confirms this logic. In the same SberAnalytics survey, the most frequently automated areas are document flow and request processing (70%), accounting and financial records (55%), HR processes and strategic planning (34% each), and customer support (30%). One important caveat: these are shares for the use of AI in general, not for agents specifically. The international picture is similar: according to an analysis by Yakov & Partners (July 30, 2026), 51% of the agentic solutions studied cover support functions, and another 37% cover customer service, marketing and sales.

What this looks like in a live environment can be seen in two of our cases. At a property developer (case) a bot runs the first line of incoming requests, and qualified enquiries land in the CRM by themselves, where a person takes the deal from there. In a network of service branches (case) an AI administrator books and reschedules appointments around the clock, and the schedule rules out double bookings. Both processes meet all four signs: a flow of repeats, a ready procedure, a tolerable cost of error, a measurable result.

Why can't a process without a written procedure be automated?

Short answer: an agent reproduces described behaviour and makes up whatever was not described — confidently.

A written procedure solves three problems at once. It sets the source of truth for answers, defines the exceptions (wherever an employee calls a colleague, the agent must call a human), and turns into acceptance criteria. Without it you cannot answer the question "what counts as a mistake," which means you can assemble neither tests nor a sign-off.

The order here is: describe the process exactly as a person performs it today, step by step, branches included. Usually at this stage it turns out that two employees do the same thing differently, and before any AI the company gets its first benefit — an agreed order of actions.

It is also worth checking whether an ordinary scripted flow would do. Anthropic recommends not starting with an agent if the task can be solved by a path written out in advance:

"Success in the LLM space isn't about building the most sophisticated system. It's about building the right system for your needs." — Anthropic, Building effective agents.

If rigid logic covers 80% of requests, the agent is needed for the remaining 20%, and it will cost noticeably less. The difference between a scripted flow and an agent is broken down in the article AI agents for business: what they are.

What does a pilot that actually proves something look like?

Short answer: a limited scope, acceptance criteria written down in advance, and a deadline after which the project either moves on or closes.

A pilot tests the benefit, not whether the technology works. Whether it works is no longer in doubt today, and that is precisely why demos pass so easily: they are shown on clean data and standard questions.

What is set before launch:

1. The boundaries of the scope. One branch, one channel, one type of request, part of the flow. The smaller the surface, the cheaper the mistake.
2. Acceptance criteria as numbers. What share of requests the agent closes on its own, what share of handovers to a human counts as normal, what is recognised as a mistake.
3. An owner. A real employee who reads the action log, reviews disputed cases and updates the knowledge base. Without one, the project comes back in six months as an incident.
4. A deadline and a decision at the end. A date on which the metric is reviewed and one of three decisions is taken: expand, rebuild, close.
5. A baseline for comparison. How the process ran before the agent: how many operations, how much time, what an hour of an employee's work cost. Without a "before" measurement there is nothing to calculate the savings from later.

The comparison point looks dull and gets skipped more often than the rest. It is also what explains those 30–40% of pilots wound down for lack of the expected financial effect: the effect may have been there, but there was nothing to show the CFO. We covered the method for calculating payback on a specific process in the article on a first-line AI agent, and the full implementation budget in the breakdown of stages and costs.

Why doesn't a pilot turn into a working system?

Short answer: because what breaks is not the model but everything around it — data, permissions, integrations, and the absence of a fallback scenario.

Yakov & Partners studied 30 products (18 international and 12 Russian) and 65 publicly described implementations (43 international and 22 Russian). Products were assessed against six operational criteria of agency: the agentic loop, planning, tool use, self-correction, memory and autonomous task completion. A solution counted as a full agent if it scored at least five.

• 7 of 18 international products (39%) passed the criteria;
• among the 12 publicly available Russian products there were no full agents: the four leaders are platforms for assembling your own, and the remaining eight are narrow assistants and chatbots;
• 23% of international implementations reached the high autonomy levels L4–L5; among Russian cases there were 4 out of 22;
• an effect above 5% of EBITDA was recorded by 9% of companies — out of the 150 largest organisations in the sample, each of which had run at least one pilot on key AI technologies.

"Today the word 'agent' often describes not a product's architecture but its marketing positioning" — Maxim Bolotskikh, partner at Yakov & Partners, CNews, July 30, 2026, translated from Russian.

Gartner had already given this a name earlier — agent washing, relabelling existing products as "agents" without real agentic capabilities. The same source carries a forecast made in June 2025: more than 40% of agentic projects will be cancelled by the end of 2027 because of rising costs, unclear value and insufficient risk control (Gartner press release of June 25, 2025). That assessment is more than a year old and should be read as a forecast, not as a measurement.

For a company buying this, the conclusion is simple: the demo shows the top layer, and the lower ones decide the outcome. Below are the three places where things tear most often.

Why does an agent invent answers to non-standard requests?

Short answer: at the edge of the knowledge base, a model prefers a well-formed answer to admitting it does not know.

Standard questions an agent handles cleanly. The problems start where the wording falls outside the corpus: unusual contract terms, a complaint, a legal question, a rare product, a reference to a verbal arrangement with a manager. By its nature a model continues text, and with no data the continuation comes out well-formed and wrong.

What removes most of the risk:

1. The answer is built only from your knowledge base. Procedures, price lists, terms. The model's general knowledge is used to understand the question, not to invent the answer.
2. A permitted refusal. "I don't know, connecting you to a manager" must be normal behaviour, not a sign of breakage. The share of such answers is measured: it shows the holes in the knowledge base.
3. A list of forbidden topics. Legal assessments, promises about deadlines and discounts, comments on claims — recorded as an unconditional handover to a human.
4. Regression checks. A set of real non-standard requests against which every change to a prompt or to the base is run. Without it, a fix made for one case quietly breaks five others.

A separate check before launch is a run on dirty data. Not on a prepared sample, but on an export of a month's real requests, with typos, voice transcripts and fragments of phrases.

What happens if handover to a human is not set up?

Short answer: without a described escalation path, the agent carries through to the end scenarios it was supposed to pass to an operator.

Escalation is defined by a list of signals, not by a general phrase like "if something goes wrong." A working set:

• the customer explicitly asks for a person;
• the same question comes up a second time (the answer did not fit);
• negativity, a complaint or a mention of regulatory bodies appears in the conversation;
• data is requested that is not in the knowledge base;
• the action touches money, obligations, or an irreversible change in a system of record.

Each signal is tied to a recipient and a deadline. Handover into nowhere — the request flies off into a shared chat that nobody reads — works worse than an honest "we don't answer at night."

Access rights belong here too. Informzashchita, a Russian information security company, published data on incidents involving AI agents (CNews, May 26, 2026); the sample size and survey coverage are not disclosed in the publication, so these shares should be read as orders of magnitude rather than precise measurements:

• 42% of organisations faced security incidents caused by agents in 2026, against 31% a year earlier;
• 53% encountered an agent exceeding the authority it had been given;
• 58% say detection and response takes more than five hours;
• among those applying the principle of least privilege, incidents are recorded in 17% of cases, against 76% for the rest.

Even allowing for the undisclosed methodology, the gap between the last two figures is large, and it was achieved by an organisational measure rather than by buying software. One rule follows from it: the decision about access is made by your systems, not by the model. The agent requests data — the system decides whether to release it to this customer in this conversation.

Why does integration with 1C and CRM eat most of the budget?

Short answer: connecting to the systems where the data lives is the main work, and a demo's estimate usually does not contain it.

Alexander Nikolaychuk's analysis on Habr, «An AI agent works until you give it access to real data» (July 21, 2026), lists what surfaces when a prototype is moved into a company:

• The data is stale. The warehouse refreshes on a schedule, and the agent honestly answers from yesterday's picture.
• Systems of record do not push data out themselves. They work on a "come and get it" model, so a separate collection and normalisation layer is needed.
• The model starts deciding access questions. A customer asks for someone else's information, and the agent either fulfils the request or errs: both outcomes are bad.
• A supply chain risk appears. A compromised dependency brings someone else's code inside the perimeter.
• There are no scenarios and no metrics. Without described behaviour you cannot assemble tests or acceptance criteria.

The same piece cites an estimate from developer Andrey Nosov: in particular cases the cost of full development came out roughly twenty times higher than the initial demo. The author himself notes that this is not a coefficient for calculations but the difference between a short working scenario and a production system. Such a number cannot be used as a guide for an estimate — it is a single experience, not an industry norm. What is useful in it is something else: the direction of the error. A budget calculated from a demo is always understated, because a demo contains no integrations, no access rights and no support.

What a finished environment looks like can be seen in our wholesale case: a two-way integration with 1C where the catalogue, stock levels, shipments and payments sync by themselves, so an order sees real stock and places a reservation. The agent has something to work with precisely because that layer exists. The connection layer itself is covered in the article on how to link 1C, CRM, the bank and Telegram into one environment.

Industrial implementations show the same dependence on the surrounding environment, only at a larger scale. According to a Strategy Partners study of generative AI use in large Russian industrial companies (early 2026), 63% of enterprises have approved an AI adoption strategy; at Nornickel more than 100 AI agents are deployed, embedded in 30 business processes (Yulia Datskaya, Kommersant, May 19, 2026). The figure "100 agents" is less interesting here than "30 processes": agents live inside described processes, not next to them.

Who answers if the agent makes a mistake in front of a customer?

Short answer: under standard contracts the risk of the agent's actions stays with the customer, and before the client and the regulator the answer comes from the company that launched the agent.

Lawyers at Clifford Chance describe this as a liability gap:

"Under the terms of many agentic AI technology agreements, the business purchasing the technology (i.e. the customer) ultimately bears the risk of the AI agents' actions" — Clifford Chance, Agentic AI: the liability gap your contracts may not cover, February 2026.

This is specifically about contract practice: a vendor's disclaimer removes liability from the vendor, but it does not answer for you before your client. The terms of the particular contract are worth reading before signing — that is where you see who carries the risk.

Two practical requirements for the project follow. First, the limits of autonomy in documents: the list of actions the agent performs on its own; the list of actions requiring operator confirmation; the list of unconditional handovers to a human. Second, an action log that records what the agent read and what it changed. Reviewing a disputed case without a log is impossible, and disputed cases will happen: half of the organisations in Informzashchita's data recorded agents exceeding their authority.

An agent allowed to issue invoices and confirm terms without a human does not create savings — it shifts the risk onto the business owner.

What does 152-FZ require when an agent sees personal data?

Short answer: sending a customer's data to an external model already counts as processing it, and for a foreign model cross-border transfer is added, with notification of the regulator.

Personal data enters the agent's environment routinely: a name and phone number in a request, an order history, a CRM export used for testing. From that moment the company acts as an operator with all the obligations that entails.

"Before beginning cross-border transfer of personal data, the operator is obliged to notify the authorised body for the protection of the rights of personal data subjects of its intention to carry out cross-border transfer of personal data" — part 3 of article 12 of Federal Law No. 152-FZ, translated from Russian.

The procedure is notification-based, but it is not a formality. The same article gives the regulator the right to restrict or prohibit the transfer, and sets stricter conditions for countries without adequate protection of data subjects' rights. The law does not offer the option of notifying after the fact.

There are three workable options, and the choice between them is made before design, not after the pilot:

1. De-identification before sending. What goes to the model is the substance of the question without names, phone numbers or contract numbers. The cheapest path; it requires careful data preparation and a check that de-identification does not destroy the meaning of the request.
2. A Russian model provider. A data processing agreement provides the legal frame; the terms of the particular service need to be read separately — some providers explicitly forbid sending personal data in requests.
3. An open-weight model inside your own perimeter. The data never leaves the company's perimeter. More expensive in infrastructure, removes almost all localisation questions.

A full breakdown of how to build an environment that data does not leak out of is in the article on neural networks without data leaks and 152-FZ.

What in an implementation plan is specific to an agent?

Short answer: three documents that do not exist in an ordinary IT project — the data regime, the limits of autonomy, and the list of integrations with the required data freshness.

The general organisational steps — process owner, "before" measurement, acceptance criteria, budget and deadlines — are the same for any automation project and are covered separately in the article on the stages and cost of AI implementation. An agent adds three things to them, and those three decide the fate of the project.

1. The data regime. What goes to an external model, what never goes, where personal data is physically processed, and in what form conversations are stored. The decision is taken before the platform is chosen: it rules out whole categories of options.
2. The limits of autonomy. Three lists — actions without a human, actions with operator confirmation, unconditional handover to a human. Plus the access rule: the agent requests data, and your systems decide whether to release it.
3. The list of integrations with data freshness. For each system: does the agent read it or write to it, does it push data out itself, how fresh is the data on the way out. A line saying "stock levels refresh once a day" is either accepted as a constraint or turned into a separate piece of work — and separate money.

Once these three documents exist, the conversation with a contractor or your own team becomes concrete, and the choice of how to build becomes the last step rather than the first. A breakdown of the four routes and their ceilings is in the article how to build an AI agent for business. Projects most often fall apart in the reverse order: first the platform is bought, then a process is sought to fit it.

The line between an experiment and a system runs where the agent starts changing data in working systems and talking to your customers on your behalf. INCUBE AI works under contract, keeps data inside Russia, and builds an agent around your procedures, with integrations and support after handover. An off-the-shelf agent runs into the same wall as any boxed product: it covers the standard process, but the procedures, reference data and list of exceptions are different in every company — and they are what determines what the agent is allowed to do. We covered the fork between a ready-made solution and a system built for your own process separately — your own system or a boxed one. If you are matching this to your own task, book a consultation: we will look at the process and say plainly where an ordinary scripted flow is enough and where you need an agent with access to your systems.

Sources

• CNews, March 24, 2026: survey by Intellektualnaya Analitika — about 50 of the largest companies, 7–10% of pilots reached implementation, 30–40% wound down for lack of financial effect
• CNews, July 30, 2026: study by Yakov & Partners — 30 products and 65 implementations, six criteria of agency, 23% of cases at level L4–L5, 9% of the 150 organisations in the sample with an effect above 5% of EBITDA
• Kommersant, Yulia Datskaya, May 19, 2026 — Strategy Partners study of industry: 63% of enterprises with a strategy, more than 100 agents across 30 processes at Nornickel
• CNews, May 26, 2026: Informzashchita on incidents involving AI agents — 42% with incidents, 53% with agents exceeding authority, 17% against 76% under least privilege; the sample is not disclosed in the publication
• ComNews, January 22, 2026: study by SberAnalytics and Sber Business Soft — 559 respondents, 39% of organisations use AI agents and assistants, which processes are automated most often
• Habr, Alexander Nikolaychuk, July 21, 2026: «An AI agent works until you give it access to real data» — what surfaces when a prototype moves into a company, a single estimate of the gap between demo and product
• Gartner, press release of June 25, 2025 — forecast that over 40% of agentic projects will be cancelled, and the term agent washing
• Clifford Chance, Agentic AI and the liability gap, February 2026 — under the terms of many agreements the risk of the agent's actions is borne by the customer
• Part 3 of article 12 of Federal Law No. 152-FZ "On Personal Data" — notifying the regulator before cross-border transfer begins
• Anthropic. Building effective agents — the recommendation to start with the simplest solution and not build an agent unless you need one