Подача ПАК в реестр Минцифры «на удачу» в 2026 году остаётся рискованной: эксперты смотрят не только на комплект документов, но и на связку программной и аппаратной частей. Предварительный аудит помогает до подачи выявить слабые места в архитектуре, правах, спецификациях и доказательной базе.
Корректная терминология: отдельного «реестра ПАК» нет. Программно-аппаратный комплекс включается как категория записи в Единый реестр российских программ для ЭВМ и БД. Оператор — Минцифры России, подача идёт через reestr.digital.gov.ru по правилам ПП РФ № 1236.
Зачем нужен аудит ПАК перед подачей
Аудит ПАК нужен не для красивого отчёта, а для проверки готовности заявки до того, как она уйдёт на экспертизу. Если слабые места выявлены заранее, заявитель может доработать архитектуру, закрыть документы по правам, уточнить описание аппаратной части и снизить риск запросов, приостановки или отказа.
Важно не обещать «гарантированное включение с первой попытки». Решение принимает экспертный совет по реестру. Задача аудита — показать реальную картину: какие требования уже закрыты, какие подтверждены слабо, что нужно исправить до подачи и какие сроки это займёт.
I. Технологический аудит: проверка связки ПО и оборудования
Для ПАК ключевой вопрос — действительно ли программная часть является управляющей и функционально определяющей работу комплекса, а не просто установлена рядом с аппаратурой. Если ПО можно без потери смысла перенести на любое стороннее оборудование, доказательная база ПАК требует усиления.
| Что проверяем | Зачем это нужно | Типовой риск |
|---|---|---|
| Архитектуру ПАК | Показать, как модули ПО управляют аппаратной частью и обмениваются данными | Комплекс выглядит как обычное ПО на стандартном оборудовании |
| Аппаратную привязку | Описать контроллеры, датчики, платы, устройства, интерфейсы и их роль | В спецификации нет функциональной связи между ПО и железом |
| Зависимости и компоненты | Проверить сторонние библиотеки, облачные сервисы, обновления и импортозависимость | Есть неподтверждённые иностранные компоненты или внешние сервисы |
| Совместимость | Понять, применимы ли требования по совместимости и доверенному ПО | Заявитель переносит требования ПП № 1937 без учёта исключений для ПАК |
II. Юридический аудит: права и структура владения
Даже технически сильный ПАК может получить замечания, если не подтверждены права на программную часть, исходный код, документацию, товарные знаки, компоненты или аппаратную спецификацию. Для реестра важно, чтобы правообладатель мог доказать законность использования и развития продукта.
- Права на ПО: договоры разработки, служебные задания, акты, передача исключительных прав, права на доработки.
- Сторонние компоненты: лицензии, условия использования библиотек, SDK, драйверов, прошивок и open source.
- Аппаратная часть: спецификация, происхождение, права использования, договоры поставки и технические описания.
- Корпоративная структура: сведения о правообладателе и контроле, которые могут быть значимы для критериев реестра.
- Связь с ГИСП: проверяется только если аппаратная часть отдельно заявляется как промышленная продукция; для каждого ПАК это не автоматическое требование.
III. Документальный аудит: комплект заявки
Документы должны описывать один и тот же продукт без противоречий. Наименование ПАК, версия ПО, состав аппаратной части, функциональные возможности, схемы архитектуры и инструкции должны совпадать между собой. Разнобой в названиях и версиях часто создаёт больше вопросов, чем сама технология.
| Документ | Что сверяем |
|---|---|
| Техническое описание | Функции ПАК, роль ПО, состав аппаратной части, схемы взаимодействия |
| Руководства пользователя и администратора | Русский язык, актуальные версии, сценарии установки и эксплуатации |
| Документы по правам | Правообладатель, разработчики, договоры, акты, лицензии компонентов |
| Спецификация аппаратной части | Комплектность, производители, модели, функциональная роль оборудования |
| Протоколы и результаты испытаний | Реальность данных, связь с заявленной версией ПАК, воспроизводимость проверок |
Сроки и маршрут проверки
По факт-базе реестра российского ПО срок рассмотрения заявки по регламенту — до 44 рабочих дней. На практике вместе с подготовкой, ответами на запросы и доработками горизонт часто составляет 60–90 рабочих дней. Если заявитель идёт дальше к доверенному статусу по ПП № 1937, это отдельный процесс, и его нельзя смешивать с базовым включением ПАК в реестр.
Частая ошибка: считать, что аудит заменяет экспертизу Минцифры. Аудит помогает подготовиться и снизить риск отказа, но итоговое решение остаётся за экспертным советом.
Результат аудита: дорожная карта исправлений
Итоговый отчёт должен быть практичным: не общий список замечаний, а карта действий до подачи. Для каждого риска указываются последствия, нужные документы, ответственный блок и приоритет исправления.
- Реестр рисков. Критические, высокие и средние замечания по архитектуре, правам, документам и срокам.
- План доработок. Что изменить в техническом описании, спецификации, договорах, инструкциях и доказательствах.
- Пакет документов. Перечень файлов, которые нужно подготовить или обновить перед подачей.
- Прогноз сроков. Реалистичная оценка времени на исправление и подачу заявки.
- Решение по маршруту. Подавать как ПАК, сначала включить ПО, доработать аппаратную часть или разделить продуктовую линейку.
Когда ПАК лучше не подавать сразу
Иногда аудит показывает, что продукт пока не готов к подаче именно как ПАК. Например, аппаратная часть описана слишком общо, ПО не определяет работу комплекса, права на код оформлены частично, а спецификация содержит неподтверждённые импортные компоненты. В такой ситуации лучше доработать досье, чем получить отказ и потерять время.
Отдельный вариант — сначала включить программную часть в реестр российского ПО, а затем готовить ПАК или доверенный статус. Такой маршрут зависит от архитектуры продукта и коммерческой задачи, поэтому его нужно выбирать после проверки документов.
FAQ
Короткие ответы на вопросы, которые чаще всего возникают при подготовке документов и подаче заявки.
ПАК включают в отдельный реестр?
Нет. ПАК включается как категория записи в Единый реестр российских программ для ЭВМ и БД Минцифры. Отдельного самостоятельного «реестра ПАК» нет.
Можно ли гарантировать включение ПАК с первой подачи?
Нет. Итоговое решение принимает экспертный совет. Профессиональный аудит снижает риск отказа, помогает заранее закрыть слабые места и подготовить доказательства, но не заменяет экспертизу.
Какие главные причины отказа по ПАК?
Чаще всего проблемы связаны со слабой связкой ПО и оборудования, неполными правами на код, противоречиями в документах, неподтверждёнными компонентами и некорректным описанием аппаратной части.
Нужен ли ГИСП для подачи ПАК в реестр Минцифры?
Не всегда. ГИСП относится к реестрам промышленной продукции Минпромторга. Для ПАК Минцифры он может быть связан только с отдельной задачей по аппаратной части, но не является обязательным этапом для каждой заявки.
Сколько длится рассмотрение заявки?
Регламентный срок рассмотрения заявки в реестр российского ПО — до 44 рабочих дней. С подготовкой, запросами и доработками практический горизонт часто составляет 60–90 рабочих дней.
Что получает компания после аудита?
Компания получает перечень рисков, рекомендации по исправлению, список недостающих документов, план подготовки заявки и оценку реалистичного маршрута: подавать как ПАК, доработать продукт или сначала идти по базовому ПО.
