Разработка ИИ-решений для бизнеса под ключ

Я не берусь за задачу «внедрить нейросеть» без понятного результата. Беру процесс с чёткой метрикой: сколько заявок обрабатывается вручную, сколько минут уходит на разбор обращения, сколько менеджер тратит на сбор отчёта. Модель встраивается туда, где рутина измерима и повторяется — тогда экономия видна в первый месяц, а не в презентации.

Типичные точки: первичная обработка входящих заявок — разбор текста, определение параметров сделки; классификация и маршрутизация обращений в поддержке; автосбор аналитики в понятный текст или голосовое сообщение вместо дашборда, который никто не открывает.

Разбор начинается с процесса, а не с модели. Смотрю, где сейчас теряется время: в переписке, в ручном заполнении CRM, в подготовке отчётов. Дальше — прототип на конкретной задаче с реальными данными клиента, не демо на абстрактном примере.

Всё собираю кодом: обращение к API модели, парсинг и валидация ответа, запись результата в CRM или базу через её API. Готовые конструкторы ботов и no-code сборщики агентов такой контроль не дают — они ограничены шаблонами провайдера и не лезут вглубь ваших данных. Здесь свой код, свои проверки, свои ограничения по стоимости запроса.

Работаю на РФ-совместимых моделях — YandexGPT и GigaChat по API, либо открытые модели на self-hosted контуре, если данные нельзя отдавать во внешний сервис. Выбор зависит от чувствительности данных: для публичных обращений хватает облачного API, для персональных данных клиентов — свой контур внутри инфраструктуры заказчика или в российском облаке.

Это не формальность. 152-ФЗ требует, чтобы персональные данные граждан России обрабатывались на территории страны, и это ограничение снимает с рассмотрения большинство западных LLM-провайдеров для задач с персональными данными.

Отдельный ИИ-инструмент, который живёт сам по себе, бесполезен — решение должно менять данные там, где на них смотрит бизнес. Поэтому агент или ИИ-модуль пишет результат в amoCRM или Bitrix24: ставит тег, меняет этап сделки, создаёт задачу. Событие уходит в сквозную аналитику, и по нему считается конверсия или экономия времени.

Если в проекте уже настроен Roistat, DataLens или своя аналитика на ClickHouse, ИИ-контур подключается к этой же схеме данных, а не создаёт отдельный источник, который потом придётся сверять вручную.

Ко мне часто приходят после пилота, который делали своими силами. Типичная картина: модель отвечает в чате, ответы выглядят разумно, но никуда не записываются. Менеджер всё равно переносит данные руками, времени уходит столько же. Решение начинает приносить деньги в момент, когда оно само меняет данные в CRM или в базе.

Вторая причина — отсутствие замера до старта. Сколько минут уходило на разбор обращения и какая доля заявок обрабатывалась руками, обычно не зафиксировано, поэтому эффект нечем доказать, и проект закрывают при первом сокращении бюджета. Я снимаю базовые цифры до запуска, даже если на это уходит неделя.

Третья — ответ модели принимают как есть. Без схемы и валидации в CRM попадают несуществующие этапы, пустые поля и текст вместо чисел. В моём контуре модель возвращает структуру, ответ проверяется по схеме, и при несовпадении обращение уходит в ручную очередь с пометкой о причине.

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

Под каждый сценарий собираю регрессионный набор: полсотни реальных обращений с проверенным ответом. Перед сменой модели, правкой промпта или обновлением версии API прогоняю набор и сравниваю. Расхождение видно до выката, поэтому переход с GigaChat на YandexGPT или обновление у провайдера проходит контролируемо.

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

Диалоговая часть — приём обращений, квалификация, ответы на типовые вопросы — обычно решается на уровне бота: разработка чат-ботов.