On-premise или облако для ИИ: что выбрать бизнесу

Когда бизнес решает внедрить ИИ, первый практический вопрос звучит так: on-premise или облако для ИИ — где разворачивать модель и где будут лежать данные. От этого выбора зависит, сколько вы заплатите в первый год, как быстро запуститесь, кто отвечает за персональные данные и не придётся ли через полгода всё переделывать под требования регулятора. Разберём решение по конкретным критериям и покажем, как посчитать, какой вариант дешевле именно вам.

Что на самом деле скрывается за выбором

Облако — это когда модель и вычисления живут у провайдера, а вы обращаетесь к ним по API. Платите за обращения или за подписку, не покупаете железо, не нанимаете людей под обслуживание GPU. On-premise (он же локальный, закрытый контур) — модель развёрнута на ваших серверах внутри периметра компании, данные физически не уходят наружу.

Важная оговорка для российского бизнеса: «облако» не равно «ChatGPT» или «Claude». Эти сервисы из РФ недоступны легально и не дают гарантий по 152-ФЗ. Реальный выбор сегодня — между российским облаком (GigaChat, YandexGPT и подобные по API) и локальным развёртыванием открытых или отечественных моделей (тот же GigaChat в закрытом контуре, Cotype, open-source модели). Дальше под «облаком» я имею в виду именно отечественные облачные LLM, а под on-premise — модель на вашем железе.

Безопасность, 152-ФЗ и КИИ: главный водораздел

Здесь проходит граница, которая чаще всего и определяет выбор. Когда вы отправляете данные в облако, они покидают периметр и обрабатываются на стороне провайдера. Для маркетинговых текстов это не проблема. Для медицинских карт, банковской тайны, паспортов клиентов и технологической документации — проблема прямая.

152-ФЗ требует, чтобы обработка персональных данных шла на серверах в России и под вашим контролем как оператора. Российские облачные провайдеры это формально обеспечивают и дают договор с условиями по защите данных. Но если вы субъект критической информационной инфраструктуры (КИИ) — банк, энергетика, транспорт, здравоохранение, связь — требования жёстче: контроль над всей цепочкой обработки, аттестация, ограничения на передачу данных третьим лицам. А с гостайной облако исключено в принципе.

Простое правило: чем выше чувствительность данных и чем строже регулятор над вашей отраслью, тем сильнее весы клонятся к on-premise. В закрытом контуре данные не покидают компанию вообще — это снимает большинство вопросов комплаенса разом. Именно поэтому OVEERMOON разворачивает ИИ-агентов на отечественных LLM внутри периметра клиента: для банка или промышленного холдинга это часто единственный допустимый вариант.

Стоимость: CAPEX против OPEX

Деньги — второй по важности критерий, и тут интуиция часто подводит. Облако выглядит дешевле на старте, потому что нет крупных вложений. Но при большом объёме обращений счёт за API растёт линейно и может обогнать стоимость собственного железа.

Критерий	Облако	On-premise
Модель затрат	OPEX, платёж за обращения/подписку	CAPEX на железо плюс OPEX на обслуживание
Старт	Минимальные вложения	Закупка GPU-серверов, от сотен тысяч до миллионов
Масштаб 100+ тыс. запросов/мес	Счёт растёт линейно	Фиксированная стоимость после закупки
Предсказуемость бюджета	Зависит от нагрузки	Высокая после старта
Команда	Не нужна	Нужны DevOps/MLOps

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

Скорость старта и производительность

Облако выигрывает по времени запуска без вариантов. Пилот можно собрать за дни: получили доступ к API, подключили к CRM, проверили гипотезу. On-premise требует закупки оборудования, развёртывания, настройки — недели, а с учётом тендерных процедур в крупной компании и месяцы.

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

Контроль, зависимость от вендора и обслуживание

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

Обслуживание — обратная сторона контроля. Облако обслуживает провайдер: обновления, безопасность инфраструктуры, отказоустойчивость. С on-premise это ваша зона: обновлять модели, следить за GPU, держать резервирование, закрывать уязвимости. Без своей команды MLOps или подрядчика, который возьмёт это на себя, локальное решение быстро деградирует.

Гибрид: чаще всего оптимум

На практике выбор редко бывает бинарным. Разумная архитектура — разделить потоки данных по чувствительности. Чувствительные процессы (персональные данные, финансы, документы под регуляторикой) идут через локальную модель в закрытом контуре. Нечувствительные и ресурсоёмкие задачи (генерация черновиков текстов, классификация публичных обращений, эксперименты) — в облако, где это быстрее и дешевле в пересчёте на задачу.

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

Как выбрать под свою ситуацию

Сведём логику к коротким сценариям.

Облако подойдёт, если:

• данные низкой чувствительности, персональных данных мало или нет;
• нужен быстрый пилот и проверка гипотезы за недели;
• объём обращений умеренный и не оправдывает закупку железа;
• нет своей команды для поддержки инфраструктуры.

On-premise нужен, если:

• вы обрабатываете персональные данные в объёме, где риск утечки критичен;
• вы субъект КИИ или работаете с гостайной;
• регулятор вашей отрасли требует полного контроля над обработкой;
• нагрузка стабильно высокая и горизонт использования — годы;
• вам важна предсказуемая задержка и независимость от внешних сервисов.

Порядок действий при выборе:

1. Классифицируйте данные по чувствительности и сверьтесь с требованиями вашего регулятора.
2. Спрогнозируйте объём обращений на год и посчитайте обе модели затрат.
3. Оцените, есть ли команда для поддержки on-premise или нужен подрядчик.
4. Зафиксируйте метрики до старта: время ответа, доля автоматизации, стоимость обработки.
5. Запустите пилот на самой узкой задаче и сравните факт с планом.

Часто задаваемые вопросы

On-premise всегда дороже облака?

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

Можно ли соблюсти 152-ФЗ в облаке?

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

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

В закрытом контуре разворачивают GigaChat, Cotype и ряд open-source моделей, дообученных под задачу. Это легальная и суверенная замена недоступным ChatGPT и Claude: данные не покидают периметр, а поведение модели вы контролируете сами.

Что выбрать для быстрого старта без больших вложений?

Облако. Пилот собирается за дни, крупных вложений не требует, а проверка ценности на реальных процессах покажет, стоит ли инвестировать в собственный контур. Если данные чувствительные — начните пилот на обезличенных данных, а боевой запуск переносите в on-premise.

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