Методические рекомендации по переходу на российское программное обеспечение и включение продукта в реестр российского ПО относятся к разным процедурам. Рекомендации помогают организовать миграцию на отечественные решения, а реестровая процедура требует отдельно подтвердить сведения о программе, правообладателе и исключительных правах. Сначала нужно определить, какой результат требуется организации или разработчику.
Коротко о главном
- Единый реестр российских программ для электронных вычислительных машин и баз данных формируется и ведётся на основании постановления Правительства России от 16 ноября 2015 года № 1236.
- Приказ Минцифры России от 18 января 2023 года № 21 утвердил методические рекомендации по переходу на использование российского программного обеспечения. Он не устанавливает процедуру включения продукта в реестр.
- Для подачи заявления важны сведения о правообладателе, цепочке исключительных прав, назначении и составе программного продукта.
- Добровольный сертификат соответствия решает отдельную задачу и не заменяет реестровую запись.
- Программное ИИ-решение рассматривают в контексте реестра российского ПО, если объектом выступает программа для ЭВМ или база данных.
- Реестр российской промышленной продукции Минпромторга России применяется к другой категории объектов и действует по иным правилам.
Что понимают под методическими рекомендациями по российскому ПО
Запрос «методические рекомендации реестр российского ПО» объединяет организационную и реестровую задачи. Первая связана с планированием перехода на отечественное программное обеспечение, вторая касается признания статуса конкретной программы в порядке, установленном правилами ведения реестра. Тематически процессы связаны, поскольку реестровая запись помогает заказчику проверить статус продукта, но один процесс не запускает другой автоматически.
Приказ Минцифры России от 18 января 2023 года № 21 посвящён мерам по ускорению перехода органов государственной власти и организаций на российское программное обеспечение, в том числе на значимых объектах критической информационной инфраструктуры. Методические рекомендации задают подход к организации перехода, а не создают для каждого коммерческого предприятия одинаковую обязанность заменить весь используемый софт.
Работа начинается с инвентаризации ИТ-ландшафта. Организация определяет используемые программы, владельцев систем, критичные функции, интеграции и зависимости от внешних сервисов. Затем специалисты оценивают совместимость российских решений, возможность переноса данных, потребность в доработке инфраструктуры, обучение пользователей и риски остановки процессов.
Для владельцев значимых объектов критической информационной инфраструктуры вопрос рассматривают с учётом Федерального закона «О безопасности критической информационной инфраструктуры Российской Федерации» и специальных требований, применимых к конкретному объекту. Такой статус нельзя переносить на любую информационную систему или коммерческую компанию только из-за использования серверов, облачных сервисов либо средств защиты информации.
Внутренний переходный план утверждает уполномоченное лицо организации в рамках принятой системы управления. Сам по себе приказ Минцифры России № 21 не означает, что такой внутренний документ нужно автоматически согласовывать с Минцифры России.
Чем переход на российское ПО отличается от включения программы в реестр
Переход на использование российского программного обеспечения
Переход представляет собой проект изменения ИТ-ландшафта. Государственный орган или компания анализирует действующие системы, определяет очередность их замены и проверяет, сможет ли российское программное обеспечение выполнять нужные функции без неприемлемого нарушения процессов.
Одна только проверка названия продукта в реестре не отвечает на вопросы совместимости. Заказчику нужно оценить форматы данных, интерфейсы обмена, зависимость от операционной системы, интеграции с оборудованием, требования к производительности, порядок обновлений и условия предоставления технической поддержки. Для SaaS-сервиса отдельно рассматривают размещение инфраструктуры, доступ к данным и границы ответственности поставщика.
По результатам анализа организация формирует последовательность миграции. В неё могут входить пилотное использование, перенос справочников и архивов, проверка интеграций, подготовка пользователей, переключение рабочих процессов и контроль после запуска. Состав действий зависит от масштаба системы и последствий возможного сбоя.
Включение программы в реестр российского ПО
Включение в реестр относится к определённой программе для электронных вычислительных машин или базе данных. Правообладатель готовит заявление и сведения, позволяющие идентифицировать продукт, оценить права на него, понять назначение, функциональные характеристики, состав и способ предоставления пользователю.
Базовые правила формирует постановление Правительства России от 16 ноября 2015 года № 1236. Минцифры России связано с ведением Единого реестра российских программ для ЭВМ и баз данных. Актуальные требования формы заявления и состава сведений нужно проверять на момент подачи, поскольку описание продукта должно отвечать действующим правилам, а не старому шаблону из ранее подготовленного комплекта.
Реестровая запись нужна, когда на неё ссылаются закупочная документация, требование заказчика, внутренний регламент или условия отраслевой платформы. Российское происхождение компании, наличие сайта, регистрация программы для ЭВМ, договор с заказчиком или добровольный сертификат сами по себе не означают, что продукт уже включён в реестр.
Организация вправе переходить на российское ПО, не будучи разработчиком и заявителем. Разработчик, в свою очередь, может готовить продукт к включению в реестр независимо от конкретного проекта миграции заказчика.
Какой реестр нужен: ПО, промышленная продукция или иной документ
Название требуемого документа нельзя определять только по словам «российский продукт» или «сертификация». Программы, оборудование, средства защиты информации и промышленная продукция относятся к разным процедурам. Даже похожие по названию реестры ведут разные органы и используют разные основания для внесения сведений.
| Задача | Какой документ или механизм рассматривают | Что он не заменяет |
|---|---|---|
| Подтвердить статус программы для ЭВМ или базы данных | Включение в Единый реестр российских программ для ЭВМ и баз данных по постановлению Правительства России № 1236 | Подтверждение производства оборудования или иной промышленной продукции |
| Подтвердить производство промышленной продукции на территории России | Механизм, предусмотренный постановлением Правительства России от 17 июля 2015 года № 719 | Реестровую запись на самостоятельный программный продукт |
| Подтвердить заявленные характеристики ПО по требованию заказчика | Добровольный сертификат соответствия в выбранной системе добровольной сертификации | Включение в реестр российского ПО и подтверждение исключительных прав |
| Проверить разрешительный статус деятельности в сфере защиты информации | Соответствующую лицензию и запись в профильном реестре, если такая лицензия требуется для конкретной деятельности | Статус российского происхождения программного продукта |
Реестр российского ПО Минцифры России
Этот реестр предназначен для программ для ЭВМ и баз данных. Он релевантен разработчикам корпоративных систем, мобильных приложений, отраслевых программ, программных комплексов, SaaS-решений и продуктов, использующих технологии искусственного интеллекта, если заявляемым объектом выступает программное обеспечение.
Если ИИ-система распознаёт изображения, анализирует видео или формирует прогнозы, одного упоминания искусственного интеллекта недостаточно. В документации нужно раскрыть назначение программы, состав модулей, пользовательские функции, используемые компоненты и порядок предоставления доступа.
Реестр российской промышленной продукции
Постановление Правительства России от 17 июля 2015 года № 719 регулирует подтверждение производства промышленной продукции на территории России. Эту процедуру связывают с Минпромторгом России. Она не заменяет включение самостоятельной программы в реестр российского ПО.
Программный модуль не становится промышленной продукцией только потому, что его используют на производстве или устанавливают на оборудование. Если заявитель поставляет программно-аппаратный комплекс, нужно разделить объекты и определить требования к каждому из них: оборудованию, встроенным компонентам, самостоятельному ПО и сопутствующим услугам.
Добровольный сертификат соответствия на ПО
Добровольную сертификацию рассматривают, если заказчик, договор, техническое задание или регламент платформы требует подтвердить определённые характеристики программного продукта. До оформления нужно установить объект оценки, нормативный документ, перечень проверяемых характеристик и ожидаемую форму результата.
Сертификат не подтверждает реестровый статус и не создаёт реестровую запись. Испытания и доказательные материалы зависят от заявленных характеристик и правил выбранной системы сертификации. Протокол нельзя составлять по произвольному перечню свойств: он должен отражать объект и применённые методы. Этот принцип виден и в других областях оценки соответствия, где протокол испытаний привязан к конкретным показателям и методам контроля.
Другие государственные реестры тоже нельзя использовать как взаимозаменяемые доказательства. Например, проверка сведений в реестре лицензий ФСБ России отвечает на вопрос о наличии определённой лицензии, но не подтверждает включение программного продукта в реестр Минцифры России.
Что проверить разработчику до подачи заявления в реестр российского ПО
Предварительная проверка нужна не ради формального комплекта. Она помогает выявить расхождения между договорами, архитектурой программы, пользовательской документацией и сведениями, которые правообладатель собирается указать в заявлении.
- Права на программу и статус правообладателя. Установите, кому принадлежат исключительные права на продукт и его существенные части. Проверьте договоры с авторами, работниками, разработчиками и подрядчиками, акты передачи результатов, служебные задания и условия перехода прав. Наименование правообладателя в документах должно соответствовать сведениям заявления.
- Описание функциональности. Зафиксируйте, какие задачи решает программа, кто ею пользуется и какие операции доступны пользователю. Для модульного продукта раскройте состав решения и взаимосвязь компонентов. Для облачного сервиса опишите порядок доступа, а для локального ПО укажите способ установки и эксплуатации.
- Архитектура программного продукта. Разграничьте основную программу, базу данных, встроенные модули, интеграции, внешние API и инфраструктурные сервисы. Публичное описание продукта не должно противоречить техническим материалам.
- Техническая и пользовательская документация. Подготовьте материалы, которые объясняют назначение, функции, состав и порядок использования ПО. Для сложного программного комплекса отдельно опишите границы продукта и зависимость от внешних систем.
- Сторонние компоненты. Проверьте библиотеки, фреймворки, программные платформы, облачную инфраструктуру, базы данных и ИИ-модели. Зафиксируйте лицензионные условия и правовые основания использования компонентов. Допустимость конкретного элемента оценивают с учётом актуальных требований и его роли в архитектуре.
- Версия и способ поставки. Сопоставьте версию продукта в документации, интерфейсе, лицензионных материалах и заявлении. Уточните, получает ли пользователь экземпляр программы, доступ к облачному сервису или право использовать программный комплекс на иных условиях.
Какие документы обычно готовят
Состав комплекта зависит от конкретного программного продукта и актуальных требований процедуры, но предварительно обычно собирают следующие группы сведений:
- Сведения о правообладателе. Данные должны позволять идентифицировать заявителя и сопоставить его с документами на исключительные права.
- Документы о правах на программу. В комплект включают применимые договоры, акты, документы о служебных произведениях и иные материалы, подтверждающие возникновение либо переход исключительных прав.
- Описание функциональности. Оно раскрывает назначение, категории пользователей, основные функции и сценарии применения продукта.
- Пользовательская документация. Инструкции должны объяснять порядок установки, настройки, доступа и использования программы в зависимости от модели поставки.
- Технические материалы. В них описывают состав продукта, архитектуру, модули, интеграции и внешние зависимости в объёме, необходимом для проверки сведений.
- Информация о версии и назначении. Эти данные позволяют отличить заявляемый продукт от других редакций, модулей и решений правообладателя.
- Сведения о лицензионной модели. Правообладатель описывает порядок предоставления экземпляра программы или доступа к сервису.
- Материалы о сторонних компонентах. Их готовят, если библиотеки, платформы, базы данных, модели или внешние сервисы существенны для работы продукта.
- Сведения по форме заявления. Перед подачей комплект сверяют с действующими правилами ведения реестра и требованиями информационной системы.
Этот перечень не исчерпывающий. Для базы данных, мобильного приложения, локальной корпоративной системы и SaaS-продукта набор пояснений различается, поскольку отличаются архитектура, порядок доступа и состав зависимостей.
Как выстроить подготовку: практический алгоритм
- Определить цель. Зафиксируйте, зачем нужен документ: для государственной закупки, требования корпоративного заказчика, регистрации на платформе, подтверждения статуса продукта или планирования миграции.
- Разделить процедуры. Установите, требуется ли реестровая запись, добровольный сертификат соответствия, документ на промышленную продукцию, подтверждение прав или внутренний переходный план.
- Проверить правообладателя. Сопоставьте сведения о заявителе с договорами, актами, служебными заданиями и документами о переходе исключительных прав.
- Провести аудит продукта. Сверьте фактическую архитектуру, состав модулей, сторонние компоненты, версии, модель поставки и публичное описание программы.
- Подготовить сведения. Соберите документацию на программный продукт и заполните заявление по актуальной форме. Названия, версии, функции и состав ПО должны совпадать во всех материалах.
- Проверить комплект и подать заявление. До отправки устраните противоречия между документами. После подачи правообладатель или его представитель отвечает на запросы, поступающие в рамках рассмотрения.
А что делать, если заказчик написал только «нужна сертификация ПО»? Сначала запросить точный текст требования, основание и ожидаемый документ. Без этого разработчик рискует оформить добровольный сертификат, когда заказчику нужна реестровая запись, либо начать реестровую процедуру для задачи, которую решает другой документ.
Частые сложности и как их решить
В требовании заказчика сказано «сертификат на ПО», но не указан вид документа
Запросите полную формулировку, ссылку на пункт закупочной документации или договора, требования к системе сертификации и ожидаемому результату. Слово «сертификат» не означает автоматически ни включение в реестр российского ПО, ни обязательную оценку соответствия.
У продукта несколько разработчиков и подрядчиков
Проверьте договоры, акты, служебные задания и условия перехода исключительных прав. Если документы называют разные объекты или не позволяют проследить передачу прав, сначала нужно устранить противоречия. Письмо подрядчика без анализа договора не всегда закрывает вопрос о правообладании.
Продукт работает как облачный сервис
Отдельно опишите программную часть, способ предоставления доступа, состав сервиса, внешнюю инфраструктуру и функции, за которые отвечает правообладатель. Документация должна показывать границы заявляемого продукта, а не только коммерческое название SaaS.
В составе решения используются ИИ-модели и сторонние библиотеки
Раскройте конкретную функциональность, перечень существенных компонентов и основания их использования. Маркетинговая формулировка «искусственный интеллект» не объясняет архитектуру программы и не подтверждает права на модель, библиотеку, обучающие материалы или внешний API.
Описание на сайте отличается от технической документации
До подачи приведите сведения к непротиворечивому виду. Особенно внимательно проверяют название продукта, версию, состав модулей, способ предоставления доступа и правообладателя. Расхождения усложняют идентификацию программного продукта.
Пример из практики: как уточняют требование к документам на ПО
В «Реестр Гарант» обратился разработчик, которому для регистрации на платформе, обозначенной заказчиком как «Госпех», потребовалась «сертификация программного обеспечения». Нужного документа разработчик не нашёл в перечне платформы, поэтому подтвердить вид процедуры по устному описанию было нельзя.
До оценки оформления специалисты запросили точную формулировку требования. Одновременно разграничили два возможных направления: добровольный сертификат соответствия и включение программы в реестр российского ПО. Это разные механизмы, и ни один из них нельзя выбирать только по общему слову «сертификация».
Ситуация показывает практическое правило: пока заказчик или владелец платформы не предоставил текст требования, нельзя достоверно утверждать, какой документ нужен, требуется ли оценка соответствия и заменяет ли один документ другой.
Частые вопросы
Нужны ли на программное обеспечение сертификаты?
Не для каждого программного продукта. Необходимость зависит от договора, закупочной документации, требований заказчика, отраслевой платформы или внутреннего регламента. Добровольный сертификат соответствия и включение в реестр российского ПО подтверждают разные обстоятельства.
Вы делаете сертификацию программного обеспечения для регистрации на платформе Госпех?
Сначала нужно изучить точную формулировку требования платформы или заказчика. Под названием «сертификация ПО» могут подразумеваться добровольный сертификат, реестровая запись или иной документ. Без текста требования нельзя корректно выбрать процедуру.
Какие варианты вы можете предложить?
В зависимости от цели рассматривают включение в реестр российского ПО, подготовку документов о статусе и правах на продукт либо добровольную сертификацию соответствия. Выбор определяет результат, который требует заказчик или владелец платформы.
Можете подробнее проконсультировать по этому вопросу?
Для предметной оценки нужны сведения о правообладателе, назначении программы, архитектуре, модели предоставления доступа и сторонних компонентах. Также потребуется точный текст требования, ради которого оформляют документ.
Можно ли включить в реестр программное обеспечение с искусственным интеллектом?
Программное ИИ-решение рассматривают как программу для ЭВМ или базу данных с учётом его фактической функциональности и состава. Использование ИИ само по себе не заменяет проверку правообладателя, исключительных прав, архитектуры и сторонних компонентов.
Добровольный сертификат заменяет запись в реестре российского ПО?
Нет. Сертификат подтверждает заявленные характеристики в рамках выбранной системы добровольной сертификации. Реестровая запись подтверждает включение продукта в Единый реестр российских программ для ЭВМ и баз данных по отдельной процедуре.
Итоги
- Методические рекомендации Минцифры России регулируют подход к переходу на российское программное обеспечение, но не устанавливают процедуру включения конкретной программы в реестр.
- Подготовка к реестровой процедуре начинается с проверки правообладателя, исключительных прав, состава продукта и документации.
- Реестр российского ПО, реестр промышленной продукции и добровольная сертификация решают разные задачи.
- При неясном требовании заказчика сначала нужно получить его полный текст и определить ожидаемый результат.
Корректный маршрут зависит от объекта и цели оформления. Специалисты центра «Реестр Гарант» могут сопоставить требование заказчика с документами на программный продукт и отделить реестровую процедуру от добровольной сертификации без обещания включения до проверки оснований.