Редакция: На какой стадии сейчас находится законопроект и насколько вероятно, что положения о суверенных, национальных и доверенных моделях будут приняты именно в таком виде?

Валерий Белов: Предлагаю изначально необходимо разграничить первоначальную концепцию законопроекта и текст, который позднее был внесен Правительством в Государственную Думу, вступление в силу которого ожидается в ближайшее время.

Первоначальный проект федерального закона «Об основах государственного регулирования сфер применения технологий искусственного интеллекта в Российской Федерации» предлагалась трехуровневая конструкция. Наряду с суверенными и национальными моделями вводилось самостоятельное понятие доверенной модели ИИ и предусматривалось создание соответствующего реестра.

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

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

Валерий Белов
Руководитель правовой и корпоративной поддержки финтех-группы, эксперт по вопросам правового регулирования цифровых сервисов и потребительского права, к.ю.н, магистр права Университета Ланкашир



Однако внесенный Правительством в Государственную Думу законопроект был существенно переработан и получил новое название — «О поддержке развития технологий искусственного интеллекта в Российской Федерации». Его предмет был заметно сужен: документ регулирует уже не все технологии и системы ИИ, а преимущественно разработку и применение больших фундаментальных моделей искусственного интеллекта.

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

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

Для национальной модели требования несколько мягче. Ее разработчиком также должно быть российское юридическое лицо, а существенные характеристики модели должны определяться и изменяться российским разработчиком. Однако допускается использование отдельных российских и иностранных компонентов, включая другие модели, при условии их распространения на основании открытых лицензий. Требования к локализации обработки и хранения данных при этом сохраняются.

Обе категории предполагают подтверждение соответствия российскому законодательству и установленным требованиям. Правительство должно определить порядок учета и присвоения статуса суверенной и национальной модели. Поэтому этот механизм функционально может быть похож на реестр, однако в самом законе специальный «реестр доверенных моделей» уже не предусмотрен, и юридически отождествлять эти конструкции пока не следует.

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

По состоянию на 10 июля 2026 года законопроект № 1271570-8 принят Государственной Думой во втором и третьем чтениях и направлен в Совет Федерации.

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

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

Учитывая, что законопроект уже прошел все три чтения в Государственной Думе, вероятность его окончательного принятия в редакции, близкой к нынешней, достаточно высока. Однако основная регуляторная конкретика появится позднее: Правительству еще предстоит установить порядок учета и присвоения статусов, процедуру подтверждения соответствия, а также перечень случаев обязательного применения суверенных или национальных моделей. Именно эти подзаконные акты в конечном счете определят, насколько новый режим затронет частный бизнес.

 

Читайте также:

 

Редакция: Для каких отраслей использование российских моделей ИИ с высокой вероятностью станет обязательным в первую очередь? Почему именно для них?

Валерий Белов: В первую очередь я бы ожидал специальных требований в государственном управлении и на значимых объектах критической информационной инфраструктуры. Общественные деятели уже называли среди приоритетных направлений государственное управление, энергетику и иные значимые отрасли. Законопроект прямо позволяет Правительству РФ определять случаи обязательного применения суверенных или национальных моделей, а в банковской сфере и на финансовом рынке такие решения должны приниматься по согласованию с Банком России.

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

Финансовый сектор также находится в зоне повышенного внимания, поскольку ИИ уже применяется при скоринге, противодействии мошенничеству, проверке операций, клиентском обслуживании и оценке рисков. Ошибка или непрозрачное изменение модели в таких процессах может затронуть большое число клиентов.

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

 

Редакция: Что изменится для обычной компании, если она уже использует ChatGPT, Claude, Gemini или другие зарубежные ИИ-сервисы? Придется ли менять процессы?

Валерий Белов: Следует отметить, что в настоящее время сам по себе законопроект не вводит общего запрета на использование зарубежных ИИ-сервисов частным бизнесом. Обычной компании не придется автоматически отключать ChatGPT, Claude или Gemini только потому, что они не относятся к суверенным или национальным моделям.

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

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

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

 

При использовании зарубежного сервиса необходимо отдельно оценивать соблюдение требований к локализации персональных данных при их сборе и правил трансграничной передачи.
   /   

 

Редакция: Есть ли риск, что компания, продолжающая те или иные ИИ (суверенные или национальные), столкнется с ограничениями или повышенными юридическими рисками?

Валерий Белов: Само по себе использование модели, не относящейся к суверенным или национальным, пока не образует нарушение.

Риски возникнут, если Правительство установит для конкретной сферы или процесса требование применять исключительно суверенную или национальную модель. Тогда продолжение использования зарубежного решения может означать нарушение обязательных требований, условий государственного контракта, требований к объекту критической инфраструктуры, лицензированию или внутреннему контролю.

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

Поэтому риск определяется не столько происхождением модели, сколько совокупностью обстоятельств: какие данные она получает, какое решение принимает, насколько серьезны последствия ошибки и какие меры контроля применила компания.

 

Редакция: Стоит ли бизнесу уже сейчас готовиться к переходу на российские модели ИИ или пока преждевременно?

Валерий Белов: Представляется, что готовиться стоит ко всему Однако в текущих реалиях отсутствует однозначная возможность утверждать, что всем компаниям необходимо немедленно отказаться от зарубежных решений. Сейчас разумнее говорить не о срочной миграции, а о создании возможности выбора.

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

Параллельно можно проводить пилотное тестирование российских решений на собственных обезличенных наборах задач. Сравнивать нужно не только качество ответа, но и стоимость эксплуатации, скорость, устойчивость, возможность развертывания в закрытом контуре, доступность журналов событий и условия договора.

Главная ошибка — оказаться полностью зависимым от одной модели или одного поставщика.

 

Редакция: Если компания покупает ИИ-решение у российского разработчика, какие условия договора вы рекомендуете проверить в первую очередь?

Валерий Белов: Прежде всего необходимо точно описать, для какой цели приобретается решение. Формулировки вроде «предоставление доступа к платформе искусственного интеллекта» практически ничего не говорят о том, что обязан предоставить поставщик и какой результат вправе ожидать заказчик.

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

Отдельный блок должен регулировать данные: какие сведения передаются поставщику, где они хранятся, используются ли запросы и ответы для дополнительного обучения, кто имеет к ним доступ, привлекаются ли субподрядчики и в какой срок данные удаляются после прекращения договора.

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

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

 

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

 

Редакция: Какие положения договора сегодня чаще всего работают в интересах поставщика ИИ, но создают риски для заказчика?

Валерий Белов: Представляется, что наиболее распространенным является условие о предоставлении модели «как есть» без каких-либо гарантий точности, бесперебойности и пригодности для целей заказчика. Одновременно поставщик указывает в презентации, что продукт подходит для конкретного бизнес-процесса. Получается противоречие: при продаже решение позиционируется как профессиональный инструмент, а в договоре поставщик фактически ни за что не отвечает.

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

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

Часто ответственность поставщика ограничивается стоимостью одного месяца услуг, тогда как потенциальные убытки заказчика могут быть несопоставимо выше. При этом на заказчика перекладывается ответственность за любые результаты работы модели, даже если ошибка возникла из-за дефекта самого продукта или необъявленного обновления.

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

 

Редакция: Нужно ли отдельно прописывать порядок обновления модели, хранения данных, аудита и ответственность за изменение качества работы ИИ после обновлений?

Валерий Белов: Крайне желательно. Для ИИ-решений это не второстепенные технические детали, а существенная часть распределения рисков.

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

Поставщик должен заранее уведомлять о значимых изменениях. Заказчику необходимо предоставить возможность протестировать новую версию в изолированной среде, отложить ее установку, отказаться от обновления либо вернуться к предыдущей версии, если качество ухудшилось.

Следует определить, какие журналы событий ведутся, как долго они хранятся и можно ли по ним восстановить, какая версия модели использовалась, какой запрос был передан, какие настройки применялись и какой результат был получен. Без таких сведений установить причину ошибки и распределить ответственность будет крайне сложно.

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

Если после обновления модель перестает соответствовать согласованным требованиям, договор должен предусматривать конкретные последствия: устранение недостатков, откат версии, уменьшение платы, возмещение убытков или право заказчика отказаться от договора без штрафа.

 

Редакция: Можете привести пример ситуации, когда ответственность действительно может быть возложена на разработчика ИИ, а не на компанию, которая использовала систему?

Валерий Белов: Представим, что разработчик поставляет модель для выявления мошеннических банковских операций и заявляет, что она протестирована для соответствующего сценария. После внедрения выясняется, что модель систематически пропускает определенный тип операций из-за ошибки в механизме обработки данных. Разработчик осознает наличие дефекта, но не сообщает о нем заказчику. В таком случае если банк использовал модель в пределах заявленного назначения, выполнил инструкции по интеграции, обеспечил предусмотренный договором контроль и не мог выявить скрытый дефект обычными средствами, основания для ответственности разработчика будут достаточно серьезными.

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

Важно отметить, что перед конечным клиентом первоначально может отвечать компания, оказавшая услугу или принявшая решение. Фраза «это решил искусственный интеллект» не должна становиться новым способом ухода от ответственности. В правовом смысле решение принимает не ИИ, а организация, которая встроила его в свой процесс. При этом после возмещения ущерба компания вправе предъявить требования к разработчику или интегратору, если докажет нарушение договора, наличие дефекта и причинную связь между этим дефектом и наступившими последствиями.

 

Редакция: Если ошибка возникла одновременно из-за модели, интегратора и пользователя, как, по вашему мнению, суд будет распределять ответственность?

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

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

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

Во внутренних отношениях между заказчиком, разработчиком и интегратором суд будет оценивать договорные обязанности, степень вины и причинную связь. Если нарушение произошло по вине обеих сторон договора, размер ответственности может быть уменьшен.

Если же действия нескольких лиц совместно причинили единый и неделимый вред, возможно применение правил о солидарной ответственности. Лица, совместно причинившие вред, отвечают перед потерпевшим солидарно, а тот, кто выплатил возмещение, затем может предъявить регрессные требования к остальным участникам в соответствии со степенью их вины. Если определить степень вины невозможно, доли могут быть признаны равными.

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