Внедрение ИИ в бизнес: какие задачи закрывать и как посчитать стоимость

Внедрение ИИ в бизнес: с чего начать и что не делать на старте

Когда к нам приходят с запросом «хотим внедрить ИИ», первое, что мы делаем — не выбираем модель и не считаем токены, а отсекаем сценарии, где ИИ не нужен. В практике руководителей e-commerce и интеграционных проектов на Битрикс 24 + 1С это происходит регулярно: задача либо решается обычным скриптом, либо данных для неё недостаточно, либо результат невозможно измерить. То, что остаётся после такого фильтра, — сценарии, где ИИ реально экономит время сотрудника или закрывает то, что раньше делалось руками и с ошибками.

Старт внедрения — это не выбор модели и не разговор с вендором. Это выбор одной задачи с измеримым результатом. «Ускорить обработку заявок» — не задача. «Сократить время менеджера на классификацию входящего обращения с 4 минут до 30 секунд» — задача. Разница принципиальная: во втором случае вы через две недели точно знаете, сработало или нет, и можете посчитать, окупается ли подписка на API.

Именно поэтому первая секция этой статьи — про процесс, а не про технологии: модель вы выберете позже, и она, скорее всего, будет меняться по ходу проекта.

Четыре шага, с которых мы начинаем любой пилот по ИИ:

1. Зафиксировать одну задачу и одну метрику успеха — время обработки, доля ошибок, стоимость операции.
2. Собрать 50–100 реальных примеров входов из вашей системы: заявок, писем, карточек товаров, обращений.
3. Выбрать вендора по требованиям к данным — где хранятся, кому передаются, есть ли договор поручения на обработку.
4. Запустить пилот на одной ветке процесса, не трогая остальные сценарии и не меняя регламенты команды.

Почему старт с инфраструктуры и выбора модели — ошибка? Потому что вы начинаете платить за токены и интеграцию до того, как поняли, какой процесс вообще нужно менять. Мы видели проекты, где команда месяц настраивала доступ к YandexGPT или GigaChat, а на этапе пилота выяснялось, что 80% обращений — это три типовых вопроса, которые закрываются обычным FAQ, а не генеративной моделью. Сначала процесс и данные, потом API.

ТЗ на пилот мы формулируем так, чтобы он закрывался за две недели. Внутри — три обязательных блока: входные данные и их источник (какая таблица, какое событие, какой вебхук), ожидаемый выход (текст, классификация, готовое поле в CRM) и метрика приёмки (например, «на 50 тестовых примерах модель даёт корректную классификацию не реже, чем в 45 случаях»). Если хотя бы один блок не заполняется — пилот рано запускать, вернитесь к шагу с примерами.

По ролям в команде на старте достаточно трёх человек: владелец процесса со стороны бизнеса (он принимает метрику и результат), разработчик интеграции (он пишет обвязку к Bitrix 24 или 1С и подключает API) и аналитик данных — хотя бы на полставки, чтобы собрать тестовую выборку и разметить её. Внедрять модель без человека, который отвечает за качество входных примеров, — самая частая причина, по которой пилот «не взлетает»: модель отвечает правильно, но на не тех данных, которые реально приходят в систему.

Какие задачи закрывает ИИ в бизнес-процессах: каталог сценариев

Самый частый запрос на эту тему звучит так: «Покажите, что конкретно ИИ может у нас сделать — не абстрактно, а по шагам». Мы собрали сценарии, которые чаще всего реализуем в e-commerce и 1С-интеграциях, и разложили каждый на три части: что подаём на вход, что получаем на выходе и куда это встраивается в Bitrix. Такой каталог удобно использовать как меню — выбрать один пункт, посчитать бюджет и запустить пилот, не пытаясь сразу закрыть всё.

В подборку попали шесть сценариев, которые дают заметный эффект при умеренной сложности внедрения:

• Генерация и обогащение карточек товаров — описания, характеристики, SEO-поля из сырых данных 1С.
• Классификация обращений — определение темы и приоритета тикета до того, как его откроет оператор.
• Ответы на типовые вопросы — черновики ответов по базе знаний и истории переписок.
• Извлечение данных из документов — счета, накладные, сканы в структурированные поля CRM.
• Суммаризация переписки — краткое резюме длинного треда для менеджера или руководителя.
• Ассистент менеджера — подсказки, следующие шаги, напоминания о договорённостях из звонка.

Ниже — матрица, по которой удобно сопоставить сценарий с точкой встраивания и типом модели. Дальше разберём два самых востребованных сценария подробно.

Генерация описаний товаров при импорте из 1С

Классическая ситуация: в 1С лежит номенклатура с артикулами, единицами измерения и парой технических полей, а на сайте нужен человеческий текст — описание, преимущества, мета-теги. Менеджеры физически не успевают заполнять это руками, особенно когда каталог измеряется десятками тысяч SKU. ИИ здесь работает как генератор черновика на основе структурированных полей, а не как источник фактов: он не придумывает характеристики, а переупаковывает то, что уже есть в 1С, в связный текст.

Встраиваем это в цепочку обмена: после парсинга XML и обновления элемента вызываем модель с промптом, куда подставляем название, бренд, категорию и ключевые свойства. Результат пишем в свойство инфоблока — например, DESCRIPTION_AI, — не затирая то, что уже заполнено вручную. Флаг «описание создано ИИ» храним отдельно, чтобы при повторном импорте не генерировать заново.

Что стоит предусмотреть сразу: батчинг запросов (по 20–50 товаров в одном вызове, чтобы не платить за каждый отдельно), кэш по хэшу входных полей и ручную модерацию первой партии. Последнее — не формальность: модели любят добавлять маркетинговые обороты вроде «идеальный выбор для настоящих ценителей», которые потом приходится вычищать.

Классификация и маршрутизация обращений в Битрикс24

Второй по частоте сценарий — разгрузить первую линию. Обращение приходит в CRM, и вместо того чтобы вручную разбирать, к какой категории оно относится, мы пропускаем текст через модель: она возвращает категорию, приоритет и предполагаемого ответственного. Дальше бизнес-процесс Битрикс24 раскладывает тикет по нужной воронке или отделу.

Технически это делается через ContactCompanyTable и новый API CRM: после создания лида или тикета запускаем робота, который отправляет текст в модель и получает структурированный JSON. Вход — тема и тело обращения, выход — метки вроде category=return, priority=high. Модель здесь нужна лёгкая и быстрая: классификация не требует больших контекстов, а задержка важнее качества формулировок.

Ключевое место для настройки — порог уверенности. Если модель не уверена, лучше оставить тикет в общей очереди, чем ошибочно отправить его в отдел возвратов. Мы обычно ставим порог и логируем все «пограничные» случаи: через пару недель по логам видно, каких категорий не хватает в таксономии, и промпт правится точно, а не наугад.

Внедрение нейросетей: YandexGPT, GigaChat или OpenAI — что выбрать

Выбор вендора нейросети — это не соревнование «кто умнее». На практике решает не качество ответа на демо, а три вопроса: проходит ли вендор по требованиям к обработке данных, можно ли его легально оплатить с расчётного счёта российской компании и как он ложится в вашу интеграцию — Bitrix 24, 1С или собственный бэкенд. Мы видели проекты, где команда неделю сравнивала бенчмарки, а потом выяснилось, что для выбранного вендора нет удобной схемы оплаты для юрлица. Весь выбор пришлось переигрывать.

Чаще всего к нам приходят с тремя вариантами: YandexGPT (Yandex AI Studio), GigaChat (Sber) и OpenAI. Других на рынке больше, но именно по этой тройке задают вопросы про доступ, оплату и данные. Ниже — сравнение по ключевым для внедрения параметрам и разбор, на каких проектах какой вендор выигрывает.

Когда выбираем YandexGPT и что нужно для доступа

YandexGPT берём, когда проект уже живёт в российском облаке или когда заказчик хочет платить по счёту с прозрачной тарификацией по токенам. Чтобы вызвать модель из кода, нужны три вещи: каталог в Yandex Cloud, сервисный аккаунт с ролью ai.languageModels.user и API-ключ. Это стандартная схема доступа через облако. Она же и главный барьер: без настроенного каталога и роли запрос не уйдёт, даже если ключ на руках.

Тарифицируется Yandex AI Studio по токенам, причём цена зависит от режима работы и типа потребления: отдельно считаются входящие токены запроса, отдельно — классификация текста, и для неё ставка привязана к конкретной модели классификации. Подсчёт токенов до отправки запроса бесплатен. Удобно, чтобы прикинуть бюджет до запуска. По данным сообщества, синхронный режим для Lite и Pro различается по цене в разы, так что для массовых операций вроде тегирования каталога логично начинать с Lite.

Отдельно стоит помнить про fine-tuning: дообучение тарифицируется отдельно от инференса, и адаптированная модель в работе дороже базовой. Если задача решается хорошим промптом, дообучение на старте обычно не нужно.

Когда выбираем GigaChat API

GigaChat выигрывает там, где нужен диалоговый ассистент и работа с документами, а заказчик хочет зафиксировать бюджет пакетом, а не платить по факту каждого токена. Для юрлиц доступен тариф с моделью GigaChat или GigaChat-2 и пакетом на 50 000 000 токенов GigaChat Pro; пакет действует 12 месяцев со дня оплаты, цены в рублях включая НДС. Фиксированный пакет удобен для планирования: вы заранее знаете верхнюю границу расходов на год.

Авторизация в GigaChat API двухэтапная: сначала получаете Authorization Key, потом обмениваете его на токен доступа. Кода чуть больше, чем у OpenAI-совместимых схем, но для серверной интеграции на Bitrix или в 1С это не проблема. Токен кэшируется, обновляется по истечении.

По нашему опыту, GigaChat хорошо ложится в сценарии, где ассистент общается с сотрудником или клиентом на русском и работает с внутренними регламентами. Для чистого пакетного тегирования каталога он обычно избыточен, там проще взять модель полегче.

Сколько стоит внедрение ИИ: считаем токены, а не запросы

Распространённая ошибка в бюджете — считать «стоимость запроса». Модель не берёт деньги за факт обращения: и YandexGPT, и GigaChat, и OpenAI тарифицируют токены, причём входные и выходные — по разным ставкам. Вход — это то, что вы отправили в модель (промпт, системная инструкция, фрагмент каталога или документа), выход — то, что модель сгенерировала в ответ. Оба потока оплачиваются отдельно, и на практике вход почти всегда тяжелее выхода: в промпт уезжает контекст, инструкции и данные, а ответ модели по объёму скромнее.

Поэтому бюджет внедрения считается не «сколько у нас запросов в день», а «сколько токенов уходит на одну задачу × сколько раз в месяц задача выполняется». Разница принципиальная. Один вызов с огромным контекстом может стоить дороже сотни коротких реплик в чате. У нас в проектах с большим каталогом именно частота обновлений и объём входного контекста определяют месячный расход, а не число пользователей, которые «потыкали в бота».

Ниже разберём, как из объёма задач вывести цифру и где прячутся скрытые блоки, о которых обычно узнают уже по факту счёта.

Как считать. Грубая прикидка: токен ≈ 4 символа или примерно 0.75 слова на английском. Для русского пропорция другая — кириллица «дороже»: символов на токен меньше, поэтому один и тот же по смыслу текст на русском даст больше токенов, чем на английском. Закладывайте запас, а не считайте по английской формуле.

Возьмём типовой сценарий: каталог на 30 000 SKU, ИИ генерирует или обновляет описание карточки. На одну карточку уходит примерно 600 входных токенов (название, характеристики, категория, инструкция для модели) и 300 выходных (готовый текст). Умножаем на частоту обновлений: если карточки перегенерируются раз в месяц целиком — это 30 000 × 600 = 18 млн входных и 9 млн выходных токенов. Если обновляется только 10% каталога — делите на десять. Тот же принцип для любой задачи: определяете объём контекста на единицу работы и умножаете на реальное число срабатываний, а не на «количество сотрудников».

Что читатель захочет поменять под себя: число SKU, долю обновляемых карточек, размер промпта и ставки вендора. Ставки держите в конфиге, а не в коде — их придётся обновлять, тарифы меняются. Скрипт ниже считает месячный расход по каталогу и частоте обновлений.

<?php
// Калькулятор месячного расхода токенов. Запускать из CLI или из агента.
// Ставки подставьте свои — они меняются, держите их в конфиге, не в коде.

$config = [
    'sku_total'         => 30000,   // всего карточек в каталоге
    'update_share'      => 0.10,    // доля каталога, обновляемая за месяц (0.10 = 10%)
    'runs_per_month'    => 1,       // сколько раз в месяц прогоняем обновление
    'tokens_in_per_sku' => 600,     // входные токены на одну карточку
    'tokens_out_per_sku'=> 300,     // выходные токены на одну карточку
    // ставки за 1000 токенов, в рублях — замените на актуальные для вашего вендора
    'price_in_per_1k'   => 0.20,
    'price_out_per_1k'  => 0.20,
];

$skuProcessed = (int)round($config['sku_total'] * $config['update_share'] * $config['runs_per_month']);

$tokensIn  = $skuProcessed * $config['tokens_in_per_sku'];
$tokensOut = $skuProcessed * $config['tokens_out_per_sku'];

$costIn  = ($tokensIn  / 1000) * $config['price_in_per_1k'];
$costOut = ($tokensOut / 1000) * $config['price_out_per_1k'];

printf("Карточек обработано за месяц: %d\n", $skuProcessed);
printf("Входных токенов:  %s\n", number_format($tokensIn, 0, '.', ' '));
printf("Выходных токенов: %s\n", number_format($tokensOut, 0, '.', ' '));
printf("Стоимость входа:  %.2f руб.\n", $costIn);
printf("Стоимость выхода: %.2f руб.\n", $costOut);
printf("Итого за месяц:   %.2f руб.\n", $costIn + $costOut);

Скрытые блоки: web search и File search в OpenAI

Отдельная строка бюджета, которую легко пропустить, — инструменты поиска. У OpenAI web search и File search тарифицируются не как обычный текст промпта, а отдельными блоками. Для gpt-4o-mini и gpt-4.1-mini с non-preview web search tool токены поискового контента считаются как фиксированный блок 8 000 входных токенов за вызов. То есть даже короткий вопрос в три слова, если под капотом сработал веб-поиск, потянет за собой восемь тысяч входных токенов — это заметно на фоне обычного промпта и особенно бьёт по сценариям с частыми короткими запросами.

Второй нюанс: File search tool call тарифицируется только в Responses API. Если вы строите сценарий на другом эндпоинте, этой строки в счёте не будет — но и самого поиска по файлам тоже. Планируя бюджет, отдельно выпишите, какие инструменты включены в ваш сценарий, и посчитайте их как отдельные блоки, а не как «ещё немного токенов промпта».

Как внедрить ИИ в компанию: подключение к Bitrix 24 и 1С

Техническая часть внедрения ИИ в Bitrix 24 и 1С сводится к трём вопросам: где живёт вызов модели, как он попадает в бизнес-процессы и как при этом не сломать обмен с 1С. У нас на проектах типовой путь — свой модуль в /local, обработчики на событиях и очередь на отправку запросов. Никаких правок ядра, никаких патчей в bitrix/modules — только штатные точки расширения. Так обновления платформы не превращаются в археологию, а интеграция переживает пару мажорных релизов без переписывания.

Второй принцип — асинхронность по умолчанию. Модель отвечает за секунды, а иногда и за десятки секунд. Если вызывать её прямо в обработчике события импорта или создания лида, пользователь будет ждать ответа, а на массовых операциях вы рискуете получить таймаут. Поэтому запросы складываем в очередь, а разбирает её отдельный воркер. Об этом ниже — в шаге 4 и в разборе класса-клиента.

Третий момент — изоляция от обмена с 1С. Событие импорта стреляет внутри сессии обмена, и любое исключение в обработчике может откатить всю партию. Наш код должен быть максимально «тихим»: логируем, ставим в очередь, выходим. Разберём по шагам.

1. Завести сервисный аккаунт и API-ключ у выбранного вендора, положить ключ в .settings.php, а не в код. Для YandexGPT это каталог в Yandex Cloud, сервисный аккаунт с ролью ai.languageModels.user и API-ключ. Никогда не коммитим ключ в репозиторий — храним в .settings.php рядом с остальными секретами проекта.
2. Создать модуль в /local/modules с классом-клиентом, который инкапсулирует HTTP-вызов и ретраи. Модуль даёт namespace, автозагрузку и место для конфигурации. Клиент отвечает за авторизацию, формирование запроса, разбор ответа и повторные попытки при сетевых сбоях.
3. Повесить обработчик на событие импорта или на создание лида через OnAfterIBlockElementUpdate / OnAfterCrmLeadAdd. Регистрируем через EventManager — это нативный D7-API. Обработчик не должен делать ничего тяжёлого: только собрать данные и положить задачу в очередь.
4. Отправлять запросы в очередь (агент или собственный worker), чтобы не блокировать пользовательский запрос. Для небольших объёмов хватит агента с задержкой, для каталогов на десятки тысяч позиций — собственный воркер на cron, обрабатывающий порции.

Ниже — рабочий класс-клиент для вызова YandexGPT из модуля. Авторизация через API-ключ сервисного аккаунта, запрос к модели, обработка ошибок и ретраи.

Автоматизация с помощью ИИ: как встроить в бизнес-процессы Битрикс24

Типичный сценарий: у клиента есть робот на стадии сделки, который должен сгенерировать коммерческое предложение или ответить на вопрос клиента — и вся команда ищет, куда прикрутить вызов модели. В Битрикс24 для этого уже есть готовые точки входа, не нужно изобретать отдельную интеграцию с нуля. Бизнес-процессы и роботы дают визуальный сценарий, REST API и вебхуки — программный доступ к данным CRM, а модель подключается как внешний сервис, который вы вызываете из своего обработчика.

Схема встраивания получается такой: робот или бизнес-процесс триггерит событие — обработчик собирает нужные поля из сделки, лида или задачи — отправляет запрос в модель — результат записывается обратно в поле или в комментарий. Ключевой момент: вызов модели живёт не внутри Битрикс24, а в отдельном сервисе, к которому Битрикс24 обращается по HTTP. Это даёт несколько плюсов сразу — ключи API не хранятся в коробке, можно менять модель без правок в CRM, а логи и ретраи живут в одном месте.

Связка с входящим вебхуком позволяет закрыть обратный сценарий: внешняя система (например, ваш сервис-обёртка над нейросетью) сама дёргает Битрикс24 и обновляет данные. Комбинируется это с роботами на стадиях — робот вызывает внешний URL, сервис отвечает, поле сделки обновляется. Дальше разберём, как это выглядит в коде и какие есть нюансы.

В Битрикс24 нам доступны входящий и исходящий вебхуки — это самый быстрый способ отладки интеграции без полноценного приложения. Входящий позволяет внешнему сервису обращаться к REST API портала, исходящий — наоборот, портал дёргает ваш endpoint. Для быстрых проверок есть блок «Генератор запросов»: прямо из интерфейса выбираешь метод из списка, настраиваешь параметры и выполняешь запрос. Удобно, когда нужно понять, какие поля реально приходят в ответе, и не писать ради этого отдельный скрипт.

Но в продакшене мы всё равно выносим вызов модели в отдельный сервис. Причины простые: ключи к YandexGPT, GigaChat или OpenAI не должны лежать в настройках коробки, а обработка ошибок, ретраи и таймауты требуют нормального кода, а не визуального робота. Робот в этом случае становится тонким триггером — он только дёргает ваш сервис и передаёт идентификатор сущности. Вся логика (сбор промпта, вызов модели, парсинг ответа, запись результата обратно через REST) живёт в сервисе.

Такой подход заодно решает вопрос с версиями: если завтра вы меняете модель или добавляете второй провайдер, в Битрикс24 ничего править не нужно. И ещё один плюс — одна кодовая база обслуживает и облако, и коробку, потому что обращения идут по одному и тому же REST API.

<?php
// handler.php — обработчик робота Битрикс24.
// Робот дёргает этот скрипт, передавая ID сделки.
// Скрипт собирает текст, вызывает модель и пишет результат обратно в поле.

use Bitrix\Main\Web\HttpClient;

require_once $_SERVER['DOCUMENT_ROOT'] . '/bitrix/modules/main/include/prolog_before.php';

$dealId   = (int)($_REQUEST['deal_id'] ?? 0);
$webhook  = 'https://your-portal.bitrix24.ru/rest/1/xxxxxxxxxxxxxxxx/'; // замените на свой входящий вебхук
$apiKey   = getenv('LLM_API_KEY'); // ключ модели — только из окружения, не из кода

if ($dealId <= 0) {
    http_response_code(400);
    echo json_encode(['error' => 'deal_id required']);
    exit;
}

$http = new HttpClient(['socketTimeout' => 30]);

// 1. Забираем сделку из CRM
$dealResp = $http->get($webhook . 'crm.deal.get?ID=' . $dealId);
$deal     = json_decode($dealResp, true)['result'] ?? [];

$sourceText = trim(($deal['TITLE'] ?? '') . "\n" . ($deal['COMMENTS'] ?? ''));
if ($sourceText === '') {
    echo json_encode(['error' => 'empty deal text']);
    exit;
}

// 2. Вызываем модель (пример — YandexGPT; endpoint и modelUri уточните в документации провайдера)
$prompt = "Сформулируй краткое резюме сделки для менеджера:\n\n" . $sourceText;

$llm = new HttpClient(['socketTimeout' => 60]);
$llm->setHeader('Authorization', 'Api-Key ' . $apiKey);
$llm->setHeader(

Коннекторы к внешним мессенджерам через imconnector

Отдельная история — если ИИ должен отвечать клиенту не в карточке CRM, а в мессенджере: WhatsApp, Telegram, свой чат. Здесь в Битрикс24 работает модуль imconnector — набор классов и событий для подключения собственного типа коннектора. Схема та же: сообщение приходит в ваш коннектор, уходит в сервис с моделью, ответ возвращается в чат через API.

Что важно понимать при разработке коннектора: регистрация типа коннектора и обработка входящих сообщений — это два разных потока, и их лучше не смешивать в одном обработчике. Первый делается один раз при установке решения, второй работает в рантайме на каждое сообщение. Детали подключения собственного типа коннекторов разобраны в курсе «Администратор сервиса Битрикс24 (коробочная версия)» — если планируете поддерживать несколько каналов, стоит начать именно оттуда.

По опыту, самое узкое место здесь не вызов модели, а сопоставление диалогов: у мессенджера свой идентификатор чата, у Битрикс24 — свой. Пока это сопоставление не отлажено, ИИ будет отвечать «не в тот чат». Поэтому мы всегда начинаем с простого тестового канала, где легко проверить соответствие, и только потом добавляем остальные.

152-ФЗ и персональные данные: что учесть до первого запроса в модель

Типичный сценарий: техлид подключает YandexGPT к бизнес-процессу Битрикс24, тестирует на реальной сделке — и в промпт уходит переписка менеджера с клиентом, номер телефона, email. Всё работает, ответ хороший, задачу закрыли. А через месяц выясняется, что любая отправка этих данных во внешний сервис — уже обработка персональных данных по 152-ФЗ, и контур под неё никто не проектировал.

По определению из закона обработка ПДн — это любое действие с ними: сбор, запись, систематизация, накопление, хранение, уточнение, извлечение, использование. Передача в API модели попадает сюда целиком. То есть вопрос не «надо ли оформлять», а «что именно мы уже делаем и как это привести в порядок». У нас в практике это стабильно всплывает на этапе, когда пилот уже работает и останавливать его никто не хочет. Поэтому контур ПДн разумнее заложить до первого запроса в модель — тогда он стоит несколько дней проектирования, а не переделки боевого сценария.

Что закон требует в общем виде и какие пробелы мы обычно закрываем у клиентов, когда приходим на аудит уже работающего ИИ-сценария:

• Отражены не все цели обработки ПДн — в документах есть «обработка обращений», но нет «передача в сервис генерации ответа».
• Нет сведений об обработке ПДн пользователей сайта — в том числе когда данные собираются метриками и аналитикой, а потом попадают в промпт.
• По каждой цели не определены категории ПДн, категории субъектов, правовые основания, перечень действий и способов обработки.
• В политике указано «распространение» или «обезличивание» ПДн, хотя фактически данные передаются во внешний API без обезличивания.

Последний пункт встречается чаще остальных. Формально документ есть, но описывает он не тот процесс, который реально работает в коде. При проверке это видно сразу: сверили заявленные способы обработки с логами интеграции — и расхождение налицо.

Набор мер, который мы закладываем в проект до подключения модели:

• Обезличивать данные перед отправкой — вырезать ФИО, телефоны, email из промпта, если они не нужны для ответа.
• Маскировать поля на уровне сборки запроса — маска применяется в коде, а не «на совесть» менеджера.
• Логировать вызовы модели без ПДн — хранить промпт и ответ в обезличенном виде, отдельно от исходных данных.
• Выделять отдельный контур для чувствительных данных — если без ПДн ответ невозможен, это уже другой сценарий с другими основаниями.
• Фиксировать цели обработки в документах — включая цель «передача в сервис генерации» с указанием конкретного вендора.

Самые частые ошибки при внедрении ИИ и как их избежать

Есть набор грабель, на которые наступают почти все, кто впервые встраивает модель в рабочий контур. Мы собрали их по своему опыту и по разборам в сообществе — не чтобы напугать, а чтобы вы прошли эти места осознанно.

Старт без метрики — первая и самая дорогая. Команда запускает генерацию описаний товаров, а через месяц выясняется, что никто не зафиксировал базовую конверсию, и доказать эффект нечем. Метрику фиксируют до первого запроса в модель, а не после.

Вторая группа ошибок — техническая. Синхронный вызов модели прямо в пользовательском запросе подвешивает страницу на секунды, а при таймауте вендора роняет её целиком. Хардкод API-ключа в коде и отсутствие лимитов на расход — классика, которая всплывает на второй неделе продакшна. И отдельно — попытка заменить ИИ там, где нужен обычный код: сортировка, валидация, арифметика по прайсу.

Читайте также: Бизнес-процессы в Битрикс24: создание, запуск и автоматизация через дизайнер и REST API, ИИ-ассистент для бизнеса: как мы внедряем нейросетевых помощников в Bitrix и 1С.

Подробнее об услуге: внедрение и доработка Битрикс24 CRM.