On-prem, облако или обезличка: какой контур корпоративного ИИ выбрать под 152-ФЗ
On-prem, облако или обезличка: какой контур корпоративного ИИ выбрать под 152-ФЗ
«А куда уйдут наши данные?» — это первый вопрос, который я слышу от собственника, как только разговор про ИИ переходит от демо к внедрению. Второй обычно звучит так: «Служба безопасности не пустит модель к данным наших клиентов». Оба вопроса абсолютно правильные. Плохо то, что ответ на них чаще всего ищут в плоскости «какой вендор лучше» — и почти никогда в плоскости «какой контур под какие данные».
Контур — это то, где физически живут ваши данные в момент работы модели и кто к ним имеет доступ. И это управленческое решение, а не техническое. Его нельзя делегировать в IT целиком — об этом отдельный разговор. Ниже — как выбирать контур под задачу, а не под презентацию подрядчика.
Три контура корпоративного ИИ: внешний API, российское облако, on-prem
Начнём с карты. Контуров по сути три, и отличаются они уровнем изоляции данных и ценой этой изоляции.
- Внешний API. Вы обращаетесь к модели зарубежного или российского провайдера через интернет — информация уходит на чужие серверы, обрабатывается, возвращается ответ. Самый дешёвый и быстрый старт, максимум возможностей модели. Минус — данные физически покидают ваш периметр, а часть зарубежных сервисов из РФ ещё и формально недоступна и не отвечает требованиям локализации.
- Российское облако. YandexGPT, GigaChat и аналоги в облаке провайдера, чьи дата-центры стоят в России. По данным Yandex Cloud, на корпоративных тарифах данные клиента по умолчанию не используются для обучения, есть приватные эндпоинты и изолированные инстансы для финтеха, госсектора и здравоохранения (yandex.cloud). Компромисс между удобством облака и требованием «данные не покидают страну».
- On-prem. Модель разворачивается на ваших серверах, внутри вашего периметра. Ничего не уходит наружу — ни к зарубежному провайдеру, ни в чужое облако. Максимальная изоляция, максимальная цена владения и ответственность за инфраструктуру на вас.
Ключевое, что почти всегда упускают: это не выбор одного контура на всю компанию. Переписка отдела маркетинга и реестр персональных данных дольщиков — это сведения разного класса, и они спокойно могут жить в разных контурах одновременно. Компании, которые пытаются загнать всё в один периметр, либо переплачивают за on-prem там, где он не нужен, либо тормозят, потому что СБ блокирует единое решение из-за самого чувствительного куска данных.
Когда данные нельзя выпускать наружу: 152-ФЗ на языке управленца
Сразу оговорюсь: это управленческий разбор, а не юридическая консультация — толкование конкретных статей под вашу ситуацию остаётся за юристом. Но на уровне принятия решения о контуре логика 152-ФЗ простая.
Главное требование, которое определяет выбор, — локализация. Сбор, запись, систематизация, накопление и хранение персональных данных граждан РФ должны вестись в базах, физически расположенных на территории России. С 1 июля 2025 года правила в этой части ужесточились (КонсультантПлюс). На практике для выбора периметра это значит одно: как только в материал, который вы отправляете в модель, попадают ПДн ваших клиентов или сотрудников — внешний зарубежный API отпадает сам собой, остаётся российское облако, on-prem или обезличивание.
Дальше вопрос степени. Не вся информация одинаково чувствительна. Контактные данные клиента, медицинские сведения, банковская тайна, данные дольщиков, гостайна — это лестница риска, и на каждой ступени цена ошибки разная. Управленческая задача здесь — не выучить закон, а честно ответить на один вопрос: какой класс данных реально нужен модели для каждой задачи. Очень часто оказывается, что нужен далеко не весь массив. К этому вернёмся в разделе про обезличивание.
И отдельно: контур — это часть AI-governance, а не разовая настройка. Кто отвечает за то, что данные не утекли, кто подписывает это решение, как оно аудируется — это зона ответственности первого лица, а не строчка в задаче для админа.
On-premise GigaChat и аналоги: что дают и чего стоят
On-prem перестал быть экзотикой. GigaChat Enterprise, например, поставляется в трёх конфигурациях — локальной (программно-аппаратный комплекс на ваших серверах), облачной и гибридной; Сбер позиционирует on-prem и частное облако как основной сценарий корпоративных внедрений (enterprise.giga.chat). YandexGPT для чувствительных отраслей предлагает изолированные инстансы в инфраструктуре Yandex Cloud, аттестованной по требованиям ФСТЭК на высший уровень защищённости персональных данных УЗ-1 (yandex.cloud). То есть технически закрытый периметр сегодня доступен — это уже не «закажите суперкомпьютер за год».
Что on-prem реально даёт:
- Данные не покидают периметр вообще — самый сильный аргумент для СБ.
- Полный контроль над доступом, логами, версиями модели.
- Снимается целый класс вопросов про трансграничную передачу и про то, «что провайдер делает с нашими промптами».
Чего он стоит:
- Железо. Качественные модели требовательны к GPU. Это капитальные затраты плюс инженеры, которые это поддерживают.
- Отставание модели. On-prem-версия почти всегда на шаг-два позади флагманской облачной. Вы платите за изоляцию качеством рассуждений.
- Ответственность за стек. Обновления, безопасность, отказоустойчивость — теперь ваши. Это не разовая покупка, а постоянная функция.
Обезличивание данных как недооценённый третий путь
Вот ход, который почти не звучит в разговорах про контур, хотя закрывает огромную долю задач: обезличить данные до того, как они уйдут в модель.
Логика простая. Модели для большинства бизнес-задач не нужны паспортные данные, ФИО и номера договоров — ей нужна структура и смысл. Если перед отправкой в API заменить все персональные идентификаторы на обезличенные метки («Клиент №1», «Договор А», «Сумма Х»), а после ответа подставить реальные значения обратно, то в чужой периметр уходит текст, который сам по себе не является персональными данными. Чувствительное остаётся внутри вашей среды, а возможности топовой облачной модели — доступны.
Это даёт то, что обычно кажется взаимоисключающим: и сильную модель, и сведения, не покидающие периметр в идентифицируемом виде. По наблюдениям из практики, для значительной части типовых задач — разбор переписки, аналитика обращений, подготовка документов по шаблону — обезличивание снимает большинство возражений СБ без затрат на on-prem.
Обезличивание — не «вместо» облака или on-prem, а слой поверх любого контура. Его можно поставить перед внешним API, можно — перед российским облаком как дополнительную страховку. Это и есть мысль про параллельные слои: не «либо изоляция, либо качество», а инструмент, который меняет сам класс данных, уходящих наружу.
Оговорка по-честному: обезличивание не панацея. Качество анонимизации нужно проверять (модель не должна восстанавливать личность по косвенным признакам), а для гостайны и ряда регуляторных сценариев оно не заменяет закрытый контур. Но как первый ход, который часто экономит и бюджет, и месяцы согласований, — сильно недооценён.
Как выбрать контур под отрасль и риск: рабочий фреймворк
Выбор контура — это пересечение двух осей: класс данных (насколько чувствительны) и отраслевой регуляторный режим. Вот рамка, с которой я обычно начинаю разбор:
| Класс данных / отрасль | Рекомендуемый базовый контур | Когда добавить обезличивание |
|---|---|---|
| Публичные / внутренние без ПДн (маркетинг, аналитика рынка) | Внешний или российский API | Не обязательно |
| ПДн клиентов, B2C-переписка, обращения | Российское облако | Да — снимает большинство возражений СБ |
| Финтех, медданные, страхование | Российское облако (изолированный инстанс) или on-prem | Да, как обязательный слой |
| Банки, КИИ, данные дольщиков, гостайна | On-prem / закрытый контур | Обезличивание не заменяет изоляцию |
И короткий чек-лист из пяти вопросов перед тем, как выбирать вендора, — заметьте, ни один из них не про бренд модели:
- Какой класс данных реально нужен модели для этой задачи — и можно ли его сократить или обезличить?
- Что говорит ваш отраслевой регулятор про обработку этих данных и про локализацию?
- Какова цена ошибки при утечке именно этого массива — репутация, штраф, отзыв лицензии?
- На каком языке СБ примет решение — есть ли у неё рамка «класс данных × контур»?
- Это решение на всю компанию или по классам данных — и где можно сэкономить, разнеся их по разным контурам?
Если по большинству задач ответы ведут в облако или к обезличиванию — отлично, дорогой on-prem можно не разворачивать. Если хотя бы один массив данных требует полной изоляции — он становится первой точкой входа в закрытый контур, а остальное достраивается параллельно. Войти в эту работу можно с любой стороны: с пилота на безопасных данных, с диагностики одной функции или с разговора, если пока непонятно, с какой стороны подходить.
Сколько стоит безопасность — и когда on-prem не оправдан
Изоляция всегда что-то стоит — деньгами, скоростью или качеством модели. Вопрос не в том, платить ли, а в том, соразмерна ли плата риску. И здесь чаще встречается перестраховка: компании разворачивают on-prem там, где хватило бы облака с обезличиванием, потому что «так спокойнее» — а это капитальные затраты и отставание модели ради риска, которого по факту нет. Любую инициативу полезно мерить тем, окупается ли она, а не тем, насколько она впечатляет на словах.
On-prem скорее не оправдан, когда:
- В исходных материалах нет ПДн или чувствительной тайны, а обезличивание закрывает остаток риска.
- У вас нет инженеров и бюджета на постоянную поддержку стека — тогда «безопасный» on-prem на деле опаснее облака, потому что обновления и дыры остаются на вас.
- Задача — быстрый пилот с понятным критерием успеха, а не годовая инфраструктура.
On-prem оправдан, когда регуляторный режим или класс данных не оставляют выбора — КИИ, банковская тайна, гостайна, — и цена утечки несоразмерно выше цены железа.
Контур — это не про то, какой провайдер моднее. Это про то, какие данные, какой риск и какая отрасль. Выберите контур под задачу — и вопрос «куда уйдут наши данные» перестанет блокировать внедрение.
Если непонятно, какой контур нужен именно вам — начнём с разговора
Разберём ваши данные, отрасль и реальный риск-профиль — и решим, нужен ли вообще on-prem, хватит ли российского облака или закрывает задачу обезличивание. Можно начать с короткого разговора (30 мин) без обязательств, можно — с точечной диагностики одной функции и прототипа на вашей инфраструктуре. Дальше уже видно, нужна ли полноценная программа.
Не обязательно сразу программу. Достаточно часового разговора, чтобы понять, какая из дверей сейчас ваша — или что пока ни одна из них не нужна.
FAQ
Можно ли вообще легально использовать ChatGPT или Claude в российской компании?
Для задач без персональных данных граждан РФ и без чувствительной тайны — как правило, технический вопрос доступа, не более. Как только в запросы попадают ПДн клиентов или сотрудников, прямой внешний зарубежный API вступает в конфликт с требованием локализации 152-ФЗ. Выход — российское облако, on-prem или обезличивание данных перед отправкой. Конкретику под вашу ситуацию стоит свериться с юристом.
Что выбрать — YandexGPT или GigaChat для бизнеса?
Оба решают задачу «данные не покидают РФ» и оба дают облачные и закрытые конфигурации. Выбор обычно идёт не по бренду, а по тому, что у вас уже в инфраструктуре, какой нужен уровень изоляции и как модель справляется именно с вашими задачами. Правильнее не выбирать заранее, а прогнать обе на одном-двух реальных кейсах и сравнить результат.
Насколько обезличивание реально защищает данные?
Если оно сделано качественно — модель получает текст, который сам по себе не является персональными данными, а идентификаторы остаются внутри вашего периметра. Проверять нужно главное: не восстанавливается ли личность по косвенным признакам. Для большинства бизнес-задач этого достаточно, для гостайны и ряда регуляторных сценариев — не заменяет закрытый контур. Это сильный первый слой, не универсальное решение.
Сколько стоит развернуть ИИ в закрытом контуре?
Честный ответ — сильно зависит от контура. Российское облако с обезличиванием стартует от подписочной модели без капзатрат. Полный on-prem — это GPU-железо, лицензии и инженеры на поддержку, то есть капитальные затраты плюс постоянная функция. Универсальной цифры нет: она определяется классом данных, отраслью и тем, нужна ли вам реально полная изоляция или хватает облачного контура.
Это решение должен принимать IT-директор?
IT реализует контур, но решение о том, какие данные в каком контуре допустимы, — управленческое. Оно завязано на риск, отрасль и стратегию, а не только на технику. Поэтому подпись под выбором контура и ответственность за governance остаются на первом лице, а IT — исполнитель этого решения, а не его автор.
Информация в материале: не является публичной офертой (ст. 437 ГК РФ) · носит общий ознакомительный характер, не является индивидуальной консультацией (юридической, финансовой, налоговой или иной) · отражает мнение автора и личный опыт на дату публикации · не гарантирует конкретные результаты, доход или сроки. Цены, условия и функциональность сторонних инструментов могут измениться без уведомления. Кейсы клиентов, упомянутые в материале, отражают конкретные проекты и не являются обещанием аналогичного результата. Эффективность AI-внедрения зависит от исходного состояния компании, готовности команды и масштаба проекта.
