Суверенный и национальный ИИ в РФ: руководство по выбору для бизнеса

Что произошло

1 сентября 2026 года в Российской Федерации вступил в силу Федеральный закон № 243-ФЗ «О поддержке развития технологий искусственного интеллекта в Российской Федерации». Этот закон вводит две новые юридические категории для больших фундаментальных ИИ-моделей: суверенные и национальные. Данное событие формирует новую правовую среду для всех компаний, использующих или планирующих внедрение генеративного ИИ, особенно в контексте гособзакупок и работы с чувствительными данными.

Законодательство разделяет модели по критериям контроля над жизненным циклом и происхождения компонентов. Суверенная модель должна быть полностью разработана и воспроизводима российским юридическим лицом на всех этапах, от архитектуры до обучения и обновления, при этом обработка запросов и хранение данных должны осуществляться исключительно в российских дата-центрах. Национальная модель также требует российского разработчика и российской инфраструктуры, но допускает использование зарубежных компонентов с открытой лицензией, что снижает барьеры для входа на рынок.

По состоянию на 8 октября 2026 года, публичный реестр моделей, получивших официальный статус, отсутствует. В публикациях упоминается, что на подтверждение соответствия претендуют продукты «Сбера» «ГигаЧат» и «Яндекса» «Алиса AI», однако официальных документов об их присвоении статуса нет. Для бизнеса это означает, что любые заявления поставщиков о «суверенности» или «национальности» требуют юридической и технической верификации на основе текста закона, а не маркетинговых материалов.

Ключевое последствие для рынка — появление нового критерия в тендерной документации и контрактах. Компании, особенно работающие с госзаказом или в регулируемых отраслях (финтех, медицина, госсектор), будут обязаны указывать и доказывать соответствие используемой ИИ-модели требуемой категории. Это напрямую влияет на ИТ-архитектуру, затраты на инфраструктуру и управление рисками зависимости от зарубежных технологий.

Как это устроено

Юридические критерии статусов

Закон устанавливает пять обязательных условий для признания модели суверенной. Первое — разработчик является российским юридическим лицом. Второе — это российское юрлицо самостоятельно осуществляет разработку на всех стадиях жизненного цикла, включая определение и изменение характеристик. Третье — обеспечивается полная техническая и технологическая воспроизводимость всего цикла, включая процесс обучения модели. Четвёртое — ответы пользователям и хранение данных обеспечиваются в ЦОДах на территории РФ, принадлежащих российским юридическим лицам. Пятое — модель прошла процедуру подтверждения соответствия законодательству РФ и традиционным российским духовно-нравственным ценностям.

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

Техническая воспроизводимость

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

Инфраструктурные требования

Обе категории моделей требуют обработки запросов и хранения данных на территории России в ЦОДах, принадлежащих российским юридическим лицам. Это исключает использование публичных облаков зарубежных провайдеров (AWS, Google Cloud, Azure) для обработки данных конечных пользователей. По нашему опыту, для средних и крупных компаний это означает выбор между арендой мощностей у российских облачных провайдеров (VK Cloud, Yandex Cloud, Selectel, MTS Cloud) и развёртыванием собственной инфраструктуры on-premise. Выбор зависит от требований к безопасности, бюджета и имеющихся компетенций. Суверенная модель в большинстве случаев предполагает более глубокую интеграцию с собственной или арендованной российской инфраструктурой для контроля над всем циклом.

Экономика статусов

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

Роль открытых компонентов

Национальные модели получают конкурентное преимущество за счёт использования открытых экосистем. Это позволяет встраивать передовые зарубежные разработки, доступные на условиях open-source, что сокращает время на выход на рынок и может повысить качество модели. Однако это также создаёт новые обязанности для компании-потребителя. Необходимо проводить лицензионный аудит используемых компонентов, проверять их на наличие ограничений на коммерческое использование, а также оценивать репутацию и стабильность сообщества, стоящего за каждым компонентом. Внезапная смена лицензии популярной open-source-библиотеки может поставить под угрозу весь проект.

Как это выглядит на практике

В типовом сценарии крупный банк, внедряющий ИИ для анализа клиентской документации и скоринга, выберет суверенную модель. Несмотря на более высокую стоимость, для него критически важен полный контроль над данными, процессом обработки и отсутствие зависимости от зарубежных поставщиков, которые могут попасть под санкции. Банк развернёт модель в собственном ЦОДе или у сертифицированного российского провайдера, заключив договор, включающий обязательства по воспроизводимости и аудиту всего жизненного цикла. ROI здесь будет рассчитываться с учётом снижения регуляторных рисков и обеспечения непрерывности бизнеса.

Средняя ритейл-компания, стремящаяся автоматизировать ответы на частые вопросы в чат-боте, скорее всего, остановится на национальной модели. Для неё скорость внедрения и экономия на старте важнее, чем максимальный уровень суверенности. Она может интегрировать модель через API от российского разработчика, который использует в своём стеке открытые компоненты. Данные клиентов будут обрабатываться в России, что соответствует закону, а компания получит современное решение в кратчайшие сроки. Основное внимание будет уделено проверке контракта на предмет ответственности поставщика за чистоту используемых open-source компонентов.

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

Что это значит для российской компании

Для российских компаний новый закон — это одновременно и ограничение, и возможность. Ограничение заключается в сужении выбора ИИ-платформ и необходимости строить архитектуру в соответствии с российским законодательством. Возможность — в формировании предсказуемой и контролируемой ИТ-среды, защищённой от внешнеполитической конъюнктуры. Влияние затрагивает юридический отдел, ИТ-архитектуру, отдел закупок и бюджетный процесс.

Доступность моделей на рынке будет расти, но компании должны научиться отличать маркетинговые заявления («российская разработка», «хранение данных в РФ») от юридически подтверждённого статуса. Импортозамещение из модного тренда превращается в жёсткое требование для целого класса систем. Бюджеты должны теперь включать не только стоимость лицензий или API-вызовов, но и затраты на юридическую экспертизу, возможную доработку инфраструктуры и управление рисками зависимости.

Санкционные ограничения и правовые требования создают новую реальность, где использование зарубежных SaaS-решений для обработки критически важных данных становится невозможным. Компании вынуждены переносить рабочие нагрузки в российскую юрисдикцию, что стимулирует местных облачных провайдеров и разработчиков ПО. Влияние на процессы выражается в появлении новой процедуры — аудита ИИ-моделей на соответствие критериям суверенности или национальности перед заключением контракта.

Что делать: пошагово

1. Провести аудит текущих и планируемых ИИ-инициатив. Определите, какие процессы и данные задействованы, и оцените их критичность.
2. Классифицировать использования по уровню рисков. Разделите все сценарии на те, где допустима только суверенная модель (госзаказы, ПДн), и те, где достаточно национальной.
3. Запросить у потенциальных поставщиков пакет документов. Требуйте доказательства статуса модели: сведения о разработчике, архитектуре, инфраструктуре и, для национальных моделей, перечень используемых open-source-компонентов с лицензиями.
4. Выполнить техническую и юридическую экспертизу компонентов. Привлеките специалистов для проверки лицензионной чистоты open-source-решений и оценки рисков их отзыва или смены лицензии.
5. Спроектировать целевую ИТ-архитектуру. Определите, будет ли модель развёртываться on-premise или в российском облаке, и какие требуются ресурсы для её работы.
6. Провести пилотный проект на ограниченном участке. Протестируйте модель на реальных, но некритичных данных, оценив не только функциональность, но и стабильность, производительность и соответствие заявленным характеристикам.
7. Рассчитать совокупную стоимость владения (TCO). Учитывайте не только тарифы API или лицензию, но и затраты на интеграцию, инфраструктуру, безопасность, аудит и поддержку.
8. Разработать стратегию управления жизненным циклом модели. Пропишите в контракте с поставщиком обязанности по обновлению, обеспечению безопасности и воспроизводимости модели на протяжении всего срока её использования.

Типичные ошибки

1. Подмена понятий. Считать, что размещение API в российском облаке автоматически делает модель суверенной или национальной. Статус определяется всей цепочкой разработки и компонентов, а не локализацией точки входа.
2. Игнорирование стека компонентов. При выборе национальной модели не анализировать её состав. Это приводит к лицензионным рискам и внезапной невозможности обновления из-за отзыва ключевого open-source-элемента.
3. Фокус на цене API. Оценивать модель только по стоимости одного запроса, игнорируя затраты на интеграцию, безопасность, соответствие стандартам и управление долгосрочными рисками.
4. Отсутствие юридической проверки. Доверять маркетинговым заявлениям поставщика о статусе модели без запроса подтверждающих документов и проведения независимой экспертизы.
5. Ожидание идеальных регуляторных разъяснений. Откладывать анализ и подготовку к внедрению до публикации полного спектра подзаконных актов. Базовые критерии уже определены законом, и работать с ними можно уже сейчас.
6. Считать суверенную модель автоматически качественнее. Юридический статус не является прямой гарантией превосходства в производительности или точности. Каждую модель необходимо тестировать под конкретные задачи бизнеса.

Как понять, что вы на верном пути

1. Поставщик предоставляет полный пакет документов, доказывающий статус модели, включая описание архитектуры и состав компонентов.
2. Ваши ИТ-специалисты и юристы работают совместно над оценкой предложения, а не изолированно друг от друга.
3. Выбранная категория модели (суверенная или национальная) соответствует уровню критичности данных и бизнес-процессов, на которых она будет использоваться.
4. Бюджет проекта включает статьи расходов не только на разработку и внедрение, но и на аудит безопасности, лицензионную проверку и управление зависимостями.
5. У вас есть чёткий план действий на случай смены лицензии или отзыва ключевого компонента в национальной модели, прописанный в SLA с поставщиком.
6. Вы понимаете, что внедрение ИИ — это не разовый проект, а непрерывный процесс управления моделью, данными и рисками.

Вопросы, которые нам задают

Уже есть модели с подтверждённым статусом?

По состоянию на 8 октября 2026 года публичный реестр моделей, прошедших процедуру подтверждения соответствия, отсутствует. Компании, включая «Сбер» и «Яндекс», заявляют о своих претензиях на статус, но юридически значимого подтверждения для конечного пользователя пока нет. Требуйте от поставщика предоставления документов, подтверждающих соответствие критериям закона № 243-ФЗ.

Насколько национальная модель уступает суверенной?

Статус не является прямой оценкой технических характеристик. Национальная модель может быть не хуже (или даже лучше) суверенной по качеству, так как использует проверенные мировые open-source-решения. Основное различие лежит в плоскости юридического контроля и долгосрочных рисков зависимости от зарубежных разработчиков, а не в производительности.

Что будет, если компонент национальной модели отзовут?

Это один из ключевых рисков. В договоре с поставщиком национальной модели необходимо прописать его обязательства по мониторингу используемых компонентов и оперативной замене отозванных или проблемных элементов на аналоги с сохранением функциональности. Ответственность за такие риски должна быть чётко распределена.

Обязательно ли использовать только российские ЦОДы?

Закон требует, чтобы обработка запросов и хранение данных осуществлялись в дата-центрах, находящихся на территории РФ и принадлежащих российским юридическим лицам. Это исключает использование зарубежных облачных площадок для этих целей. Выбор между собственным ЦОДом и арендой у российского провайдера остаётся за компанией.

Источники

• Коммерсантъ — Обзор нового закона об ИИ от 5 октября 2026
• Business FM — Выступление представителя «Яндекса» о дефиците мощностей