КИБЕРБЕЗОПАСНОСТЬ

Почему ИИ в SOC делят на «быстрый» и «медленный»

98% инцидентов в SOC можно разбирать автономно, а человеку оставлять меньше 2% — так рынок переосмысляет роль ИИ в кибербезопасности.

✍️ Редакция iTech News | 14.07.2026 | ⏱ 5 мин | Источник: The Hacker News
🔑

98% алертов в центре мониторинга безопасности можно разбирать автономно, а человеку оставлять меньше 2% случаев, где действительно нужен контекст и суждение. В этом и состоит новая ставка рынка на ИИ в SOC: не делать из аналитика живой парсер очереди, а отдать рутину автономным агентам и использовать copilots там, где они правда усиливают команду.

Такой тезис разбирает The Hacker News в материале от 13 июля 2026 года. Поводом стала встреча автора статьи, Литал Ашер-Дотан, CMO компании Intezer, с CISO одной из компаний из списка Fortune 50: служба ИБ уже подключила Claude к нескольким инструментам детектирования и увидела пользу в отдельных расследованиях, но сама архитектура, по ее оценке, была перекошена в сторону сложного ИИ для редких кейсов и почти не решала проблему массового потока алертов.

Дальше автор проводит параллель с книгой Даниэля Канемана Thinking, Fast and Slow. Логика знакомая многим не только по психологии, но и по продуктовой аналитике: у человека есть «Система 1» для быстрых, автоматических решений и «Система 2» для медленного, затратного по когнитивной энергии анализа. В статье приводится упрощенная пропорция: около 95% мышления приходится на быстрый автоматический режим и около 5% — на вдумчивый. Из этого делается прямой вывод для SOC: ошибка начинается в тот момент, когда команда заставляет дорогой человеческий или LLM-ресурс делать работу, которая по природе должна быть автоматизирована.

Что авторы считают неправильной архитектурой SOC

Ключевая цифра в статье — исследование на массиве более 25 млн корпоративных алертов. По этим данным, 98% событий могут быть закрыты автономно, и менее 2% реально требуют участия человека. В той же логике приводится еще одна метрика: в компании с примерно 450 тыс. алертов в год в «низкоприоритетном шуме» могут скрываться 54 реальные угрозы. Не потому что аналитики ленивы или плохо обучены, а потому что у очереди нет дна: пока человек разбирает очевидно срочные инциденты, менее заметные сигналы так и остаются в хвосте.

Из этого тезиса вырастает довольно жесткая критика двух популярных подходов. Первый — классический, когда аналитики SOC вручную разгребают сотни уведомлений в день, тратя время на проверку того, что давно пора отдать машине: известен ли вредоносный файл, встречался ли этот IP в уже закрытом кейсе, похоже ли поведение входа на исторический профиль пользователя. Это не аналитика высокого уровня, а конвейер. Итог тоже давно знаком рынку: люди устают, начинают упрощать triage, приоритизируют только то, что выглядит громко, а реальные угрозы тихо лежат в «низкой важности».

Второй подход — более свежий и как раз поэтому опасно модный: взять frontier-модель, подключить ее напрямую к сырым данным детектирования и назвать это «AI SOC». В статье прямо упоминаются Claude, Codex и Cursor, но не как замена всему SOC, а как инструменты для медленного слоя работы. Когда же такую модель пытаются прогнать по каждому алерту, возникает проблема сразу в трех измерениях. Во-первых, агент часто все равно требует человеческого запуска или подтверждения. Во-вторых, экономика на реальных объемах начинает трещать: токены стоят денег, а поток алертов в крупном enterprise не спрашивает, готов ли бюджет. В-третьих, команда снова приходит к старой болезни и просто перестает смотреть часть очереди, только уже под более модной вывеской.

Где в этой схеме место для Claude, Codex и аналитика

Самая сильная часть материала — не в красивой метафоре про «быстрый» и «медленный» мозг, а в приземленном распределении ролей. Быстрый слой SOC, по этой логике, должен непрерывно и без запроса со стороны человека прогонять 100% сигналов через форензик-проверки: анализ памяти, файлов, корреляцию данных между endpoint, identity, network и cloud. Его задача — не писать эссе по инциденту, а выносить вердикт там, где шум действительно шум, и собирать доказательную базу там, где нужен аналитик. В статье утверждается, что такой слой может выходить на 98% точности и укладываться меньше чем в две минуты на расследование.

А вот медленный слой — это уже территория copilots. Здесь LLM полезны не потому, что они «умнее SOC», а потому, что умеют синтезировать данные, помогать с инженерией правил детекта, incident reporting и threat hunting по отраслевым сводкам. В правильной конфигурации Claude или другой помощник не начинает с сырого алерта. Он получает уже собранный кейс: связанные сигналы, результаты форензики, черновик response и контекст. Тогда аналитик наконец перестает быть оператором бесконечной очереди и возвращается к работе, за которую его вообще нанимали: принятие решений под контекст бизнеса, оценка риска, настройка правил, разбор нетривиальных инцидентов.

Для русскоязычной IT-аудитории здесь важен не только кибербезопасный, но и организационный вывод. Если компания продолжает строить SOC как фабрику ручного triage, она масштабирует штат линейно и все равно теряет покрытие. Если же она пытается «накрыть все LLM-кой», не решив слой автономного расследования, то просто меняет тип расходов и получает ту же очередь, только дороже. Для разработчиков это означает спрос на системы, которые умеют не болтать о безопасности, а качественно склеивать телеметрию и автоматизировать расследование. Для продактов и IT-директоров — необходимость считать не только качество модели, но и стоимость обработки полного потока. Для HR в ИБ — сдвиг роли аналитика от ручной сортировки к supervision и rule engineering.

Отдельно статья задевает тему, которую рынок обсуждает пока заметно тише: кому принадлежит слой накопленного знания. Если расследования полностью отданы внешнему MDR-провайдеру, то история кейсов, логика triage, правила детектирования и организационный контекст оседают внутри платформы вендора. Тогда подключить к этой среде тот же Claude или Codex формально можно, а практически им не на чем работать: «медленный мозг» остается без собственной базы решений. Поэтому разговор об ИИ в SOC быстро превращается из темы про удобные ассистенты в вопрос владения операционным знанием и внутренней инфраструктурой безопасности.

Главный вопрос теперь не в том, появятся ли AI-агенты в SOC, а в том, кто первым перестанет путать автоматизацию потока с красивой демонстрацией LLM на одном алерте. Если цифры про 25 млн алертов и 98% автономного разбора хотя бы близки к реальности, следующий этап конкуренции в security operations пойдет не за самый разговорчивый copilot, а за самый незаметный «быстрый слой», который закрывает шум без участия человека и не пропускает те самые 54 угрозы в хвосте очереди. The Hacker News

Поделиться: Telegram X LinkedIn