Журнал "Information Security/ Информационная безопасность" #3, 2026

ны. Модель усваивает эти аномалии как норму. Когда начнется реальная атака, использующая эти паттерны, ИИ просто закроет на неё глаза. Он будет считать легитимным то, что на самом деле является взломом. Второй – отравление базы знаний (RAG Poisoning). В архитектурах Retrieval-Augmented Generation модель не меняет свои веса, а использует внешние документы как контекст. Зло- умышленник внедряет вредоносные инструкции или ложные факты прямо в корпоративные документы: PDF-отчеты, записи в Wiki-подобные системы, опи- сания прошлых инцидентов. Когда ИИ- агент ищет информацию для ответа, он извлекает этот отравленный документ. Для модели это выглядит как легитим- ный контекст. В итоге она либо выдаст ложные рекомендации, либо выполнит скрытую команду атакующего, спрятан- ную в тексте. 3. Небезопасная обработка выход- ных данных (Insecure Output Handling / LLM06). Если ИИ автоматически пишет скрипты для исправления конфигура- ций (Bash-скрипты или правила для маршрутизаторов), его ответы требуют строжайшей проверки. Скомпромети- рованная через Prompt Injection модель может, например, сгенерировать код, содержащий команду удаления дан- ных или открытие скрытых портов доступа. Проблема черного ящика Математическая архитектура глубо- ких нейросетей состоит из миллиардов параметров. Человек не способен про- следить точную логическую цепочку, почему модель приняла конкретное решение на основе данного набора логов. Если инцидент уже произошел, отсутствие прозрачности становится серьезным препятствием. Инженеры и специалисты по расследованию не могут оперативно установить причину сбоя: был ли это целенаправленный взлом самого ИИ, проявление уязви- мости или легитимное, но ошибочное решение модели. Модели зрелости делегирования прав ИИ Предоставление автономии ИИ долж- но осуществляться последовательно. Кроме того, различные уровни автоно- мии требуют разные полномочия деле- гирования. В практике ИБ принято выде- лять различные уровни зрелости, то же самое есть и в части ИИ. Так, к примеру, есть широко распространенная в техни- ческой литературе трехуровневая шкала, описывающая степень автономии ИИ и уровень участия человека в процессе: Human-in-the-Loop (HITL), Human-on-the- Loop (HOTL), Human-out-of-the-Loop (HOOTL). В начале 2026 года соучредителем и главным исполнительным директо- ром Cloud Security Alliance была пред- ложена шестиуровневая таксономия уровней автономии 2 , которая помогает организациям понять, что они развер- тывают, какие меры контроля уместны и как ответственно управлять ИИ- системами. Данная таксономия, по мнению автора, более близка приня- тым в ИБ моделям зрелости. Рассмот- рим, как она применяется в контексте управления инцидентами и как пере- секается с общепринятой трехуровне- вой шкалой: l Уровень 0. Нет автономии (No Auton- omy / управляется человеком). ИИ в контуре управления отсутствует. Анали- тики вручную собирают логи, пишут ста- тические правила корреляции и выпол- няют команды реагирования. Скорость обработки инцидентов ограничена про- изводительностью команды реагирова- ния. l Уровень 1. Ассистируемый (Assisted / второй пилот – Co-Pilot). ИИ работает как интеллектуальный ассистент. Он агрегирует данные, выявляет скрытые взаимосвязи, обогащает контекст через RAG и выдает рекомендации. Решение о действии принимает человек, ИИ лишь предлагает варианты. Пример – модель анализирует алерт и говорит "С веро- ятностью 94% процесс вредоносен. Реко- мендуется изолировать хост 10.0.2.15". l Уровень 2. Контролируемый (Con- trolled / одобрение человеком). ИИ само- стоятельно формирует пакет действий, но человек должен их утвердить перед исполнением. Агент собирает доказа- тельства по инциденту, готовит скрипт блокировки или изоляции, но не выпол- няет его без явного одобрения аналити- ка. Это классический Human-in-the-Loop с пакетной обработкой. l Уровень 3. Условно-автономный (Con- ditionally Autonomous / Human-on-the- Loop). ИИ действует самостоятельно, но в жестко заданных рамках. Ему делеги- рованы права на запись, но только для определенных типов инцидентов (напри- мер, низкой критичности) или только для изолированных сегментов инфра- структуры. Человек не участвует в каж- дом шаге, но мониторит действия ИИ в реальном времени и может перехватить управление. Обязательное условие – наличие механизма мгновенного отката операции. l Уровень 4. Высокоавтономный (Highly Autonomous / Human-out-of-the-Loop для оперативных решений). ИИ-агент пол- ностью автономен в реагировании на инциденты. Он обрабатывает атаки в реальном времени, динамически пере- страивая конфигурации сети. Человек исключен из цикла оперативного реаги- рования, потому что скорость атак не оставляет времени на человеческую реакцию. Однако человек остается в контуре управления: он получает пост- фактум-отчеты, разбирает исключения, задает общие правила и политики. Область действия ИИ жестко ограничена заранее утвержденными сценариями. l Уровень 5: Полная автономия (Full Autonomy / самостоятельная постановка целей). ИИ сам ставит цели, адаптирует стратегии и модифицирует собственное поведение без участия человека. В кор- поративной ИБ этот уровень остается теоретическим (по крайней мере пока). Делегирование нейросети права пере- писывать собственные правила и бес- контрольно изменять периметр безопас- ности создает неприемлемые риски. Пока не существует надежных механиз- мов контроля за системами, которые могут изменять собственную логику работы. Пример архитектуры безопасного внедрения Для уровней зрелости, начиная со второго, архитектура должна ограничи- вать возможности ИИ так, чтобы даже скомпрометированная модель не могла выйти за рамки своих полномочий. 1. ИИ-аналитик -- анализирует логи и данные в режиме чтения. Изменять инфраструктуру он не может. На выходе формирует JSON с предлагаемыми дей- ствиями и обоснованием. 2. Шлюз оркестрации -- обычная детер- минированная программа без ИИ. Она проверяет JSON на соответствие поли- тикам безопасности и только после этого выполняет допустимые действия. Напри- мер, запрос на блокировку хоста будет отклонен, если он входит в список кри- тических систем. 3. Guardrails -- два слоя фильтрации: перед ИИ и после него. Первый анали- зирует входящие данные и промпты, выявляя признаки инъекций. Второй про- веряет ответ модели. Если ИИ под воз- действием инъекции попытается выпол- нить нерелевантное действие, Guardrails заблокирует такой ответ. Только после проверки сценарий передается в среду исполнения. В заключение Делегировать ИИ доступ к данным и инцидентам придется. Скорость совре- менных атак измеряется минутами, а объем событий давно превышает воз- можности человека. Без автоматизации защитные команды просто не успевают реагировать. Но доверять модели без ограничений нельзя. Безопасность здесь обеспечивает не сам ИИ, а архитектура, которая жестко контролирует его пол- номочия и оставляет принятие критичных решений за человеком l • 77 ИИ-АССИСТЕНТЫ ДЛЯ ИБ www.itsec.ru Ваше мнение и вопросы присылайте по адресу is@groteck.ru 2 https://cloudsecurityalliance.org/blog/2026/01/28/levels-of-autonomy