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

Какие критерии обсуждались

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

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

Что нужно описать в продукте

В договоре на использование ИИ определите, предоставляется ли доступ к сервису, программа, лицензия на отдельные компоненты или комплекс услуг. От модели зависит содержание обязательств поставщика.

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

Как проверить заявления поставщика

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

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

Как описать состав ИИ-продукта в договоре

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

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

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

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