За разными формулировками требований к ПАК в отраслевых материалах стоит один и тот же набор критериев, только по-разному пересказанный, а иногда — дополненный слишком специфичными деталями, не имеющими подтверждения. Собираем критерии в одну справочную структуру, отдельно отмечая, что подтверждено нормативно, а что похоже на додуманную детализацию.
Главное: формальные критерии для программной части ПАК опираются на постановление №1236: доля участия граждан РФ в правообладателе более 50%, выплаты иностранным правообладателям менее 30% выручки, отсутствие принудительного управления или обновления из-за рубежа. Аппаратная часть подтверждается отдельно через методику постановления №719. Специфичные технические требования (например, для отдельных категорий продукции с задачами ИИ) стоит проверять по действующим нормативным актам для конкретной категории, а не по общим утверждениям без ссылки на источник.
Три признака, определяющих ПАК как единый продукт
| Признак | Что он означает на практике |
|---|---|
| Аппаратное единство | Физическая часть — законченное техническое изделие, а не набор компонентов общего назначения, собранных для демонстрации |
| Программное управление | Предустановленное ПО обрабатывает данные и управляет функциями именно этого оборудования, а не работает на нём случайно как на одном из многих совместимых серверов |
| Неразрывность функций | Ни аппаратная, ни программная часть не могут выполнять заявленные задачи по отдельности — это и есть формальный тест на то, что перед экспертизой действительно ПАК, а не раздельный продукт |
Подтверждённые критерии по компонентам
Для программной части действуют требования постановления №1236: правообладатель — российская организация или гражданин РФ с долей участия граждан России более 50%, выплаты иностранным лицам по лицензионным и иным договорам менее 30% выручки от реализации продукта, отсутствие принудительного обновления и управления из-за рубежа. Для аппаратной части применяется методика постановления №719: подтверждение российского происхождения через ГИСП, набор необходимых баллов локализации для соответствующей категории продукции. Требование о совместимости программной части с отечественной операционной системой действует и постепенно ужесточается, но точные сроки и формулировки для конкретных классов ПО стоит уточнять по действующей редакции правил на момент подачи заявки, а не по устаревшим или неточно пересказанным условиям.
На практике многие отказы или замечания на этапе экспертизы связаны не с содержательным несоответствием продукта, а с формальными пробелами в доказательной базе: заявитель считает критерий очевидно выполненным и не прикладывает документальное подтверждение, полагая, что эксперт «и так поймёт». Экспертиза работает с представленными документами, а не с общим впечатлением о продукте, поэтому каждый из перечисленных критериев стоит подтверждать конкретным документом, а не общими заверениями в сопроводительном письме.
Требование к сервисной поддержке как самостоятельный критерий
Отдельно от технических характеристик самого продукта экспертиза оценивает готовность заявителя обеспечивать техническую поддержку и обслуживание на территории России: наличие штата или сервисных партнёров, способных решать типовые запросы пользователей без критической зависимости от зарубежной инфраструктуры. Это не формальность для галочки — производителю стоит заранее продумать организационную структуру поддержки, а не выстраивать её постфактум после получения статуса, поскольку отсутствие продуманной схемы обслуживания — частая причина замечаний экспертизы даже при полном соответствии продукта техническим критериям.
Для небольших компаний, у которых нет ресурсов на собственный штат технической поддержки в разных регионах, разумной альтернативой становится партнёрство с существующими сервисными организациями: главное, чтобы договорные отношения ясно фиксировали ответственность за обслуживание именно на территории РФ, а не просто декларировали общее сотрудничество без конкретных обязательств.
Что стоит отдельно проверять, а не принимать на веру
В материалах о требованиях к ПАК иногда встречаются очень специфичные технические условия — например, конкретные требования к вычислительным мощностям для продукции, связанной с обработкой данных или искусственным интеллектом (определённое количество процессоров, минимальная мощность дата-центра). Такие детализированные технические пороги, если они реальны, обычно устанавливаются отраслевыми стандартами или отдельными нормативными актами для конкретной узкой категории продукции, а не общими правилами реестра ПАК в целом. Прежде чем закладывать подобные конкретные цифры в план подготовки продукта, стоит найти их в первоисточнике применительно именно к своей категории, а не заимствовать из общей статьи про ПАК.
Как собрать доказательную базу под каждый критерий
Практичный подход к подготовке заявки — составить таблицу, где каждому формальному критерию соответствует конкретный документ, подтверждающий его выполнение, а не описывать соответствие общими словами в сопроводительном письме. Доля российского участия подтверждается выпиской из реестра юридических лиц и учредительными документами. Доля выплат иностранным правообладателям — финансовой отчётностью или расчётом по лицензионным договорам. Отсутствие принудительного управления из-за рубежа — техническим описанием архитектуры и, при необходимости, результатами аудита кода. Неразрывность связи софта и железа — протоколами совместных испытаний, а не декларативным утверждением в техническом задании.
Такой подход экономит время на этапе экспертизы: эксперт, который видит соответствие каждого критерия конкретным документом, а не общими фразами, реже возвращает заявку на доработку с запросом дополнительных материалов. Если собрать такую доказательную базу самостоятельно затруднительно, разумно обратиться за консультацией к специалисту, который поможет соотнести имеющиеся у компании документы с конкретными формальными требованиями, прежде чем подавать заявку и рисковать получить замечания по каждому пункту.
Вопросы и ответы
Короткие ответы на вопросы, которые чаще всего возникают при подготовке документов и подаче заявки.
Обязательно ли иметь отдельную страницу продукта на русском языке?
Требования к документации и описанию продукта на русском языке в целом характерны для процедуры включения в реестр российского ПО; конкретный формат (отдельный сайт, раздел в существующем ресурсе, документация в личном кабинете) стоит уточнять в действующих правилах, а не считать, что подходит только один жёстко определённый вариант.
Можно ли использовать компоненты с открытым исходным кодом?
Да, если заявитель обеспечивает их поддержку, адаптацию и, как правило, сборку самостоятельно или силами российского вендора, а само использование не нарушает условий распространения открытого компонента.
Что если аппаратная часть ещё не подтверждена в ГИСП?
Без подтверждённого происхождения аппаратной части экспертиза не может признать единство комплекса как ПАК: сначала нужно пройти процедуру подтверждения производства по методике постановления №719, а затем уже подавать заявку на регистрацию самого ПАК.
Действуют ли одинаковые технические требования для всех категорий ПАК?
Нет, базовые формальные критерии (доля российского участия, выплаты иностранным лицам, неразрывность связи) общие, но отдельные технические стандарты и пороги могут различаться для разных категорий продукции — это стоит уточнять применительно к конкретному классу устройств.
Источники
- КонсультантПлюс, постановление Правительства РФ от 16.11.2015 №1236: критерии реестра российского ПО, включая ПАК.
- ГИСП, сервис постановления №719: подтверждение российского происхождения аппаратной части.
