Gartner уже успел перевести AI SOC Agents из стадии раннего хайпа в пик завышенных ожиданий, а рынок по-прежнему продает AI SOC-платформы через идеально вылизанные демо. Проблема в том, что между красивой презентацией и работой в боевом SOC часто лежит пропасть: в гайде, на который ссылается BleepingComputer, оценка доли корпоративных AI-проектов, проваливающихся в продакшене, достигает 80-95%.
Поводом стал материал Prophet Security, подготовленный вместе с бывшими аналитиками Gartner Оливером Рочфордом и Пратеком Бхаджанкой. Авторы предлагают не спорить о магии ИИ в Security Operations в абстракции, а проверять, как конкретная AI SOC-платформа поведет себя в среде компании: с ее активами, учетными записями, оргструктурой, шумом телеметрии и реальными сценариями инцидентов. Для русскоязычной IT-аудитории это особенно практичный сигнал: если вендор обещает «автономного аналитика SOC», первым делом нужно смотреть не на скорость ответа в демо, а на то, где и почему модель ошибается в проде.
Главная мысль гайда звучит неприятно для продавцов, но полезно для покупателей: на старте стоит понять, что именно компания вообще собирается покупать. Просто инструмент? Новую функцию для уже существующей команды? Или новую операционную модель, где часть работы в SOC уйдет машине, а часть ролей придется перекроить под нее? Для SecOps это не философия, а вопрос бюджета и оргдизайна. Авторы напоминают, что автоматизация в SOC не вчера появилась: байесовские антиспам-фильтры, SOAR, плейбуки, enrichment-пайплайны рынок видел давно. Разница в том, что генеративный ИИ и большие языковые модели претендуют сразу на слишком широкий кусок: от triage оповещений и сбора доказательств до расследования и реакции. Из-за этого ошибка в выборе operating model бьет сильнее, чем в эпоху обычной автоматизации.
Первый и самый неприятный вопрос для любого заказчика звучит просто: может ли AI SOC-платформа выдавать надежные вердикты именно в вашей среде? И здесь авторы ломают популярную иллюзию, что качество модели будет плавно расти по мере докормки данными. По их логике, все работает скорее как пороговый эффект: если у системы нет достаточного контекста, никакой prompt engineering не спасет, а если нужный контекст есть, качество вердиктов резко становится пригодным для практики. Под нужным контекстом понимаются не абстрактные «больше логов», а вполне конкретные вещи: данные об идентичностях, инвентаре активов, поведенческих нормах, организационной структуре. Иначе ИИ не отличит атакующего от штатного администратора, который делает ровно то же действие, но по регламенту. Отсюда и важный вывод для пилота: если proof of concept ограничен фишинговыми кейсами, где хватает метаданных письма и базовой репутационной проверки, заказчик тестирует самый легкий сценарий и почти ничего не узнает о поведении системы на lateral movement, privilege escalation и других тяжелых историях.
Вторая проблема еще опаснее, потому что ее часто не замечают: совпадает ли модель работы продукта с тем, как устроена команда безопасности. У небольшой команды запрос к ИИ один: закрыть руками машины те задачи, на которые у людей просто не хватает времени. У крупного SOC логика другая: там AI SOC-платформа должна усиливать аналитиков, а не подменять их декоративным «human in the loop». Поэтому авторы советуют проводить тест в параллельном режиме хотя бы пару недель, фиксировать baseline до включения ИИ и отдельно собирать статистику по случаям, когда аналитики отменяют или исправляют выводы системы. Это не шум, а главный материал для оценки. Если в пилоте люди не расследуют инциденты независимо, а просто утверждают вывод ИИ, это уже тревожный знак. Причина в том, что многие решения принимаются еще до финального вердикта: что ingest'ить, что подавлять, как приоритизировать, какой контекст поднимать, как формулировать картину инцидента. Чем раньше в цепочке стоит решение машины, тем хуже оно заметно и тем труднее его потом раскрутить назад. В такой схеме аналитик быстро превращается в человека, который ставит галочку под уже навязанной трактовкой события.
Третий блок оценки касается надежности на дистанции, и именно его почти гарантированно не видно в двухнедельном пилоте. Система может выглядеть убедительно в день запуска и тихо деградировать потом. В гайде предлагают отдельно давить на несколько тем: устойчивость к adversarial-сценариям, дрейф модели, способность адаптироваться к изменениям в инфраструктуре и риск привязки к одному вендору. На этом этапе особенно важны референсы клиентов и реальный track record, потому что рынок AI для SOC сейчас щедр на обещания, а вот с доказательствами у многих сложнее. Отдельно полезна мысль про «неопределенность как нормальный ответ». Если продукт всегда выдает бинарный вывод и никогда не говорит «недостаточно данных», это не признак зрелости, а маскировка неуверенности. Авторы советуют смотреть на трехсостоявшуюся классификацию: benign, suspicious, malicious, плюс на детерминированные правила эскалации для решений с высоким риском.
Самая приземленная часть материала построена на опыте практиков, уже запустивших ИИ в SOC. И там меньше всего футуризма. Один из приведенных кейсов описывает, как в крупной компании роли, завязанные на triage фишинга и проверку DMARC, автоматизировались буквально за недели, быстрее, чем менеджмент успел решить, чем эти специалисты будут заниматься дальше. Вывод неприятный, но здравый: новые роли вроде detection engineering, threat hunting, red teaming и AI oversight надо проектировать до внедрения, а не после него. Еще один интересный тезис касается эффекта от ИИ: максимальная польза приходит не от того, что существующие алерты разбираются быстрее, а от того, что SOC начинает расследовать вещи, до которых у людей раньше просто не доходили руки. Авторы приводят пример корреляции HR-данных, логов аутентификации и записей об активах по разным локациям, чтобы ловить совместное использование учетных данных. Для человека такой кейс часто слишком дорог в расчете на низкий приоритет сигнала, а для машины становится экономически допустимым. Та же логика меняет и economics detection engineering: экспериментальные правила, которые раньше топили команду в false positive, получают шанс, если разбор ложных срабатываний берет на себя ИИ.
Для рынка это означает простую вещь: эпоха покупки AI SOC-платформы «по демо-эффекту» заканчивается быстрее, чем хотелось бы отделам продаж. Следующий этап конкуренции будет не за самые эффектные презентации, а за доказуемость в реальной среде, прозрачность расследования, управляемость ошибок и внятную схему разделения полномочий между моделью и человеком. И если этот рынок действительно идет по кривой Gartner к более зрелой фазе, выигрывать будут не те, кто громче всех обещает автономный SOC, а те, кто честно показывает пределы автоматизации. Подробности исходного материала можно посмотреть в .