По данным исследования «Информзащита» 2026 года, 42% организаций столкнулись с инцидентами безопасности из-за ИИ-агентов — против 31% годом ранее. За каждым процентом — сорванный спринт, переназначенные задачи без объяснений, удалённые зависимости или утечка проектных данных во внешний API. Разница между 31% и 42% за один год объясняется просто: компании начали выводить агентов из пилотных зон в реальные рабочие контуры — без формальной эскалации и без аудита действий.
Для проектной команды это означает конкретное: агент может самостоятельно изменить приоритет задачи, сдвинуть дедлайн, переназначить исполнителя. Не по запросу менеджера — по собственной логике. И команда узнает об этом постфактум.
Эта статья даёт чек-лист оценки рисков до запуска агента, матрицу эскалации с уровнями автономии и практику аудита через логи задач. Плюс контр-интуитивный вывод о том, почему «больше автономии» почти никогда не означает «быстрее работа».
Почему агентный ИИ — это не «умный чат-бот», а новый класс операционного риска
Разница между чат-ассистентом и ИИ-агентом не в качестве ответов. Она в том, кто инициирует действие.
Чат-ассистент отвечает на вопрос. Он ничего не меняет в системе — генерирует текст, который человек читает и решает, что с ним делать. ИИ-агент работает иначе: получает цель и самостоятельно выбирает инструменты для её достижения. Создать задачу, обновить статус, вызвать API стороннего сервиса, переназначить исполнителя — всё это агент делает без явного запроса на каждое действие.
Для проектной команды это принципиально меняет профиль риска. Менеджер, который использует чат-ассистента, остаётся единственным субъектом изменений в системе. Менеджер, который запустил ИИ-агента, получил второго субъекта — со своими правами доступа, своей логикой приоритизации и своей скоростью принятия решений. Агент не устаёт, не отвлекается и не откладывает действие на утро. Он просто делает то, что считает правильным, прямо сейчас.
Класс угроз сместился: раньше говорили про «недобросовестного сотрудника» или «человеческий фактор», теперь — про «неконтролируемого агента». Субъект нежелательного действия в системе изменился. Те же данные «Информзащиты» показывают, что рост с 31% до 42% за год напрямую связан с выводом агентов за пределы пилотных зон — туда, где агент получает реальные данные и реальные права.
Здесь есть контр-интуитивный момент. Компании, которые быстрее всех масштабировали агентов из пилота в продуктив, получили больше инцидентов, чем те, кто задержался на стадии тестирования. Скорость внедрения без зрелости контроля не создаёт конкурентное преимущество. Она создаёт задолженность по безопасности, которая выплачивается инцидентами.
Пять конкретных рисков агентного ИИ для сроков, бюджета и команды
Искажение приоритизации задач. ИИ-агент оптимизирует по формальным параметрам: дедлайн, зависимости, загрузка исполнителя. Но у каждого проекта есть неформальный слой — договорённости со стейкхолдерами, стратегическая важность направления, политический контекст внутри компании. Агент этого не видит. Результат: задача, которую менеджер придерживал намеренно, улетает в работу раньше времени. Ключевой стейкхолдер узнаёт об изменении приоритетов постфактум — и это уже не технический инцидент, а управленческий. О том, как формализовать приоритизацию так, чтобы агент не ломал логику планирования, — в материале о приоритизации задач.
Скрытое влияние на бюджет. Каждый вызов внешней LLM — это расход токенов. Каждый API-запрос к сторонним сервисам — это деньги. Без жёстких лимитов агент может за сутки израсходовать месячный бюджет на ИИ-инфраструктуру. По данным академического исследования по модели зрелости ИИ-агентов в российских компаниях, трёхлетние затраты для крупных компаний составляют 200–300 млн рублей, для среднего бизнеса — 30–60 млн рублей (данные 2026 года, методология — совокупная стоимость владения с учётом инфраструктуры, лицензий и поддержки). Это растёт нелинейно, если агент работает без потолка расходов. Отдельная строка — стоимость расследования инцидентов, которые агент спровоцировал.
Сдвиг сроков из-за «молчаливых ошибок». ИИ-агент не сообщает о неуверенности. Он не пишет «я не уверен, правильно ли интерпретировал контекст» — он просто действует. Если модель неверно поняла формулировку задачи и создала дублирующий тикет или закрыла незавершённую задачу, команда обнаружит это на ближайшем стендапе или при ревью спринта. Между действием агента и обнаружением ошибки — часы или дни работы в неверном направлении. Этот класс сбоев подробно разобран в материале «Когда ИИ-агент ошибается молча»: шесть сценариев, где агент действует уверенно, но неверно, и никак не сигнализирует о проблеме.
Демотивация команды. Представьте: разработчик открывает таск-трекер в начале дня и видит, что его задача переназначена другому исполнителю, а оценка трудозатрат изменена с 5 до 2 часов — без комментария, без объяснения, без запроса. Агент «оптимизировал» распределение нагрузки по формальным метрикам. Для разработчика это сигнал: его экспертная оценка не имеет значения, решения принимаются без него. Автономия — один из фундаментальных факторов вовлечённости. ИИ-агент, который молча переписывает чужие задачи, системно разрушает этот фактор. Подробнее о том, почему это критично для проектных команд — в материале блога о системе мотивации.
Непреднамеренные изменения в бизнес-процессах. По данным агрегированного отраслевого анализа 2026 года, 41% инцидентов с ИИ-агентами приводят к непреднамеренным изменениям в бизнес-процессах, 43% — к операционным сбоям. В переводе на язык проектного управления: изменённые оценки трудозатрат, удалённые зависимости между задачами, переставленные вехи. Всё это обнаруживается не сразу — и к моменту обнаружения часть команды уже работает по устаревшей картине проекта.
Эти риски не устраняются запретом на использование агентов. Они управляются через оценку перед запуском, формализованную эскалацию, регулярный аудит и — что часто упускают — через обучение команды распознавать следы действий агента в таск-трекере.
Что оценить до запуска ИИ-агента в проектную команду
Перед тем как дать агенту доступ к проектным данным и возможность совершать действия, команда должна пройти формализованную оценку по восьми параметрам.
- Определён ли владелец сценария. Конкретный человек, который отвечает за результат работы агента — не «команда», не «все вместе», а один сотрудник с именем и фамилией. Без владельца некому разбирать инцидент и некому принимать решение об изменении полномочий агента.
- Составлен ли реестр действий. Список всего, что агент может делать: создавать задачи, обновлять статусы, менять приоритеты, переназначать исполнителей, вызывать внешние API, удалять объекты. Если этот список не написан явно — значит, никто не знает реальных полномочий агента.
- Применён ли принцип минимальных привилегий. Агент имеет доступ только к тем проектам, задачам и полям, которые нужны для его конкретного сценария. Не ко всей базе данных компании, потому что «так удобнее».
- Установлены ли лимиты. Максимальное количество действий за час или сутки, потолок расхода токенов, ограничение по стоимости одного решения. Без лимитов агент работает как сотрудник без бюджетного контроля. Типичная ошибка при масштабировании из пилота: команда предполагает, что агент будет делать примерно то же, что делал аналитик. На практике он делает это в десятки раз быстрее — и с теми же правами.
- Определён ли порог эскалации. При какой стоимости действия, при каком количестве затронутых задач или исполнителей агент обязан остановиться и запросить подтверждение человека. Этот порог должен быть числом, а не формулировкой «когда что-то важное».
- Есть ли kill switch. Возможность мгновенно остановить агента без потери данных. Не «написать разработчику», не «отозвать токен через три шага в настройках» — а одно действие, доступное владельцу сценария прямо сейчас.
- Настроено ли журналирование. Каждое действие агента фиксируется: временная метка, идентификатор агента, тип действия, объект, предыдущее и новое значение, основание (какое правило или промпт сработал). Без этого расследование инцидента превращается в догадки.
- Проведён ли пилот на непроизводственных данных. Первые две недели — задачи с низкой ценой ошибки или тестовая среда. Это способ получить данные о реальном поведении агента до того, как он получит доступ к чему-то критичному.
Согласно исследованию по инцидентам ИИ-агентов, при использовании общих учётных записей инциденты фиксировались у 63,5% компаний; при раздельной идентичности каждого агента — у 40,9%. Индивидуальная идентичность агента снижает вероятность инцидента почти на четверть — и это напрямую связано с пунктами 2 и 7 выше: без уникального ID агента реестр действий и журнал теряют смысл.
Схема эскалации: какие решения агент не должен принимать сам
Эскалация для ИИ-агента — это формализованная матрица, где тип действия и его стоимость определяют, кто принимает финальное решение.
Рабочая модель строится на трёх уровнях автономии.
Первый уровень — агент действует самостоятельно и логирует. Сюда относятся рутинные действия с низкой ценой ошибки и высокой обратимостью: обновление статуса задачи, отправка напоминания о дедлайне, добавление комментария. Если агент ошибся — исправление занимает минуту, затронутых людей ноль или один.
Второй уровень — агент предлагает действие и ждёт подтверждения. Переназначение задачи, изменение приоритета, добавление исполнителя в проект. Цена ошибки выше: затронуто несколько человек, изменение влияет на план спринта или распределение нагрузки. Предложение агента уходит в мессенджер владельцу сценария, а не применяется напрямую в системе.
Третий уровень — агент только информирует, решение принимает человек. Удаление задач, изменение бюджетных параметров, сдвиг вехи проекта, любые действия с необратимыми последствиями. Агент формирует предложение с обоснованием, но кнопку нажимает менеджер.
Критерии отнесения действия к уровню — стоимость ошибки в рублях или человеко-днях, обратимость действия и количество затронутых людей. Чем выше хотя бы один из параметров — тем выше уровень.
Практика «первый месяц — только подтверждения» работает именно потому, что даёт данные. Когда агент предлагает действие, а менеджер его утверждает или отклоняет, за месяц накапливается статистика: где рекомендации агента совпадают с решением человека, а где расходятся. Это эмпирическая база для настройки порогов. Без неё любые пороги — это угадывание.
Microsoft в документе Maturity Model: Security and Governance for AI Agents (2026) формулирует это так: «Ответственность за ИИ должна быть встроена в работу команд: нужно документировать решения и предположения, безопасно поднимать этические вопросы и регулярно практиковать реакцию через сценарии и ретроспективы». Каждая проектная команда, работающая с агентом, должна иметь свою практику разбора действий агента — регулярную, встроенную в рабочий цикл, а не делегированную ИБ-отделу раз в квартал.
О том, как выстроить уровни эскалации в таск-трекере — с конкретными правилами и сроками — подробнее в разборе по эскалации задач и инцидентов.
Аудит действий агента: что логировать и как разбирать инциденты
Без сквозного журналирования невозможно ни расследовать инцидент, ни доказать, что агент действовал в рамках полномочий. «Мы посмотрели — всё нормально» не работает, когда нужно понять, почему три задачи в спринте поменяли приоритет в пятницу вечером.
Минимальный набор данных в каждой записи лога: временная метка, идентификатор агента (не общая учётная запись — конкретный агент с уникальным ID), тип действия, объект действия (задача, проект, поле), предыдущее и новое значение, основание для действия — какое правило или промпт сработал. Без последнего пункта лог фиксирует факт, но не объясняет причину.
Общие учётные записи — главный враг аудита. Если агент работает под тем же логином, что и менеджер, или под общей сервисной учёткой отдела, в логах системы невозможно отличить действие агента от действия человека. Именно этим объясняется разница в статистике: при shared credentials инциденты фиксировались у 63,5% компаний, при раздельной идентичности — у 40,9%. Индивидуальный идентификатор агента — это не техническая деталь, а условие работоспособности любого аудита.
Регулярность ревью логов не должна определяться инцидентами. Два режима: еженедельный экспресс-аудит — пять минут на просмотр аномалий (всплески действий в нетипичное время, действия за пределами обычного сценария, повторяющиеся ошибки) и ежемесячный полный аудит — сверка всех действий агента с ожидаемым сценарием. Если агент делал то, что не предполагалось при запуске — это сигнал пересмотреть полномочия, а не повод «посмотреть в следующий раз».
Как это выглядит на практике? В Shtab AI, например, менеджер видит экран подтверждения перед каждым действием агента: «Переназначить задачу X с Иванова на Петрова. Причина: загрузка Иванова превышает 110% на текущей неделе». Менеджер нажимает «Подтвердить» или «Отклонить» — и оба варианта сохраняются в истории чата. Вернуться к любому решению и восстановить контекст можно в любой момент. Агент работает строго в рамках прав конкретного пользователя — выйти за пределы его доступа невозможно технически. Для команд с требованиями к изоляции данных доступен on-premise режим.
Статистика инцидентов: как выглядит неконтролируемый агент в цифрах
По данным глобального опроса 2026 года, охватившего 107 компаний, 54% уже пережили инцидент или предотвращённую угрозу, связанную с ИИ-агентами. Из них 18% — подтверждённый инцидент с последствиями, 36% — ситуация, которую удалось остановить до ущерба. Только 42% участников не зафиксировали подобных событий вообще.
Структура последствий: 61% — утечки данных. Финансовые потери зафиксированы примерно у трети пострадавших компаний.
Переведём эти цифры в язык проектного управления. Операционные сбои — это заблокированные задачи, которые нельзя взять в работу, потому что зависимости нарушены. Сорванные спринты, когда команда обнаруживает в понедельник, что приоритеты изменились в пятницу. Простой исполнителей, которые ждут решения по задаче, которая технически «закрыта» агентом, но фактически не выполнена. Непреднамеренные изменения в бизнес-процессах — это переприоритизация без согласования со стейкхолдерами, изменённые оценки трудозатрат, удалённые зависимости между задачами.
Всё это обнаруживается с задержкой.
Прогноз по масштабированию тоже неутешительный: по оценкам того же исследования по модели зрелости ИИ-агентов, более 40% проектов по внедрению агентного ИИ могут быть закрыты к концу 2027 года. Причины — недостаточная зрелость данных, слабая устойчивость процессов и завышенные ожидания от пилота. Успешный пилот и успешное масштабирование — это разные задачи с разными требованиями к governance.
О том, как ИИ-анализ помогает выявлять риски срывов до того, как они материализуются — в материале о прогнозировании срывов в Agile.
Контр-интуитивный вывод: больше автономии агента — не всегда больше эффективности
Интуиция подсказывает: чем меньше агент останавливается на подтверждениях, тем быстрее работа. Данные говорят иначе.
Компании, которые внедряли агентов через контролируемые пилоты — read-only на первом этапе, затем подтверждение каждого действия, затем ограниченная автономия для проверенных сценариев — реже попадают в статистику инцидентов. Каждый этап даёт данные о реальном поведении агента и позволяет откалибровать пороги до того, как агент получит полные полномочия.
Стоимость 30-секундного подтверждения несопоставима со стоимостью разбора инцидента, который затронул 10 задач и 5 исполнителей. По данным отраслевых постмортемов, расследование одного инцидента с ИИ-агентом при качественных логах и индивидуальной идентичности агента занимает 4–8 часов рабочего времени; без логов и при shared credentials — до двух-трёх рабочих дней. Подтверждение действия занимает секунды. Разрыв в стоимости — на порядок.
Для проектного менеджера «трение» эскалации — это инвестиция в предсказуемость. Команда, которая знает, что агент не изменит приоритеты без явного подтверждения, работает с меньшей тревожностью и тратит меньше времени на ручные проверки «а вдруг агент что-то поменял».
В Shtab AI этот выбор сделан явным: можно подтверждать каждое действие агента вручную или разрешить работать автономно. Для команд, которые только начинают работу с агентным ИИ, рекомендуется начинать с режима подтверждения и переходить к автономии поэтапно — по мере того как накапливается доверие к конкретному сценарию. Дополнительно доступны правила безопасности, которые ограничивают, какие данные агент может показывать сотрудникам в ответах.
Три шага, которые можно внедрить на этой неделе
1. Составить реестр действий агента. Открыть таблицу или карточку в таск-трекере и перечислить всё, что агент делает или может делать. Для каждого действия — указать уровень автономии: действует сам, предлагает и ждёт подтверждения, только информирует. Это занимает 30 минут. Результат — карта полномочий агента, которой сейчас нет ни у кого в команде, хотя агент уже работает.
2. Включить режим подтверждения для всех действий на первые две недели. Даже если это замедлит темп — это даст данные. За две недели станет видно, какие действия агент предлагает чаще всего, где его рекомендации совпадают с решениями менеджера, а где расходятся. Это эмпирическая база для настройки порогов эскалации — вместо догадок про то, «что агент, наверное, делает правильно».
3. Назначить владельца агента. Один конкретный человек, который раз в неделю просматривает логи действий и фиксирует аномалии. Не комитет, не «все по очереди», а один ответственный с конкретным слотом в расписании. Практика показывает: именно так инцидент обнаруживается за дни, а не за недели.
Что делать, если ИИ-агент уже работает, а реестра действий никогда не было?
Начните с инвентаризации постфактум: выгрузите логи за последние две недели и составьте список всего, что агент фактически делал. Это займёт час-два, но даст реальную картину полномочий — часто она расходится с тем, что команда предполагала при запуске. Дальше — стандартный чек-лист: назначить владельца, прописать реестр, включить режим подтверждения. На выходе — документ на одну страницу, который впервые фиксирует, что именно агент имеет право делать в вашем проекте. Без этого документа любые разговоры о контроле остаются разговорами.