Управляемость ИИ проверяют не на старте, а когда меняются данные, модели и права
изображение: grok
Контроль изменений, пересмотр прав, журнал решений, разбор инцидентов и регулярная аттестация контура работают не разово при запуске проекта, а постоянно, вместе с самой системой.
Контур ИИ обычно проходит проверку один раз. Согласовали политику доступа, подписали регламент, запустили пилот. На этом этапе риска почти нет, так как данные статичны, модель одна, права розданы разово. Все выдыхают и переключаются на следующий проект.
Настоящая проверка начинается позже. Данные обновляются. Модель дообучается или заменяется на новую версию. Права расширяются под сценарии, которых не было при запуске. Решения, которые раньше принимал человек, теперь принимает агент. В этот момент управление либо держит систему под контролем, либо превращается в документ, который аккуратно лежит в папке и ничего не предотвращает.
Так появляется долг управляемости. Он копится незаметно, пока никто не пересматривает права, не ведет журнал решений и не аттестует контур заново. Платить по этому долгу приходится в момент инцидента, с процентами: расследование постфактум, репутационный удар, вопросы регулятора.
Похожую логику уже закладывает регулятор. С 1 марта 2026 года приказ ФСТЭК № 117 обязал считать показатели защищенности и зрелости мер безопасности регулярно, а не полагаться на разовую проверку на несколько лет вперед. ФСТЭК готовит аналогичные изменения для значимых объектов КИИ в приказах № 235 и № 239: проект опубликован в апреле 2026 года, но пока не принят. То есть там, где регулятор уже переходит от разовой проверки к периодическому пересчету, для ИИ-систем нужен тот же переход, но с добавлением второго, событийного триггера.
Календарный цикл ловит медленные изменения. Событийный должен ловить то, что специфично именно для ИИ: модель дообучилась, сменила версию, изменился состав обучающих данных, расширились права системы. Каждое такое событие обязано запускать внеплановую проверку контура, а не ждать ближайшей регулярной сверки. Если ресурсов на полную проверку в моменте нет, разумный выход, знакомый практике КИИ, это компенсирующие меры с письменным обоснованием риска, уже предусмотренные приказом ФСТЭК № 239: не пропускать триггер, а фиксировать, чем он временно закрыт.
Рекомендую строить архитектуру, в которой эти два триггера работают как единый механизм, а не как два независимых требования. Внутри этой архитектуры пять точек контроля связаны в цепочку, а не существуют параллельно. Контроль изменений фиксирует факт обновления модели или датасета и передает его в пересмотр прав, потому что новая версия модели редко нуждается в старом наборе полномочий. Пересмотр прав отражается в журнале решений: кто согласовал расширение доступа и на основании какого события. Журнал решений становится источником для разбора инцидентов, когда что-то идет не так, а разбор инцидентов возвращает выводы обратно в контроль изменений, замыкая цикл. Регулярная аттестация проверяет, что все четыре механизма действительно сработали за отчетный период, а не существуют только на бумаге.
Роли в этой цепочке распределены явно: владелец системы фиксирует событие, ИБ-функция проводит проверку, руководитель, утверждающий контур, отвечает за журнал решений и итоговую аттестацию. Без такого распределения любая из пяти точек превращается в формальность, за которую никто не отвечает лично.
Цена невыстроенного контура не абстрактна. Для компаний, работающих с критической инфраструктурой и государственными заказчиками, это остановка эксплуатации до устранения замечаний, отзыв допуска, срыв контракта на этапе, когда сроки уже утверждены перед заказчиком. Регулятор и заказчик оценивают состояние контура в момент проверки, которая может случиться в любой точке жизненного цикла системы, а не намерения, заявленные на старте проекта.
Управление, рассчитанное на один проход в начале проекта, устаревает быстрее, чем успевает принести пользу. Управление должно двигаться в том же темпе, что и сама система, и запускаться теми же событиями, что запускают изменения в ней. Тогда рост мощности ИИ доходит до результата, а не растворяется в устранении последствий.
Станислав Ежов, директор по развитию ИИ, ПАО “Группа Астра”
