Автор Den Левко 
Суть проблемы: иностранное ПО как главный барьер
Министерство цифрового развития отмечает: основная причина отказов при включении в государственный реестр - наличие иностранного программного обеспечения в решениях разработчиков.
Речь идет не только о полном использовании зарубежных продуктов, но и о компонентах, библиотеках или сервисах, которые встраиваются в российские программы.
Даже если сама система создана в РФ, присутствие "чужих" модулей может стать поводом для отклонения заявки.
Такой подход объясняется стремлением к технологической независимости и безопасности критической инфраструктуры. Регуляторы тщательно проверяют софт на соответствие требованиям по происхождению кода, лицензирования и возможности поддержки внутри страны. В результате компании вынуждены пересматривать архитектуру своих продуктов и искать замену иностранным компонентам, чтобы пройти проверку.
Причины и последствия для разработчиков
Многим разработчикам привычно опираться на готовые библиотеки и сервисы, которые ускоряют разработку и снижают затраты. Однако при работе на российском рынке это создает риски: использование зарубежных зависимостей может привести к запрету на госзакупки или исключению из реестра.
Для компаний это означает не только потерю потенциальных контрактов, но и необходимость переработки решений, что увеличивает сроки и расходы.
Последствия такого подхода касаются и рынка в целом. С одной стороны, ужесточение требований стимулирует создание отечественных альтернатив и повышает спрос на локальные разработки. С другой - в краткосрочной перспективе это тормозит внедрение инноваций, так как замена проверенных зарубежных инструментов на ещё не отлаженные аналоги вызывает дополнительные риски и затраты.
Многие компании переходят на гибридные модели, но это не всегда помогает пройти сертификацию, если критерии жёстко интерпретируются.
Что могут сделать компании прямо сейчас
Первое - провести аудит архитектуры и зависимостей: выявить все внешние компоненты, библиотеки и сервисы, которые присутствуют в продукте. Второе - разработать план по их замене или локализации.
Это может включать прямую замену на отечественные аналоги, модульную перестройку, чтобы изолировать критичные части, либо оформление прав и гарантий от поставщиков, если это допустимо регулятором.
Также важно документировать происхождение кода и лицензионные условия, чтобы при проверке можно было оперативно подтвердить соответствие требованиям.
Наконец, стоит наладить диалог с заказчиками и регуляторами: прозрачность процессов и готовность к доработкам повышают шансы на успешную интеграцию в реестр.
Долгосрочные стратегии для устойчивости
Для устойчивого присутствия на рынке компаниям выгодно инвестировать в развитие собственных платформ и в сотрудничество с отечественными поставщиками.
Создание библиотек с открытым кодом, участие в профильных консорциумах и обмен наработками помогают снизить зависимость от внешних технологий и ускоряют адаптацию к требованиям регуляторов.
Кроме того, полезно формировать внутренние команды по сопровождению и аудитам безопасности, которые смогут оперативно реагировать на изменения регуляторной практики.
Комплексная стратегия - сочетание технической независимости, прозрачной документации и партнерских отношений с локальными разработчиками - уменьшит риск отказа в будущем и укрепит позиции на рынке.
Вывод? Баланс между безопасностью и скоростью внедрения
Требования к отказу из реестра из‑за иностранного ПО - сигнал рынку: защита цифровой инфраструктуры становится приоритетом. Разработчикам предстоит выбрать между быстрым применением проверенных зарубежных решений и долгосрочной стабильностью, обеспечиваемой локальной экосистемой.
Подготовка, аудит и стратегические инвестиции в отечественные технологии - ключ к тому, чтобы не терять доступ к госзаказам и одновременно оставаться конкурентоспособными.