КИИ: где проходит граница между ПО и ПАК

9 сентября 2026 года был опубликован проект изменений в регулирование технологической независимости критической информационной инфраструктуры. Он разграничивает полномочия Минпромторга и Минцифры в части программно-аппаратных комплексов и программного обеспечения. Минцифры также предлагается наделить полномочиями по выдаче разъяснений по вопросам перехода владельцев значимых объектов КИИ на российское ПО. Хочу остановиться на том, что это может изменить для рынка, где проходит граница между ПО и ПАК и зачем нужны единые подходы к испытаниям сложных ИТ-решений.

Что изменится для рынка после разграничения полномочий Минцифры и Минпромторга

Проект преимущественно закрепляет уже сложившееся на практике разделение: было понятно, что за аппаратное обеспечение отвечает Минпромторг, а за программное — Минцифры. У ведомств также действуют отдельные реестры.

Кроме того, у Минпромторга уже была практика работы с доверенными программно-аппаратными комплексами (ПАК), где аппаратная часть должна соответствовать требованиям промышленного реестра, а используемое ПО — реестру российского ПО. То есть то, что раньше существовало де-факто, теперь закрепляется де-юре.

Практическое значение у этого шага есть: участникам рынка становится проще ориентироваться в распределении полномочий между ведомствами, понятнее, куда обращаться по встроенному ПО, например BIOS, и кто отвечает за формирование соответствующих требований.

Что изменится для интеграторов

Современная ИТ-инфраструктура редко состоит только из оборудования или только из программного обеспечения. Серверы, системы виртуализации, средства информационной безопасности и промышленное ПО образуют единый технологический стек, поэтому четкое распределение полномочий между Минпромторгом и Минцифры может сократить число ситуаций, когда разработчику или заказчику приходится самостоятельно решать, к какому нормативному контуру относится продукт, какие требования к нему применять и с каким ведомством это согласовывать.

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

Серверное оборудование и программно-аппаратная ИТ-инфраструктура

В ГК Softline отмечают, что комплексные ИТ-решения могут находиться на стыке программного и аппаратного обеспечения

Один из ключевых вопросов — граница между отдельным ПО, встроенным ПО и ПАК. Какие пограничные случаи здесь наиболее показательны

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

Хороший пример — система хранения данных. У нее есть собственная операционная система. Формально операционная система относится к ПО, но в данном случае она является неотделимой частью СХД: ее нельзя заменить независимо от аппаратной платформы без риска нарушить работу всего комплекса.

Та же история с сетевым оборудованием, гиперконвергентными платформами, промышленными контроллерами, средствами информационной безопасности и различными appliance-решениями, когда сервер поставляется с предустановленным ПО. В таких продуктах необходимую функциональность обеспечивает именно связка оборудования и программного обеспечения. Если разделить эти компоненты, решение может перестать работать так, как предусмотрено производителем.

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

Проект предусматривает возможность получать разъяснения Минцифры по переходу на российское ПО. Какие вопросы возникают у владельцев КИИ при планировании миграции и какие из них особенно важны для инфраструктурных проектов

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

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

Для рынка здесь также важен публичный и единообразный подход к разъяснениям, согласованный с позициями Минпромторга, отраслевых регуляторов, Банка России и других ведомств.

Отдельный блок проекта касается головной научно-исследовательской организации. Какие задачи она могла бы решать

На мой взгляд, головной научно-исследовательской организации логично передать прежде всего методологические функции: анализ технологической зрелости российских решений, формирование подходов к классификации ПАК и встроенного программного обеспечения, разработку методик испытаний, в том числе сравнительных, а также референсных архитектур и сценариев миграции. Полезной могла бы быть и система независимой сравнительной оценки российских решений по единым критериям.

Еще одна возможная задача — формирование сети независимых испытательных полигонов. Там можно будет проверять совместимость оборудования, системного ПО, средств виртуализации, СУБД, прикладных систем и средств информационной безопасности. В результате появятся площадки, где архитектуру можно проверить в конкретных условиях эксплуатации.

Для инфраструктурных проектов Softline важен прежде всего практический результат таких испытаний: можно ли стабильно работать на выбранной архитектуре и провести миграцию без сбоев. От отрасли к отрасли требования разные: где-то минута простоя допустима, а где-то и секунда недопустима.

Как при такой модели учитывать специфику разных отраслей

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

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