После вступления в силу 58-ФЗ субъекты КИИ обязаны переводить значимые объекты на ПО из единого реестра. Но реестр закрывает не каждую нишу: для отдельных классов систем российского аналога с нужной функциональностью пока нет. Закон это допускает – при условии, что субъект документально обоснует невозможность перехода в установленные сроки. Проблема в том, что большинство таких обоснований регулятор разворачивает: не потому что аналога правда нет, а потому что документ оформлен как отписка. Разбираем, что должно быть внутри, чтобы обоснование приняли.

Что обоснование должно доказать

Обоснование – это не заявление «российского аналога не существует». Это доказательство, что вы провели полноценный поиск и сопоставление, и что переход в текущем виде создаёт неприемлемые технические или эксплуатационные риски. Ключевое слово – сопоставление по требованиям, а не по названию продукта.

Минимальный состав документа:

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

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

Где обоснования проваливаются

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

Вторая ошибка – отсутствие плана выхода. Обоснование невозможности перехода не равно бессрочному освобождению. Регулятор ждёт дорожную карту: к какому сроку и каким способом субъект снимет зависимость. Без неё документ читается как попытка уклониться от требований 58-ФЗ, принятого в апреле.

Третья ошибка – ручная сборка доказательной базы по сотням документов и протоколов тестирования. Здесь помогает автоматизация: извлечение и сверка требований из проектной документации хорошо ложится на конвейеры агентного ИИ для документов, которые собирают контекст и готовят проект обоснования для проверки специалистом.

Вывод

Обоснование невозможности перехода – рабочий инструмент 58-ФЗ, а не лазейка. Принимают его тогда, когда оно построено как инженерный документ: проверяемые требования, честное сопоставление с реестром, оценка интеграционных разрывов и план устранения зависимости со сроком. Подготовка такого документа – от аудита объекта до дорожной карты импортозамещения и защиты КИИ – требует и инженерной экспертизы, и опыта диалога с регулятором.