36 из 40 протестированных ИИ-моделей на сложных вопросах чаще выдавали уверенный неверный ответ, чем правильный. Для кибербезопасности это означает неприятную вещь: галлюцинации ИИ уже нельзя считать забавным побочным эффектом чат-ботов, когда на кону доступы, инциденты и изменения в критичной инфраструктуре. Для русскоязычных IT-команд вывод практический: если модель звучит как старший аналитик SOC, это еще не делает ее правой.
О рисках такого класса сообщает The Hacker News, разбирая, как ошибочные ответы ИИ попадают в контур реальных решений. Проблема в самой механике языковых моделей: когда системе не хватает уверенности, она не останавливается и не говорит честное «не знаю», а достраивает наиболее вероятный ответ по шаблонам из обучающих данных. На экране это выглядит как связный, уверенный и местами даже убедительный текст. В операционной безопасности этого достаточно, чтобы человек кивнул, а автоматизация пошла выполнять команды.
В материале приводится показатель из бенчмарка AA-Omniscience компании Artificial Analysis за 2025 год: из 40 моделей только четыре на трудных вопросах реже ошибались с уверенным видом, чем отвечали верно. Цифра неприятна именно тем, что она не про редкие сбои на краю распределения, а про системный паттерн. Если ИИ все чаще подключают к разбору алертов, анализу журналов, подсказкам по реагированию и работе с привилегированными учетными записями, то ошибка модели становится не просто неверным текстом, а потенциальной уязвимостью в цепочке принятия решений.
Что именно идет не так, источник описывает довольно приземленно. Во-первых, модель наследует дефекты обучающих данных: устаревшие сведения, перекосы, неточные формулировки. Во-вторых, базовые LLM не проверяют факты, а оптимизируют правдоподобие ответа. В-третьих, расплывчатые промпты дают системе пространство для догадок, а догадки в ИБ обычно заканчиваются лишней работой или лишним инцидентом. Отдельный риск связан с будущим качеством данных: чем больше сеть заполняется сгенерированным контентом, тем выше шанс, что новые модели начнут учиться на старых выдумках. Это уже не просто шум, а угроза деградации самих источников знаний.
На практике галлюцинации ИИ бьют по безопасности тремя способами. Первый — пропущенные угрозы. Если атака похожа на уже известный паттерн, модель справляется прилично. Если техника новая, редкая или относится к zero-day, сравнивать ей попросту не с чем. В результате вредоносная активность проходит мимо радаров. Второй — придуманные угрозы. Обычный сетевой трафик или штатное поведение пользователя модель может принять за атаку, поднять тревогу и заставить команду реагирования выключать сервисы, тратить часы аналитиков и плодить хаос на ровном месте. Со временем такие ложные срабатывания ведут к классической усталости от алертов: люди начинают меньше верить даже тем предупреждениям, которые уже не шутят.
Третий сценарий самый опасный — неверная ремедиация. Это момент, когда доверие к модели уже заработано, а ее совет звучит конкретно и деловито: удалить файлы, поменять конфигурацию, отключить правило на межсетевом экране, скорректировать права доступа. Если такую рекомендацию исполняет человек с широкими полномочиями или, хуже того, автоматизированный контур, локальный инцидент легко превращается в полноценный пробой. Ошибочный совет может открыть дорогу к lateral movement, сломать защитные механизмы или привести к необратимой потере данных. И тут важно неприятное уточнение: даже если ИИ верно обнаружил аномалию, он все равно может испортить развязку неправильным рецептом лечения.
Для разработчиков и продуктовых команд из этого следует довольно жесткая инженерная дисциплина. Нельзя проектировать AI-функции так, будто модель по умолчанию является источником истины. Если ИИ участвует в triage инцидентов, подготовке playbook, управлении политиками доступа или инфраструктурными изменениями, на выходе должна стоять не кнопка «выполнить», а этап проверки. Причем проверка обязательна не только для подозрительных ответов. В этом и проблема: модель одинаково уверенно формулирует и правильные выводы, и полный вздор. На слух они различаются куда хуже, чем хотелось бы.
Бизнесу и IT-руководителям источник советует смотреть на тему не как на проблему качества текста, а как на вопрос управления доступом. Самая здравая мера — принцип наименьших привилегий. Если AI-система должна читать файлы, она не должна их удалять. Если она анализирует журналы, ей не нужен доступ к изменению конфигурации. Если она предлагает действия по инциденту, это еще не повод давать ей полномочия на применение этих действий. Такой подход ограничивает ущерб даже в тех случаях, когда галлюцинации ИИ все-таки пробиваются в рабочий процесс.
Вторая линия обороны — данные и промпты. Обучающие и grounding-данные приходится рассматривать как полноценный актив безопасности: чистить устаревшее, вычищать ошибки, отслеживать смещения. Параллельно нужно учить сотрудников задавать системе точные и проверяемые запросы. В расплывчатом вопросе модель почти всегда найдет место для фантазии. В хорошей постановке задачи больше шансов получить ответ, который можно быстро сверить с логами, политиками, CMDB или реальным состоянием инфраструктуры. Для HR и руководителей это означает вполне прикладную вещь: обучение работе с ИИ в ИБ-командах должно быть частью процессов, а не факультативом для энтузиастов.
Главный вывод здесь немного раздражающий, но полезный: чем активнее компании встраивают ИИ в безопасность, тем важнее становится старая добрая инженерная скука — проверка, разграничение прав, аудит данных и контроль автоматизации. Рынок уже привык продавать ИИ как ускоритель SOC и помощника для перегруженных команд. Следующий этап взросления, похоже, будет менее глянцевым: выигрывать станут не те, кто первым подключил модель к критическим процессам, а те, кто заранее предусмотрел, что она может ошибаться уверенно, быстро и в самый неподходящий момент.