© «Директор по безопасности», №11-2026, Ноябрь, 2026 г.
Начало: журналы "Директор по безопасности" №09,10-2026
Продолжение:
Тимур Биячуев – кандидат технических наук по информационной безопасности (НИУ ИТМО), более 20 лет в кибербезопасности и разработке.
Более 15 лет в «Лаборатории Касперского»: от руководителя антивирусной лаборатории до вице-президента по исследованию угроз, в 2024–2025 – исполнительный вице-президент по корпоративному бизнесу. В перерыве руководил исследовательскими лабораториями Huawei и Samsung. Соавтор трёх патентов по автоматизации анализа вредоносных объектов.
Выступал на международных отраслевых конференциях – GITEX (ОАЭ, Сингапур), Luxembourg Cybersecurity Day, Иннопром.
Сейчас ведёт независимую исследовательскую практику по безопасности ИИ-агентов; научный консультант магистерской программы «Технологическое предпринимательство» бизнес-школы МФТИ.
Telegram-канал: @tbiyachuev
1. Агенты входят в рабочие процессы
В первых публикациях цикла мы разобрали, что представляют собой ИИ-агенты и какие угрозы для организации они могут нести. Теперь перейдем к отечественной практике и посмотрим, на какие участки и задачи компании уже допускают автономные системы, а также как это меняет привычный периметр контроля.
Для меня то, что сегодня происходит с ИИ-агентами, выглядит как уже знакомый путь. В середине 2000-х, в период моей работы в Лаборатории Касперского, мы проводили схожую по масштабу ИИ-трансформацию. Поток угроз тогда стал расти лавинообразно, и мы вовремя приняли упреждающие меры: вместо бесконечного наращивания ручного труда аналитиков сделали ставку на автоматизацию процессов с использованием машинного обучения. Многолетняя масштабная перестройка процессов антивирусной лаборатории привела к тому, что основной объем выявления угроз взяли на себя автоматические средства с широкими, но строго управляемыми полномочиями. ИИ-системы обнаруживали и блокировали основную долю угроз самостоятельно. На долю вирусных аналитиков остался самый сложный экспертный труд – исследовать качественно новые векторы атак и дообучать автоматические системы.1 Автоматизация позволила справляться с растущим потоком угроз и одновременно повысить качество антивирусной защиты. Пожалуй, главный практический вывод тех лет применим и к современным системам: успех автоматизации определяется не одной лишь мощностью моделей, а разграничением прав, подготовкой людей и архитектурой защитных систем. Конечно, современные агенты обладают качественно иной степенью самостоятельности – они интерпретируют естественный язык как инструкции, выбирают цепочки действий и обращаются к разным корпоративным сервисам. Однако, на мой взгляд, базовые принципы управляемости процессов и снижения рисков остаются во многом прежними.
Для этой статьи я разобрал более ста докладов с конференций, профильных вебинаров, экспертных дискуссий и публикаций в инженерных блогах за последние два года. Отобранные примеры как раз и отражают ключевые развилки внедрения – какие действия поручать агентам, как перестраивать привычные процессы и кому доверять контроль за результатом.
Российские компании делегируют агентам широкий спектр задач – от первой линии клиентской поддержки и разработки программ до анализа корпоративных данных и первичной фильтрации алертов безопасности. При этом опыт 2025–2026 годов демонстрирует значительный разброс полномочий. В одних проектах агентам поручают только сбор и агрегацию данных, а в других – дают право самостоятельно проводить транзакции и менять записи в рабочих базах.
Для службы безопасности в этом опыте ключевое значение имеют сопутствующие изменения в периметре контроля – новые права доступа к данным, перераспределение нагрузки между людьми и ИИ-системами, правила приемки и персональная ответственность за результат. Чтобы увидеть эту механику в деталях, разберем конкретный рабочий сценарий.
В кейсе МТС, который описал Владимир Дробот в техническом блоге компании, агентной системе поручили первичный анализ обращений технической поддержки. Раньше инженеру второй линии при разборе инцидента требовалось сначала вручную понять, что именно искать в документации и какие логи поднимать. Теперь же агент получает обращение, определяет необходимые источники (документацию, журналы или базы данных) и формирует сводку. Основные этапы анализа в этой системе заданы заранее, но внутри них ИИ самостоятельно выбирает источники и дальнейшие действия. Результат сохраняется прямо в тикет-системе в виде аналитической сводки и проекта ответа для инженера. При этом доступ агента к эксплуатационным базам данных через протокол MCP ограничен только чтением, а автоматические ответы внешним клиентам у команды в планах на будущее.2
У агента здесь есть четко очерченный участок работы и границы действий. Но при масштабировании такого сценария неизбежно встает вопрос о том, кто будет поддерживать систему, проверять результаты и отвечать за изменения после завершения пилота. Поэтому организации с самого начала нужен устойчивый регламент.
2. Как оценить готовность процессов организации
Представим типовую ситуацию – несколько отделов подключаются к единой корпоративной ИИ-платформе, которую поддерживает ИТ. Сама платформа технически готова к нагрузкам, но в командах пока не выработаны единые стандарты работы. Так, в пилотной группе сотрудники со временем нащупывают границы применимости инструмента и у них появляется понимание, где агента нужно перепроверить, но часть этого опыта часто остается недокументированной. Если передать сценарий в соседний отдел без понятных инструкций, новые пользователи рискуют либо чрезмерно довериться непроверенным подсказкам, либо, напротив, разочароваться в инструменте после первых же неточностей.
Здесь уместно вспомнить правило AI-трансформации, которое вывела компания BCG – при внедрении ИИ 70% усилий должны приходиться на людей и процессы и лишь 30% – на технологии, алгоритмы и данные.3 С этим подходом согласуются и результаты исследования Strategy Partners – 82% опрошенных представителей российских ИТ-компаний назвали главным барьером внедрения долгие согласования.4
В моей практике при первой волне автоматизации наблюдалась схожая картина. Аналитики начали массово писать собственные утилиты под свои участки работы. Инструментов стало много, но общая производительность подразделения не росла. Пока мы не собрали разрозненные скрипты в единый реестр, не устранили дубликаты и не написали общее руководство, технологии оставались заложниками личных привычек отдельных специалистов. Одни лишь инструменты процесса не создадут.
Прежде чем подключать агента к новым процессам или распространять сценарий на другие отделы, полезно выяснить, какие правила уже действуют как регламент, а какие все еще зависят от энтузиазма отдельных инженеров.
Оценить готовность организации как раз и помогают модели зрелости – в частности, фреймворк Microsoft Agentic AI Adoption Maturity Model5. Модель применяют к компании в целом или к выбранному подразделению по пяти оцениваемым направлениям:
- цели внедрения и удобство работы с агентами;
- процессы и измерение эффекта;
- управление, безопасность и сопровождение;
- технологии и данные;
- роли, навыки и мотивация сотрудников.
Каждое направление оценивают отдельно, по тому, как работа идет изо дня в день. Порой наличие готовой платформы создает иллюзию высокой готовности всей компании: доступ к моделям открыт, мощности закуплены. Но если разграничение прав и регламенты безопасности остаются на уровне стихийных экспериментов, технологический прогресс превращается в неуправляемый риск. Модель Microsoft полезна именно тем, что не позволяет спрятать незрелость процессов за мощной ИТ-инфраструктурой, а заставляет оценивать каждое направление самостоятельно.
На практике российские команды идут похожим путем, последовательно нащупывая границы действий агентов, перестраивая передачу работы и расширяя допуск. Прежде чем оценивать зрелость компании по шкале, разберем ключевые вопросы, с которыми неизбежно сталкивается безопасность: где провести границы полномочий агента, как перестроить проверку возросшего потока задач и кто отвечает за систему после пилота.
3. Полномочия и место человека
В описанном выше примере МТС наглядно видно, как полномочия агента «нарезаются» под конкретные шаги процесса. К базам данных ему дают доступ только на чтение, чтобы исключить случайные изменения. В тикет-системе агент создает записи и готовит проект ответа, но решение по заявке принимает сотрудник.2 Это важный момент с точки зрения безопасности – разрешения на чтение данных, запись комментариев, закрытие обращений и отправку ответов клиентам должны настраиваться раздельно.
Другой жизненный сценарий взаимодействия с корпоративной средой описывает Никита Костенчук (К2Тех): агент, который имеет доступ к почте и календарю, готовит черновик письма по надиктованному сотрудником тексту договоренностей после прошедшей встречи. К приходу сотрудника на рабочее место письмо уже готово.6
В этом примере агент сохраняет подготовленный текст в черновиках внутренней почтовой системы, не выполняя отправку. Службе безопасности важно различать границы таких операций: генерация текста моделью и создание черновика в почтовом ящике – это внутренние действия, тогда как отправка письма адресату создала бы иной уровень риска и внешних последствий. В описанном сценарии граница автоматизации проходит по этапу подготовки черновика, а решение об отправке принимает человек.
Степень участия человека зависит от критичности выполняемой операции. На практике применяются две основные схемы контроля: предварительное одобрение (когда специалист проверяет операцию до ее совершения, снижая риск ошибок на входе) и ретроспективная проверка (когда действие выполняется автоматически, а человек выборочно оценивает результаты постфактум). В некоторых сценариях сотрудник вовсе не участвует, а результат поступает дальше по процессу автоматически.
Поэтому для оценки рисков любого сценария службе безопасности недостаточно маркетинговых названий вроде «помощник», «копилот» или «автономный агент». Требуется четко зафиксировать два параметра: фактический перечень доступных агенту данных и операций (включая права на запись) и точку в процессе, где подключается контроль человеком. При этом локальное размещение модели (on-premise) не предполагает отправку запросов внешнему провайдеру при ее вызове, но само по себе не защищает от утечек через сетевые инструменты агента и не решает проблему разграничения прав внутри периметра, определяющую, к каким базам он имеет доступ на запись и какие внешние соединения может инициировать.
Чем больше результатов агент передает на приемку, тем выше нагрузка на проверяющих. Перед масштабированием или расширением рабочего сценария с ИИ-агентами придется выяснить, успевает ли следующий участник в конвейере использовать подготовленное. Иначе выигрыш на одном участке может превратиться в очередь на другом.
4. Ускорение требует перестройки процесса
С точки зрения безопасности одним из существенных факторов риска является затор на этапе приемки/проверки. Пытаясь не тормозить бизнес, команды могут начинать «срезать углы», то есть упрощать согласования или снижать глубину проверок.
Как команды справляются с возросшим потоком работы, видно на примере разработки. Михаил Чернов из Альфа-Банка рассказал, как его команда перестраивала процесс после внедрения ИИ-ассистентов разработчика. С ростом объема подготовленного кода новым узким местом стало тестирование: инженеры не успевали проверять поток изменений. Чтобы снизить нагрузку на тестирование, команда начала пилотировать агента, который готовит тесты и сценарии проверок, в то время как специалист по тестированию валидирует их и добавляет нестандартные граничные случаи. Так команда пытается расшить узкое место, подключая возможности ИИ к следующему звену производственного конвейера.7
Схожая динамика может возникать и в сфере безопасности приложений (AppSec). Разработчики с помощью ИИ создают код быстрее, но процедуры безопасной разработки – ручной разбор находок статического анализа, аудит архитектуры и согласование доступов – часто сохраняют прежнюю скорость. В результате поток непроверенных изменений скапливается перед релизом, и команда безопасности рискует оказаться в роли «бутылочного горлышка», сталкиваясь с давлением бизнеса «не тормозить релизы».
Здесь критична координация всего сквозного процесса, поэтому руководителям разработки, тестирования и команд безопасности важно заранее договориться, какой объем изменений команды способны надежно проверять, чтобы ускорение на одном этапе не приводило к снижению контроля на другом.
Эффект следует оценивать по всей цепочке: сколько времени проходит до использования результата, сколько требуется доработок, как меняется качество и сколько труда уходит на проверку. В итоге сквозная скорость процесса определяется не только тем, как быстро агент подготовил результат, но и тем, сколько времени уходит на его безопасную проверку и внедрение.
Один из способов справиться с возросшим потоком – дифференцированный контроль. Для операций с существенными последствиями требуется предварительное одобрение человеком, тогда как действия с допустимым риском самостоятельного выполнения можно проверять выборочно постфактум. Если же риск остается неприемлемым даже при участии человека, операцию агенту вовсе не поручают. Подобное распределение ролей часто применяется и в центрах мониторинга (SOC).
5. Как расширяют допуск и сохраняют контроль
Практика центров мониторинга (SOC) наглядно показывает, как можно выстроить поэтапный допуск ИИ к критичным процессам.
На SOC Forum 2025 Антон Кириченков из Т-Банка описал опыт передачи ИИ-агенту первичной обработки сигналов мониторинга. Внедрение шло в два этапа. Сначала агент работал в фоновом режиме параллельно с аналитиками, что позволяло сверять его выводы с решениями людей и дорабатывать логику обработки. Когда качество подтвердилось, агенту разрешили автоматически закрывать сигналы, которые он однозначно классифицировал как ложные (false positives). Если же у агента возникают сомнения (вердикт uncertain) или сигнал похож на реальную атаку, событие передается на разбор аналитику. При этом дежурная смена регулярно проверяет выборку автоматически закрытых кейсов, а комментарии специалистов возвращаются в базу знаний, помогая агенту избегать повторения разобранных ошибок.8
Аналогичную архитектуру совместной работы человека и ИИ-систем («Автоматический вирусный аналитик») мы проектировали при защите сотен миллионов пользователей: модели брали на себя поток, в котором уверенность классификатора была максимальной, а любые пограничные случаи, требовавшие взвешенного решения, автоматически направлялись на рабочее место эксперта. Разметка человека тут же обогащала обучающую выборку. Такой симбиоз разгружает людей от рутины, сохраняя человеческий интеллект для нестандартных инцидентов.
Другой подход на PHDays 2025 показал Игорь Гоц из Яндекс Cloud. В его примере агент не принимает решений о закрытии инцидента, а в роли ассистента аналитика самостоятельно опрашивает источники, собирает логи и телеметрию, формируя сводный отчет для расследования. В этом сценарии агент помогает человеку тем, что берет на себя рутину сбора сведений, их обогащение, а также анализ ситуации.9
При этом для службы безопасности важно различать последствия поручаемых операций. Собрать сведения, закрыть сигнал, изолировать скомпрометированный компьютер или заблокировать учетную запись – это действия с принципиально разным уровнем критичности. Право закрывать ложные срабатывания не дает агенту права вмешиваться в работу инфраструктуры. Расширение допуска требует отдельного решения и проверок для каждого типа действий.
Контроль должен действовать на каждом этапе работы агента. В сфере безопасности ИИ классический принцип наименьших привилегий дополняется принципом наименьшей самостоятельности (least agency)10: агенту не просто ограничивают доступ к данным, но и урезают степень автономности – предоставляют доступ строго к минимально необходимому набору инструментов и ограничивают самостоятельное выполнение операций с неприемлемым риском. Действия агента в рабочих системах должны проверяться на допустимость отдельным техническим механизмом до исполнения. А также фиксироваться в неизменяемом журнале аудита, чтобы при инциденте можно было по шагам восстановить происходившее. Человек подключается там, где требуется экспертная оценка ситуации и проверка корректности выводов.
Технический контроль полномочий (вправе ли агент выполнить вызов API) и содержательная валидация (корректен ли результат) – это два самостоятельных эшелона защиты, которые не заменяют друг друга. В рабочем процессе необходимы оба уровня.
6. Кто отвечает за работу после запуска
Следует помнить, что система с ИИ-агентами не работает по принципу «настроил и забыл». Со временем меняются бизнес-процессы и API, разработчики обновляют версии моделей, а изменения во входных данных могут приводить к незаметному снижению качества решений. Без постоянного контроля агент рискует превратиться в бесконтрольный сервис с избыточными системными правами. За регулярную проверку качества, актуализацию правил и разбор инцидентов должен отвечать конкретный уполномоченный владелец процесса.
Аналитики Strategy Partners в исследовании 2026 года рекомендуют закреплять за каждым сценарием уполномоченного владельца процесса.4 Логика здесь простая: отвечать за систему должен тот, у кого есть полномочия менять бизнес-процесс и бюджет на его сопровождение. Если возложить на руководителя только ответственность, но не выделить ресурсы на аудит и сопровождение, система со временем может накапливать ошибки и терять доверие пользователей.
Передовые компании формализуют эти требования заранее. Например, на GoCloud 2026 Александр Абрамов (ВкусВилл) описал внедрение корпоративной матрицы рисков, регламента безопасности и этики применения ИИ, а также ознакомление сотрудников с этими правилами под подпись.11 Так требования безопасности формализуются организационно, а у участников процесса появляется общая основа для оценки допустимых действий.
Насколько широко такие правила формализованы на практике, показывают отраслевые опросы 2026 года, охватывающие технологии ИИ в целом. По данным международного исследования ISACA (более 3400 специалистов по аудиту и безопасности), комплексная формальная политика использования ИИ действует в 38% организаций, а еще 30% сообщили о наличии ограниченной политики.12 В свою очередь, совместное исследование К2 Кибербезопасности и «Лаборатории Касперского» показало, что отдельный целевой бюджет на безопасность ИИ выделили 22% организаций из выборки крупных российских компаний.13 В остальных случаях затраты на защиту ИИ могут входить в общий бюджет информационной безопасности либо решаться в рамках отдельных ИТ-инициатив.
Существенную, часто недооцененную часть совокупной стоимости владения (TCO) рабочим сценарием с ИИ-агентами составляют трудозатраты экспертов на валидацию результатов, сопровождение, актуализацию промптов и аудит безопасности. Поэтому для каждого внедрения критично заранее понять, обеспечены ли работы по проверке, регулярному аудиту и сопровождению ресурсами в бюджетах подразделений и рабочем графике специалистов.
За каждым сценарием закрепляются уполномоченный владелец процесса и ответственная техническая команда. При расширении полномочий агента изменения рисков и доступов обязательно согласуются со службой безопасности.
7. Как выбрать следующий шаг
Сопоставление описанного российского опыта показывает, что агенты уже приносят пользу в конкретных рабочих сценариях. Однако выигрыш на отдельной задаче не всегда ускоряет весь процесс: дополнительная проверка результатов или очередь на следующем участке могут поглотить сэкономленное время. Расширение применения агентов поэтому требует согласовать работу смежных команд, границы полномочий, проверку результатов и ответственность за сопровождение.
Чтобы оценить, насколько комплексно организация решает эти задачи, служба безопасности может соотнести текущее состояние процессов со шкалой модели Microsoft (уровни от 100 до 500)5:
|
|
|
|
|
|
|
|
|
|
|
|
Эта шкала задает ориентир для первоначальной самооценки. Сопоставив процессы компании с уровнями каждого из пяти направлений, служба безопасности может наглядно увидеть перекосы – например, когда технологическая база уже готова к масштабированию (уровень 400), а регламенты контроля и обучение людей остаются на этапе ранних экспериментов (100–200).
Такая оценка помогает обнаружить конкретное «бутылочное горлышко» и выбрать ближайшую задачу. Если результаты скапливаются в очереди, следующим шагом может стать перестройка передачи работы, пересмотр полномочий агента и выбор подходящего режима контроля – предварительного одобрения (pre-approval) для операций с существенными последствиями или ретроспективного аудита (post-audit) для действий в пределах допустимого риска. При этом у каждого улучшения должны быть владелец и четкий, измеримый результат: например, сокращение времени ожидания при сохранении качества и управляемости риска.
Высокий уровень зрелости не требует полной автономии агента или обязательного сокращения участия людей. Обязательное одобрение человеком может оставаться частью зрелого процесса, если этого требуют последствия операций и допустимый риск.
В следующей статье разберем целевую модель контроля: как обнаружить агентов в корпоративном периметре (включая теневой ИИ), какие требования к защите инструментов, памяти и промптов должна предъявить служба безопасности, как выявлять скрытые риски при объединении доступов и расследовать инциденты по детальной истории действий агента.
Источники
1. Касперский Е. Двадцатилетие «Автодятла». Блог Касперского. 24.02.2025. https://www.kaspersky.ru/blog/auto-woodpecker-anniversary/39111/
2. Дробот В. Жизнь после RAG: как мы построили ИИ-агента для анализа тикетов технической поддержки. 01.07.2026. https://habr.com/ru/companies/ru_mts/articles/1051784/
3. BCG. Scaling AI Requires New Processes, Not Just New Tools. 2026. https://www.bcg.com/publications/2026/scaling-ai-requires-new-processes-not-just-new-tools
4. Strategy Partners. ИИ-агенты: успех внедрения решает не технология, а владелец процесса. 10.09.2026. https://strategy.ru/research/research/v-73-kompanii-net-vladelca-processa-dlia-vnedreniia-ii-agentov/
5. Microsoft. Agentic AI adoption maturity model: Repeatable patterns for successful adoption. https://learn.microsoft.com/en-us/agents/adoption-maturity-model/
6. Костенчук Н. Выступление на вебинаре «Как обойти грабли при внедрении ИИ: учимся на реальном опыте К2Тех». К2Тех. 08.09.2026. https://rutube.ru/video/ac7dfefec7174d26a2b4fbef3217b1ee/
7. Чернов М. AI в PDLC: как перестроить производственный процесс в большом финтехе. 01.09.2026. https://habr.com/ru/companies/alfa/articles/1075836/
8. Кириченков А. Как AI меняет процессы реагирования – от автоматизации к автономии. Доклад на SOC Forum 2025. https://forumsoc.ru/program-2025/
9. Гоц И. LLM и агенты: разгоняем SOC. PHDays 2025. https://rutube.ru/video/153a2a6f6a826857e7582cfa70ffdd72/
10. OWASP Gen AI Security Project – Agentic Security Initiative. OWASP Top 10 for Agentic Applications 2026. Декабрь 2025. https://genai.owasp.org/download/52117/
11. Абрамов А. Дискуссия «Реальная польза от GenAI». GoCloud 2026, Cloud.ru. 09.04.2026. https://cdn.cloud.ru/backend/video/gocloud/2026/open/open-discussion.mp4
12. ISACA. AI Use Accelerates, While Governance and ROI Lag, Says New ISACA Research. 05.05.2026. https://www.isaca.org/about-us/newsroom/press-releases/2026/ai-use-accelerates-while-governance-and-roi-lag-says-new-isaca-research
13. К2 Кибербезопасность. Безопасность ИИ входит в ТОП-5 приоритетов четверти российских корпораций. Результаты совместного исследования с «Лабораторией Касперского». https://cybersecurity.k2.tech/blog/news/bezopasnost-ii-nbsp-vkhodit-v-nbsp-top-5-prioritetov-chetverti-rossiyskikh-korporatsiy
Автор гарантирует, что обладает всеми необходимыми правами на предоставленные фото-, видео- и графические материалы, включая, но не ограничиваясь, авторским правом и правами на изображения третьих лиц, и несет полную ответственность за нарушение интеллектуальных прав правообладателей.
Редакция публикует указанные материалы на условиях информационного посредничества (ст. 1253.1 ГК РФ) и не осуществляет проверку правомочности их использования до момента получения соответствующего требования от правообладателя. Редакция обязуется принять меры по удалению материалов при получении мотивированного заявления.
Делитесь с коллегами!
Мы делаем сложное понятным!
ИД Советник, ж-л Директор по безопасности, ж-л Безопасность компании
Присоединяйтесь к нам:
Telegram| MAX | Наш сайт www.sec-company.ru
Для связи: info@sec-company.ru
+7(967) 119-00-42 - Подписка, +7(499) 404-21-71 - Сотрудничество
