Для включения программы в реестр российского ПО недостаточно презентации продукта и свидетельства о регистрации авторских прав. Эксперту нужно понять, что делает программа, как её запустить и проверить, кто поддерживает продукт и где находятся средства хранения кода, сборки и управления лицензиями. Юридические документы проверяются отдельно от технических.
В GLS Expert мы начинаем подготовку с работающей версии программы. Затем сопоставляем её функции, документы и сведения заявления. Такой порядок помогает обнаружить расхождения до подачи. Ниже объясняем, что требуют правила реестра и как самостоятельно подготовить содержательные документы. Условия сверены на 6 октября 2026 года.
Что входит в пакет по правилам, а что помогает пройти проверку
Пункт 11 Правил, утверждённых постановлением Правительства РФ №1236, перечисляет документы и материалы для заявления. Среди них — экземпляр ПО с возможностью законно использовать его для проверки, документы о полномочиях и правообладателе в применимых случаях, а также несколько направлений технической документации.
Фиксированного универсального ответа «нужны ровно четыре PDF» нет. Важно раскрыть требуемые сведения и правильно приложить их в действующей форме заявления. Один красиво оформленный файл не компенсирует отсутствующие сведения о сборке или неработающий доступ к продукту.
| Блок документации | Что означает требование | Что подготовить по существу |
|---|---|---|
| Функциональные характеристики | Какие задачи выполняет именно заявленная программа | Назначение, пользователи, функции, входные данные и результат, ограничения |
| Установка и эксплуатация | Как получить работоспособную программу и пользоваться ею | Среда, зависимости, последовательность запуска, настройки, роли, основные операции |
| Поддержание жизненного цикла | Кто и как исправляет ошибки и развивает продукт | Процесс обработки обращений, исправления, проверки и выпуска изменений, необходимый персонал |
| Хранение кода и компиляция | Где хранятся исходный и объектный код и как получается исполняемая версия | Технические средства, их размещение, последовательность сборки и ответственные |
| Активация и лицензионные ключи | Как разрешается использование продукта и кто управляет этим механизмом | Средства активации, выпуска, распространения и управления ключами либо описание фактически используемой модели |
| Совместимость и специальные основания | Какие дополнительные требования применимы к продукту и правообладателю | Подтверждения по действующей редакции правил с учётом класса ПО, даты и установленных исключений |
Сценарии проверки, понятные скриншоты и таблица ролей — полезные способы раскрыть содержание. Их не следует выдавать за отдельные обязательные формы, если такой формы нет в правилах или текущих требованиях к подаче.
Общий порядок вступления, права и корпоративные условия разобраны в инструкции по реестру российского ПО. Здесь сосредоточимся на документации, по которой можно воспроизвести работу продукта.
Функциональное описание: покажите действие и результат
Фраза «система автоматизирует бизнес-процессы» не объясняет, что именно эксперт должен проверить. Для каждой основной функции назовите пользователя, исходные данные, действие и наблюдаемый результат. Укажите, что входит в поставку, а что выполняется внешним сервисом или отдельным модулем.
Условный пример — программа складского учёта. Вместо «управление запасами в едином окне» полезно объяснить: кладовщик загружает файл с поступлениями, программа проверяет артикулы и количество, создаёт документ приёмки и увеличивает остатки на выбранном складе. Строки с неизвестным артикулом отклоняются с указанием причины. Это пример описания, а не история клиента GLS Expert.
| Слишком общее утверждение | Что уточнить для проверки |
|---|---|
| «Есть аналитика» | Какие показатели рассчитываются, из каких данных, за какой период и где виден результат |
| «Поддерживается интеграция» | С какой системой, в каком направлении передаются данные, что требуется настроить, как обрабатывается ошибка |
| «Есть разграничение доступа» | Какие роли существуют и какие действия запрещены каждой роли |
| «Используется искусственный интеллект» | Какую конкретно функцию он выполняет, где проходит вычисление, как проверяется результат и какие есть ограничения |
Не включайте в текущую функциональность план разработки на следующий год. Если модуль только проектируется, он не должен выглядеть доступным в проверяемой версии.
Установка: сможет ли другой специалист запустить продукт
Проверяющий не знает настроек компьютера разработчика. В инструкции должны быть все существенные предварительные условия: операционная система и её версия, необходимые компоненты, требования к ресурсам, права пользователя, сетевые условия и порядок получения проверяемого экземпляра.
Для устанавливаемой программы разберите последовательность от чистой среды до первого успешного действия:
- Подготовка среды. Укажите поддерживаемые версии ОС, базы данных и других обязательных компонентов. Ссылка «скачать последнюю версию» может привести к несовместимому выпуску.
- Получение и установка. Объясните, какой комплект использовать, как выполнить установку и какие сообщения означают успешное завершение.
- Первый запуск. Опишите создание учётной записи, подключение базы, настройки и активацию, если она нужна.
- Контрольный сценарий. Проведите пользователя через одну основную операцию с безопасными тестовыми данными и понятным результатом.
- Восстановление после ошибки. Покажите, где найти диагностическую информацию и как передать обращение в поддержку. Не обещайте автоматическое восстановление, если его нет.
Для облачного продукта отдельно объясните клиентскую часть: поддерживаемый браузер, порядок входа, роли, доступные функции и ограничения демонстрационной среды. Способ предоставления экземпляра и доступа для экспертизы сверяйте с действующей процедурой. Одна публичная посадочная страница с кнопкой «заказать» не даёт возможности проверить ПО.
Учётная запись для проверки должна открывать заявленные функции на согласованный период. Если нужная операция доступна только администратору, а эксперту выдана роль наблюдателя, содержание документации и фактическая проверка разойдутся. Используйте отдельные тестовые данные, без персональных данных клиентов и доступа к их рабочим средам.
Совместимость: учитывайте класс ПО и дату требований
В действующих правилах есть требование о совместимости не менее чем с двумя операционными системами, отвечающими требованиям к доверенному ПО, и предусмотрены отдельные исключения для совместимости с одной ОС. Постановление №1937 вводит применение этого условия поэтапно: для офисного ПО — с 1 сентября 2026 года, для других перечисленных групп — по установленным датам 2027 года.
Поэтому перед подготовкой доказательств определите класс своей программы и применимую дату. Нельзя заменить это проверкой «работает в любом Linux» или автоматически распространить срок для офисного пакета на всё прикладное ПО. Для ПО в составе программно-аппаратного комплекса дополнительно учитывайте специальные правила; эта статья не описывает полный пакет регистрации ПАК.
В документах фиксируйте точные наименования и версии ОС, проверенную версию программы, выполненные операции и результат проверки. Если используются серверная и клиентская части, объясните, к какой части относится каждый результат. Документы должны подтверждать фактическую совместимость, а не только намерение её добавить.
Жизненный цикл: кто устранит ошибку после включения в реестр
Фраза «техническая поддержка осуществляется разработчиком» не раскрывает процесс. Из документа должно быть понятно, как компания получает сообщение об ошибке, устанавливает причину, готовит исправление, проверяет его и передаёт пользователю новую версию.
Опишите реальную организацию работы:
- Куда поступает обращение и какие сведения нужны для воспроизведения ошибки.
- Кто разбирает обращение, кто меняет код и кто проверяет исправление.
- Как различаются ошибка продукта, вопрос пользователя и предложение новой функции.
- Как выпускается обновление, как пользователь о нём узнаёт и какие действия от него требуются.
- Какой персонал нужен для сопровождения: функции, квалификация и распределение ответственности.
Правила предъявляют требования к тому, кто осуществляет поддержку и модернизацию. Указание иностранного подрядчика как единственного исполнителя такой работы требует проверки соответствия. Не пишите о круглосуточной поддержке, если её нет в договоре и фактическом процессе.
Срок реакции на обращения можно указать, если он действительно установлен. Не придумывайте соглашение об уровне сервиса ради убедительности заявки. Небольшой команде полезнее правдиво описать ответственных и последовательность действий, чем заявить несуществующие отделы.
Код, сборка и лицензирование: назовите реальные технические средства
Требование о технических средствах хранения кода и компиляции означает, что нужно описать, где находятся исходные тексты, готовые сборки и средства, с помощью которых из исходников получается продукт. Для этих средств правила предусматривают размещение на территории России.
Проверьте всю последовательность. Репозиторий может находиться в России, а автоматическая сборка — выполняться на иностранной инфраструктуре. Одной фразы «сервер отечественного провайдера» недостаточно, если она относится только к сайту продукта. Укажите фактическую среду хранения, сборки, размещение и способ управления доступом. Полезно сопоставить описанную процедуру с выпуском той версии, которую подаёте на проверку.
Отдельно разберите механизм активации и управления лицензиями. Если есть сервер ключей, опишите его назначение, размещение и контроль. Если используется подписка или иной механизм доступа без привычных ключей, объясните действительную модель; отсутствие ключа в интерфейсе само по себе не отменяет проверку применимых требований.
Описание инфраструктуры не означает публикацию исходного кода, паролей или закрытых ключей. Публичные документы и материалы, передаваемые для экспертизы предусмотренным способом, нужно разграничить. Перед размещением удалите секреты, персональные данные и действующие учётные данные из скриншотов и примеров.
Как проверить пакет до подачи
Начните с фиксации версии: название продукта, номер выпуска, правообладатель и состав поставки должны согласовываться в заявлении, документах и проверяемом экземпляре. Переименование компании или программы нужно отразить последовательно, а не только на обложке руководства.
Затем проведите проверку с коллегой, который не участвовал в настройке демонстрационной среды:
- Передайте ему те же инструкции и разрешённый доступ, которые подготовлены для проверки.
- Попросите выполнить установку или вход и основные сценарии без устных подсказок разработчика.
- Запишите места, где понадобилась помощь: пропущенная зависимость, неверное название кнопки, отсутствующая роль, истёкшая лицензия.
- Исправьте документы или программу, затем повторите именно неудачные действия.
- Сверьте итоговые файлы и доступность опубликованных документов с текущими полями заявления. Не заменяйте проверяемую сборку без оценки влияния на пакет.
Это внутренний способ подготовки, а не отдельная обязательная процедура Минцифры. Его результат — воспроизводимый сценарий и устранённые расхождения; он не гарантирует положительного решения.
Ошибки, которые не исправить одним новым PDF
Если исключительные права не оформлены, техническое руководство не восполнит этот пробел. Документы на разработку сотрудниками и подрядчиками нужно проверять отдельно; подробнее — в материале о правах на разработку.
Если продукт не выполняет заявленную функцию, сначала исправьте продукт или корректно ограничьте заявление. Если используемая инфраструктура не соответствует правилам, потребуется техническое изменение, а не замена названия провайдера в тексте. Причины замечаний разобраны в статье об отказе во включении в реестр ПО.
Ещё одна ошибка — обещать общий срок включения на основании срока одного этапа рассмотрения. Подготовка, регистрация заявления, экспертиза и ответы на запросы — разные действия. Планируйте работу с учётом состояния программы и документов, а сроки внешнего рассмотрения сверяйте с действующей процедурой.
Как GLS Expert помогает с подготовкой
Для первичной оценки достаточно описания продукта, его модели поставки, сведений о правообладателе и перечня уже имеющихся документов. Конфиденциальный код и доступ к рабочим системам в общую форму отправлять не нужно.
Мы можем проверить комплектность и согласованность пакета, перевести техническое описание в понятные проверяемые сценарии, выявить пробелы в документах и согласовать сопровождение подачи. Разработчики подтверждают реальные функции и инфраструктуру; неподтверждённые сведения в заявку не включаем. Стоимость зависит от объёма необходимых работ и состояния исходных материалов.
Обсудить подготовку можно на странице включения в реестр российского ПО. Если проблема связана с правами или технической готовностью продукта, сначала определим эти работы и их исполнителей.
