Почему вам откажут во включении в реестр российского ПО в 2026 году

Я проанализировала 115 экспертных заключений Минцифры (март-июнь 2026 г.) и готова поделиться с вами выводами по причинам отказа.

Все данные в статье основаны исключительно на текстах 115 экспертных заключений, вынесенных за последние 3 месяца. Это не официальная статистика и не выборка, репрезентативная для всего потока заявок по включению в реестр. Я проводила анализ в рамках своей практики (чтобы понимать, с какими причинами могут столкнуться мои клиенты). Все документы находятся в открытом доступе на сайте Минцифры, но я намеренно не указываю в статье названия продуктов и их правообладателей.

Есть вопросы по включению ПО в реестр российского ПО Минцифры? Пишите комментарии или пишите в телеграм, будем разбираться.

Что нужно знать:

1. Для включения в реестр российского ПО ваш продукт уже должен быть жизнеспособным (как говорится официальным языком, «введен в гражданский оборот»).

2. Отказ не лишает вас права подать заявление повторно (главное, чтобы в заключении не было указано, что вы предоставили недостоверные сведения). Можно проанализировать отказ и подать новое заявление хоть на следующий день. Часть правообладателей, которым отказали уже исправили недочеты, переподали заявление и были включены в реестр.

• 60% всех отказов связаны с использованием иностранных компонентов, попадающих под экспортные ограничения. Это причина №1 с гигантским отрывом.

• 14% отказов содержат сразу несколько причин

• Топ-3 конкретных компонента-«убийцы»: NVIDIA CUDA (14 заключений), CentOS и Red Hat Enterprise Linux (по 12).

• Каждый шестой отказ вообще не связан с продуктом: экземпляр ПО не предоставили, он не запустился или не открылся удалённый доступ. Эксперт просто не смог посмотреть ПО, поэтому отказал.

Что вообще проверяет техническая экспертиза

Чтобы попасть в реестр, ПО должно соответствовать требованиям пункта 5 «Правил формирования и ведения единого реестра российского программного обеспечения», утверждённых постановлением Правительства РФ от 16 ноября 2015 г. № 1236. Пункт 5 разбит на подпункты от («а» до «л») и по каждому эксперт выносит вердикт «соответствует/не соответствует». Отдельно есть пункт 11 «а» (про обязанность заявителя предоставить работоспособный экземпляр ПО для технологической экспертизы).

Семь самых распространенных причин отказа

Я разбила все отказы на группы — их получилось семь. Один отказ может относиться к нескольким группам сразу (поэтому сумма процентов больше 100%).

Теперь рассмотрим эти причины более подробно.

Причина №1. Иностранные компоненты с экспортными или лицензионными ограничениями (69 отказов из 115)

Это абсолютный чемпион — в шести из десяти отказов эксперт указывает, что для работы (или сборки) продукта требуется иностранное ПО, на которое распространяются экспортные ограничения США или других стран. Тут у Минцифры простая логика — «российское ПО» должно работать, даже если все ограничат (потому оно и «российское»).

Теперь разберём конкретные компоненты (число рядом — количество заключений, где компонент стал основанием отказа).

Самая частая проблема — это операционная система

• Тут лидер CentOS (12 заключений). Причем часто CentOS не заявлена, как основная, а содержится внутри docker-контейнеров (например, CentOS Linux 7 в контейнере с Sphinx или ElasticSearch.

• Red Hat Enterprise Linux (12 заключений). Чаще всего она обнаруживается как базовый образ контейнеров с MinIO, Keycloak, Kafka, Zookeeper (то есть внутри компонентов, которые разработчики даже не считают своими.

• Microsoft Windows Server (9 заключений). Windows Server 2016/2019 «или выше» как базовая серверная ОС не подходит из-за экспортных ограничений. Часто идёт в связке с IIS и MS SQL Server.

• Oracle Linux Server (9 заключений). Часто всплывает в паре с Oracle Linux Server 9.7 в docker-контейнере с MySQL.

• AlmaLinux (1 заключение). Тоже считается компонентом с экспортными ограничениями.

Вывод по ОС: самая частая ошибка — «запрещенная» ОС в контейнерах (эксперт заходит внутрь образа и читает /etc/os-release , а там NAME=“CentOS Linux” — это отказ.

Вторая по распространенности проблема — NVIDIA CUDA

Отдельный и самый частый единичный компонент (14 отказов). Формулировки разные (CUDA Toolkit, NVIDIA Container Toolkit, драйверы NVIDIA, Video Codec SDK), но суть одна. В заключениях нередко приводится прямая цитата из лицензии NVIDIA о том, что SDK подпадает под экспортное законодательство США и не может поставляться в отдельные страны.

Для всех, кто делает продукты, связанные с 3D-моделированием, обработкой видео, научных и медицинских расчетах это стандартный стек, но факт остаётся фактом: если для установки и функционирования ПО требуется пакет NVIDIA/CUDA, это основание для отказа.

Отказы из-за СУБД

• MySQL в связке с Oracle Linux (9 отказов). Ту самую пару «Oracle Linux + MySQL в docker-контейнере» эксперты находят иногда с точным указанием ID контейнеров.

• Microsoft SQL Server / MSSQL (4 отказа). Отдельно или в связке с Windows Server и IIS.

Виртуализация

• VMware (ESXi / vSphere) (7 отказов). Причём часто VMware указан заявителем как обязательный элемент в описании функциональных характеристик или инфраструктурных программных средств. То есть команда сама, добровольно, вписала в требования систему виртуализации с экспортными ограничениями.

• Microsoft Hyper-V (1 отказ).

Офисные пакеты

Неочевидная, но регулярная история (4 отказа). Продукт «формирует документы через Microsoft Excel», или в обязательных требованиях прописан предустановленный Microsoft Office. Получается, что сам заявитель признаёт зависимость от иностранного офисного пакета.

Системы лицензирования и защиты

Thales Sentinel HASP/LDK и SafeNet Hasp HL — аппаратно-программные системы защиты и лицензирования с экспортными ограничениями (в одном случае эксперт сослался на конкретный пункт EULA).

Java от Oracle

Oracle JDK / Java HotSpot. Не стоит забывать, что лицензия Oracle содержит оговорки об экспортном контроле США.

Прочие компоненты

• Unreal Engine 5 (который сам под экспортными ограничениями и не русифицирован). Хотя ранее был опубликован протокол экспертного совета Минцифры от 2023 г., которым рекомендовали не запрещать, по причине отсутствия аналогов.

• Intel IPP и другие библиотеки Intel (появлялись при запуске установщика вместе с CUDA и Hasp HL).

• IBM FileNet (был заявлен как обязательная программная платформа).

Главный вывод по причине №1: проверяйте не то, что вы написали в заявке, а то, что реально лежит в ваших образах. Эксперт разворачивает ПО и смотрит на фактический стек.

Причина №2. Экземпляр ПО не предоставлен или неработоспособен (19 отказов из 115)

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

Внутри этой группы несколько характерных сценариев:

• Экземпляр не предоставлен вообще. Самая частая формулировка: «Экземпляр ПО, пригодный для технологической экспертизы, ни в составе заявки, ни на дополнительный запрос не предоставлен».

• Предоставлен нерабочий экземпляр. «Битый» архив, который не распаковывается. Дистрибутив, который «не является архивом». Docker-образ, который не поднимается по инструкции.

  Реальные технические ошибки, зафиксированные в заключениях:

  remote: HTTP Basic: Access denied на первом же шаге инструкции

  Error response from daemon: failed to resolve reference … no such host;

  tls: failed to verify certificate: x509: certificate has expired

• Не открылся удалённый доступ.

ssh: connect to host … port 22230: Connection timed out (несколько попыток);

по SSH не дали ключ или пароль;

• Некорректная инструкция. Эксперт не понял, как установить экземпляр по вашей инструкции.

  Вывод по причине №2: это самый обидный тип отказа, потому что он не про качество продукта, а про элементарную подготовку (особенно обидно это для юристов, которые готовят документы для реестра). Прежде чем подавать заявку, разверните ваш экземпляр по вашей же инструкции на чистой машине, без доступа к вашим внутренним сетям и приватным репозиториям. Помните — у эксперта на рассмотрении могут быть десятки заявлений, он не будет плясать с бубном, чтобы добраться до вашего ПО.

Причина №3. Зависимость от иностранных платформ, сервисов и API (18 отказов из 115)

Близкая к причине №1, но здесь речь не про архитектуру, а про внешние зарубежные сервисы, без которых продукт не работает. Если ключевая функция замыкается на иностранной платформе, продукт не автономен.

• GitHub (5 отказов). В двух ролях: как источник зависимостей при установке («установка ПО зависит от иностранных репозиториев https://github.com») и как место хранения исходников (об этом подробнее в причинае №4).

• Telegram (4 отказа). Сервисы, у которых вся логика — это телеграм-бот («аутентификация в Telegram»), «доступ к функциям через телеграм-бота. Удобно для клиентов, а для реестра — это зависимость от иностранной инфраструктуры.

• Steam (3 отказа). Все три отказа — это компьютерные игры, для запуска которых «требуется иностранная платформа (Steam)».

• Amazon AWS / S3 (2 отказа). Облачное хранилище Amazon S3 или платформа AWS указаны как обязательный элемент инфраструктуры.

• OpenAI (GPT-4 API) и DeepSeek API (2 отказа). Сервис обращается к моделям через API, расположенные за пределами РФ.

• Microsoft Azure / Azure DevOps (1 отказ). Исходники хранятся на облачных серверах Azure.

• И, внезапно, Google Fonts (1 отказ). Да, даже подгрузка шрифта в CSS попала в основание отказа.

• Внешние блоб-хранилища (1 отказ). Установка тянет данные из gethstore.blob.core.windows.net и GitHub (кейс с криптовалютами/блокчейном, управляемым в том числе из-за рубежа).

  Вывод по причине №3: любая внешняя (за пределами РФ) база — потенциальное основание для отказа. Telegram-бот как единственный интерфейс, вызов зарубежного LLM, шрифты — всё это стоит либо убрать из обязательных зависимостей, либо заменить на отечественные аналоги или самописные решения.

Причина №4. Хранение кода и компиляция вне территории РФ (8 отказов из 115)

Подпункт «и» пункта 5 требует, чтобы технические средства хранения исходного и объектного кода, а также средства компиляции находились на территории РФ. «завалились» именно здесь. Типичные формулировки из отказов по этой причине:

• Не предоставлено подтверждение, что технические средства хранения исходного текста ПО находятся на территории РФ (в описании прямо указано, что для хранения используется GitHub).

Вывод по причине №4: GitHub, GitLab.com, Azure DevOps как «технические средства хранения исходного кода» — прямое основание для отказа. Держите репозитории на инфраструктуре в РФ и подробно, с адресами, заполняйте соответствующий раздел заявки.

Причина №5. Отсутствие русскоязычного интерфейса (10 отказов из 115)

Формулировки однотипные: «Отсутствует реализация графического интерфейса на русском языке», «Графический пользовательский интерфейс ПО на русском языке отсутствует», «Веб-интерфейс должен быть полностью на русском языке».

Нюансы из заключений:

• В одном кейсе доступ был дан только к англоязычному интерфейсу. В другом при авторизации с тестовыми данными на сайте не было никаких настроек, «что не даёт проверить, есть ли возможность сменить язык интерфейса» (то есть отсутствие возможности продемонстрировать русский интерфейс приравнивается к его отсутствию)

  Вывод по причине №5: русскоязычный интерфейс обязателен (и желательно включить его по умолчанию на экземпляре для проверки).

Причина №6. Не собственная разработка и правовые нарушения (11 отказов из 115)

Разнородная группа отказов. Здесь эксперт ставит под сомнение не стек, а сам факт того, что перед ним самостоятельный российский продукт с понятным правообладателем. Например,

• вендор — иностранная компания (как «собственная разработка» представлен продукт, вендором которого является Oracle или издателем компьютерной игры значится зарубежная компания)

• не самостоятельный продукт. (например, продукт оказался плагином для Unreal Engine («без Unreal работать не будет»), а веб-сервер оказался набором дополнительных модулей для Apache Tomcat и эксперт потребовал переделать всю документацию)

• идентичность зарубежному решению (по одному из продуктов эксперт зафиксировал «полную идентичность зарубежным решениям (сайт, ПО, аппаратные решения)» со ссылкой на сайт зарубежного вендора

• нарушение условий лицензий и оборота, например не соблюдаются условия GNU GPL (этого типа лицензий вообще лучше избегать для компонентов ПО, которое планируется включить в реестр); незаконное использование чужого товарного знака.

• противоречивые сведения (заявитель предоставил противоречащие друг другу данные о технических средствах лицензирования; в другом кейсе документацию признали недостоверной, поскольку продукт не является тем, чем заявлен).

  Вывод по причине №6: Проверьте, что вы правообладатель (а не просто интегратор чужого движка), что ваши лицензии на open-source компоненты соблюдены (GPL особенно), что товарные знаки ваши, а сведения в документах не противоречат друг другу.

Причина №7. Прочее (1 отказ из 115)

Сюда попал единичный, но показательный случай: договор аренды инфраструктуры был действителен до конкретной ближайшей даты.

Итак, чек-лист проверки своего ПО перед включением в реестр

Инфраструктура и стек (причина №1, 60% отказов):

• Проверили фактические базовые образы всех контейнеров: cat /etc/os-release внутри каждого. Нет CentOS, RHEL, Oracle Linux, AlmaLinux, Windows Server.

• Базовая ОС из реестра российского ПО (Astra Linux, РЕД ОС, ALT и т. п.).

• Убрали VMware (ESXi/vSphere) и Hyper-V из обязательных требований.

• СУБД PostgreSQL или отечественная; не MS SQL Server и не MySQL внутри Oracle Linux.

• Проработали вопрос с CUDA (самый частый компонент, 14 отказов): обоснование, альтернативы, изоляция зависимости.

• Нет обязательной зависимости от Microsoft Office/Excel.

• Системы защиты/лицензирования не Thales Sentinel HASP / SafeNet.

• Java OpenJDK или отечественная сборка, не Oracle JDK.

Экземпляр и доступ (причина №2, 17% отказов):

• Развернули продукт по своей же инструкции на чистой машине без доступа к внутренним сетям и приватным репозиториям.

• Архив/дистрибутив распаковывается, образы не тянутся из недоступных снаружи.

• Сертификаты работают.

• Если доступ удалённый (SSH реально работают, ключи и пароли переданы)

• Есть внятная инструкция как запустить.

Внешние сервисы (причина №3, 16% отказов):

• Продукт не зависит критически от Telegram, Steam, зарубежных LLM (OpenAI/DeepSeek и других), AWS/S3, Azure.

• Установка не тянет зависимости из GitHub и внешних иностранных репозиториев.

Код и права (причины №4 и №6, 10% и 10% отказов):

• Исходники, объектный код и компиляция в РФ. Не GitHub.com, не Azure DevOps.

• Вы сделали это ПО сами.

• Лицензии open-source компонентов (особенно GPL) соблюдены.

Локализация (причина №5, 9% отказов):

• Интерфейс полностью на русском, и это видно на предоставленном экземпляре.

Материал подготовлен на основе разбора текстов 115 экспертных заключений экспертного совета по программному обеспечению при Минцифры России. Классификация причин авторская, наименования продуктов и правообладателей обезличены. Цифры отражают частоту причин в данной выборке отказных кейсов и не являются официальной статистикой Минцифры.