1) Почему отказывают во включении в реестр российского ПО (ссылка на 7ю статью)
2) Ошибки при подготовке заявки в реестр
3) Рассмотрим так же ()
Самая частая иллюзия, с которой приходят компании к включению в реестр — это убеждение, что достаточно просто заполнить форму. Кажется, что это административная процедура: собрать документы, описать продукт, отправить заявку и получить результат. Но реальность устроена иначе. Заявка — это отражение всего продукта: его юридической структуры, архитектуры, прав и инфраструктуры. И если хотя бы один из этих элементов не проработан, это почти всегда всплывает на этапе экспертизы.
Самая распространённая ошибка — это отсутствие целостной логики между разделами заявки. В одном поле компания пишет, что продукт — это SaaS-платформа, в другом — описывает его как локальное программное обеспечение. В одном разделе указывается одна архитектура, в другом — фактически описывается другая. На уровне здравого смысла это может не бросаться в глаза, но для экспертизы это сигнал: заявка собрана без системного понимания требований.
Вторая большая ошибка — это формальное отношение к правам. Мы подробно разбирали это в статьях второго блока, особенно в материале про заказную разработку. Очень часто компании не до конца понимают, кому принадлежат исключительные права на продукт, или считают, что по умолчанию права принадлежат им. Но если договоры с разработчиками оформлены неправильно, если права не переданы, если есть сторонние подрядчики без корректных актов передачи — это становится прямым основанием для отказа.
Ещё один блок ошибок связан с инфраструктурой. Компания описывает продукт как российский, но фактически ключевые компоненты размещены в зарубежных облаках, доступ к исходному коду осуществляется через иностранные сервисы, а хранение данных не соответствует требованиям. Мы подробно говорили об этом в статье про инфраструктуру и размещение данных — это один из самых чувствительных аспектов для экспертизы.
Отдельная категория — использование open-source компонентов. Сам по себе open-source не запрещён, но проблема возникает тогда, когда компания не понимает: какие лицензии используются и какую роль эти компоненты играют в продукте. Если ваш продукт фактически построен на базе чужого решения, а собственный вклад минимален — это вызывает вопросы.
И, наконец, есть ошибки чисто «технические», но при этом критичные: некорректные формулировки назначения ПО, отсутствие согласованности между документами, неточности в описании функциональности. На практике именно такие мелкие несоответствия часто становятся триггером для дополнительных проверок, а иногда и для отказа.
Все эти ошибки объединяет одно — они возникают не из-за того, что продукт плохой, а из-за того, что заявка готовится без учёта логики экспертизы. Именно поэтому компании, которые проходят включение в реестр с первого раза, почти всегда подходят к этому процессу как к проекту: проводят аудит, проверяют документы, выстраивают архитектурное описание, согласовывают формулировки.
Если вы сейчас на этапе подготовки — лучше потратить время на выравнивание всех блоков заявки, чем потом работать с отказом. А если отказ уже произошёл — важно понять, как именно он выглядит на практике. Мы разберём типовой отказ Минцифры и покажем, как его правильно читать.
Разбор типового отказа Минцифры
Типовой отказ Минцифры редко выглядит как что-то катастрофическое. В нём нет резких формулировок или субъективных оценок. Это аккуратный, юридически выверенный документ, в котором перечислены причины, по которым заявка не может быть одобрена. И именно в этом его особенность — за внешней сухостью скрывается очень конкретная логика экспертизы, а иногда и вполне читаемый чек-лист того, что именно нужно доработать.
Обычно отказ содержит несколько блоков замечаний. Например, может быть указано, что не подтверждено соответствие требованиям к российскому происхождению. За этой формулировкой может стоять всё что угодно: структура владения с иностранным участием, некорректно оформленные права, отсутствие подтверждения передачи прав от разработчиков или даже несоответствие фактической роли компании в разработке продукта.
Другой частый блок — замечания к архитектуре и инфраструктуре. Формулировка может звучать нейтрально: «не подтверждено размещение ключевых компонентов на территории Российской Федерации». Но фактически это означает, что экспертиза увидела зависимость от зарубежной инфраструктуры, отсутствие контроля над критическими компонентами или несоответствие между архитектурным описанием и фактической реализацией.
Иногда отказ связан с описанием функциональности. Например, заявка позиционирует продукт как самостоятельное программное обеспечение, но из описания видно, что это лишь надстройка, модуль или клиент к другой системе. В этом случае экспертиза может посчитать, что заявленный объект не соответствует критериям самостоятельного ПО.
Есть ещё один слой, который редко очевиден для заявителя — это формальные несоответствия в самой заявке. Например, расхождения в названиях продукта, различия в указании версий, неточности в данных о правообладателе. Такие вещи кажутся мелочами, но для экспертизы это индикатор качества подготовки заявки.
Важно понимать, что отказ — это не оценка продукта. Это оценка того, насколько корректно и полно вы смогли доказать соответствие требованиям реестра. И если внимательно разобрать типовой отказ, становится видно, что он фактически повторяет структуру формы заявки: правообладатель, архитектура, инфраструктура, функциональность, документы.
Ещё один практический момент — сроки. Между подачей заявки и получением отказа проходит значительное время, и это делает каждую попытку особенно ценной. Именно поэтому важно извлекать максимум пользы из первого отказа и использовать его как основу для системной доработки.
Мы часто видим, что компании после отказа пытаются исправить только те пункты, которые явно указаны в документе. Но более эффективный подход — посмотреть на заявку целиком и проверить все связанные блоки. Потому что замечания редко существуют изолированно.
Именно такой системный подход позволяет превратить отказ не в препятствие, а в рабочий инструмент для последующего успешного включения в реестр.
Как правильно доработать заявку после замечаний
Доработка заявки после замечаний — это, по сути, финальный этап перед включением в реестр. И именно здесь становится понятно, насколько глубоко компания понимает требования и логику экспертизы.
Самая частая ошибка на этом этапе — это попытка точечных правок. Исправить одну формулировку, добавить недостающий документ, уточнить описание. Но если замечания указывают на системные несоответствия, такие правки не дают результата.
Правильная доработка начинается с декомпозиции замечаний. Нужно понять, какие из них относятся к правам, какие — к архитектуре, какие — к инфраструктуре, а какие — к формулировкам. После этого становится видно, какие блоки заявки требуют полной переработки.
Дальше начинается работа по выравниванию всех элементов. Если меняется архитектурное описание — его нужно согласовать с инфраструктурой. Если корректируются данные о правообладателе — это должно отражаться во всех разделах. Если уточняется функциональность — она должна быть согласована с категорией ПО и назначением продукта.
Очень важный аспект — доказательная база. Экспертиза оценивает не только описание, но и подтверждающие документы. Поэтому на этапе доработки важно не просто переписать текст, а усилить его документами: договорами, актами передачи прав, схемами архитектуры, подтверждением размещения инфраструктуры.
Ещё один практический момент — язык заявки. Формулировки должны быть точными, однозначными и согласованными между собой. Слишком общие или размытые описания часто становятся причиной дополнительных вопросов.
Также важно учитывать сроки и последовательность действий. После получения отказа у компании есть возможность подготовить новую заявку, но на это требуется время. И чем раньше начинается работа по доработке, тем быстрее можно вернуться в процесс рассмотрения.
На практике именно качественная доработка становится решающим фактором. Потому что на этом этапе компания уже понимает требования, знает свои слабые места и может выстроить заявку таким образом, чтобы она отвечала на все возможные вопросы экспертизы.
Именно здесь проявляется разница между формальной подачей и профессиональным сопровождением. Потому что доработка заявки — это не просто текст, а синхронизация юридической, технической и организационной части продукта. Если этот этап пройти грамотно, повторная подача превращается не в риск, а в почти гарантированный результат.