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

Пока ИИ советует, ответ- ственность остается в руках специалиста. Но если ИИ начнет менять настройки, блокировать доступ или запускать сценарии реаги- рования, то вопрос управле- ния риском станет вопросом архитектуры доверия. Есть еще один риск, который пока редко попада- ет в отчеты: чем больше рутинного анализа берет на себя ИИ, тем меньше специалисты сталкиваются с исходными данными. Ана- литик перестает просматри- вать тысячи событий, инже- нер реже вручную анализи- рует журналы, эксперт мень- ше работает с сырым мате- риалом. В краткосрочной перспективе это повышает эффективность, но в долго- срочной – возникает вопрос: сохранит ли команда спо- собность самостоятельно принимать решения. рекомендации к действию без заранее заданных ограниче- ний, журналирования и обяза- тельного подтверждения со стороны человека. Эти про- блемы не означают, что авто- матизация в ИБ невозможна. В части сценариев реагирова- ния она давно работает и оправдана. Но каждый такой сценарий должен быть задан явно, ограничен и проверяем. Иначе вы получаете не управ- ляемый инструмент, а некон- тролируемого участника про- цесса. Большинство ИИ-реше- ний пока что остаются помощ- никами, которые дают реко- мендации, но не действуют самостоятельно. Однако рынок быстро движется к агентным системам, способным иниции- ровать процессы без участия человека. Именно здесь появляются новые риски. Пока ИИ советует, ответственность остается в руках специалиста. Но если ИИ начнет менять настройки, блокировать доступ или запускать сценарии реа- гирования, то вопрос управле- ния риском станет вопросом архитектуры доверия. Третий источник проблемы – непрозрачные рекомендации. ИБ-решения должны быть объ- яснимы: для внутренних про- цессов, для регулятора, для раз- бора инцидента. Проект нового ГОСТ Р для ИИ в КИИ как раз двигает рынок в эту сторону – непрерывный контроль, аудит, фиксация действий, планы реа- гирования и регулярные про- верки становятся не желатель- ной практикой, а формальным требованием. Есть еще один риск, который пока редко попадает в отчеты: чем больше рутинного анализа берет на себя ИИ, тем меньше специалисты сталкиваются с исходными данными. Анали- тик перестает просматривать тысячи событий, инженер реже вручную анализирует журналы, эксперт меньше работает с сырым материалом. В крат- косрочной перспективе это повышает эффективность, но в долгосрочной – возникает вопрос: сохранит ли команда способность самостоятельно принимать решения, если ИИ окажется недоступен или нач- нет систематически ошибать- ся? Автоматизация снимает нагрузку, но одновременно может приводить к постепен- ной эрозии профессиональных навыков. Есть и системный риск, кото- рый часто недооценивают. Когда разные члены команды исполь- зуют разные публичные ИИ-сер- висы вне контролируемого кон- тура, у службы ИБ нет видимости и нет возможности разграни- чить, кто, что и куда передавал, поэтому нет оснований считать, что чувствительные данные не ушли за периметр. Зрелый подход к ИИ Мой практический вывод: ИИ-помощник в ИБ допустим только внутри доверенного и управляемого контура. И это не красивая формальная пози- ция, а экономическая и опера- ционная необходимость. На практике это означает несколько положений. 1. Там, где данные чувстви- тельны, допустимо только локальное или закрытое раз- вертывание. Никаких публичных API с корпоративными данными, никакой отправки журналов событий или содержимого инци- дентов во внешние облака. Это базовый гигиенический уровень. 2. Разграничение доступа: ИИ-помощник должен видеть ровно столько, сколько нужно для конкретной задачи, и не больше. 3. Журналирование всех дей- ствий и запросов – иначе вы не сможете ни провести рассле- дование, ни пройти проверку. 4. Встраивание в действую- щие средства контроля, а не параллельный контур, который живет отдельно от SIEM и про- цессов реагирования. 5. И главное – обязательное подтверждение значимых дей- ствий человеком: не как фор- мальность, а как реальный эле- мент архитектуры. Теперь об экономике. ИИ в ИБ надо оценивать не по числу пользователей и не по тому, сколько раз обратились к моде- ли. Правильные метрики: сни- жение трудозатрат на первич- ный анализ, ускорение MTTR, уменьшение доли ручной рути- ны, влияние на число пропу- щенных событий из-за устало- сти команды. И отдельно – стои- мость владения с учетом интег- рации, безопасного разверты- вания, аудита и контроля самого ИИ-контура. По данным IBM, компании, внедрившие ИИ и автоматизацию в процессы ИБ, сокращали ущерб от инци- дентов в среднем на $1,9 млн и завершали расследования быстрее на 80 дней. Но это результат системной работы, а не просто установки ИИ- помощника. Многие проекты проваливаются именно потому, что запускают ИИ в неправиль- ный процесс – с высокой ценой ошибки и без нормального кон- тура управления. Я вижу в ИИ-помощнике реальный инструмент для раз- грузки ИБ-команды. Но это именно инструмент: точечный, управляемый, встроенный в архитектуру с понятными ролями, журналом и ограниче- ниями. Для ИБ опаснее всего не слабый ИИ, тот, которому доверили лишнее, и который работает без надлежащего контроля в контуре, где ошибка имеет последствия. l • 81 ИИ-АССИСТЕНТЫ ДЛЯ ИБ www.itsec.ru Ваше мнение и вопросы присылайте по адресу is@groteck.ru