Ошибки при подготовке заявки в реестр

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

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

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

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

Отдельная категория — использование open-source компонентов. Сам по себе open-source не запрещён, но проблема возникает тогда, когда компания не понимает: какие лицензии используются и какую роль эти компоненты играют в продукте. Если ваш продукт фактически построен на базе чужого решения, а собственный вклад минимален — это вызывает вопросы.

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

Все эти ошибки объединяет одно — они возникают не из-за того, что продукт плохой, а из-за того, что заявка готовится без учёта логики экспертизы. Именно поэтому компании, которые проходят включение в реестр с первого раза, почти всегда подходят к этому процессу как к проекту: проводят аудит, проверяют документы, выстраивают архитектурное описание, согласовывают формулировки.

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