Система защиты решает, что учётная запись финансового директора скомпрометирована, и отключает ему доступ. Через десять минут выясняется: атаки не было, а компания сорвала согласование платежа.

Это защита или уже новый инцидент? ИИ в центре мониторинга способен объединять предупреждения, анализировать поведение пользователя и предлагать ответные меры. Следующий шаг — разрешить ему самому отзывать сеансы и ключи доступа, блокировать учётные записи, изолировать устройства или ограничивать сетевые соединения.

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

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

Поэтому вопрос не сводится к выбору «ИИ или человек». Нужно решить, какой ущерб компания разрешает системе автоматически причинить ради снижения киберриска.

Моя позиция: часть защитных действий необходимо постепенно переводить в автономный режим. Полностью ручное реагирование уже становится архитектурным ограничением. Но давать ИИ общее право «блокировать пользователей» я бы не стал.

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

Для каждого действия я бы определял четыре границы. Первая — объект. Временный пользователь, финансовый директор, сервисная учётная запись и единственный администратор аварийной системы не могут обрабатываться одинаково.

Вторая — масштаб. Решение по одной учётной записи не должно автоматически распространяться на тысячу других только из-за общего признака.

Третья — обратимость. Отозвать сеанс безопаснее, чем удалить учётную запись или остановить производственную нагрузку.

Четвертая — время. Автоматическая мера должна иметь срок действия. Если расследование не подтвердило атаку, доступ восстанавливается автоматически.

На этой основе можно построить четыре уровня автономности: — уровень 0: ИИ только рекомендует действие; — уровень 1: самостоятельно выполняет узкое и обратимое ограничение; — уровень 2: временно блокирует учётную запись или изолирует устройство при нескольких независимых сигналах; — уровень 3: затрагивает привилегированные учётные записи, производственные сервисы или множество объектов только после подтверждения человеком.

Предварительный Cyber AI Profile NIST выделяет применение ИИ для киберзащиты в отдельное направление. Но главный управленческий вопрос начинается там, где анализ превращается в действие. Зрелая автоматизация — это не максимальная автономность. Это право выполнить строго определённое действие с ограниченным масштабом, сроком и понятным способом отмены.

Какое максимальное действие вы готовы разрешить ИИ без участия человека: отозвать сеанс, заблокировать учётную запись, изолировать устройство или остановить производственную систему?