Ещё три года назад словосочетание «искусственный интеллект» в информационной безопасности встречалось в основном в презентациях крупных вендоров. Сегодня ситуация изменилась. Практически любой продукт на рынке так или иначе использует AI (ИИ), ML, LLM или другие аббревиатуры, связанные с искусственным интеллектом.
Если верить маркетинговым материалам, современные решения способны самостоятельно выявлять атаки, расследовать инциденты, прогнозировать угрозы и почти заменить аналитиков SOC. И когда заказчик слышит слово «ИИ», то ожидает почти универсального цифрового эксперта. Но после внедрения оказывается, что чудес не произошло, ведь за громкими заявлениями часто скрываются совершенно разные технологии, где рядом с генеративными языковыми моделями будет «сидеть» классическая корреляция событий или машинное обучение.
Давайте разберемся, где искусственный интеллект действительно помогает специалистам по ИБ, а где пока остается скорее маркетинговым ярлыком.
Причины этого понятны:
-
Рынок ИБ испытывает серьезный кадровый дефицит и найти опытного аналитика SOC, специалиста по расследованию инцидентов или эксперта по threat hunting становится все сложнее.
-
Бизнес постоянно ищет способы повысить эффективность и сократить расходы.
-
А вендоры заинтересованы в том, чтобы показать свои продукты максимально инновационными.
На стыке этих факторов рождается опасное ожидание: технология продается как надежда, а значит достаточно купить решение с пометкой ИИ, и значительная часть проблем безопасности исчезнет сама собой.
Но сначала уточним…
Что сегодня называют ИИ в ИБ
Проблема ложных ожиданий рождается из одной простой уловки: вендоры намеренно стирают границы между разными технологиями, называя всё одним модным словом «ИИ». Чтобы понять, где нас обманывают, давайте на секунду станем занудами и разведём понятия по полочкам.
№1. Классические правила корреляции
Они присутствуют, к примеру, в SIEM-системах. SIEM-система может сработать, если пользователь вошел в сеть ночью, получил административные права и начал выгружать данные. Но никакого искусственного интеллекта в них нет, а есть заранее заданные правила.
Для аналитика SOC разница между правилами и ИИ — это не академический спор, а вопрос выживания смены. Когда система позиционируется как «с ИИ», ожидания у всех выше: «Она должна видеть больше, понимать контекст, снижать шум». А по факту это те же правила корреляции, только с новым интерфейсом.
Я видел, как из‑за этой подмены понятий росла нагрузка: команда ждала от системы большей самостоятельности, а вместо этого получала те же алерты плюс дополнительные вопросы от руководства. В итоге коллеги тратили время не на расследование инцидентов, а на объяснение, почему ИИ не делает того, чего от него ждут.
Да, правила корреляции — это база SOC. Они закрывают огромный пласт типовых угроз и делают это надежно. Но давайте называть вещи своими именами: это не ИИ — это грамотная инженерия. И именно на этой базе мы строим реальную защиту, а не на красивых словах.
№2. Машинное обучение
Система анализирует большой массив исторических данных и формирует модель нормального поведения. Затем ищет отклонения от этой нормы.
Я сам экспериментировал с ML‑модулем в одном из решений: подключили, обучили, запустили в пилот. Вендор обещал «снижение шума на ХХ процентов» и раннее обнаружение сложных атак. Первые две недели только и разбирали срабатывания. Да, система честно находила аномалии: кто‑то зашел с нестандартного устройства, кто‑то скачал чуть больше обычного. Но из 1000 алертов за неделю реальными инцидентами оказались ровно…два. Остальное это были легитимные процессы: работа аутсорс‑команды, временные права и пр.
Этот пилот всех быстро приземлил и стало понятно, что это не «умная кнопка», а инструмент, который нужно долго калибровать под конкретную инфраструктуру.
№3. Генеративный ИИ
Это уже языковые модели. Они умеют анализировать текст, писать запросы, формировать отчеты и помогать специалистам взаимодействовать с системами безопасности.
Проблема в том, что в маркетинговых презентациях все три технологии часто называют одним словом — ИИ. Поэтому первое, что стоит выяснить при выборе продукта: какая именно технология используется под капотом.
И самое главное — нельзя верить обещаниям без цифр. Нужно требовать от вендоров не красивые слайды, а реальные метрики, например долю ложных срабатываний (FP), время на валидацию одного алерта и процент реально выявленных инцидентов. Иначе все это просто слова в презентации.
А «предвыборные обещания» вендоров утомляют. Но не потому, что я против прогресса, а потому что они создают иллюзию безопасности — и эта иллюзия опасна.
Когда CISO согласует решение «с ИИ» за 20+ млн. рублей, ожидая, что оно закроет дыру в защите, а на деле там обычная корреляция по трём правилам, страдает не просто бюджет. Страдает реальная защищенность компании. И расхлебывать последствия придется живым людям: аналитикам, инженерам, тем, кто не верит в чудо‑кнопки.
Не нужно продавать надежду как технологию. Технологии действительно помогают, но исполняют не все обещания. Давайте посмотрим, какие предвыборные обещания остаются нереализованными.
Где маркетинг пока опережает технологии
Ниже четыре главных «обещания», которые я слышу слишком часто.
Обещание №1. ИИ сам найдет неизвестные атаки
Это один из самых популярных тезисов на рынке и формально он не является ложью, так как современные решения класса UEBA, NDR, XDR и некоторые SIEM действительно способны выявлять аномалии, которые сложно обнаружить вручную.
Представим ситуацию:
-
Сотрудник бухгалтерии никогда не подключался к корпоративной сети ночью.
-
Он не использует PowerShell.
-
Он не работает с серверами.
Внезапно в три часа ночи его учетная запись входит через VPN, запускает PowerShell и начинает обращаться к нескольким серверам. Каждое действие по отдельности может не выглядеть подозрительно. Но алгоритм машинного обучения видит отклонение от привычного поведения пользователя и формирует инцидент. Здесь технология действительно работает.
Однако есть важный нюанс. Система выявляет аномалию, а не атаку. Возможно, это злоумышленник. А возможно, сотрудник ИТ-службы временно использовал учетную запись для проведения работ.
Именно поэтому окончательное решение все равно принимает аналитик.
Пример с ситуацией выше я добавил не случайно. Пару лет назад я прочувствовал такую ситуацию, когда тревога пришла по учетке, которая вообще не должна была светиться ночью (классика для заголовка «ИИ поймал хакера»). А реальность оказалась банальнее: обычный рабочий процесс, просто оформленный как атака. Да, система поймала аномалию, и формально была права. Но реакция на нее могла стоить компании простоя, срыва отчетности и нервотрепки всей команде.
Этот случай показал, что самая опасная вещь в ИБ — иллюзия, будто технология уже закрыла проблему. Система честно сделала свою работу — нашла аномалию. Но именно человек должен решить, что с ней делать. И если мы будем считать, что ИИ уже все решил, мы сильно рискуем.
Обещание №2. Автоматическое расследование сложных инцидентов
Многие производители заявляют, что их ИИ способен самостоятельно расследовать инциденты. Частично это правда. Система может собрать логи, построить таймлайн и показать цепочку событий. Но полноценное расследование требует понимания бизнес-контекста.
Представим производственную компанию: нарушитель получил доступ к инженерной станции и начал движение в сторону технологического сегмента. ИИ способен показать подозрительную активность, но он не знает:
-
Какие системы критичны.
-
Какие подрядчики сейчас работают на объекте.
-
Какие последствия вызовет отключение оборудования.
Без этого контекста расследование невозможно завершить автоматически.
Обещание №3. ИИ заменит аналитиков SOC
Ооо, это одно из самых популярных заблуждений!
Причина его популярности понятна — SOC испытывают постоянную нехватку кадров, а атаки усложняются. Но если посмотреть на реальные проекты, становится очевидно: сегодня ИИ выступает скорее помощником аналитика.
Например, современные платформы могут автоматически:
-
Группировать связанные события.
-
Удалять часть ложных срабатываний.
-
Собирать контекст по инциденту.
-
Формировать черновики отчетов.
-
Предлагать возможные сценарии реагирования.
Всё это серьезно снижает нагрузку на специалистов.
Однако представим реальный инцидент: компания обнаруживает подозрительную активность на сервере, обслуживающем интернет-магазин. ИИ собирает артефакты и сообщает о возможной компрометации и дальше возникает целый ряд вопросов:
-
Можно ли отключить сервер прямо сейчас?
-
Сколько клиентов потеряют доступ к сервису?
-
Есть ли резервная площадка?
-
Какие финансовые потери возникнут в случае остановки?
Ответов на эти вопросы в логах нет.
Это не делает систему плохой: она честно ловит отклонения. Но это делает нашу работу сложнее: приходится тратить время на проверку легитимных действий, потому что контекст «так договорились» в модель не заложили.
Именно поэтому я не верю в «автоматическое обнаружение неизвестных атак» без участия человека. Алгоритмы видят цифры, а мы видим людей и процессы. И пока эти две картины не совпадают, аналитик остается незаменимым ключевым участником процесса.
Обещание №4. Разработка стратегии безопасности
Ещё один популярный сценарий. Допустим, компания оказывает услуги аутсорсинга, участвует в тендерах, работает с персональными данными и обязана использовать российское ПО. Если попросить языковую модель разработать стратегию ИБ, результат будет выглядеть весьма убедительно: появятся рекомендации по управлению рисками, мониторингу, обучению сотрудников и контролю доступа.
Однако модель не знает:
-
Ограничения бюджета;
-
Особенности корпоративной культуры;
-
Реальные риски бизнеса;
-
Требования ключевых клиентов или акционеров.
В итоге получится хороший шаблон. Но стратегия безопасности всегда требует участия человека.
Однажды я видел подобное — как на стол руководству ложилась «стратегия ИБ», сгенерированная языковой моделью. Все выглядело солидно: разделы, термины, формулировки, даже матрица рисков. На первый взгляд это готовый документ, чтобы отправить «наверх».
А вот начинаешь копать под реальные процессы — и всё рассыпается, потому что модель не знает, что у нас аутсорс‑разработка, часть команд работает в часовых поясах +7, бюджет на ИБ ограничен, а инфраструктура требует отдельного контура с шифрованием. Если бы внедряли вслепую, получили бы либо неработающие процессы, либо постоянные конфликты между безопасностью и бизнес-подразделениями.
Это как дать штурману универсальный маршрут, не зная, где мели и штормы на твоем маршруте. Я не против использовать ИИ для черновиков и структуры. Но финальная стратегия должна быть подписана человеком, который готов отвечать за её реализацию. Иначе это не стратегия, а шаблон.
Где ИИ действительно приносит пользу
Читая предыдущий раздел может сложиться впечатление, что я концептуальный враг искусственного интеллекта. Это, конечно же, не так. ИИ в ИБ — это не волшебная палочка, которая заменит человека, а мощный экскаватор. Бесполезно пытаться копать им траншею в цветочном горшке (как в случае со стратегией), но на правильной стройке он творит чудеса, поэтому я бы хотел показать, где ИИ реально отрабатывает свою стоимость.
Антифрод
Если искать область, где технологии доказали свою эффективность, то это финансовый сектор.
Я работаю с антифрод-системами уже больше 8 лет. В 2018 это были в основном правила и скоринговые модели. Система смотрела на совокупность параметров: сумма, страна, тип устройства. Если транзакция не укладывалась в жесткие рамки, то срабатывало правило, а если укладывалась — пропускала. И этого хватало ровно до тех пор, пока мошенники не научились обходить эти рамки.
Помню кейс: крупная нелегитимная операция прошла, потому что была разбита на несколько переводов чуть ниже порога срабатывания. Модель честно посчитала их нормальными, а по факту это была эксфильтрация.
К 2026 году антифрод стал принципиально другим. Это уже не просто набор правил, а карнавал моделей, которые видят не отдельные признаки, а паттерны кликов, скорость заполнения форм, отклонения от привычного ритма и нюансы взаимодействия с приложением.
Сейчас антифрод-система способна распознать мошенничество, даже если сумма не превышает лимитов, а IP выглядит правильно. Она ловит не одну странность, а совокупность мелких аномалий, которые раньше проходили незамеченными. Антифрод-система анализирует десятки факторов одновременно: локацию, тип операции, историю поведения клиента и прочее, и, если, например клиент банка пенсионного возраста в 13:00 оплатил продукты в магазине рядом с домом, а в 14:00 купил что-то на 180 000 рублей в интернет-магазине посредством только что установленного мобильного приложения с IP-адресом Нью-Йорка, то такая операция блокируется. И здесь, как никогда, полезен ИИ.
Разница между 2018 и 2026 годами огромна — это переход от «защиты по порогам» к «защите по профилю». И этот переход был не про маркетинг, а про реальную необходимость: угрозы стали умнее, и защита должна была стать умнее тоже.
Поведенческая аналитика
Еще один хороший пример — системы класса UEBA.
Представим системного администратора:
-
В среднем он скачивает около 200 Мб данных в день.
-
Работает в стандартное время.
-
Подключается только из корпоративной сети.
За неделю до увольнения он начинает регулярно заходить ночью и выгружает 40 Гб архивов с файлового сервера.
Каждый признак сам по себе может быть допустимым. Но вместе они формируют серьезную аномалию. Система выявляет отклонение от исторического профиля пользователя и уведомляет службу безопасности. Именно в таких сценариях машинное обучение показывает лучшие результаты.
Генеративный ИИ для аналитиков
Отдельно стоит упомянуть современные языковые модели. Многие вендоры уже внедряют их в свои платформы. Например, аналитик может написать: «Покажи все подключения к внешним IP-адресам с сервера бухгалтерии за последние сутки». Система самостоятельно сформирует необходимый запрос.
Или другой пример. Аналитик получает сложное правило обнаружения атаки и просит систему объяснить его простым языком. Модель формирует понятное описание логики работы правила.
Это не что-то революционное, но экономия времени весьма заметна.
Корреляция больших объемов событий
И, пожалуй, самый успешный сценарий применения технологий.
Современная инфраструктура генерирует миллионы событий ежедневно и человек физически не способен обработать такой объем информации. Алгоритмы же могут находить взаимосвязи между событиями, разделёнными днями или даже неделями. Именно поэтому многие современные SIEM и XDR-платформы используют элементы машинного обучения.
Как отличить реальный ИИ от маркетинговой наклейки
Итак, мы выяснили, с чем ИИ отлично справляется, к примеру, там, где требуется анализ больших объемов данных, выявление аномалий и автоматизация рутинных операций.
Однако между возможностями технологий и ожиданиями рынка до сих пор существует заметный разрыв. ИИ хорошо помогает специалистам, но пока не способен заменить понимание бизнеса, опыт аналитика и выстроенные процессы безопасности. Поэтому при выборе решений стоит смотреть не на количество упоминаний ИИ в презентации, а на конкретную задачу, которую технология помогает решить.
Как отсечь маркетинг от инженерии на этапе покупки? Когда вы видите рекламный баннер ИБ-продукта с ИИ (что, кстати тоже сгенерирован ИИ), то какие вопросы нужно задать, чтобы не купить кота в мешке?

Есть несколько простых вопросов:
-
Какая именно технология используется?
-
На каких данных обучалась модель?
-
Какие показатели улучшились после внедрения?
-
Как эти показатели измерялись?
-
Есть ли реальные кейсы заказчиков?
Если поставщик не может дать понятные ответы на эти вопросы, существует высокая вероятность того, что перед вами не революционная технология, а маркетинговый ярлык.
И в помощь также оставлю сравнительную таблицу: «маркетинг vs реальность». Надеюсь, эти материалы помогут вам принять правильное решение.
|
Что видим на сайте/ в презентации |
Что должно быть в техническом разговоре |
Почему это важно для ИБ |
|
Обнаруживает неизвестные атаки. |
Выявляет аномалии на основе модели нормального поведения (ML/UEBA) либо по правилам корреляции. |
«Неизвестные атаки» — слишком широкое обещание. Важно понимать, какой именно механизм детекта используется и какие типы угроз реально закрываются. |
|
Самообучающаяся система. |
Модель дообучается на новых данных; есть процесс валидации и контроля качества данных. |
Без контроля качества модель может начать детектировать легитимные процессы как аномалии. «Самообучение» без надзора — риск роста шума |
|
Снижение инцидентов на X%. |
Снижение доли ложных срабатываний на X%; сокращение времени валидации одного алерта на Y минут. |
В ИБ инциденты часто трактуются по‑разному. Нужны понятные и измеримые метрики, привязанные к конкретным процедурам SOC. |
|
Работает из коробки. |
Требуется настройка профилей пользователей, исключений, правил + пилот 4-8 недель. |
ИБ‑инфраструктура уникальна. Если вендор обещает мгновенный эффект без адаптации, он не учитывает специфику заказчика. |
|
Кейсы крупных заказчиков. |
Обезличенные примеры: тип инфраструктуры, сценарий детекта, метрики эффективности, доля ложных срабатываний. |
Общие слова про «крупного заказчика» не дают понимания, как решение работает в реальных условиях. |
Телеграм-канал Alfa Digital, где рассказывают о работе в IT и Digital: новости, события, вакансии, полезные советы и мемы.
Читайте также:
Автор: KonstantinChmil


