On-premise и облако как модели CRM-системы и CDP различаются тем, где хранятся данные клиентов, стоимостью и скоростью запуска. В статье — критерии выбора и опыт «Яндекса», «Додо Пиццы», Okko.tv и других компаний.
1 июля 2026
On-premise: что это такое, чем отличается от облака и кому подходит
Выбор между on-premise и облаком — одно из самых дорогих решений в ИТ-инфраструктуре. Ошибка здесь не исправляется парой кликов: смена платформы означает повторное внедрение, миграцию данных и месяцы работы команды. Разобрались, чем отличаются две модели и как не прогадать с выбором.
В статье — опыт «Яндекса», «Додо Пиццы», Okko.tv и еще 10 компаний.
Содержание:
Что такое on-premise
Когда сотрудники компании используют почту на «Яндексе» или Gmail, письма хранятся в облаке, то есть на серверах провайдера. А если персонал общается с помощью корпоративного почтового сервера, который стоит в серверной комнате компании, — это on-premise. Та же логика работает для CDP, CRM-систем и любых других сервисов автоматизации маркетинга.
On-premise встречается в двух вариантах:
1. Собственная разработка. Компания создает программное обеспечение с нуля: штатная команда пишет код, выстраивает архитектуру и определяет, как развивать продукт.
2. Готовое решение. Бизнес покупает продукт у вендора и устанавливает его на собственных серверах. Этот вариант проще в поддержке, потому что доработки программы берет на себя поставщик, но кастомизация ограничена рамками его продукта.
Чем on-premise отличается от SaaS, IaaS и PaaS
Все четыре модели описывают, где физически работает программное обеспечение и кто несет ответственность за инфраструктуру. Главное различие — степень контроля над данными и системой:
On-premise. Компания сама владеет «железом» — серверами и оборудованием, а также управляет всем софтом. Бизнес сам несет ответственность за безопасность, обновления, доступность системы.
SaaS. Вендор сам обслуживает инфраструктуру, выпускает обновления, следит за доступностью. Пример: большинство облачных CRM-систем и CDP, в том числе Mindbox.
IaaS. Управление инфраструктурой — на стороне заказчика, физическое «железо» — на стороне провайдера. Пример: Yandex Cloud, VK Cloud.
PaaS. Промежуточный вариант: провайдер берет на себя инфраструктуру и среду разработки, а компания разрабатывает и запускает собственные приложения на этой платформе.
Главное отличие on-premise от облачных моделей — данные не покидают периметр компании. При IaaS и PaaS физические серверы все равно принадлежат провайдеру.
Преимущества on-premise
Локальная модель развертывания подходит для бизнеса, который готов взять на себя полную ответственность за инфраструктуру. Это требует финансовых и кадровых ресурсов, но дает то, чего облако принципиально не может: возможность держать систему под собственным контролем.
Кастомизация
Когда компания сама разрабатывает решение, она может выстроить систему точно под свои процессы. Если бизнес закупает on-premise продукт у поставщика, он часто готов подстроить продукт под бизнес-процессы заказчика. Например, можно предусмотреть быструю обработку данных десятков миллионов клиентов или каталога с сотнями тысяч товаров и их характеристик.
Вендоры on-premise решений готовы бесплатно дорабатывать продукт, если он затрагивает «боли» многих клиентов — это повышает приоритет разработки. Если же заказчику нужен специфический функционал и быстро, его всегда можно заказать. С облачным решением получить нужную доработку вне очереди не получится даже за деньги.
Также кастомизация может учесть нетипичный CJM, когда путь клиента не укладывается в стандартную логику интернет-торговли. Например, в недвижимости сделка может занять несколько месяцев: клиент долго изучает рынок, несколько раз возвращается к просмотрам и только потом решается на покупку.
В B2B цикл продаж тоже устроен иначе: несколько лиц принимают решение о сделке, этапы согласования растянуты во времени, а повторные покупки редки. Стандартные облачные инструменты иногда плохо обрабатывают такую цикличность. Например, система не понимает, когда ждать следующего контакта, и не может выстроить логичную цепочку коммуникаций.
Облако обычно разрабатывают под логику e-commerce. Для других отраслей они подходят неидеально: слишком отличаются структура данных и бизнес-процессы. У меня был неудачный опыт внедрения облачного CDP для медицинской сети. Проект не взлетел, потому что не удалось совместить логику CJM клиник и платформы.
В таких случаях больше подходят on-premise решения, где все можно подстроить под специфику бизнеса. Но возможен и гибридный подход: мы в «Самолете» используем on-premise как основу для инфраструктуры, а облачные сервисы — для коммуникаций.
Иногда задача, которая кажется компании уникальной, решается без глубокой доработки, если разобраться, какой результат нужен бизнесу. Есть разница между запросом на гибкую настройку существующих инструментов и разработкой нового функционала под конкретные процессы. В первом случае подойдет и облачное решение, во втором — нужно локальное решение.
Я продавал платформу автоматизации маркетинга Mindbox три года. Чем крупнее бизнес, тем чаще я слышал запрос на специфические фичи. Бывают ситуации, когда мы действительно не можем предоставить требуемый уровень кастомизации и сами отказываемся от проекта. Например, был запрос от букмекерской конторы — нужны были продвинутые элементы геймификации для сайта. У нас есть простые механики типа попапа «колесо фортуны» — разрабатывать более сложные шаблоны под заказ мы не готовы.
Но зачастую нужно просто разобраться, в чем конечная цель кастомизации, ее польза для бизнеса. Возможно, есть решения с готовым функционалом. Например, многие думают, что Mindbox подходит только для e-commerce, потому что сущности в платформе называются «продукты», «заказы». Но на те же сущности можно разложить процессы почти в любом бизнесе — от B2B до финтеха.
Например, сервис MoneyMan адаптировал логику нашей платформы под выдачу займов. Статус займа обновляется каждую ночь, а у нас предусмотрен лимит — не более ста редактирований заказа. Коллеги настроили автоудаление промежуточных состояний заказа — это никак не повлияло на бизнес-логику, но позволило избежать ошибок.
Контроль за данными
Локальное развертывание по умолчанию дает больше контроля над корпоративной информацией, потому что она остается в собственном периметре компании. Это особенно важно для бизнеса, где клиентские данные чувствительны по природе: финансы, недвижимость, медицина. Чем выше цена утечки, тем весомее аргумент держать инфраструктуру у себя.
On-premise решения чаще выбирают крупные компании с большим объемом данных: им важно сохранять полный контроль. Особенно принципиально это для бизнеса с высоким чеком. Это как раз случай недвижимости: мы владеем чувствительной информацией о крупных тратах клиентов.
Другое дело, что отказаться от on-premise гораздо сложнее, чем поменять одно облако на другое, — это оборотная сторона развертывания решения в своем периметре.
Управление производительностью
В облаке компания зависит от мощностей и приоритетов провайдера. В on-premise — сама решает, сколько ресурсов выделить под пиковые нагрузки и как распределить их между задачами.
Контроль над производительностью требует экспертизы внутри компании. Для одних бизнесов — это барьер, для других — осознанная стратегия: наращивать собственную компетенцию, а не зависеть от того, как и когда отреагирует внешний провайдер.
Мы предпочитаем самостоятельно контролировать все системы и наращивать собственную экспертность. Поэтому выбрали on-premise, где мы сами отвечаем за надежность, безопасность и доступность инфраструктуры. При этом экспертность в информационной безопасности становится критически важной.
Облачные решения используем, если нет других вариантов. Например, пытались разработать собственное решение для работы с маркетинговыми рассылками, но оставили эту идею из-за сложности. В результате купили облачный Mindbox из-за отсутствия альтернативы под наши требования. Используем его для рассылок, проведения тестов и сбора данных по ним.
Независимость от внешних обстоятельств
Если поставщик облачного решения уходит с рынка, компания теряет доступ к системе. С on-premise от вендора лицензия обычно продолжает работать даже без поддержки и обновлений. Это дает время на переход к другому поставщику без потери операционной функции.
После февраля 2022 года наш прошлый сервис ушел из России — те, у кого была облачная версия, сразу лишились программы лояльности и рассылок. У нас была версия on-premise, и мы спокойно могли пользоваться ею еще год, пока не закончилась лицензия.
Когда мы искали новый сервис, то сперва рассматривали только on-premise. Но, к сожалению, такие решения или были слишком дорогими, или не отвечали нашим требованиям, например не могли отправлять каскадные рассылки. В результате выбрали облачный Mindbox и пока не планируем от него отказываться.
Преимущества облачных решений
Облако отличается от локального развертывания логикой управления: компания передает провайдеру инфраструктуру, безопасность и обновления, а сама сосредотачивается на бизнесе.
Быстрый запуск
Облачное решение не требует закупки оборудования и длительной настройки инфраструктуры, можно начать работу сразу после подключения. Это особенно важно, когда нужно быстро проверить гипотезу или запустить новый канал коммуникации без многомесячного внедрения.
Преимущество облачных SaaS-решений в том, что это стандартный продукт с четко прописанными протоколами интеграции, включая API, загрузки и выгрузки данных. Вся техническая документация передается разработчикам клиента — понятно, что именно нужно делать.
А большинство on-premise энтерпрайз-проектов по-своему уникальны: вендоры подстраиваются под особенности клиентов. Из-за этого на развертывание уходит больше времени: сперва необходимо обсудить бизнес-процессы, затем написать требования под витрины, которые будут отображать данные, потом протестировать их.
Конечно, все зависит от особенностей конкретного бизнеса, но, по моему опыту, внедрение on-premise занимает в два-три раза больше времени, чем SaaS-решения.
Подключение дополнительных функций
В облаке новый функционал подключается к уже работающей системе без отдельных закупок «железа» и сложных интеграций, например с email- и SMS-рассылками. Это меняет логику развития продукта: маркетинговая команда может расширять возможности платформы самостоятельно, не дожидаясь ИТ-ресурсов.
Облачные решения более гибкие. В них есть готовые модули, поэтому подключение новых опций требует меньше ресурсов, чем с on-premise.
Например, если компания хочет отправлять автоматические рассылки и использует облачное решение, то у нее для этого все есть. Конечно, может потребоваться дополнительная интеграция, но сам процесс уже настроен. Данные собираются и обрабатываются в режиме реального времени, затем срабатывает триггер и рассылки отправляются.
С on-premise гораздо сложнее: для автоматических рассылок нужно много чего настроить. Поясню на простом примере «брошенной корзины». Чтобы запустить такую механику, нужно собирать события с сайта или приложения в режиме реального времени и загружать их в высоконагруженный и быстродоступный сервис. Для этого часто нужно купить отдельный realtime-модуль, дорогое «железо» с оперативной памятью, настроить мониторинги доступности, например с помощью Grafana, а также интегрировать сервис для сбора событий с сервисом для отправки коммуникаций.
Чаще появляются новые фичи
Облачный вендор вынужден развивать продукт быстро, иначе клиенты уйдут к конкурентам. Это создает для него стимул следить за рынком и оперативно закрывать новые потребности заказчиков. У вендоров on-premise с ограниченным кругом заказчиков такого стимула нет: сменить решение для заказчика сложно и дорого, поэтому ниже необходимость постоянно дорабатывать продукт.
У облачных решений нет проблем с развитием продукта. Они работают со многими компаниями из разных сфер — не нужно ничего придумывать, достаточно слушать, чего хотят клиенты. Происходит постоянный custdev, поэтому облачные сервисы хорошо реагируют на запросы рынка.
Вендорам on-premise решений сложнее: круг их клиентов ограничен. Хуже всего тем, кто сам разрабатывает продукт. Такие компании реагируют только на собственные запросы и рискуют отстать от рынка. Им нужно придумывать, как собирать информацию о том, что происходит. Это можно решить с помощью найма, но только частично.
В облачном сервисе запрос от одной компании может превратиться в фичу, которую получают все клиенты. Благодаря тому, что команда заказчика участвует в формировании продукта, инструменты развиваются вместе с задачами бизнеса.
Мы часто общаемся с продуктовыми командами Mindbox и обсуждаем новые фичи. Из последнего — post-view-отчетность. Сначала собрали такой отчет для себя, его увидела наша менеджер, рассказала коллегам, и они сами пришли к нам с вопросами. Мы несколько раз созванивались, обсуждали варианты отчетности и ее важность для нас — сейчас этот функционал уже в работе.
Облачный вендор может выпускать обновления хоть каждый день, и клиенты получат их автоматически. Для маркетинговой команды заказчика это значит, что новые инструменты появляются в работе сразу, без предварительного согласования с собственным ИТ-отделом.
Мы в Mindbox разрабатываем продукт на основе обратной связи от клиентов: чтобы реализовать новую фичу, ориентируемся на их боли и потребности. Поскольку продукт развернут в облаке, мы можем быстро доставить обновление всем клиентам. Технически это занимает час, но для надежности действуем итерациями: сначала раскатываем фичу на небольшую тестовую группу, ждем два часа, затем открываем доступ всем клиентам. Облако — это процесс постоянной выкатки релизов, что позволяет быстро внедрять изменения.
Вендоры on-premise решений выпускают новые релизы реже, обычно раз в месяц. По-другому не получится: нельзя удалить из продукта устаревшую фичу, пока все клиенты не обновятся до последней версии. Если бы решения on-premise обновлялись так же часто, как облачные, им пришлось бы подстраиваться под график обновлений, согласованный с клиентом, и ждать релиза. В коде накапливались бы устаревшие фрагменты. Они усложняют кодовую базу, замедляют прохождение релизов и тестов, а в конечном счете — всю разработку.
Дешевле использование
В облаке компания платит за использование готовой инфраструктуры, которую вендор содержит за счет всех клиентов. При локальном развертывании все затраты на «железо», лицензии и поддержку ложатся на компанию.
Есть две основные причины, почему облако обычно дешевле:
1. Облако требует меньше вложений. Серверы закуплены, продукт работает и не требует усилий по развертыванию для каждого нового клиента. Не нужна и выделенная команда по каждому контракту: вендор не поддерживает разные версии продукта и не разбирается с конфигурацией клиентских серверов.
Мы делали примерный просчет разницы в стоимости между облачным и on-premise-вариантом Mindbox: для базы в 1 млн контактов on-premise минимум в пять раз дороже, для базы от 1 до 10 млн — в три раза.
2. Стоимость «железа» распределяется на всех клиентов. Софт обходится дешевле, потому что нагрузка на него распределяется: клиенты отправляют рассылки в разное время. Получается, что бизнес оплачивает только реальное использование серверов. При выборе on-premise на «железо» приходится существенная часть затрат, и компании приходится оплачивать его простой.
Разница в цене становится очевидной, если считать не стартовые вложения, а совокупную стоимость владения решением на горизонте нескольких лет.
Всегда нужно считать полную стоимость проекта. При выборе облака можно получить готовый продукт с минимальным time-to-market. Например, для отправки первых рассылок даже не нужна полная интеграция: достаточно выгрузить список клиентов. Сделать это под силу любому начинающему разработчику за полчаса.
Разрабатывать решение своими силами сложно и дорого: нужны высокопрофессиональные разработчики. В результате компания получит «свой» продукт, но вместе с ним и дополнительную единицу администрирования, на которую нужно будет выделять ресурс техподдержки.
Даже при внедрении готового on-premise решения придется заложить затраты на обслуживание «железа», лицензионные платежи, организацию взаимодействия с их поставщиками. А если речь о продуктах, требующих высокой надежности, например о процессинге программы лояльности, обслуживание должно быть круглосуточным, а это существенные дополнительные расходы.
Отдельная статья затрат локального развертывания — прогнозирование нагрузки. Компания закупает «железо» под ожидаемый рост базы, но точно угадать объем заранее удается редко.
Прогноз стоимости обычно делается на пять лет и учитывает не только рост базы, но и покупку дополнительных модулей, например программы лояльности. Для малого и среднего бизнеса использование облака по умолчанию дешевле, чем on-premise. Но с ростом картина может измениться: при нашем размере базы локальное решение обошлось бы дешевле.
Разница в стоимости определяется самой сутью решений. Облако — это покупка только лицензии, масштабирование происходит на стороне вендора. С on-premise нужно заложить стоимость не только самого решения, но и «железа», а также затраты на его поддержку и обслуживание.
Прогноз нужного количества «железа» и его конфигурации (так называемый сайзинг) — сложная задача. Я много раз сталкивался с ситуацией, когда бизнес ошибался с сайзингом и оказывалось, что при растущей базе «железо» не вытягивает запросы маркетинга. Возникает необходимость докупать или арендовать «железо».
On-premise требует и постоянной поддержки. Потребуется команда, состоящая из системных администраторов, data-инженеров, аналитиков, DevOps-инженеров и специалистов по ETL-процессам, которые перекладывают данные в нужную структуру. Также нужна сильная служба информационной безопасности.
В облаке планировать нагрузку не нужно — ресурсы масштабируются под реальное потребление, а компания платит только за фактическое использование.
В пиковые моменты, например во время «черной пятницы», Mindbox автоматически подключает виртуальные машины в «Яндекс Облаке». Платим только за время их использования, что также повышает экономическую эффективность для нас и, соответственно, наших клиентов. С on-premise пришлось бы закупать дополнительное «железо», которое простаивает бóльшую часть года.
Ниже потребность в собственной ИТ-экспертизе
Локальное развертывание требует постоянной команды: системные администраторы, DevOps-инженеры, специалисты по информационной безопасности. В облаке эти функции берет на себя вендор, а заказчик платит только за сервис.
У малых и средних предприятий может не хватать ресурсов, чтобы обеспечить штат экспертами в узкоспециализированных отраслях ИТ и кибербезопасности. Для таких компаний облачные решения и услуги становятся спасением: исчезают проблемы найма и затраты на поддержание собственной инфраструктуры.
Если у бизнеса большой штат специалистов по кибербезопасности и управлению инфраструктурой, можно рассмотреть вариант on-premise — он даст больше контроля над продуктом и сервисом. Правда, в ИТ большой дефицит специалистов, так что поиск нужных людей может стать непростой задачей.
Нам эффективнее делегировать вопрос безопасности клиентских данных. У Synergetic просто нет такой экспертизы, как у облачных платформ, где команда информационной безопасности следит за происходящим и при необходимости готова принять нужные меры.
Для многих компаний это принципиальный выбор: заниматься профильным бизнесом или тратить ресурс на поддержку инфраструктуры, которая не создает конкурентного преимущества.
Мы стараемся использовать облачные решения, потому что хотим заниматься тем, что хорошо умеем. А хорошо умеем мы делать продукт для пиццерий — франчайзи и клиентов. У нас есть собственная информационная система Dodo IS — разрабатываем ее максимально надежной и безопасной. А хостинг, работа с «железом», менеджмент серверов — не наша экспертиза, и мы стараемся не брать на себя лишнюю работу.
Проще восстановить данные после сбоя
Когда в собственной инфраструктуре компании происходит взлом, ошибка разработки или отказ оборудования, данные могут повредиться или полностью потеряться. Если при этом компания использует облачный сервис, он становится резервной копией: данные там хранятся независимо от состояния внутренних систем.
За последние полгода в Mindbox трижды обращались клиенты с просьбой передать им данные для восстановления собственных баз. Причиной потери данных может стать взлом или технический сбой, например при критической ошибке разработки.
В двух из трех случаев Mindbox был единственным сервисом, который продолжал функционировать. И благодаря тому, что расчет заказов для касс происходит на нашей стороне, продажи в офлайне не останавливались.
Что безопаснее: on-premise или облако
Выбор инфраструктуры определяет, кто несет ответственность за безопасность данных, но не гарантирует ее. Обе модели не дают автоматической защиты от утечек информации.
При локальном развертывании компания контролирует периметр полностью: данные не передаются третьим сторонам, доступ настраивается под внутреннюю политику безопасности. Но вся ответственность за их защиту тоже лежит на компании.
По итогам 2025 года крупнейшие утечки данных пришлись на четыре государственных on-premise сервиса. Иными словами, решение безопасно ровно настолько, насколько сильна внутренняя команда по информационной безопасности.
Мне кажется, что идея хранить данные в своем периметре — пережиток прошлого и не гарантирует их защиту. Публикации об утечках информации в крупных компаниях появляются постоянно, и это только публичная информация, реальность намного хуже, что видно по числу спам-звонков. А если крупные компании, которые допускают утечки, при их уровне информационной безопасности не могут гарантировать сохранность данных, то что уж говорить о компаниях малого и среднего бизнеса с гораздо более низким уровнем ИБ.
По моему мнению, выбирать нужно не между облаком и on-premise как таковыми, а ориентироваться на пользу для бизнеса. Собственная разработка точнее учитывает потребности компании. Но чтобы такое решение стало сравнимо по качеству с тем, что разработано специализированным вендором, должно пройти время. Time-to-market облаков быстрее, поэтому я апологет таких решений, особенно когда нужен быстрый запуск.
Чтобы обеспечить безопасность данных при выборе облачного решения, достаточно ориентироваться на репутацию вендора и проверять базовые характеристики, например количество утечек и судебных тяжб, а также обсудить способы защиты информации. Естественно, защита данных должна соответствовать их категории и чувствительности потери для бизнеса.
Идея, что чувствительные данные могут храниться на чужих серверах или в облаке, а не на собственном «железе» в соседней комнате, все еще не нравится российским безопасникам. Важно помнить, что ни облако, ни on-premise — не гарантия защиты от утечек. А дальше вопрос к пользователям: читали ли они инструкции, используют ли пароли сложнее, чем 123456.
Главная проблема в том, что традиционно в России строят защиту от внешнего атакующего. Но утечки происходят и по вине сотрудников. Бывает и комбинация факторов. Например, бывший сотрудник, у которого забыли отобрать права: он атакует снаружи, но по факту действует как инсайдер.
В облаке ответственность за инфраструктуру несет провайдер. Крупные российские поставщики таких решений вкладываются в защиту инфраструктуры и проходят внешние аудиты, но это не гарантирует полную безопасность информации заказчиков. Среди типичных причин утечек из облачных хранилищ — ошибки в конфигурации и общедоступных базах данных, слабые пароли, фишинговые атаки и невнимательность сотрудников.
Сомнения компаний, которые не готовы отдавать данные в облако, можно свести к четырем пунктам:
1. В облаке выше риск утечки данных. Уровень надежности и безопасности облачного сервиса зависит от размера вложений и качества процессов вендора. При выборе посоветовал бы ориентироваться на то, с какими клиентами работает вендор. Если в портфеле есть крупные федеральные сети, это хороший признак: у таких компаний обычно сильная служба безопасности, которая тщательно проверяет вендоров.
2. Облачный сервис использует данные для обогащения чужой клиентской базы. Такой риск действительно есть, поэтому нужно уточнять правила конкретного вендора. Мы храним базы клиентов изолированно: для каждого заказчика есть свой экземпляр продукта и только у него есть доступ к базе данных.
3. Не все компании имеют право по закону использовать облачные решения. Действительно, в облаке нельзя хранить особые категории персональных данных, к которым относится банковская и медицинская тайны. Но это не значит, что запрет распространяется на все данные финансовых и медицинских компаний.
Банки могут запускать попапы на сайте для привлечения новых клиентов, отправлять массовые рассылки без персонализации или использовать облачный сервис просто как шлюз для отправки писем и сообщений с сегментацией на своей стороне. Медучреждения более свободны в работе с персональными данными, если они не затрагивают медицинскую тайну. Например, клиники могут предлагать клиенту записаться к врачу, если тот просматривал сведения о нем на сайте. Или персонализировать рассылки на основе пола и возраста, например отправлять письмо о профилактике рака груди женщинам определенного возраста.
4. Если передавать данные по выручке и заказам стороннему решению, то доступ к ним получит ФНС. Некоторые компании хранят данные на своих серверах за рубежом — это уловка, чтобы до них не дотянулась налоговая. В этом смысле облако прозрачнее: проверяющий действительно имеет право прийти к вендору и запросить данные. Тут я ничего не могу посоветовать, кроме «белого» ведения бизнеса.
Для ряда компаний выбор решения продиктован не только соображениями безопасности, но и прямыми требованиями законодательства.
Закон «О персональных данных» обязывает бизнес хранить личную информацию российских граждан на серверах, расположенных на территории России. Для большинства компаний это требование закрывается облачными решениями российских провайдеров, если их инфраструктура физически находится в РФ.
За нарушение требований к локализации компаниям грозят штрафы. За первое нарушение юридическим лицам придется заплатить от 1 до 6 млн рублей, а за повторное — от 6 до 18 млн рублей.
Строже требования для организаций, работающих с государственными информационными системами (ГИС) и объектами критической информационной инфраструктуры (КИИ). Например, к ним относятся компании в сфере энергетики, транспорта, финансового сектора, здравоохранения, промышленности. Такому бизнесу и госкомпаниям нужно оценить критичность своих систем, описать возможные угрозы, внедрить сертифицированные средства защиты и пройти аттестацию. Это фактически означает развертывание на собственной инфраструктуре.
За нарушение требований к системам безопасности значимых объектов КИИ есть административные штрафы: для должностных лиц — 10–50 тыс. рублей, для юридических лиц — 50–100 тыс. рублей. Также такие компании обязаны уведомлять госорганы об инцидентах, связанных с информационной безопасностью. В противном случае им грозит штраф до 500 тыс. рублей.
Кратко: когда лучше on-premise, когда — облако
Если свести опыт экспертов к нескольким абзацам, то ситуация выглядит так:
On-premise — лучший выбор, если у компании уникальные бизнес-процессы, например нестандартный CJM, большой объем данных или специфические требования к интеграциям. При этом есть достаточно ИТ-ресурсов, в том числе на регулярную поддержку и доработку, особенно если команда тестирует много маркетинговых гипотез. Важно, чтобы в команде были эксперты в информационной безопасности и работе с инфраструктурой.
Облако — лучший выбор, если нужно быстро запускать продукты, подключать новые фичи и тестировать гипотезы. Например, модель подходит, если нужно за несколько недель, а не месяцев внедрить новые каналы коммуникации или механики программы лояльности. При этом облако оптимально, когда нет задачи выстроить уникально сложный CJM (путь клиента), хранить данные на своей стороне. И нет избытка ИТ-ресурсов, а также внутренней экспертизы в информационной безопасности и работе с инфраструктурой.
С точки зрения безопасности различие одно: при on-premise компания отвечает за защиту данных сама, при облаке — эта ответственность на провайдере. Ориентироваться стоит на соблюдение стандартов и на то, работает ли вендор с крупными компаниями с сильной службой безопасности. При этом ни облако, ни локальное развертывание не гарантируют защиты от утечек. Поэтому главный критерий выбора — бизнес-польза: как новое решение поможет улучшить CJM и повлияет на важные для компании метрики.
On-premise
Облако
Кастомизация
Глубокая: система настраивается под любые бизнес-процессы
Кастомизация возможна, но только в рамках функций, которые поставщик заложил в продукт
Стоимость
Выше на старте и в поддержке: «железо», лицензии, команда
Ниже на старте: подписка без затрат на «железо». Растет предсказуемо вместе с базой
Безопасность
Полный контроль периметра, данные не покидают инфраструктуру. Вся ответственность на компании
Ответственность на провайдере. Зависит от качества его процессов и внутренних политик заказчика
Скорость запуска
В 2–3 раза дольше SaaS: нужно закупить «железо», развернуть систему, настроить интеграции
Минимальный time-to-market: можно начать работу сразу после подключения
Обновления
Часто требуют участия штатного инженера компании
Автоматически для всех клиентов
Независимость от вендора
Высокая: лицензия работает даже после ухода поставщика с рынка
Низкая: уход вендора означает немедленную потерю доступа к системе
Восстановление данных после сбоя
Сложнее: при проблемах во внутренней инфраструктуре резервная копия может отсутствовать
Облачный сервис становится резервной копией при сбое во внутренних системах заказчика
Потребность в ИТ-экспертизе
Высокая: нужны администраторы, DevOps-инженеры, специалисты по ИБ
Низкая: инфраструктуру и безопасность берет на себя вендор
Можно ли интегрировать on-premise с ИИ
Языковые модели открывают новые возможности для CRM-маркетинга: персонализация коммуникаций на основе клиентских данных, автоматическая сегментация аудитории, генерация текстов рассылок. Облачные платформы уже встраивают такие инструменты в готовые продукты, например ML-модули для предсказания оттока или подбора товарных рекомендаций. Но компании, которые работают с чувствительными данными, сталкиваются с проблемой безопасности. Им хочется использовать современные ИИ-инструменты, а передавать информацию о клиентах во внешние облачные сервисы нельзя ни по регуляторным требованиям, ни по внутренней политике безопасности.
Для компаний, использующих локальные решения, единственный вариант работы с ИИ — open source языковые модели, например российские GigaChat Ultra от «Сбера» или YandexGPT Lite. Их можно развернуть внутри собственного периметра: данные не покидают инфраструктуру компании, а модель дообучается на внутренних данных без доступа внешних провайдеров.
В то же время у локального развертывания есть ограничения. Облачные модели генерируют ответ за секунды, а локальные на стандартном корпоративном сервере работают медленнее — для сложных задач время ожидания может достигать нескольких минут. При этом часть инструментов, которые в облачном контуре работают через внешние сервисы, в закрытом периметре недоступна, например проверка контрагентов или поиск по внешним базам данных. Если ИИ-агент обращается к такому инструменту, он должен сообщить пользователю, что задача недоступна в текущем контуре, иначе начнет генерировать недостоверные данные.
Для большинства компаний, которые работают с чувствительной информацией о клиентах, оптимален гибридный подход:
- on-premise инфраструктура и локальные модели — для задач внутри периметра, например для сегментации на основе клиентских данных;
- облачные сервисы — для задач, где чувствительные данные не задействованы: тестирование гипотез, генерация черновиков коммуникаций.
Как выбрать решение для бизнеса
До сравнения конкретных продуктов стоит ответить на несколько вопросов:
- Каковы цели бизнеса на ближайшие три-пять лет?
- Какой объем данных предстоит обрабатывать?
- Есть ли внутри компании ИТ-экспертиза для поддержки сложной инфраструктуры?
- Насколько критично хранить данные в собственном периметре?
Ответы на эти вопросы определят, какие критерии выбора окажутся приоритетными — они будут разными для обеих моделей.
Критерии при выборе on-premise
Локальное развертывание — долгосрочная инвестиция, которую сложно пересмотреть: смена решения потребует повторного внедрения, миграции данных и времени команды. Поэтому оценивать его нужно строже, чем облако: с запасом на рост и с проверкой каждого технического аспекта.
Соответствие бизнес-целям и процессам компании
Функциональность on-premise сложно расширить постфактум: каждая новая опция — это отдельный проект с согласованием, разработкой и тестированием. Поэтому список требований лучше составлять с запасом, а не отталкиваться от текущих задач.
Нужно сравнить цели компании минимум на два-три года с тем, какие возможности предоставляет on-premise. Иначе можно попасть в ситуацию, когда решение будет тормозить развитие компании, а переинтегироваться будет слишком дорого и сложно.
Например, бизнесу может понадобиться программа лояльности или автоматические рассылки в режиме реального времени. Или, возможно, есть планы перейти от скидочной к балльной программе лояльности — должно быть четкое видение того, будет ли нужная опция в продукте.
Проверка безопасности
При выборе локального решения от вендора изучение сертификатов — необходимое условие, но этого недостаточно. Они подтверждают соответствие стандартам безопасности, но не означают, что в коде продукта нет уязвимостей.
Компания-вендор может быть сертифицирована, например по ISO 27001. Но это не гарантирует информационную безопасность при развертывании внутри контура: у вендора нет доступа к инфраструктуре и процессам покупателя продукта. Поэтому при выборе on-premise ответственность за безопасность инфраструктуры ложится на плечи заказчика. Единственное, что можно сделать с точки зрения продукта — независимый аудит исходного кода на уязвимости. Аудиторы дают рекомендации, а после устранения уязвимостей делают повторное заключение.
Доступ к серверам
Локальное развертывание решения от вендора часто воспринимают как полностью закрытый контур. На практике для установки, настройки и обновлений поставщику продукта может понадобиться доступ к серверам заказчика.
On-premise — необязательно полностью изолированный продукт: доступ для установки и настройки может быть у инженеров вендора. Этот фактор нужно учесть в модели угроз — в документе с перечнем всех используемых сервисов и возможных рисков. В итоге может оказаться, что риски равны при обоих вариантах развертывания. Стоит также продумать безопасные входы для инженеров поддержки и прописать юридические аспекты.
Поддержка продукта
После внедрения on-premise общение с вендором не заканчивается. После запуска начинается долгосрочное сотрудничество с поставщиком: обновления, исправление ошибок, развитие функциональности. Качество этой поддержки влияет на то, насколько решение будет актуальным через несколько лет.
Важно, как продукт сопровождается после покупки. Сюда входит все — от обновления и устранения уязвимостей до доработки фичей.
Например, недавно мы хотели купить одно on-premise решение, но оказалось, что вендор не планирует устранять существующие уязвимости, потому что сфокусирован на развитии облака. Нас не устраивает такой подход.
При выборе on-premise важно понять, как происходит обновление продукта — как часто и насколько сложно. Если процесс незаметен для компании, то неважно, как часто это происходит. Если же обновление ведется не автоматически и требует нескольких часов работы инженера, то лучше, чтобы оно происходило как можно реже. В этом случае на стороне вендора должно быть серьезное тестирование уязвимостей новой версии, чтобы не пришлось ее «откатывать».
Работа с обновлениями в нашей on-premise CDP происходит оперативно: вендор присылает файл с обновлением, DevOps-инженер его быстро «накатывает». Процесс происходит ночью — без даунтайма и влияния на работоспособность. Ни разу за несколько лет не приходилось «откатывать» обновления назад: мы получаем отточенные версии без багов. Но так происходит не у всех вендоров — не всегда поддержка работает качественно и оперативно.
Критерии при выборе облака
У облачных решений меньше технических рисков на этапе внедрения, зато велика цена ошибки в выборе функциональности: сменить облачный сервис проще, чем локализованный продукт от вендора, но миграция данных и переобучение команды все равно стоят времени и денег.
Соответствие целям компании
Иногда облачный сервис, который компания выбирала несколько месяцев, в итоге не решает реальных задач. Причина обычно в том, что бизнес заранее не сформулировал, что ему нужно от системы.
Зачастую продукт покупают без четких целей. Но ни одно решение не определит бизнес-требования за заказчика. Поэтому сначала нужно понять, зачем, что и как компания будет делать. И только потом подбирать продукт под эти требования: по мановению волшебной палочки никакой вендор не решит задачи бизнеса.
Требования к безопасности
Перед выбором облачного решения стоит составить список детальных вопросов для вендора. Иначе оценка сводится к презентации продукта, а не к реальной проверке его защищенности.
У нас в «Яндексе» есть список требований к новым сервисам, оформленный в виде анкеты с вопросами. Среди требований — шифрование трафика и логирование событий, связанных с идентификацией и выдачей прав. Для SaaS-решений — изолированное хранение баз компаний-клиентов.
Спрашиваем также про управление обновлениями и инфраструктуру, на которой работает продукт. Сам по себе он может быть суперсовременным, но, если использует устаревшую операционную систему с кучей уязвимостей, нам он не подойдет.
Облачные решения различаются не только по функциональности, но и по тому, насколько заказчик может влиять на защиту своих данных внутри платформы.
Для нас обязательно, чтобы серверы были расположены на территории России, — это снижает вероятность потери доступа к данным. Важна также возможность дополнительно обезопасить базу, например разграничить права доступа к клиентским данным, замаскировать персональные данные или поставить ограничения на выгрузку.
Базовые признаки надежности вендора — сертификаты по информационной безопасности и результаты аудитов. Они подтверждают, что система проверена по установленным стандартам.
При выборе решения мы в первую очередь обращаем внимание на сертификаты и выполнение стандартов, гарантирующих информационную безопасность системы. В частности, смотрим на соответствие требованиям 152-ФЗ и международному стандарту ISO27001:2013. Важно также, чтобы проводился аудит всей системы на наличие уязвимостей и его прохождение подтверждалось соответствующими документами.
Сертификаты и аудиты — отправная точка. Важно так же понять, как вендор работает с безопасностью в повседневном режиме, а не только во время плановых проверок.
Если в компании есть служба безопасности, которая может оценить риски, имеет смысл запросить описание системы защиты данных. Другой вариант — заказать внешний аудит. Полезно также поговорить с сотрудником вендора, отвечающим за безопасность. Важно не просто формальное соблюдение стандартов, а то, какие усилия компания прикладывает для обеспечения и роста уровня безопасности.
Например, мы стараемся постоянно улучшаться: раньше проверяли доступы сотрудников раз в квартал, сейчас используем систему алертов, которая проводит постоянный мониторинг. Или еще пример: в стандарте не указано, какой именно тест проникновения заказывать. Раньше делали относительно простой, он охватывал только админки наших клиентов. Сейчас заказываем расширенный тест, который также проверяет сервисы, обрабатывающие данные.
Мощность решения
Облачные сервисы работают на общей инфраструктуре провайдера, и для большинства компаний этой мощности достаточно. Но при большом объеме данных стоит проверить производительность на реальной нагрузке.
Если речь об энтерпрайз-компании, то нужно понять, позволит ли облако обрабатывать весь объем данных: делать запросы и сегментации, в какой гранулярности. И, конечно, оценить, как долго запросы будут обсчитываться. Например, для этого можно загрузить свою базу гостей и заказов и измерить, как долго будут считаться основные сегменты.
Чувствительность информации и круг пользователей
Не все облачные решения требуют одинакового уровня проверки. Чем чувствительнее данные, которые через них проходят, тем серьезнее должны быть требования к вендору.
При выборе облачного решения отталкиваемся от критичности данных и требований надежности. Условно, если нужно разработать чат-бота, который будет присылать информацию об открытии новых пиццерий, используя информацию из открытого API, такую работу можно доверить вчерашнему студенту. Он соберет чат-бота на no-code-платформе за вечер.
Но если речь идет о персональных данных клиентов или о другой чувствительной информации, то нам нужна компания с именем, выстроенными процессами и технологиями. Аудиты и сертификаты для нас косвенный признак, важнее — репутация, люди и культура.
При выборе нового решения мы смотрим на круг потенциальных пользователей и чувствительность данных, которые будут обрабатываться. Чем шире круг пользователей и выше чувствительность данных, тем строже требования.
В случае с маркетинговыми решениями требования по безопасности заведомо очень высокие, потому что с этими решениями взаимодействует очень много сотрудников: разработчики, отвечающие за интеграцию, менеджеры, настраивающие рассылки и акции. Кроме того, через такие платформы проходят персональные данные клиентов.
Реакция на утечки
Утечки порой случаются даже у надежных вендоров — вопрос в том, как компания на них реагирует. Это один из немногих критериев, который можно проверить до подписания договора: достаточно поискать публичные случаи инцидентов и посмотреть, как вендор о них сообщал.
При выборе решения важна реакция вендора на утечки — даже не сам их факт, потому что гарантии 100% безопасности нет ни у кого, особенно во время нынешней волны кибератак. В идеале компания должна сразу опубликовать информацию об утечке и рассказать, что утекло и как, какие действия предприняли для улучшения своей системы.
8 вопросов об on-premise
Что такое on-premise решение простыми словами?
Это программное обеспечение, которое работает на серверах внутри компании, а не у провайдера. Компания сама решает, как настроить систему, когда обновлять и кто имеет доступ к данным.
В чем разница между on-premise и SaaS?
При on-premise компания владеет «железом» и управляет всем софтом, несет полную ответственность за безопасность и доступность системы. SaaS — готовая программа в облаке по подписке: вендор обслуживает инфраструктуру, выпускает обновления, следит за доступностью. Главное отличие — только при локальном развертывании данные не покидают периметр компании.
On-premise или облако — что безопаснее?
Ни одна из моделей не дает автоматической защиты от утечек. Выбор инфраструктуры определяет, кто несет ответственность за безопасность, но не гарантирует ее.
Локальное развертывание безопасно ровно настолько, насколько сильна внутренняя команда по информационной безопасности. В облаке все зависит от надежности провайдера. Но типичные причины утечек не зависят от модели развертывания: ошибки в конфигурации, слабые пароли, фишинг и невнимательность сотрудников могут быть в любом случае.
Когда on-premise обязателен по закону?
В России организациям, работающим с государственными информационными системами и объектами критической информационной инфраструктуры нужно пройти аттестацию и внедрить сертифицированные средства защиты. Это фактически означает развертывание на собственной инфраструктуре. Как правило, для соблюдения законодательства на on-premise переходят компании в сфере энергетики, транспорта, финансового сектора, здравоохранения, промышленности.
Можно ли использовать ИИ (LLM) в on-premise контуре?
Да, с помощью open source языковых моделей, например GigaChat Ultra от Сбера или YandexGPT Lite. Их можно развернуть локально, внутри собственного периметра. При этом локальные модели работают медленнее облачных, а часть инструментов, требующих внешних сервисов, в закрытом контуре недоступна.
Во сколько раз on-premise дороже облака?
Для базы в 1 млн контактов on-premise минимум в пять раз дороже, для базы от 1 до 10 млн — в три раза. При этом с ростом базы картина может меняться: крупным компаниям локальная модель иногда обходится дешевле.
Что такое гибридная инфраструктура и кому она подходит?
Гибридная инфраструктура — модель, при которой компания совмещает локальное развертывание и облако. Есть два варианта такого подхода:
1. On-premise как основа для хранения данных и инфраструктуры, облачные сервисы — для коммуникаций с клиентами.
2. Локальные ИИ-модели для задач внутри периметра, например для сегментации на основе клиентских данных, облачные сервисы для задач, где чувствительные данные не задействованы: тестирование гипотез, генерация черновиков коммуникаций.
Сколько времени занимает внедрение on-premise по сравнению с SaaS?
Внедрение on-premise занимает в два-три раза больше времени, чем SaaS-решения.
