AI-чатбот за 2 недели: что проверить до сметы на 2 млн

Самый опасный AI-чатбот не падает. Он отвечает не тем регламентом, путает старую инструкцию с новой или ведёт клиента в сценарий, который давно закрыли. На демо это выглядит как «поправим базу». В продакшене это тикеты, потерянные заявки и вопрос от юриста: «а кто дал ему доступ к этим данным?»

Мы делаем AI-чатботы и RAG-системы, и почти каждый разговор начинается с фразы: «Хотим бот с GPT. Сколько стоит?» Я бы начинал с другого вопроса: какой один процесс бот должен улучшить за первые две недели?

Если на него нет ясного ответа, большой продакшен считать рано. Сначала нужен короткий PoC.

Бизнес приходит, когда вопросы уже накопились

Запрос на AI-чатбота обычно появляется после вполне приземлённых симптомов. Поддержка отвечает на одно и то же. Сотрудники ищут регламент дольше, чем выполняют задачу. Новичок спрашивает у пяти людей, где отпуск, бонусы и заявка на технику. Клиент пишет вечером, а менеджер видит обращение только утром.

В таких случаях бот нужен не для красивого окна с текстом. Он должен снизить нагрузку на поддержку, ускорить поиск по базе знаний, автоматизировать онбординг, консультировать клиентов и не терять обращения вне рабочего времени.

Звучит просто, пока не начинаешь смотреть на данные. Где лежат актуальные инструкции? Кто отвечает за обновление базы? Какие вопросы бот имеет право закрывать сам, а где обязан передать диалог человеку? Вот это и стоит проверить до большой разработки.

За две недели проверяется один сценарий

У PoC узкая задача: проверить одну гипотезу на рабочем прототипе. Например, «бот отвечает на типовые HR-вопросы», «бот ищет ответы по базе знаний для отдела продаж» или «бот помогает клиенту выбрать товар по каталогу».

За две недели можно подключить ограниченную базу знаний, настроить один-два сценария, прогнать тестовые диалоги и показать команде живой прототип. В хорошем PoC видно, где ответ подтверждён найденными источниками, где контекста недостаточно, а где система должна запросить уточнение или передать диалог оператору.

Это ещё не полноценный продукт с CRM, правами доступа, аналитикой и мониторингом качества. Зато у команды появляется материал для решения: развивать идею, менять сценарий или закрывать гипотезу до того, как она съела бюджет.

Слабое место чаще в базе, а не в модели

На пресейле полезнее просить AI-разработчика назвать риски, чем подтверждать очевидное «GPT прикрутим». Модель можно подключить быстро. Дальше начинаются менее эффектные, зато более дорогие вопросы.

Первое слабое место — база знаний. Если в ней лежат старые инструкции, дубли и документы без владельца, бот будет доставать из неё такой же беспорядок.

Второе — интеграции. На словах нужно «просто подтянуть данные из CRM». На практике выясняется, что CRM, ERP, 1С или Битрикс24 живут по своим правилам, а API не всегда отдаёт данные в удобном виде.

Третье — права доступа. Бот не должен показывать сотруднику документ, который тот не увидел бы в обычной системе. Это надо проектировать, а не добавлять в последний день.

Четвёртое — нетипичные вопросы. Пользователь не обязан спрашивать так, как написано в тестовом сценарии. Он ошибается, сокращает, злится, присылает кусок переписки и ждёт ответа.

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

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

Первым клиентом бота стали мы сами

У нас уже был близкий опыт до нынешней волны AI-проектов. На vc.ru мы рассказывали историю Wombot — конструктора Telegram-ботов, который помогает собирать сценарии, принимать оплату, работать с курсами, поддержкой и онбордингом.

Первыми пользователями стали мы сами. В отдельном материале про онбординг в IT мы писали, как собрали в боте регламенты, графики отпусков, корпоративные бонусы и заявки. Для команды 60+ сотрудников это стало единым входом в типовые HR-вопросы: где посмотреть правила, как оформить отпуск, какие бонусы есть в компании, что нужно новичку на старте.

По внутренней оценке, за год через HR-бота прошли около 50 сотрудников. Он забрал на себя часть типового онбординга и повторяющихся HR-вопросов: это экономило команде примерно 3-4 часа в день, или около 80 часов в месяц. Ещё около 20 часов в месяц удавалось сохранять за счёт того, что регламенты и инструкции были собраны в одном месте.

Ценность бота появляется там, где он помогает с конкретными действиями.Он отвечает, ведёт к следующему шагу, находит документ, а для заявки или статуса заказа запускает отдельную интеграцию с бизнес-системой. Один пересказ базы знаний быстро перестает давать эффект.

На реальном проекте RAG помогал подбирать двери и комплектующие

Один из практических кейсов Qtim — AI-консультант для магазина дверей. Его задача была вести клиента через первичный подбор: определить тип двери, условия установки, размеры, требования к материалу, тепло- и шумоизоляции, внешнему виду и комплектации.

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

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

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

Фактически это был диалоговый подбор: запрос клиента → уточняющие вопросы → требования → поиск по каталогу и связанным данным → проверка правил → рекомендация.

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

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

Продакшен начинается там, где бот получает доступы

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

После PoC к продукту добавляются источники данных, правила извлечения и актуализации контекста, интеграции с CRM, ERP, 1С или Битрикс24, интерфейсы для Telegram, WhatsApp или веба, логирование, аналитика, сценарий передачи оператору, мониторинг качества, роли и доступы, защита данных и регулярное обновление базы знаний. RAG здесь не равен векторному поиску: система может брать контекст из файлов, каталогов, баз данных, сайтов и других источников, если они удобны для конкретного сценария.

Именно здесь становится понятно, что AI-чатбот — это продуктовая система, а не отдельная кнопка «спросить у GPT». Чем больше бот делает внутри бизнеса, тем важнее архитектура вокруг него.

Где в бюджете появляются 1,5–2 млн

В статье про стоимость разработки MVP в 2026 году я уже разбирал, как AI влияет на смету. Чат-бот с GPT, подключённый к базе знаний через RAG, может добавлять к бюджету примерно 1,5–2 млн рублей.

Эта цифра не описывает «цену любого бота». Она про полноценный слой вокруг языковой модели: подготовку данных, поиск по базе, промпты, сценарии, тестирование, логирование, интеграции и контроль качества.

Простую AI-интеграцию разумно начинать с PoC. Полноценный продукт считают после него: когда понятны каналы, объём данных, сложность интеграций, требования к безопасности и ожидаемая нагрузка.

С чего я бы начал вместо сметы

Перед разработкой я бы задал один вопрос: какой один процесс бот должен улучшить за первые две недели?

Сократить типовые обращения в поддержку. Ускорить поиск по внутренним документам. Помочь новичкам пройти онбординг. Ответить клиенту ночью и передать контекст менеджеру утром.

Если процесс измерим, проект проще оценить и довести до результата. Если сценарий уже есть, можно принести его на обсуждение AI-проекта. За первые две недели станет понятно, где у идеи рабочее ядро, а где начинается продакшен с интеграциями, безопасностью и настоящей экономикой.