Компания проверила AI-систему перед запуском: - провела threat modeling и red teaming; - устранила критические замечания; - согласовала риски; - разрешила выход в production.

Через месяц название продукта осталось прежним. Но провайдер обновил модель, команда изменила system prompt, подключила новый RAG-источник и дала агенту право записывать данные в CRM. Можно ли считать действительным первоначальный security assessment? Формально проверку прошёл тот же продукт. Фактически перед нами уже другая конфигурация и другой риск.

В этом слабость традиционной модели: assessment → закрытие замечаний → допуск в production → следующая проверка через год.

Для стабильной системы такой цикл ещё может работать. Для быстро меняющегося AI годовой assessment как единственный механизм контроля почти гарантированно запаздывает.

У допуска AI в production должны быть не только дата и владелец, но и условия, при которых он сохраняет силу.

Я бы использовал четыре состояния: Current — production-конфигурация соответствует одобренному fingerprint, обязательные тесты пройдены, мониторинг работает; Conditional — произошло ограниченное изменение, автоматические проверки пройдены, но целевая валидация ещё не завершена; Stale — конфигурация или threat landscape изменились настолько, что прежних доказательств уже недостаточно; Suspended — выявлен критический дефект, нарушение контрольной границы или потеря необходимой наблюдаемости.

Что должен видеть CISO Метрика «90% AI-систем прошли assessment» создаёт ложное чувство контроля. Часть этих проверок может относиться к конфигурациям, которых уже нет в production.

Полезнее измерять: - долю production AI с состоянием Current; - долю систем с полным configuration fingerprint; - время нахождения систем в состоянии Stale или Conditional; - число несанкционированных изменений AI-конфигурации.

NIST в 2026 году отдельно показал две стороны этой проблемы. Отчёт AI 800-4 подчёркивает необходимость наблюдать реальное поведение после deployment из-за недетерминированности, динамических входных данных и непредвиденных последствий. Другая работа NIST объясняет ограниченность подхода one-and-done для защиты от адаптивных враждебных промтов и предлагает постоянный поиск слабостей и обновление защитных механизмов.

Это не означает, что NIST уже установил универсальную обязательную периодичность повторных проверок. Но направление ясно: статическое подтверждение безопасности плохо соответствует динамической природе AI.

Моя позиция: Обеспечение безопасности должно двигаться вместе с системой.

Какое изменение production AI в вашей компании автоматически делает предыдущий security assessment неактуальным — если вообще делает?