Choosing an AI model: YandexGPT, GigaChat or foreign models

Which task to start from when choosing a language model

A language model is a program that works with text. It reads a request, takes into account the materials you give it, and produces an answer. YandexGPT, GigaChat, OpenAI, Claude and Gemini are different families of such models. Each vendor has its own connection terms, pricing and limits.

Start with the task, not the model name. Typical business tasks are: answering employees and customers from a knowledge base, classifying and routing requests, extracting data from documents, drafting reports and emails, and searching internal documents. Each task depends on different things. For some, the accuracy of field extraction is critical. For others, it is the tone of the answer or the speed of handling a stream of requests.

Before you compare models, answer these questions: What result do you want? What data will the model see? Who checks its answers? What happens if it makes a mistake? These answers rule out some options right away and save you unnecessary comparisons.

YandexGPT and GigaChat for business, or foreign models

In practice, the question "Russian or foreign model?" breaks down into several criteria you can check. Until you check them, statements like "YandexGPT is more accurate" or "Claude is more convenient" remain opinions, not grounds for a decision. Model features, prices, limits and versions change. So compare on your own tasks and against the vendor's current terms.

Include the Russian models, YandexGPT and GigaChat, in your comparison on equal terms with OpenAI, Claude and Gemini. Below are criteria your company can check on its own. Each one is covered in the sections that follow. In practice, different processes often suit different models, and that is normal.

• Data: where requests are processed, whether the vendor stores them, and whether you may pass your materials to it.
• Quality: how the model handles your real examples, including difficult and unusual ones.
• Cost: what the payment consists of and how it changes as the load grows.
• Deployment: whether you can run the model in your own infrastructure or an approved cloud.
• Dependence: how hard it is to move to another model if the terms change.
• Access: how to pay for the service and whether its terms are acceptable to your legal and finance teams.

Data and personal data: what to check first

This is the strictest filter. It can rule out a model regardless of its quality. First, find out what data the model will receive. If requests contain surnames, phone numbers, passport details or other information about people, that is personal data. Its processing is covered by Federal Law No. 152-FZ (the Russian personal data law).

Next, you need answers from the vendor and from your lawyer. Vendors' terms for handling data differ and change, so rely on current documents, not on retellings. If passing data to an external service raises doubts, there are two options: anonymize the data before sending it to the model, or run the model in a closed environment.

Some tasks do not require personal data at all. Classifying requests by topic or searching regulations often works on anonymized text. In that case, more models are acceptable. Questions to ask the vendor:

• Where are requests and answers physically processed and stored?
• Is your data used to further train the vendor's models?
• How long are request logs kept, and can they be disabled or deleted?
• What contract terms and liability apply when personal data is processed?
• Can personal data be removed from a request before it is sent, for example by anonymization?

How to test a model's quality on your own tasks

Rankings and demos show how a model handles other people's tasks. Your requests, contracts and regulations may behave differently: specific terminology, abbreviations, errors in the source data. That is why testing on your own examples is the main step in choosing.

Typical mistakes: choosing on the basis of one good conversation, testing only easy examples, judging by eye with no criterion, and not planning what a person does when the model makes a mistake. Model errors never disappear completely, so the process needs human review and a log of answers. How to run the test:

• Collect real examples (requests, documents, questions to the knowledge base) and anonymize them if needed.
• Include not only typical cases but also rare ones: empty fields, unusual wording, contradictory data.
• Define what a correct answer looks like before the test, not after.
• Run the same set through several models under the same conditions.
• Ask employees who know the process to rate the results without telling them which model gave which answer.
• Study the errors separately: what kind they are, how dangerous they are, and whether a rule or a human check can catch them.
• Repeat the test when the model version or the vendor's terms change.

Cost and deployment: what to count besides the price per request

The cost of using a model is not only the per-request rate. Count the full cost: calls to the model, which grow with the load; infrastructure; development and integrations; rework when the process changes; and support. Vendor rates change, so plan for recalculation and check your forecast in a pilot with a real stream of requests.

Where the model runs is a separate question. The options are the vendor's service via API, a Russian cloud, or your own infrastructure. The stricter your data requirements, the more often a closed environment is considered. But it needs servers, monitoring and people to maintain them. Hosting inside your own infrastructure is not possible for every model. Ask the vendor whether it is offered and on what terms. Include in your calculation:

• calls to the model at the current and expected load;
• infrastructure: your own servers or a cloud;
• integrations with 1C, CRM and other work systems;
• quality checks and rework when model versions change;
• support and monitoring after launch.

How to avoid depending on a single provider: the model must be replaceable

Provider terms, pricing, availability and the models themselves change. If a solution is tied tightly to one model, any change turns into a rebuild of the whole system. So it makes sense to design it from the start so that the model is a replaceable component.

In practice, this comes down to a few decisions. A separate layer sits between your systems and the model and handles calls to it. Switching providers then means adjusting that layer, not the whole product. Model instructions (prompts), rules and reference data are stored with you, not inside the provider's service. You have a set of test examples that you can run on a new model and compare with the previous result. The model's work is logged, so you can see what changed after a replacement.

Replaceability lets you use different models for different tasks. For example, you can process requests with personal data in a closed environment and give the preparation of anonymized texts to another model. These questions help you check how a contractor understands these principles:

• How does model replacement work, and what will have to be rewritten when you change provider?
• Who owns the prompts, rules, configurations and fine-tuned weights, and what do you receive under the contract?
• What data will you use to check quality, and by what criterion will you accept the result?
• Where will the solution run, and how are the requirements of Federal Law No. 152-FZ taken into account?
• What ongoing costs are included after launch?
• How are human oversight and the log of model responses organized?

How we approach model selection

We work with OpenAI, Claude, Gemini, YandexGPT and GigaChat (Russian AI models). We choose the model to fit the task and the data requirements, not the other way around. We start with a free discovery of one of your processes. In 3–5 business days we prepare a written document with a process map, the boundaries of the solution, an acceptance criterion and an estimate of the scope of work.

If the task turns out not to be a fit for AI, we say so directly: some tasks are cheaper to handle with a written procedure or a ready-made service. If AI is a fit, we build a first prototype on your data, from 3 weeks, and compare models on your examples. We accept the result against a criterion that we put in writing before work begins.

We deploy the solution in your infrastructure or in a Russian cloud, your choice, in line with the requirements of Federal Law No. 152-FZ (the Russian personal data law). After launch, we stay with the solution: monitoring, incident review and improvements when the process or the model terms change. The support arrangement is set out in the contract.