«Облачный или коробочный бот» — этот вопрос всплывает почти на каждом первом созвоне с корпоративным заказчиком. На практике речь идёт не о двух разных продуктах, а о двух режимах размещения одной и той же кодовой базы. Разберём, в каких ситуациях окупается каждый вариант, как считать TCO на горизонте 1, 3 и 5 лет, и какие требования регуляторов (152-ФЗ, 187-ФЗ, ФСТЭК) влияют на выбор.
Материал ориентирован на тех-лидов, CTO и безопасников, которые принимают решение о модели деплоя бота в MAX-мессенджере (VK Tech) для среднего и крупного бизнеса.
Что значит «облачный» и «коробочный» в контексте MAX
Облачный бот (cloud, SaaS-like) — приложение, которое разворачивается на внешней инфраструктуре провайдера. В российской реальности это Yandex Cloud, VK Cloud, Selectel, Timeweb, Cloud.ru (бывший SberCloud) или MTS Cloud. Заказчик получает работающий сервис; команда эксплуатации — на стороне студии или провайдера. Финансовая модель — OpEx: ежемесячная подписка, оплата по факту потребления.
Коробочный (on-premise) бот — поставка кодовой базы и Docker-образов в инфраструктуру заказчика: его собственный дата-центр, частное облако (VMware, OpenStack, Proxmox) или закрытый КИИ-сегмент сети. Развёртывание — на серверах клиента, доступ снаружи — только через настроенные шлюзы. Финансовая модель — CapEx (закупка железа, лицензий) плюс OpEx (DevOps, поддержка, электричество, охлаждение).
Логика бота при этом одна и та же: webhook от MAX, FSM, Postgres, Redis, очередь, интеграции с CRM/ERP, иногда AI-провайдер. Меняется только периметр и операционная модель.
Когда выгодно облако
Облако — дефолтный выбор для малого, среднего бизнеса и для большинства маркетинговых, B2C и не-критичных B2B-сценариев. Признаки, что вам подходит облачная модель:
- Скорость запуска критична. Time-to-market — недели, а не месяцы.
- Нагрузка непредсказуема или сильно варьируется. Маркетинговые кампании, сезонные пики, рассылки.
- Нет собственной DevOps-команды. Не хотите держать админа и сетевика только ради бота.
- Данные не относятся к чувствительным категориям. Лиды, заявки, FAQ, заказы — обычные ПДн без специальных категорий.
- Бюджет ограничен на старте. CapEx в железо — неподъёмен или нерационален.
Стоимостно: VPS на 4 ГБ ОЗУ у российского провайдера обходится в 600–1500 ₽/мес и тянет бота с нагрузкой до 50 тысяч диалогов в день. Managed-Postgres плюс Redis добавляют ещё 1500–4000 ₽/мес. Итого инфраструктура среднего бота — 3000–8000 ₽/мес. Для крупного бота с RAG, очередями и шардированием — 30 000–80 000 ₽/мес.
Когда нужна коробка
On-premise становится оправданным, если в проект приходит хотя бы один из факторов:
- Чувствительные данные. Медицина (специальные категории ПДн уровня здоровья), банкинг (банковская тайна), госсектор, КИИ — требования к локализации, аудиту и контролируемому периметру.
- Корпоративный security-периметр. Бот ходит в 1С, ERP, внутренние CRM, MES — доступ к которым извне закрыт фаерволом и недоступен через интернет.
- Внутренняя эксплуатация. У клиента есть DevOps-команда, GitLab/Jenkins, Kubernetes-платформа и стандарты CI/CD — встраиваться в них дешевле, чем тащить отдельную внешнюю инфраструктуру.
- Регуляторные требования. ФСТЭК-аттестация ИСПДн, требования 187-ФЗ для объектов КИИ, отраслевые регламенты (ЦБ для банков, Минздрав для клиник).
- Военный/оборонный сегмент. Полностью закрытые сети, отсутствие внешнего интернета.
Коробка стоит дороже на старте — закладываются работы по интеграции, настройке резервного копирования, документации для службы безопасности, прохождению пилотного аудита. Срок запуска — 4–8 недель против 2–3 в облаке.
Сравнительная таблица
| Критерий | Облако | Коробка (on-prem) |
|---|---|---|
| Время до запуска | 2–4 недели | 6–16 недель |
| Контроль над данными | Shared responsibility | Полный |
| Стоимость старта | Низкая (OpEx) | Высокая (CapEx) |
| Стоимость владения 1 год | Меньше | Больше |
| Стоимость владения 5 лет | Больше | Меньше (для крупного бизнеса) |
| Масштабирование | Автоматическое | Через закупку железа |
| Обновления | Push, минуты | Согласование + развёртывание |
| Команда эксплуатации | Backend-разработчик | + DevOps + ИБ + сетевик |
| Требования к ИТ-инфраструктуре | Минимальные | Серьёзные |
| 152-ФЗ | Закрывается договором-поручением | Априори в контуре оператора |
| 187-ФЗ (КИИ) | Ограниченно подходит | Основной вариант |
| ФСТЭК-аттестация | Требует сертифицированного облака | Возможна в полном объёме |
| Vendor lock | Высокий | Минимальный |
Безопасность: shared responsibility vs полный контроль
В облаке действует модель shared responsibility. Провайдер отвечает за физическую безопасность ЦОДа, сетевую инфраструктуру, гипервизор и патчи на managed-сервисах. Заказчик — за конфигурацию виртуальных машин, доступы, шифрование данных в приложении, бэкапы и аудит.
В on-premise все слои — на стороне заказчика: от физического доступа в серверную и охлаждения до патчей ОС и резервного копирования. Это даёт полный контроль, но требует зрелой команды ИБ.
Облачная модель уязвима к: компрометации API-ключей провайдера, ошибкам конфигурации (открытые S3-бакеты, неограниченные секьюрити-группы), общим инцидентам провайдера. On-premise уязвима к: внутренним угрозам, недостаточному финансированию ИБ-команды, устаревшим патчам, единой точке отказа без должного DR.
Соответствие 152-ФЗ
Оба варианта совместимы с 152-ФЗ, но через разные механизмы.
- Облако: оператор персональных данных — заказчик; провайдер — обработчик по поручению. Заключается договор-поручение на обработку ПДн (ст. 6 п. 3, ст. 18.1 152-ФЗ). Обязательное условие — серверы провайдера на территории РФ (ст. 18 ч. 5). Российские провайдеры по умолчанию хостят в РФ; при использовании Yandex Cloud, VK Cloud, Selectel, Cloud.ru, MTS Cloud — требование локализации закрывается.
- On-premise: заказчик — единственный оператор и единственный обработчик; договоров-поручений не требуется. ИСПДн полностью внутри его контура.
Если есть специальные категории ПДн (здоровье, биометрия, политические/религиозные взгляды) — практика смещается в сторону коробки или сертифицированного облака с аттестацией.
Соответствие 187-ФЗ (КИИ)
Для значимых объектов критической информационной инфраструктуры (КИИ) — банки, телеком, энергетика, транспорт, нефтегаз, госсектор, здравоохранение — действует 187-ФЗ и приказы ФСТЭК (239, 235). Бот, который интегрирован в значимый объект КИИ, наследует требования к нему.
В этом случае on-premise — основной вариант: размещение в аттестованном сегменте, использование сертифицированных СЗИ (Secret Net, ViPNet, Континент), регулярные аудиты, формализованные процедуры реагирования на инциденты. Облако возможно только при наличии у провайдера соответствующего аттестата (например, защищённый сегмент Yandex Cloud или Cloud.ru).
Ценообразование: реальные цифры
Облачная модель (pay-per-use, OpEx):
| Размер бота | Инфраструктура/мес | Поддержка/мес |
|---|---|---|
| Малый (до 5 тыс. диалогов/день) | 3 000–8 000 ₽ | 8 000–25 000 ₽ |
| Средний (до 50 тыс./день) | 15 000–40 000 ₽ | 25 000–80 000 ₽ |
| Крупный (до 500 тыс./день) | 80 000–250 000 ₽ | 80 000–250 000 ₽ |
On-premise (CapEx + OpEx):
| Статья | Сумма (разово / в месяц) |
|---|---|
| Серверы (2 узла + резерв) | 500 000 – 5 000 000 ₽ разово |
| Лицензии ОС, СУБД, СЗИ | 200 000 – 2 000 000 ₽ разово |
| Внедрение, документация, аудит | 200 000 – 800 000 ₽ разово |
| DevOps + ИБ + поддержка | 50 000 – 500 000 ₽/мес |
| Электричество, ЦОД, амортизация | 20 000 – 100 000 ₽/мес |
Облачный бот средней сложности: 60 000–250 000 ₽ разработка плюс инфраструктура от 8 000 ₽/мес. Коробочный: 200 000–800 000 ₽ разработка плюс существенные затраты на железо и эксплуатацию.
TCO на горизонте 1, 3 и 5 лет
Усреднённый расчёт для среднего бота (50 тыс. диалогов/день, интеграция с CRM, базовая аналитика):
| Горизонт | Облако | On-premise |
|---|---|---|
| 1 год | 0.7–1.5 млн ₽ | 2.0–4.5 млн ₽ |
| 3 года | 2.0–4.5 млн ₽ | 3.5–7.5 млн ₽ |
| 5 лет | 3.5–7.5 млн ₽ | 5.0–11.0 млн ₽ |
Для крупного бизнеса с собственным ЦОДом и амортизированной DevOps-командой картина меняется: предельные затраты на дополнительный сервис в существующем контуре низкие, и on-premise начинает выигрывать уже на 3–4 году. Для среднего бизнеса облако чаще выгоднее на всём горизонте до 5 лет.
Время до запуска
| Этап | Облако | On-premise |
|---|---|---|
| Согласование архитектуры | 3–5 дней | 2–4 недели |
| Закупка железа и лицензий | — | 4–12 недель |
| Подготовка инфраструктуры | 1–2 дня | 2–4 недели |
| Разработка бота | 2–4 недели | 4–8 недель |
| ИБ-аудит и пилот | — / 1 неделя | 2–4 недели |
| Запуск в прод | Сразу | 1–2 недели |
| Итого | 3–6 недель | 3–8 месяцев |
Обновления и релизы
В облаке обновления выкатываются в pipeline CI/CD, проходят авто-тесты и попадают в прод за минуты. В корпоративных контурах процесс короткий — апрув одного-двух человек. Откат — переключение тега Docker-образа.
В on-premise каждый релиз проходит: согласование с ИБ, формальное тестирование на стенде, окно обслуживания в нерабочее время, ручное развёртывание. Цикл — от двух недель до месяца. В строго регулируемых средах — квартал.
Команда эксплуатации
| Роль | Облако | On-premise |
|---|---|---|
| Backend-разработчик | Нужен | Нужен |
| DevOps | Часть времени | Полная ставка |
| Инженер ИБ | По запросу | Полная ставка |
| Сетевой инженер | Не нужен | Полная ставка |
| Администратор БД | Managed-сервис | Нужен |
Реальная коробка для крупного бота — это команда 3–6 человек только на эксплуатацию. Облако обходится одним backend-разработчиком на 0.2–0.5 ставки.
Гибридная модель
Распространённая практика — гибрид:
- AI-провайдер в облаке + бот в on-prem. LLM-вызовы (YandexGPT, GigaChat) идут наружу через прокси с маскированием ПДн; вся бизнес-логика и БД — в контуре заказчика.
- Бот в облаке + интеграции в on-prem через VPN. Сам бот — в Yandex Cloud, доступ к 1С/ERP — через site-to-site VPN или защищённый канал.
- Облачный фронт + on-prem ядро. Webhook-приёмник и буфер очереди — в облаке (для эластичности при пиках), обработка и хранение — в контуре.
Гибрид даёт компромисс: эластичность облака там, где данные не критичны, и контроль on-prem там, где это необходимо.
Риски
Облачная модель:
- Vendor lock-in — миграция между провайдерами стоит времени и денег.
- Downtime провайдера — даже у крупных операторов случаются инциденты на несколько часов.
- Изменение тарифов — провайдер может пересмотреть цены.
- Геополитические риски — санкции, блокировки, изменение требований регуляторов.
On-premise:
- Единая точка отказа без должного DR (резервного ЦОДа).
- Высокие затраты на DR-площадку и регулярные учения.
- Устаревание железа на 4–5 году требует капитальных вложений.
- Уход ключевых ИТ-сотрудников — критичен.
- Технический долг растёт быстрее: обновления откладываются из-за регламентов.
Migration paths
Из облака в on-prem — типичный путь для растущих компаний, у которых критичность бота выросла или подключили чувствительные данные. Универсальная архитектура (Docker, .env, Postgres, Redis) делает миграцию реальной за 4–8 недель.
Из on-prem в облако — реже, но встречается, когда CapEx-модель перестаёт быть выгодной (низкая утилизация железа, дорогая поддержка), либо при реструктуризации ИТ. Сложнее: нужно убедить ИБ, переоформить договоры на обработку ПДн, провести аудит провайдера.
В обоих случаях ключ — изначально универсальный стек: контейнеризация, конфигурация через переменные окружения, отсутствие проприетарных managed-сервисов в критическом пути.
Чек-лист выбора модели
Ответьте «да/нет» на 10 вопросов. Если 5 и больше «да» — вам ближе on-premise.
- Бот обрабатывает специальные категории ПДн (здоровье, биометрия)?
- Бот интегрирован в значимый объект КИИ?
- Требуется аттестация ФСТЭК?
- Бот ходит во внутренние системы (1С, ERP), недоступные снаружи?
- У вас есть собственная DevOps-команда и платформа Kubernetes?
- Ожидаемый срок жизни бота — 5+ лет?
- Бюджет на CapEx (от 2 млн ₽) выделен и согласован?
- Юридические требования запрещают передачу данных третьим лицам?
- Бот критичен и downtime провайдера для бизнеса неприемлем?
- У вас уже есть резервный ЦОД с DR-процедурами?
Если 5+ «да» — коробка. Если меньше — облако или гибрид.
Стек, который мы используем в обоих режимах
Чтобы переход облако → коробка не превращался в переписывание, проект изначально собирается универсально:
- Контейнеризация — Docker и Docker Compose, всё стартует одной командой.
- Конфигурация через
.env— секреты не зашиты в код, легко переносятся между окружениями. - Постгрес как состояние, Redis как кеш и очередь — оба легко переносятся в чужую сеть, есть managed-аналоги у всех российских провайдеров.
- Webhook через nginx с TLS — стандартная схема, работает в любом окружении.
- Логи в JSON, метрики Prometheus — клиент подключает их в свой Grafana, ELK или Loki.
- CI/CD на GitLab или GitHub Actions — пайплайн адаптируется под внутренний GitLab заказчика без переписывания.
- Без проприетарных облачных функций в критическом пути — никаких Lambda, Cloud Functions, специфических managed-сервисов одного провайдера.
В этой архитектуре одна и та же кодовая база ездит и на нашу VPS, и в защищённый сегмент клиента без переписывания.
Итого
Облачный бот в MAX — быстрее, дешевле и подходит большинству B2C и среднего B2B. On-premise — оправдан там, где данные и инфраструктура клиента диктуют закрытый периметр, есть требования 187-ФЗ или ФСТЭК-аттестация, или собственная DevOps-команда. Технологически это одно и то же приложение в разных режимах размещения; ключ к гибкости — изначально универсальная архитектура на Docker и стандартных компонентах. Гибридная модель — рабочий компромисс, который снимает 80% претензий и сохраняет 80% выгод.
Частые вопросы
Что выбрать — облачный или коробочный бот в MAX?
Облако — дефолт для малого и среднего бизнеса, B2C-сценариев и задач без жёстких регуляторных требований. Коробка (on-premise) оправдана, когда хотя бы один из факторов: чувствительные данные (медицина, банкинг, госсектор, КИИ), корпоративный security-периметр с закрытым доступом к 1С/ERP, готовая DevOps-команда у клиента, или регуляторные требования (ФСТЭК-аттестация, ИСУ ПДн, 187-ФЗ). Гибрид «облако на старте, переезд в коробку через полгода-год» — нормальный путь для растущих компаний.
Сколько стоит облачный бот в MAX по сравнению с коробочным?
Облачный бот средней сложности — 60 000–250 000 ₽ разработка, 2–4 недели срок, инфраструктура 3 000–40 000 ₽/мес, поддержка от 8 000 ₽/мес. Коробочный — 200 000–800 000 ₽ разработка плюс CapEx на серверы (500 тыс. – 5 млн ₽), лицензии (200 тыс. – 2 млн ₽), и OpEx 50 000–500 000 ₽/мес на DevOps и ИБ. На горизонте 1–3 года облако дешевле почти всегда; на 5+ годах для крупного бизнеса с амортизированной командой коробка может выиграть.
Можно ли разместить бот MAX на серверах клиента (on-premise)?
Да. Поставляется кодовая база и Docker-образы в инфраструктуру заказчика — собственный ЦОД, частное облако (VMware, OpenStack, Proxmox) или закрытый сегмент сети. Доступ снаружи — только через настроенные шлюзы. Логика бота та же, что в облаке (webhook от MAX, FSM, Postgres, Redis, очередь, интеграции), меняется только периметр размещения. Срок развёртывания — 4–8 недель против 2–3 недель в облаке за счёт дополнительной интеграции с ИТ-контуром заказчика и прохождения ИБ-аудита.
Как 152-ФЗ и 187-ФЗ влияют на выбор модели деплоя?
152-ФЗ закрывается обоими вариантами: в облаке — через договор-поручение на обработку ПДн с провайдером и хостинг на серверах в РФ (Yandex Cloud, VK Cloud, Selectel, Cloud.ru); в on-prem — априори, поскольку оператор и обработчик совпадают. 187-ФЗ (КИИ) для значимых объектов сдвигает выбор в сторону on-prem с аттестованным сегментом и сертифицированными СЗИ. Сертифицированные облачные сегменты (например, защищённый Yandex Cloud) тоже подходят, но дороже обычного облака.
Можно ли перенести бот из облака в коробку без переписывания?
Если архитектура собрана универсально — да, без переписывания. Универсальность означает: контейнеризация на Docker и Compose, конфигурация через .env, Postgres как состояние и Redis как кэш/очередь, webhook через nginx с TLS, логи в JSON и метрики Prometheus, CI/CD на стандартных инструментах (GitLab, GitHub Actions), отсутствие проприетарных managed-сервисов одного провайдера в критическом пути. С таким стеком одна и та же кодовая база ездит и на VPS, и в защищённый сегмент клиента; миграция занимает 4–8 недель.
Что такое гибридная модель и когда она нужна?
Гибрид — комбинация облака и on-prem в одном решении. Типичные конфигурации: AI-провайдер в облаке (YandexGPT, GigaChat) плюс бот в on-prem с маскированием ПДн перед отправкой в LLM; бот в облаке плюс интеграции в on-prem через site-to-site VPN; облачный фронт и буфер очереди плюс on-prem ядро для обработки. Гибрид даёт эластичность облака там, где данные некритичны, и контроль on-prem там, где это необходимо. Подходит компаниям, которые не хотят полностью отказываться ни от одной модели.
Какая команда нужна для эксплуатации on-premise бота?
Минимально: backend-разработчик (часть ставки), DevOps-инженер (полная ставка), инженер ИБ (полная или часть ставки), сетевой инженер, администратор БД. Для крупного бота — команда 3–6 человек только на эксплуатацию плюс DR-процедуры и резервный ЦОД. Облачная модель обходится одним backend-разработчиком на 0.2–0.5 ставки и студией поддержки на стороне исполнителя. Это одна из главных причин, почему on-prem окупается только при определённом масштабе бизнеса.