Two AI Services in Two Weeks: How They Differ—and Why Both Still Need 1C Integration

Summer has been hot: over the past two weeks, we built two AI services for two entirely different clients and two entirely different business processes.

The first is meant to prepare a personalized commercial proposal using company data and the results of a free service period. The second is meant to bring order to a reference catalog containing hundreds of thousands of items and lay the groundwork for an AI procurement assistant.

One project is about copy, arguments, and personalization. The other is about resistors, duplicates, and some rather uncomfortable questions about procurement controls.

Yet their current status is the same: the service logic works, the JSON API has been agreed, and the responses are already being tuned. In both cases, a full MVP is waiting for 1C integration.

It is a useful illustration of why the speed of building an AI service and the speed of getting a business outcome are two different speeds.

Project No. 1. Doing in two to three months what had been planned for a year

The client already had an internal project to create the ideal commercial proposal. Not another template with the company name swapped out, but a genuinely personalized document:

• based on data about a specific client;
• incorporating the results of a free service period—a trial;
• using arguments suited to that particular company;
• with logic that turns collected information into a meaningful proposal.

The internal project plan was expected to take about a year.

We suggested changing the system boundary. Instead of trying to build all the logic inside 1C, move the intelligent part into a separate AI service. It receives data, processes it, and returns a ready proposal structure. 1C remains the working interface and produces the final PDF.

The planned project horizon fell to two or three months.

Important: this is not an achieved result yet; it is the new implementation plan. But the difference itself is revealing. AI is not accelerating the writing of a few paragraphs here. It changes the architecture of the project and takes on the part of the logic that was the reason the project existed in the first place.

We are building the project in Yandex AI Studio. f(AI) Studio is an official Yandex Cloud partner.

The first week went into project approval in the Yandex Cloud partner environment, setting up the environment, and deploying the first release.

The bureaucracy was mildly surprising: around ten people on Yandex’s side spent a month on approvals—and the result was one project finally getting started. AI promises to speed up almost everything, except the approval of an AI project.

Over the following week, we implemented the service logic and the agreed API contract for 1C integration. We are now testing responses on synthetic data and tuning quality.

Project No. 2. The client asked us to find duplicates. But duplicates were not the real problem

The initial request in the second project looked almost technical: the reference catalog contains around 300,000 items, and it needs to identify duplicates and similar names.

That is an understandable task. By itself, however, it says almost nothing about why the business needs AI.

A deeper interview revealed the real pain. For example, a resistor was purchased for 2.3 rubles even though a suitable alternative could have been bought for 1.8. The difference is half a ruble per unit, or nearly 28%. With procurement volumes in the billions, even a small share of irrational decisions becomes meaningful money.

There is a more sensitive risk as well: a new item may appear in the catalog not because the company truly needs a new product, but because it makes it easier to direct a purchase to a preferred supplier.

The task is to reduce that risk and build a control system. Because when the catalog is bloated and identical goods live under different names, almost any choice can be justified—not only the optimal one.

And this is where the paradox appeared: the first important phase of the AI project may not require AI at all.

First, we need a reproducible algorithm that finds duplicates, groups alternatives, and brings the catalog into a state suitable for further analysis. Without that, the future AI assistant will work very quickly and very convincingly with the disorder that already exists.

During the first week, we deployed the environment on a VPS and then a test environment on the client’s server. During the second, we implemented the service logic and the API.

We are now testing requests through a GUI stub and tuning response quality.

What is actually ready after two weeks

We did not launch two finished business products in two weeks. We built two service components of future MVPs:

• implemented the logic defined in the technical specification;
• agreed JSON API contracts;
• obtained working responses in test scenarios;
• started tuning the algorithms and quality.

We define a complete MVP as the first end-to-end run:

user action in 1C → request to the AI service → processing → response in 1C → result in the working interface.

For that, 1C needs to provide two things:

1. Integration through the agreed JSON API.
2. User-interface work to call the required function and handle its result.

Until that is in place, we can demonstrate that the service logic works, but not the complete business function.

Why we did not wait

We could have waited for the 1C teams to complete the integration and only then started AI development. The project schedule would have looked tidier. And longer.

So we split the work:

• everything that depends on the final interface and real data waits for integration;
• everything that can be done without risking later rework started immediately;
• the boundary between the systems was fixed in advance in the API contract.

That contract lets two teams move in parallel. The AI service can already accept and return the agreed structure. The 1C team can implement its part without waiting for every algorithm to be tuned.

For a business owner, this may be the main conclusion of the story: a fast AI pilot does not begin with choosing a model. It begins with dividing the work correctly and agreeing the boundaries between systems.

A jet aircraft in the server room

One client has its own GPU server. By the standards of our current project, it is a jet aircraft.

The most interesting part is that the aircraft barely flies. Our service will use only a small share of its resources.

So we proposed using the infrastructure more broadly: building an AI-powered development environment around one or more 1C developers, then testing the approach with other internal teams.

Not simply giving a programmer an AI assistant, but connecting the following into a managed process:

• breaking down and estimating tasks;
• preparing technical solutions and draft code;
• automated code review;
• generating test scenarios;
• documentation, build, and release of changes;
• building a knowledge base for the configuration and customizations.

The purpose of this pilot is to test on real tasks whether development throughput can be increased materially, errors reduced, and dependence on one specialist lowered. There are no results yet: this is the next experiment, not the conclusion of the current story.

What to prepare before an AI pilot or implementation project begins

1. An honest business pain. "Find duplicates" is a task. "We overpay and cannot explain supplier selection" is a business pain.
2. The boundary of the AI function. What the AI service does, how the familiar user interface—such as 1C—is preserved, and what decision a person makes.
3. An API contract before development is complete. What data arrives, what returns, and what an error looks like. This lets teams work in parallel.
4. An end-to-end definition of MVP. Not a pretty model response, but a completed path inside the working interface.
5. An integration owner and success criteria. Who closes the loop, who accepts a disputed answer, and what will be measured after launch.

The two current projects differ in almost everything: users, data, logic, and outcome. But they share one lesson.

An AI service can indeed be assembled quickly. To get business impact just as quickly, you need to design the entire route to the user’s action alongside it—and verify that internal processes support that route.

In future articles, I will look separately at how AI assembles a personalized commercial proposal, and why the path to an AI procurement assistant sometimes begins with an algorithm containing almost no AI at all.