How to implement AI in business: a step-by-step plan for executives

AI implementation in business processes: how to choose the first task

A typical mistake at the start is a scope that is too broad: "implement AI in sales" or "automate document flow". For the first task you need one process and one section of it. Then it is clear who owns it, what material it runs on and how to measure the result.

AI works well where the work repeats but is a little different each time: requests are worded in different ways, documents arrive in different formats, and the answer has to be found in a large knowledge base. If the rule can be written in one line, ordinary automation or a written procedure is cheaper — you don't need AI for that.

Typical tasks to start with: sorting incoming requests and routing them to the right employee, extracting data from contracts and invoices, searching documents and the knowledge base, preparing standard replies and reports, and spotting deviations in operations. Check your chosen task against the list below.

• The process repeats regularly, and employees spend a noticeable share of their working time on it.
• You have real examples of incoming material: requests, documents, exports.
• It is clear what counts as a correct result, and you can check it against examples.
• A mistake does not lead to irreversible consequences: disputed cases can be passed to a person.
• The result has to appear in a system that employees already use.

What data and people you need to implement AI

Data does not have to be a large database. To start, a set of real examples is usually enough: requests, documents, correspondence, exports from your accounting systems — with typos, empty fields and the non-standard cases that come up in real work. The solution is tested on exactly these. Neatly prepared samples only get in the way: quality will look higher on them than it is in the real flow.

If the material contains personal data, settle this before work starts: which fields the solution really needs, whether it can work on anonymized data, and where it will be deployed — in your infrastructure or in an agreed cloud. The requirements of Federal Law No. 152-FZ (the Russian personal data law) are built in at the design stage, not fitted to a finished solution.

People matter just as much: a technically strong project stalls at acceptance without them. On your side you will need:

• A process owner — knows how the work really runs and can explain the exceptions.
• A person responsible for acceptance — agrees the criterion and decides whether the result is good enough.
• A systems specialist — provides access and describes how 1C, CRM and your other systems work.
• Employees who run the process — mark the solution's errors during the pilot; their comments are the material for improvement.

Discovery, a pilot on real data and an acceptance criterion

Discovery is short pre-project work. The contractor studies the process as it runs today, looks at your material and answers in writing: is there work for AI here, which section to automate first, what the limits of the solution are, and how much work it will take. The result is a document: a process map, the chosen section, an acceptance criterion, an estimate of scope and a list of risks. An honest discovery may end with the conclusion that you don't need AI: some tasks are cheaper to solve with a written procedure or a ready-made service.

An acceptance criterion is a condition written down in advance under which the result counts as accepted. It must be checkable on examples. For instance: on an agreed sample of real requests, the solution correctly identifies the type and the responsible person, and passes disputed cases to a human. Without such a criterion, the argument over whether the solution works turns into a conversation about impressions.

A pilot on real data is the first version of the solution, built for your process and tested on your material, including rare cases: non-standard requests, empty fields, errors in the input data. The next step is a run on the live flow in parallel with normal work. Employees keep working the old way, the solution runs alongside, and the results are compared. Only after that is it worth relying on the solution.

Bringing AI agents into business processes: how to build the solution into your systems

An AI agent is a solution that does not only answer a question but also takes actions: it accepts a request, finds the answer in the knowledge base, creates a record in a CRM or in 1C (a Russian ERP platform), and assigns a task to an employee. The wider the set of actions, the more important the limits: what the agent does on its own and what it only suggests to a person.

Employees quickly stop opening a solution that lives in a separate window. So the result has to appear where people already work: in 1C, CRM, ERP, email, a messenger. This is usually done through an API — an interface that lets systems exchange data — without replacing what already works. Find out in advance which systems have an API, who provides access and how quickly it can be done.

Plan control separately: a log of the solution's actions, alerts about failures, a rollback procedure in case of a fault, and handing difficult cases to an employee together with the context. For an example of an AI assistant that understands a request in plain words, see the Carfast AI case study below this article.

Who is responsible for the result after launch

Launch is not the end of the project. Processes change, the wording of requests and document formats change, and the systems themselves are updated. If nobody is responsible, quality slowly drops, and you find out from complaints by employees or customers.

Choose the model before launch. In the first, your team runs the solution, and the contractor stays available to the extent set out in the contract. In the second, the contractor takes over support and improvement: monitors operation, investigates incidents and updates the solution when the process changes. Either way you need a responsible person on your side, access that stays in place, and written terms: what support includes, how incidents are handled, and who owns the code, configurations and rights.

Also clarify the ongoing costs in advance: model calls and infrastructure are paid separately from development, and they are worth estimating before the start, not after.

Common implementation mistakes and questions for your contractor

The mistakes are usually the same ones. Teams take a task that is too broad instead of one step of a process. They test the solution on hand-picked samples, not on the real flow. They don't set an acceptance criterion, and later argue about the result. They keep people out of the process: hard cases either land on an employee with no context, or get decided automatically with no oversight. They put off the question of support until the first failure.

To see how a contractor will actually work, ask questions whose answers show up in documents, not in a presentation:

• What will the first stage deliver, and do we keep it if we don't continue the project?
• On which of our data and against which acceptance criterion will quality be checked?
• What happens if the solution doesn't meet the criterion: who fixes it, and at whose cost?
• Where will the solution run, and how are the requirements of Federal Law No. 152-FZ handled?
• Who owns the code, the configurations and the prompts — the text instructions for the model?
• Who monitors the system after launch, and how are incidents and support terms recorded?
• What do the ongoing costs consist of, and how much does support cost?

How we approach a first project

We start with a free discovery of one task. We study the process, look at your examples, and answer in writing: is there work here for AI, where are its limits, and how big is it. Discovery takes 3–5 business days. We give an exact timeline once we see the scope. You keep the document either way. You can use it to work on your own or to talk to another contractor.

If the task can be solved with a written procedure, ordinary automation or an off-the-shelf product, we say so plainly. If AI is needed, the next step is a prototype on your data. It takes from 3 weeks, and AI projects start at $2,100. For 1C (a Russian ERP platform) and CRM integrations, the timeline is from 4 weeks. The acceptance criterion is set in writing before work begins, and we refine the solution until it meets that criterion, at our expense. After launch, support comes in packages of 10, 20 and 40 hours a month, from $400.