Моя позиция простая. Машине можно поручить самостоятельное расследование в пределах заранее выданных полномочий. А право блокировать системы, лишать сотрудников доступа и завершать расследования нужно ограничивать ещё строже. Уверенность нейросети не заменяет доказательств и не даёт права рисковать чужим бизнесом.

Расследователь должен задавать вопросы, а не раздавать ярлыки

Обычная система сортировки получает тревогу и решает, насколько срочно показать её человеку. ИИ-расследователь идёт дальше. Увидел подозрительную программу, выяснил, откуда она появилась. Нашёл сетевое соединение, проверил адрес и действия пользователя. Обнаружил признаки захвата учётной записи, посмотрел, не вошёл ли злоумышленник с теми же данными на другие серверы. Каждый следующий шаг зависит от предыдущих находок.

Разница напоминает приёмный покой больницы. Одно дело передать врачу записку "пациент, вероятно, здоров". Другое, приложить результаты анализов, историю симптомов, список непроверенных подозрений и объяснить, почему случай требует внимания. Хороший ИИ оставляет аналитику вторую версию. Не красивый ответ, а последовательность событий, исходные записи и честный перечень того, чего выяснить не удалось.

Особенно опасен вывод "признаков атаки нет", сделанный из неполных данных. Если сетевой журнал не поступил, агент не знает, связывалась ли подозрительная программа с внешним сервером. Отсутствие записи нельзя превращать в доказательство безопасности. Никакой мощности языковой модели здесь не поможет.

Есть ещё разница между закрытием отдельной тревоги и завершением расследования. Допустим, одно оповещение оказалось ложным. Агент обоснованно убрал его из очереди. Но связанные события могут по-прежнему требовать проверки, а злоумышленник вполне способен использовать другой способ проникновения. Закрытый сигнал не означает устранённую угрозу. Нормальная система хранит связь между отдельными оповещениями, общим происшествием и действиями по его устранению. И не выдаёт первое за третье.

Дорогой агент быстро обнаружит дешёвый беспорядок

Чтобы связать вход сотрудника, запуск программы и сетевое соединение в одну историю, записи должны содержать правильное время и идентификаторы устройств. На практике часы одного сервера отстают, другой записывает местное время без указания часового пояса, третий давно перестал отправлять журналы. Машина способна собрать из обрывков убедительную последовательность. Неправильную, зато с красивым объяснением.

Не меньшее значение имеет опись оборудования. Одинаковая подозрительная активность на ноутбуке сотрудника, сервере резервного копирования и системе, через которую проходят платежи, требует разных мер. Для безопасного решения нужны назначение устройства, ответственный сотрудник, связь с другими системами и последствия остановки. Без таких сведений автоматическая "защита" может прервать продажи или лишить компанию доступа к резервным копиям в самый неудачный момент.

Следующая проверка ещё неприятнее для руководства. Знает ли служба безопасности, какие изменения согласованы с администраторами? Когда на десяти серверах одновременно появляется новая служба, агент должен сопоставить происходящее с заявкой на установку программы. Если компания живёт по принципу "поставили и потом сообщим", машине не с чем сравнивать подозрительную активность. Она либо начнёт без конца тревожить людей, либо однажды примет настоящую атаку за обычную работу инженеров.

Получается довольно злая история. Компания покупает дорогую систему, рассчитывая сократить расходы на безопасность, а внедрение вскрывает многолетний управленческий бардак. Никто толком не знает, какой сервер за что отвечает, кому разрешено его отключать и почему вчера вечером на нём появилась новая программа. Искусственный интеллект не исправит плохую организацию работы. Зато поможет узнать о ней за весьма приличные деньги.

Пусть ИИ ищет ответы, но не получает ключи от всего здания

Автоматизировать реагирование на атаки умели задолго до нынешних языковых моделей. Для такой работы существуют платформы SOAR, которые связывают средства защиты и запускают заранее утверждённые сценарии. Например, собирают связанные события, отправляют подозрительный файл на проверку, запрашивают разрешение на блокировку и записывают результат. Для повторяющихся происшествий подобная схема прекрасно обходится без генеративного ИИ.

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

Например, для проверки одного подозрительного письма агенту не обязательно читать переписку всего руководства. А для анализа заражённого ноутбука не требуется доступ ко всем резервным копиям компании. Права на чтение данных тоже нужно ограничивать. Необходимо задавать допустимые источники, объём запросов и перечень инструментов, фиксировать обращения и контролировать передачу сведений во внешние сервисы. Иначе расследователь с самыми добрыми намерениями превращается в программу, которой разрешено копаться буквально везде.

С опасными действиями ограничения должны быть ещё жёстче. Примерно как корпоративная карта. Сотрудник сам выбирает, что купить для работы, но лимиты устанавливает бухгалтерия, а не вдохновение покупателя. Подозрительный ноутбук рядового сотрудника при определённых условиях можно автоматически отключить от корпоративной сети. А вот останавливать сервер, который принимает платежи, только потому, что нейросеть объявила атаку почти несомненной, идея сомнительная.

Даже если модель сообщает об уверенности в 98%, нельзя заключить, что вероятность ошибки составляет оставшиеся 2%. Для подобной трактовки оценку сначала нужно проверить на реальных данных и убедиться, что заявленная уверенность соответствует фактической частоте правильных решений. Но и отказываться от блокировки из страха перед простоем не всегда разумно. Если нападение продолжается, промедление может обойтись ещё дороже. Решение зависит от последствий обоих вариантов, ошибочной остановки системы и пропущенной атаки, а не от красивого процента на экране.

Есть и другая ловушка. Отправить команду на блокировку не означает остановить атаку. Компьютер может оказаться выключен или недоступен по сети. Удаление одного вредоносного файла не гарантирует, что злоумышленник не оставил второй способ проникновения. А смена пароля вовсе не обязательно завершает уже открытые сеансы пользователя в приложениях.

У Microsoft в документации встречается неожиданная рекомендация. При отзыве доступа у скомпрометированной учётной записи в инфраструктуре, где локальная Active Directory связана с облачной системой входа, пароль в локальном каталоге советуют сбросить дважды. Причина связана с риском атак с использованием похищенных цифровых отпечатков паролей, особенно при задержках между серверами. Для обычного сброса пароля такое правило не требуется. Но даже двойной сброс не гарантирует завершения всех сеансов в сторонних приложениях.

Поэтому агент должен проверять не факт отправки команды, а фактический результат. Устройство изолировано? Подозрительные соединения прекратились? Доступ действительно закрыт? Если подтверждения нет, расследование продолжается или переходит человеку. Иначе отчёт "угроза устранена" может означать лишь то, что система успешно нажала кнопку.

Четыре тревоги, в которых легко ошибиться

Пределы автономии хорошо видны на обычных происшествиях. Опасность редко скрывается в каком-нибудь фантастическом приёме хакеров. Чаще машине нужно отличить будничную работу от начала атаки.

Письмо от "службы поддержки". Сотруднику предлагают срочно войти в корпоративную почту. Агент проверяет ссылку, отправителя и похожие письма у коллег. Но одинаковая тема не делает рассылку вредоносной. Даже переход по ссылке ещё не означает кражу пароля. Нужно выяснить, вводил ли сотрудник данные, появились ли подозрительные входы и не остались ли копии письма в других ящиках.

Текстовый редактор запускает системную команду. Такое действие настораживает, поскольку документ может запускать вредоносный код. Но похожим способом иногда работают законные средства автоматизации. ИИ должен восстановить цепочку запуска, проверить созданные файлы и соединения, а не отключать компьютер лишь по сочетанию названий двух программ. Для рабочего ноутбука и сервера с важным приложением допустимые меры будут разными.

Вход из другой страны. Незнакомый адрес может принадлежать корпоративной сети или посреднику для защищённого подключения. Подозрения усиливаются, если сразу после входа кто-то меняет способы подтверждения личности, создаёт пересылку почты на посторонний адрес или обращается к незнакомым ресурсам. География сама по себе не повод лишать сотрудника доступа.

Новая служба сразу на нескольких серверах. Возможно, администраторы разворачивают обновление. Возможно, атакующий распространяется по сети. Решающий вопрос порой не технический, а организационный. Существует ли согласованная заявка, совпадают ли в ней время, учётная запись и список машин? Даже полное совпадение не доказывает безопасность неизвестного файла, а отсутствие заявки ещё не доказывает атаку. Сверка, кстати, не появляется автоматически при покупке ИИ. Связь с системой управления изменениями придётся настроить.

Общий принцип один. Хороший расследователь показывает, на каких фактах построен вывод. Плохой превращает недостаток сведений в гладкое объяснение, после которого человеку особенно трудно заметить ошибку.

Злоумышленник может спрятать команду внутри самой улики

Есть угроза, которой у обычных средств автоматизации не было в таком виде. Языковая модель читает не только инструкции разработчиков, но и тексты, частично контролируемые злоумышленником. Тему письма, имя файла, содержимое документа, адрес страницы или строку журнала. Преступник может встроить туда обращение к ИИ с требованием проигнорировать признаки атаки, признать событие безопасным или передать собранные сведения постороннему получателю.

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

Причём грубое "забудь все предыдущие указания" далеко не обязательно сработает. Гораздо интереснее попытка выдать вредоносную строку за замечание старшего аналитика или служебное подтверждение безопасности. В исследовании, представленном на конференции USENIX Security 2026, учёные показали, что вредоносные инструкции внутри сетевых журналов способны влиять на выводы языковых моделей. Проверки проводились в экспериментальных условиях, поэтому результаты нельзя автоматически переносить на любой промышленный SOC.

Некоторые разработчики пытаются бороться с ошибками, поручая одной модели перепроверять другую. В декабре 2025 года Yandex Cloud описала подобную схему в собственном центре мониторинга. Один ИИ-агент обрабатывает входящие тревоги, второй проверяет достоверность данных. По заявлению компании, система автоматизировала 39% рутинных задач, а время обработки некорректных оповещений сократилось на 86%.

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

Поэтому непроверенные тексты нужно отделять от управляющих инструкций, хранить исходные доказательства и ограничивать права агента. Критичные выводы желательно сверять с независимыми источниками событий и установленными правилами. А при испытаниях специально подсовывать системе письма и журналы, содержащие попытки обмануть модель. Если агент не умеет сопротивляться таким проверкам, право самостоятельно закрывать расследования выдавать рано.

Пустая очередь тревог ещё не означает экономию

Первые результаты внедрений выглядят впечатляюще. По клиентскому кейсу Microsoft, медицинская сеть St. Luke's University Health Network экономит почти 200 часов работы аналитиков в месяц благодаря автоматическому разбору и закрытию тысяч ложных тревог, связанных с фишинговыми письмами. Именно фишинговыми, а не всеми происшествиями центра мониторинга. Закрыть ошибочное оповещение от сотрудника гораздо проще, чем расследовать проникновение злоумышленника в корпоративную сеть и убедиться, что доступ действительно прекращён.

Случай показательный, но переносить 200 часов на чужую инфраструктуру бессмысленно. Перед нами результат конкретной организации, опубликованный поставщиком. И даже тысячи закрытых оповещений ничего не говорят о том, сколько полноценных расследований завершилось, сколько атак удалось остановить и не пропустила ли система настоящую угрозу среди ложных тревог.

Считать выгоду нужно по отдельным видам происшествий, а не по всему центру мониторинга сразу. У фишинга одни закономерности, у захвата учётных записей другие. Количество закрытых сигналов само по себе мало что говорит о результате. Гораздо полезнее измерять время до обоснованного вывода, скорость фактической остановки атаки и общий труд аналитиков вместе с исправлением ошибок агента.

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

Выход не в том, чтобы заставить самых опытных специалистов перечитывать каждое закрытое дело. Нужен независимый выборочный контроль. Часть случаев выбирают случайно, часть по повышенному риску, например когда затронут критичный сервер, привилегированная учётная запись или не хватает журналов. Проверяющему полезно сначала показать исходные события без машинного вердикта, чтобы заключение "безопасно" не подсказывало готовый ответ. Спорные и сложные случаи передают специалистам с подходящими знаниями и полномочиями.

Затраты на такую работу необходимо включать в расчёт экономии. И отдельно учитывать атаки, которые обнаружили позже среди автоматически закрытых происшествий. Если после внедрения люди стали работать меньше, но пропущенные угрозы никто не ищет, перед нами не доказанная эффективность, а очень удобная статистика.

Эксперимент со 167 аналитиками показал цену слова "безопасно"

В ноябре 2025 года исследователь Microsoft Джеймс Боно опубликовал эксперимент с участием 167 специалистов по безопасности. Каждому дали очередь из 25 писем, на которые пожаловались сотрудники. Одна группа работала самостоятельно, вторая видела оценки и объяснения ИИ, а третья получала письма в порядке, подготовленном машиной, но не знала об этом.

Результат на первый взгляд почти рекламный. По расчётам авторов, если исключать из ручной проверки письма, признанные агентом безопасными, аналитики могли выявлять в 6,5 раза больше вредоносных писем за минуту работы. В более неблагоприятном расчётном сценарии, где ИИ распознавал атаки хуже, а доля вредоносных писем была выше, выигрыш составлял около 3,1 раза. Причём основную часть прироста давала возможность не показывать людям письма, которые машина уже отсеяла.

Но есть существенная оговорка. На исходном наборе из 93 писем агент классифицировал все случаи правильно. Поэтому исследователи специально создали ошибочные машинные вердикты, чтобы проверить, как люди реагируют на неверные подсказки. Полученные результаты относятся к контролируемому эксперименту, а не к измеренной частоте ошибок в работающем центре мониторинга.

И вот здесь начинается самое интересное. Когда вредоносное письмо сопровождалось ложной оценкой ИИ "безопасно", аналитики, видевшие машинную подсказку, пропускали угрозу в 46% случаев. Контрольная группа без подсказки пропускала те же специально подготовленные случаи в 17% случаев. Разница составила 29 процентных пунктов.

При этом участники не соглашались с машиной автоматически во всём. На письма, признанные агентом вредоносными, аналитики тратили больше времени и внимательно проверяли выводы. Проблема проявлялась именно в обратной ситуации. Когда ИИ объявлял письмо безопасным, человек начинал доверять готовому заключению и чаще пропускал угрозу.

Исследование не подтверждает расхожую мысль, будто начинающие специалисты обязательно хуже опытных справляются с подобными задачами. Участники с меньшим стажем не показали систематически худшую способность находить вредоносные письма. Опасность заключается не в должности проверяющего, а в том, как машинная подсказка меняет человеческое решение. Именно поэтому независимая проверка должна по возможности начинаться с исходных фактов, а не с чтения готового оправдания агента.

Авторы исследования считают рациональным скрывать от аналитиков письма, которые агент признал безопасными. Расчёт понятен, иначе исчезает значительная часть выигрыша во времени. Но для руководителя центра мониторинга остаётся неудобный вопрос. Кто заметит атаку, которую машина ошибочно убрала из очереди? Ответ придётся искать не в новой модели, а в независимых проверках, контроле качества и готовности платить за обнаружение собственных ошибок.

У пустой к утру очереди тревог бывают два объяснения. Одно означает, что специалисты действительно разобрались с угрозами. Другое, что опасные события научились закрывать так быстро, что их больше никто не видит. Отличить одно от другого можно единственным способом. Иногда открывать то, что машина уже назвала безопасным.