Служба безопасности говорит: «Данные за периметр не выпускаем». Из этого часто делают вывод, что компании остается либо отказаться от ИИ, либо купить дорогой сервер и содержать его своими силами.
Но запрет обычно относится не к ИИ вообще. Он относится к определенным данным, маршрутам передачи или поставщикам. Коммерческое предложение без персональных данных, кадровый документ, технологический чертеж и сведения значимого объекта критической информационной инфраструктуры требуют разных решений.
Поэтому первый вопрос звучит не «можно ли нам ИИ», а так:
Какие именно данные нельзя передавать, куда именно нельзя и на основании какого требования?
После ответа остается три рабочих варианта: облако российского провайдера, гибридный контур или полностью локальная система. Свой сервер нужен не всегда.
Значит ли «данные нельзя отдавать наружу», что ИИ компании недоступен?
Нет. Это значит, что архитектуру ИИ нужно выбирать после классификации данных, а не до нее.
В одном процессе могут одновременно встречаться данные трех типов:
- общая информация, которую разрешено обрабатывать у внешнего провайдера;
- персональные или коммерчески чувствительные данные, для которых нужны договор, контроль доступа, журналирование и согласованный маршрут;
- сведения, которые по закону, отраслевым требованиям или внутренней модели угроз должны оставаться внутри инфраструктуры компании.
Например, ИИ может разбирать обезличенные технические описания в облаке, а исходные документы хранить внутри компании. Или вся система, включая модель, поиск по документам и журналы, может работать на площадке предприятия.
Фраза «никаких данных наружу» тоже требует расшифровки. «Наружу» может означать:
- за пределы России;
- за пределы инфраструктуры компании;
- любому внешнему подрядчику, даже если оборудование физически стоит на территории предприятия.
Это три разных запрета. Под каждый подходит свой контур.
Что именно нужно согласовать с ИБ до выбора технологии?
Разговор полезно начать не с названий моделей и серверов, а с карты движения данных.
Возьмем ассистента по внутренним документам. В его работе участвуют не только исходные файлы. Система получает запрос сотрудника, ищет подходящие фрагменты, передает их модели, формирует ответ и сохраняет технические журналы. В логах могут остаться имя пользователя, IP-адрес, текст запроса и найденные фрагменты.
Поэтому вопрос «где лежат документы?» недостаточен. Нужно отдельно определить, где находятся и кем обрабатываются:
- исходные документы;
- поисковый индекс по ним;
- запросы сотрудников;
- фрагменты, переданные модели;
- ответы модели;
- журналы действий;
- резервные копии.
Если подрядчик говорит «данные не покидают периметр», попросите показать эту схему. У одного поставщика внутри остаются только файлы, а запросы уходят во внешнюю модель. У другого внутри работают и хранилище, и модель, но администраторы подрядчика подключаются удаленно. Одна фраза описывает разные риски.
Когда подходит облако российского провайдера?
Облако подходит, если компания разрешает обрабатывать выбранные данные у внешнего поставщика, а требования ИБ закрываются договором, размещением в России, разграничением прав и журналированием.
В этом варианте компания не покупает вычислительное оборудование. Она получает доступ к модели через API или арендует вычислительные мощности у провайдера. Это позволяет быстро проверить процесс и платить за фактическое использование или выбранную конфигурацию.
Облако стоит рассматривать, когда:
- в процесс не попадают сведения, которым запрещено покидать инфраструктуру компании;
- поставщик может договорно зафиксировать место обработки и правила работы с данными;
- понятна цепочка субподрядчиков и внешних моделей;
- ИБ может проверить права доступа, логи, сроки хранения и удаление данных;
- компании важнее начать с ограниченного процесса, чем сразу покупать оборудование.
Российское размещение решает вопрос территории, но не делает систему автоматически безопасной. Нужно проверить, какие данные сохраняет провайдер, использует ли их для обучения, куда пишет резервные копии и кто имеет административный доступ.
Для персональных данных требования особенно конкретны. Передача таких данных зарубежному ИИ-сервису считается трансграничной передачей. По требованиям закона о персональных данных для нее нужно иметь законное основание, выполнить требования 152-ФЗ и при необходимости уведомить Роскомнадзор. Отдельной проверки требуют история диалогов, IP-адреса и сочетания атрибутов, по которым можно определить человека. Это общий разбор требований 152-ФЗ, а не индивидуальное юридическое заключение для конкретной компании.
Если процесс можно очистить от персональных и закрытых данных, облако часто остается самым простым способом проверить пользу ИИ. Если очистить нельзя, нужно обсуждать гибрид или локальный контур.
Когда нужен гибридный контур?
Гибрид нужен, когда часть цепочки можно вынести к провайдеру, а часть должна остаться у компании.
Единой схемы гибрида нет. На практике встречаются как минимум три варианта:
- Документы и поисковый индекс остаются внутри, а во внешнюю модель уходят только найденные и при необходимости обезличенные фрагменты.
- Модель работает внутри компании, а управление, обновления или мониторинг выполняет подрядчик.
- Провайдер устанавливает GPU-серверы на площадке заказчика, но продолжает обслуживать систему удаленно.
В августе 2026 года российский провайдер представил корпоративного ассистента, который можно разместить в облаке или на GPU-серверах на площадке заказчика. В описании заявлены маскирование чувствительных данных, проверка входящих и исходящих запросов, интеграция с IAM и SSO. Поставщики также заявляют запуск примерно за две недели, но публичные результаты внедрений не раскрыты. Поэтому это пример доступной архитектуры, а не доказанный кейс с посчитанным эффектом.
Гибрид полезен, когда полный локальный контур избыточен, но обычное облако ИБ не согласует. Например, можно оставить внутри договоры, карточки клиентов и индекс, а модели передавать только обезличенный отрывок, необходимый для ответа.
Но слово «обезличенный» само по себе ничего не гарантирует. Нужно проверить, можно ли восстановить человека по сочетанию должности, подразделения, суммы, даты и других полей. Маскирование должно тестироваться на реальных документах компании.
Когда нужен полностью локальный ИИ?
Локальный контур нужен, если исходные данные, запросы, вычисления и журналы не должны покидать инфраструктуру предприятия.
Это может быть требованием для конкретной категории сведений, следствием статуса информационной системы или решением компании по собственной модели угроз. Для значимых объектов КИИ действуют отдельные требования. Сам факт, что предприятие относится к промышленности, еще не означает, что все его системы автоматически являются значимыми объектами КИИ. Статус и требования нужно подтвердить у ответственных за ИБ и юристов, а не выводить из отрасли по умолчанию.
В полностью локальной схеме внутри компании находятся:
- модель и вычислительное оборудование;
- документы и поисковый индекс;
- система управления доступом;
- запросы, ответы и журналы;
- резервные копии;
- средства обновления и контроля.
В открытых кейсах АО «Апатит» сообщало о развертывании платформы «Ясень» в собственном ЦОД. Компания использует несколько моделей, а локальное размещение позволило работать без ограничений по типам загружаемой информации. По данным самого предприятия, системой пользуются около 2,5 тыс. человек, средняя точность ответов составляет 88%, а время подготовки документов сократилось примерно на 15%. Методика замеров не опубликована, а масштаб компании и собственный ЦОД делают этот кейс верхней границей, а не готовым образцом для предприятия на 100-500 человек.
Локальный контур дает максимум контроля, но не делает ИИ безопасным автоматически. Если права на сетевом диске настроены по принципу «все свои», ассистент может пересказать одному сотруднику документ другого отдела. Если журналы не ведутся, расследовать ошибку будет так же трудно, как во внешнем сервисе. Периметр защищает от одного класса рисков, но не заменяет управление доступом.
Как выбрать между облаком, гибридом и своим сервером?
Удобнее сравнивать не технологии, а допустимый маршрут данных.
| Ситуация | Базовый вариант | Что проверить до решения |
|---|---|---|
| Выбранные данные разрешено обрабатывать у российского провайдера | Облако | договор, место обработки, субподрядчики, обучение на данных, логи, удаление |
| Исходные документы должны остаться внутри, но отдельные фрагменты можно передавать модели | Гибрид | что именно выходит наружу, как работает маскирование, где лежит индекс, кто администрирует систему |
| Нельзя выпускать документы, запросы, вычисления и журналы | Полностью локально | оборудование, модели, резервирование, обновления, права доступа, команда сопровождения |
| Требования различаются по документам и процессам | Несколько контуров | классификация данных и правила маршрутизации между контурами |
Последний вариант часто практичнее попытки построить одну систему на все случаи. Кадровые документы могут обрабатываться локально, обезличенные технические тексты в гибриде, а открытая информация в облаке. Самый строгий класс данных не обязан определять архитектуру для всей компании.
Во сколько обойдется держать ИИ у себя?
Публичной цены на физический on-premise сервер для ИИ «под ключ» в России нет. В открытых предложениях продавцы указывают «по запросу», а не готовую сумму. Поэтому честно назвать цену своего сервера без нагрузки, модели и требований к отказоустойчивости невозможно.
Оценка складывается не только из покупки железа. В нее входят:
- Вычислительное оборудование. GPU-сервер, оперативная память, диски, сеть и запас по мощности.
- Резервирование. Второй узел, запасные компоненты, резервные копии и восстановление после сбоя, если простой критичен.
- Программное обеспечение. Лицензии, корпоративная поддержка моделей и инфраструктурных компонентов, если они нужны.
- Интеграция. Подключение документов и учетных систем, поиск по базе знаний, права доступа, журналирование и интерфейс для сотрудников.
- Люди. Администратор, специалист по ИБ, разработчик интеграций и тот, кто отвечает за качество ответов и обновление базы.
- Эксплуатация. Электричество, охлаждение, место в серверной, мониторинг, ремонт и замена оборудования.
- Обновления. Новые версии моделей, проверка качества после обновления, исправление уязвимостей и совместимость с внутренними системами.
Плата за доступ к готовой модели не является ценой внедрения. Компания отдельно оплачивает интеграцию, права доступа, журналы, поддержку и работу с документами. Для локального варианта к тем же статьям добавляются оборудование и его эксплуатация. Итоговая стоимость считается от задачи и зависит от объема и требований.
Когда свой сервер может оказаться разумнее облака?
Свой сервер стоит считать, если одновременно выполняются три условия:
- нагрузка постоянная и достаточно высокая;
- локальный контур действительно обязателен;
- у компании есть люди, которые смогут поддерживать систему после запуска.
Если сотрудники обращаются к ИИ несколько раз в день, дорогое оборудование большую часть времени будет простаивать. Если запросы идут непрерывно, аренда мощностей может со временем стать дороже владения. Но такой вывод делают только после замера реальной нагрузки.
Сравнивать нужно два полных варианта:
Облако = использование модели или аренда мощности + интеграция + сопровождение + контроль поставщика.
Свой контур = покупка и резервирование оборудования + интеграция + люди + электричество и охлаждение + обновления + ремонт.
В открытых российских источниках нет независимого сравнения совокупной стоимости владения облаком, гибридом и локальной системой по одной методике. Поэтому универсального ответа «свой сервер окупается за такой-то срок» сейчас нет.
Что отвечать на возражение «служба безопасности все равно не пропустит»?
Не пытайтесь убедить ИБ, что риск преувеличен. Попросите превратить общее «нельзя» в проверяемые условия.
Запрет без разрешенного варианта часто оставляет сотрудникам только личные аккаунты. Тогда документы уходят наружу без договора, журнала и контроля компании. По открытой судебной публикации, в 2026 году Бабушкинский районный суд Москвы рассматривал дело, где директор по продажам, среди других нарушений, выгружала сведения из внутреннего PowerBI в DeepSeek. Суд признал увольнение законным. Важно, что решение касалось не «использования ИИ» само по себе, а вывода защищенной информации во внешние каналы без производственной необходимости. Сведений о вступившей в силу апелляции в публикации нет.
Этот случай не доказывает, что любая облачная нейросеть незаконна. Он показывает другое: если компания не определила разрешенный контур, сотрудники могут построить свой.
Задача разговора с ИБ не в том, чтобы получить согласие «на ИИ вообще». Нужно согласовать один процесс, его данные и допустимый маршрут. После этого облако, гибрид или локальная система становятся следствием требований, а не предметом спора вкусов.
Какие три вопроса задать своей службе безопасности?
До встречи с подрядчиком выпишите ответы на три вопроса.
1. Какие конкретно данные нельзя передавать внешнему поставщику и почему?
Попросите назвать категории данных, документы и основание ограничения: закон, статус системы, договор с заказчиком, режим коммерческой тайны или внутренняя модель угроз. Ответ «все внутреннее» не позволяет выбрать архитектуру.
2. Что именно считается выходом за периметр?
Отдельно уточните передачу за пределы России, обработку в российском облаке, удаленный доступ подрядчика, передачу обезличенных фрагментов и хранение журналов. Так станет понятно, возможен ли гибрид.
3. Какие проверяемые условия должен выполнить контур, чтобы ИБ его согласовала?
Нужен список доказательств: схема потоков данных, место хранения, перечень субподрядчиков, модель прав доступа, журналирование, маскирование, резервные копии, сроки хранения и удаления, порядок обновлений и административного доступа.
С этими ответами разговор с подрядчиком начинается не с фразы «покажите безопасный ИИ», а с технически проверяемого задания.
С чего начать выбор контура?
Не выбирайте сервер до выбора процесса.
Один и тот же завод может законно использовать все три контура. Открытые инструкции обрабатывать в облаке, договоры и персональные данные в гибриде, а сведения критичной системы только локально. Если сначала купить железо «для безопасности», можно получить дорогую систему без достаточной нагрузки. Если сначала подключить облако «для скорости», можно позже обнаружить, что нужные документы туда передавать нельзя.
Рабочая последовательность такая:
- Выберите один процесс и перечислите данные, которые в нем проходят.
- Вместе с ИБ определите допустимый маршрут для каждой категории.
- Сравните контуры по полной стоимости, а не только по цене модели или сервера.
- Попросите подрядчика показать схему движения данных и условия согласования ИБ.
- Проверяйте пользу на разрешенном наборе документов, не расширяя доступ заранее.
Если хотите понять, какой контур нужен вашему процессу, оставьте заявку на бесплатную диагностику Neuroprem, 35-45 минут. До разговора подготовьте ответы на три вопроса выше. Они помогут отделить реальное требование безопасности от привычного «ничего наружу» и не покупать свой сервер там, где задачу можно решить проще.