Почему демо AI-бота мало: что нужно для production

Что умеет демо и почему это обманчиво

Демо-бот обычно работает в идеальных условиях:

• Тестовые данные чистые и полные.
• Вопросы задаёт тот, кто знает «правильные» формулировки.
• Нет параллельных запросов, нет нагрузки.
• Никто не пытается сломать бота намеренно или случайно.
• Нет интеграции с реальной CRM, складом, 1С.

Это как тест-драйв на пустой дороге. Машина едет отлично. Но вы не проверили, что будет в пробке, на грунтовке и при минус тридцати.

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

Что ломается при переходе в production

Реальные данные грязнее тестовых

В CRM — дубли контактов. В базе знаний — устаревшие инструкции. В карточках товаров на Ozon — три версии описания. Бот, обученный на чистых данных, начинает галлюцинировать или выдавать противоречивые ответы.

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

Нет обработки крайних случаев

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

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

Нет логов и трассировки

Когда бот ответил неправильно, вам нужно понять: какой запрос пришёл, какой контекст бот собрал, какой prompt ушёл в модель, какой ответ вернулся, какие данные использовались. Без логов вы даже не узнаете, что бот ошибся, — пока клиент не напишет жалобу.

Что делать. Логировать каждый шаг: входящее сообщение, найденный контекст, prompt, ответ модели, финальный ответ пользователю. Хранить минимум 30 дней. Настроить алерты на аномалии: резкий рост отказов, необычно длинные ответы, повторные обращения того же клиента.

Нет разделения прав доступа

Демо-бот обычно имеет доступ ко всему: все клиенты, все заказы, все данные. В production менеджер поддержки видит только своих клиентов, а бот — почему-то всех. Или бот может редактировать записи в CRM, хотя должен только читать.

Что делать. Бот работает с теми же правами, что и роль, которую он заменяет. Если оператор поддержки не может менять цены — бот тоже не может. Реализуется через API-ключи с ограниченными scope или через прокси-слой.

Нет подтверждения критичных действий

Бот квалифицировал лид и сразу перевёл его на «горячий» этап в amoCRM. Бот автоматически ответил на отзыв на WB — и ответ оказался неуместным. Бот изменил статус заказа, хотя клиент просто спрашивал.

Что делать. Определить список действий, которые бот выполняет только после подтверждения человеком. Это и есть human-in-the-loop. Чтение данных, формирование ответов, черновики — автоматически. Изменение статусов, отправка от имени компании, финансовые операции — через очередь на утверждение.

Чек-лист: из демо в production

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

Данные и контекст:

• Аудит источников данных, к которым обращается бот
• Приоритет источников при противоречиях
• Регламент обновления базы знаний

Обработка ошибок:

• Fallback на оператора при низкой уверенности
• Ответ на нераспознанные запросы (не молчание)
• Лимит попыток — после N уточнений передать человеку
• Обработка таймаутов API и недоступности сервисов

Безопасность и права:

• API-ключи с минимальными правами
• Бот не видит данные, которые не нужны для его задачи
• Критичные действия — через подтверждение
• Запрет на передачу персональных данных между контекстами

Мониторинг:

• Логи всех шагов обработки
• Алерты на ошибки и аномалии
• Дашборд: количество обращений, процент fallback, среднее время ответа
• Регулярный ревью выборки диалогов (раз в неделю)

Версионирование:

• Промпты хранятся в репозитории, не захардкожены
• Изменения промптов проходят через тестирование
• Возможность откатить промпт к предыдущей версии

Сколько это стоит по времени

Частая ошибка — считать, что переход из демо в production занимает «пару дней, там же всё работает».

Реалистичные сроки для типового бота поддержки в Telegram, подключённого к CRM:

Демо — это 10–15% работы. Остальное — инженерия надёжности.

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

Типичные ошибки при запуске

«Мы обучим бота на всех наших документах». Больше данных — не значит лучше. Бот, у которого в контексте 200 страниц регламентов, отвечает хуже, чем бот с 20 страницами актуальных инструкций. Качество источников важнее объёма.

«Пользователи сами разберутся». Нет. Если бот не объясняет, что он умеет и чего не умеет, пользователи будут ожидать от него всего — и разочаруются. Нужен onboarding: что бот делает, как к нему обращаться, когда лучше написать человеку.

«Запустим и посмотрим». Без метрик вы не поймёте, работает бот или нет. Определите до запуска: какой процент обращений бот должен закрывать сам? Какое время ответа приемлемо? Сколько fallback-ов на оператора — это норма, а сколько — сигнал проблемы?

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

Когда можно обойтись без полного production-подхода

Не каждый бот требует всех перечисленных мер. Если бот:

• работает только как внутренний инструмент команды (не общается с клиентами);
• отвечает на вопросы по базе знаний без доступа к данным клиентов;
• не выполняет никаких действий, только информирует;
• используется малой группой (до 5–10 человек), которая понимает ограничения, —

можно запускать проще: логи + fallback + еженедельный ревью. Но как только бот общается с вашими клиентами или меняет данные — полная подготовка обязательна.

FAQ

Сколько стоит перевести демо-бота в production?

Зависит от сложности интеграций и количества сценариев. Для типового бота поддержки в Telegram с одной CRM — от 2 до 6 недель работы. Стоимость разработки кратно меньше стоимости репутационного ущерба от бота, который работает без контроля.

Можно ли сначала запустить демо на реальных клиентах и доработать по ходу?

Можно, если запустить в shadow mode: бот формирует ответы, но отправляет их не клиенту, а оператору. Оператор решает — отправить ответ бота или написать свой. Через 1–2 недели у вас будет статистика качества и карта проблемных случаев.

Какие метрики отслеживать после запуска?

Минимальный набор: процент обращений, закрытых без оператора; среднее время первого ответа; количество fallback на человека; количество повторных обращений; оценка удовлетворённости, если есть.

Что такое human-in-the-loop и всегда ли он нужен?

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

Что делать, если бот начал отвечать неправильно после обновления модели?

Фиксировать версию модели в конфигурации. Тестировать новую версию на сохранённых тестовых диалогах перед переключением. Иметь возможность откатить за минуту. Это называется version pinning, и без него любое обновление — лотерея.

Можно ли сделать production-бота на no-code платформе?

Для простых сценариев (FAQ, маршрутизация обращений) — да. Для интеграций с CRM, маркетплейсами, сложной логикой квалификации — no-code быстро упирается в ограничения. Как понять границу — мы разбирали в статье про автоматизацию процессов.

Чем production-бот отличается от AI-агента?

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

Что дальше

Если у вас есть демо-бот или идея автоматизации — и вы хотите понять, что нужно, чтобы это надёжно работало на реальных клиентах, — напишите Дмитрию в Telegram @dmkosik. Разберём ваш процесс, покажем, где нужен контроль, и оценим путь до production.

Или опишите задачу на paramiko.ru — сделаем диагностику и предложим архитектуру.