40% команд информационной безопасности уже используют ИИ каждый день, ещё 56% тестируют его в работе. AI-агенты в SOC обещают разгрузить аналитиков от рутины, но без доступа к данным, понятных правил и метрик они лишь ускорят выпуск сомнительных выводов. Для российских ИБ-команд это знакомая развилка: купить ещё один инструмент проще, чем подготовить к нему процессы.
О таких выводах сообщает The Hacker News со ссылкой на исследование Prophet Security State of AI in Security Operations 2026. В опросе участвовали более 250 CISO, руководителей SOC и практиков. Лишь 4% респондентов заявили, что вообще не планируют внедрять ИИ. Остальным приходится решать менее рекламный, но более полезный вопрос: готов ли их центр мониторинга к агенту, который будет сам собирать доказательства по алерту и делать предварительное заключение.
Авторы предлагают смотреть на готовность в двух плоскостях. Первая — есть ли в SOC работа, для которой агент действительно нужен: очередь алертов, медленные эскалации от MDR-провайдера, ночные инциденты без полноценного покрытия, отключённые из-за шума правила. Вторая — способен ли агент получить контекст и действовать по предсказуемым правилам. Если на вторую часть махнуть рукой, автоматизация не уменьшит риски: она просто будет быстрее масштабировать пробелы в телеметрии и процессах.
Проблема не выглядит надуманной. Респонденты сообщили, что 28% алертов вообще не расследуются. При этом 60% сталкивались с ситуацией, когда пропущенное или проигнорированное срабатывание позже оборачивалось серьёзным инцидентом — от простоя до взлома. Полное расследование одного алерта в среднем занимает 75 минут, а до первого просмотра уведомление нередко ждёт почти час. В такой арифметике даже хороший аналитик неизбежно начинает сортировать риски по срочности, а не по реальной опасности.
Где агент приносит пользу, а где упирается в данные
Наиболее заметный эффект, по версии Prophet Security, получают команды, у которых есть хотя бы несколько типичных болей. Например, MDR или MSSP долго передаёт действительно опасную эскалацию, потому что обрабатывает общую очередь многих клиентов. Или провайдер возвращает алерт с вопросами: ожидаем ли этот вход, является ли сервер промышленным, находится ли сотрудник в командировке. У внешней команды обычно нет такого контекста, а внутренним аналитикам приходится заново достраивать картину.
Собственный SOC сталкивается с тем же, только без посредника. Когда в новостях появляется критическая уязвимость или новая кампания, руководству нужен ответ «нас это затронуло?» в тот же день. Аналитик вручную ходит между SIEM, EDR, системой идентификации, облачной консолью и почтовой защитой, одновременно разгребая обычную очередь. Низкоприоритетные события ждут, правила с избытком ложных срабатываний выключаются, а threat hunting и разработка детектов остаются задачами «на свободный вечер».
AI-агенты в SOC рассчитаны именно на первый слой этой работы: начать проверку сразу после срабатывания, собрать сигналы из подключённых систем и сохранить логику решения. Часть платформ умеет также запускать поиск по инфраструктуре после публикации новой угрозы или предлагать детекты. Но агент не может расследовать то, чего не видит. Если ему доступен EDR, но закрыт доступ к провайдеру идентификации, он опишет активность на хосте, но не сможет уверенно связать её с учётной записью и её ролью.
Минимальный технический набор включает API-доступ к SIEM, EDR, IdP, облачным платформам, почтовым системам и критичным SaaS-сервисам. Не менее важен бизнес-контекст: критичность активов, роли пользователей, списки VIP, подразделения, известные легитимные сценарии — от плановых сканирований до административных скриптов. Наконец, нужно контролировать здоровье потоков данных. Задержка или тихо переставший поступать журнал способны создать убедительную, но ложную иллюзию завершённого расследования.
Перед пилотом придётся описать работу людей
Практичный тест готовности прост: взять пять недавних закрытых инцидентов и выписать все запросы, которые делал сильный аналитик. Каждый запрос, недоступный будущему агенту, — конкретный пробел для пилота. Заодно стоит спросить поставщика, используются ли данные заказчика для обучения моделей и где они обрабатываются. Конфиденциальность данных и обучение моделей назвали главным препятствием 44% опрошенных команд.
Вторая обязательная работа — записать стандарт расследования хотя бы для наиболее частых типов алертов. Что должно быть проверено в фишинговом кейсе? Когда impossible travel требует звонка руководителю сотрудника? Каких доказательств достаточно, чтобы признать событие безопасным? В зрелых командах ответы нередко живут в голове пары старших аналитиков. Формализованный чек-лист нужен не только агенту, но и новичкам, которые иначе учатся на фрагментах чужих тикетов.
До запуска важно снять базовые показатели: долю расследованных алертов, время до первого просмотра, среднее время расследования и число повторно открытых кейсов. Полезно также собрать список отключённых детектов: по данным опроса, до 40% организаций выключали часть правил, потому что не хватало людей на проверку срабатываний. Если агент стабильно разбирает поток, эти правила можно возвращать постепенно, проверяя качество, а не устраивая в SOC фестиваль шума.
Главная проверка для рынка будет не в том, сколько алертов агент успеет закрыть, а в том, насколько прозрачно он обоснует решение и где остановится перед действием. Автоматизированное расследование способно вернуть аналитикам время на детекты и охоту за угрозами, но ответственность за доступы, качество данных и границы полномочий всё равно останется у команды. Подробности методики и цифры исследования доступны в .
