Границу автономности агента определяет стоимость ошибки для каждого действия менеджера. Оцените действие по трём осям — обратимость, радиус поражения, стоимость задержки — и назначьте уровень L0–L4. Чеклист из семи вопросов перед запуском и метрики после помогут не перегнуть с автономностью и не задушить процесс проверками. Выбор между агентом и копилотом для конкретного этапа воронки мы разобрали в статье «Копилот продаж vs автономный агент: где провести границу для менеджера». Здесь идём дальше: инструмент выбран, теперь нужно решить, какие действия менеджера можно отдать агенту без постоянного контроля, а какие требуют человека в петле. Вопрос не «агент или копилот?», а «какой уровень автономности назначить каждому действию и как это зафиксировать в архитектуре?» Главная ось — стоимость ошибки. Агент, который ошибается в обновлении CRM, и агент, который ошибается при отправке договора клиенту, — это два разных уровня риска. Первое действие обратимо за минуту и не затронет внешнюю среду. Второе может привести к юридическим последствиям и потере клиента. Поэтому граница автономности проектируется не сверху вниз («дадим агенту всё, а там посмотрим»), а снизу вверх — через разбор конкретных действий. Стоимость ошибки как главная ось Для каждого действия менеджера оцените три параметра: Обратимость (Reversibility) — можно ли откатить действие за 5 минут без потерь? Например, обновление статуса в CRM обратимо: вы можете поправить значение. Отправленное клиенту коммерческое предложение с ошибкой в цене необратимо: оно ушло, и следующий шаг — извинения. Радиус поражения (Blast Radius) — сколько клиентов, сделок или рублей затронет ошибка? Если агент неправильно обновляет внутренние заметки, пострадает только один менеджер. Если агент массово рассылает некорректные КП, ущерб измеряется репутацией и потерянными сделками. Стоимость задержки (Cost of Delay) — во сколько обходится ожидание человека в петле? Если подготовка КП занимает у менеджера 30 минут, а агент мог бы сделать черновик за 2 минуты, задержка из-за ручной работы — это потерянное время, которое менеджер мог бы потратить на переговоры. Но если задержка на апрув критичного действия (например, согласование скидки) предотвращает финансовую ошибку, она оправдана. Сочетание этих трёх осей даёт ответ, какой уровень автономности назначить: от L0 (агент только читает и логирует) до L4 (агент делает всё в заданных рамках). Оценка не требует сложных формул: достаточно экспертного суждения менеджера, который знает свой процесс. Таблица действий менеджера: три оси и уровень автономности Ниже — типовые действия B2B-менеджера в CRM. Для каждого действия указана оценка по трём осям и рекомендуемый уровень автономности. Это не универсальный шаблон: в вашей компании цифры могут отличаться, но логика одинакова. Действие менеджера | Обратимость | Радиус поражения | Стоимость задержки | Рекомендуемый уровень Обновить CRM (статус, поля) | Высокая: исправить за минуту | Низкий: только внутренние данные | Средняя: ручная работа отнимает время | L3 — агент обновляет по данным из переписки, менеджер видит изменения в ленте Подготовить КП | Средняя: документ можно редактировать до отправки | Высокий: ошибка в КП уходит клиенту | Средняя: задержка снижает скорость сделки | L2 — агент генерирует черновик, менеджер проверяет и утверждает до отправки Согласовать скидку | Низкая: после озвучивания клиенту откатить сложно | Высокий: влияет на маржу сделки | Низкая: клиент подождёт несколько минут | L3 — агент рассчитывает скидку в пределах утверждённых лимитов, менеджер видит уведомление; выше лимита — апрув Отправить договор | Низкая: отправленный договор не отозвать | Высокий: юридические и финансовые последствия | Средняя: задержка замедляет сделку | L2 — агент заполняет шаблон договора, менеджер проверяет реквизиты и отправляет Эскалировать сделку | Средняя: уведомление можно отменить | Средний: затронут менеджер и руководитель | Высокая: пропущенная эскалация может потерять сделку | L3 — агент эскалирует при срабатывании триггеров (клиент молчит 3 дня, сумма крупная), менеджер получает уведомление Логика проста: чем ниже обратимость и выше радиус поражения, тем ниже уровень автономности. Действия с высокой стоимостью задержки, но низким риском (эскалация) можно автоматизировать смелее — агент не наносит ущерба, только ускоряет процесс. Уровни автономности L0–L4 на языке менеджера Шкала из инженерных статей переведена в действия: L0 — агент только читает и логирует. Агент анализирует данные, но не предлагает и не делает. Это режим наблюдателя: агент собирает информацию о сделке, готовит сводку для менеджера. Человек принимает все решения. Подходит для разовых экспериментов, когда вы ещё не доверяете агенту. L1 — агент предлагает, человек кликает. Агент формирует рекомендации: «предложите скидку 7%», «отправьте договор клиенту Н». Менеджер видит предложение и подтверждает. Так работает копилот: он ускоряет решение, но не принимает его. Рекомендуемый стартовый уровень для большинства действий. L2 — агент делает, человек видит потом. Агент выполняет действие (например, обновляет поле в CRM, отправляет уведомление) и логирует его. Менеджер может просмотреть изменения постфактум и откатить, если нужно. Подходит для обратимых действий с низким радиусом поражения. L3 — агент делает, человек апрувит необратимое. Агент автономно выполняет рутинные действия, но перед необратимыми (отправка договора, массовая рассылка, финансовые операции) требует подтверждения менеджера. Это основной режим для B2B-процессов: скорость есть, риск контролируется. L4 — агент делает всё в заданных рамках. Полная автономия внутри чётких границ: агент сам обновляет CRM, готовит КП, согласует скидки до лимита, отправляет договоры после проверки автоматических правил. Человек вмешивается только при исключениях. Такой уровень безопасен только для узких рутинных сценариев с накопленной статистикой качества. Не обязательно все действия должны быть на одном уровне. У одного и того же агента обновление CRM может быть на L3, а отправка договора — на L2. Граница — это не глобальная настройка, а карта действий. Чеклист: 7 вопросов до запуска агента Перед тем как дать агенту доступ к CRM или другим системам, ответьте на семь вопросов: 1. Данные размечены и актуальны? Без качественных данных агент будет галлюцинировать и принимать решения на мусоре. Проверьте, есть ли в CRM структурированные данные: статусы, этапы, поля сделок. 2. Действие обратимо за 5 минут без потерь? Если да — можно повышать уровень автономности. Если нет — оставить апрув. 3. Радиус поражения ограничен? Сколько клиентов, сделок или рублей затронет ошибка? Если радиус большой — снижайте уровень. 4. Есть стоп-кран? Должна быть кнопка экстренной остановки агента, доступная менеджеру без обращения в IT. 5. 152-ФЗ: данные на серверах в РФ? Если агент обрабатывает ПДн и отправляет их в LLM, убедитесь, что серверы находятся в России или есть согласие субъекта. 6. Настроен аудит-лог? Все действия агента должны фиксироваться: кто, что, когда сделал. Без лога невозможно разбирать инциденты. 7. Назначен ответственный за инциденты с агентом? Определите, кому менеджер сообщит об ошибке агента, и какой регламент реагирования. Если хотя бы на один вопрос нет однозначного «да» — возьмите стартовый уровень L1 или L2 для пилотных действий и начните с них. Антипаттерны, которые превращают агента в риск Семь типовых ошибок при проектировании границы автономности: Uniform Autonomy — одинаковый уровень для всех действий. Разработчики дают агенту полный доступ к CRM, не разбирая, что он будет делать. Результат: 42% организаций уже столкнулись с инцидентами из-за ИИ-агентов (CNews, 2026). Разные действия — разные уровни. Autonomy by Hope — «авось не ошибётся». Запускают агента в продакшн без измерения качества решений на исторических данных. Если агент на тестовой выборке ошибается в 10% случаев, нет причин ждать, что в проде будет лучше. Review Theater — апрув ради апрува. Требуют подтверждения на каждое действие, а интерфейс апрува настолько неудобен, что менеджер кликает «ОК» не глядя. Создаётся иллюзия контроля: агент делает что хочет, а люди устали проверять. Метрика approval fatigue: если время на один апрув >2 минут, пересматривайте gate-точки. Static Rules — выставили и забыли. Граница не пересматривается после запуска. Но агент накапливает данные, его качество может улучшаться или ухудшаться. Нужен ежеквартальный пересмотр или после каждого инцидента с радиусом поражения выше порога. Data-Last Approach — запуск агента до готовности данных. Агент без размеченных данных галлюцинирует и принимает решения на мусоре. Это не проблема модели, а проблема данных. Сначала приведите в порядок CRM и регламенты, затем давайте агенту полномочия. Игнорирование 152-ФЗ. Автономная передача ПДн в облачную LLM на зарубежных серверах создаёт регуляторный риск с оборотными штрафами до 3% выручки. Даже если агент работает хорошо, один регуляторный инцидент может перекрыть всю выгоду. Монолитный агент вместо специализированных. Попытка сделать одного агента для всех задач менеджера приводит к покрытию 25–40% сценариев и частым зависаниям. Эффективнее несколько узкоспециализированных агентов с чёткими границами: один обновляет CRM, другой готовит КП, третий эскалирует. 152-ФЗ и российский стек: где граница сдвигается Российская регуляторика влияет на автономность там, где агент обрабатывает персональные данные. Ключевое ограничение 152-ФЗ: хранение ПДн на серверах в РФ, а трансграничная передача в страны без адекватной защиты требует отдельного согласия субъекта. Что это значит для уровня автономности: • Если агент читает данные из CRM (ФИО, контакты) и отправляет их в облачную LLM, размещённую за рубежом (например, OpenAI), это трансграничная передача ПДн. Такое действие должно быть под контролем человека: либо данные предварительно обезличиваются, либо менеджер явно подтверждает отправку (уровень L1/L2). • Если LLM развёрнута в российском контуре (YandexGPT, GigaChat, локальные модели), риск снижается. Но даже тогда необратимые действия с ПДн (массовая рассылка, передача третьим лицам) должны требовать апрува (L3). • Оборотные штрафы с 30.05.2025 — до 3% годовой выручки. Для компании с выручкой 1 млрд рублей это 30 млн рублей. Стоимость задержки из-за одного апрува выглядит иначе. Практическая рекомендация: держите LLM в российском контуре, настройте аудит-лог всех обращений агента к данным, и для любых действий, где ПДн покидает контур компании, включайте человека в петлю. Метрики после запуска: как понять, что граница правильная Граница автономности не статична. После запуска отслеживайте пять метрик: % действий агента, отклонённых или скорректированных человеком. Если этот показатель стабильно выше 30%, агент берёт слишком много: граница выставлена неверно, менеджеры не доверяют. Снижайте уровень для этих действий. Среднее время на апрув одного gate-действия. Если менеджер тратит больше 2 минут на один апрув, растёт риск approval fatigue: люди начинают кликать не глядя. Оптимизируйте UI или уменьшайте количество gate-точек. Стоимость ошибок агента за период против стоимости задержек из-за HITL. Считайте в деньгах: финансовые потери от ошибок + время на исправление, с одной стороны, и упущенная скорость из-за ручных апрувов — с другой. Если стоимость ошибок превышает выгоду от скорости, граница слишком высокая. Если наоборот — можно повышать. Blast radius реализованных инцидентов. Для каждого сбоя агента фиксируйте, сколько клиентов/сделок/рублей затронуто. Если инциденты редкие, но крупные (например, массовая ошибочная рассылка), снижайте автономность для соответствующих действий. % процессов менеджера, покрытых агентом автономно. Цель — не 100% автоматизации, а снижение рутины до 20%. Если менеджер всё ещё тратит больше половины времени на рутинные действия, есть куда сдвигать границу. Эти метрики пересматривайте ежеквартально или после каждого инцидента с радиусом поражения выше порога. Кейс: слишком высокая автономность в оптовой компании Оптовая компания (B2B, продажа строительных материалов) внедрила агента для работы с входящими заявками. Разработчики дали агенту доступ к CRM, email и генерации документов. Изначально уровень был L3 для всех действий: агент сам обновлял данные, готовил КП, согласовывал скидки до 15% и отправлял договоры после автоматической проверки. Через месяц обнаружили потери маржи: агент в 12% сделок применял скидку выше нормативной (например, 12% вместо 7%), потому что неправильно распознал категорию клиента из переписки. Несколько договоров ушли с ошибкой в реквизитах. Итог: 14 клиентов получили некорректные КП, 5 договоров пришлось переделывать, маржа по 9 сделкам снизилась в среднем на 4%. Разбор показал: агент не был обучен на размеченных данных по категориям клиентов, а действие «согласовать скидку» имело низкую обратимость и высокий радиус поражения, но было назначено на L3 без апрува. Договоры тоже отправлялись без ручной проверки. Пересмотр границы: • Согласование скидки: понизили до L2 — агент готовит расчёт и предлагает, менеджер подтверждает. • Отправка договора: понизили до L2 — агент заполняет шаблон, менеджер проверяет реквизиты. • Обновление CRM: оставили L3, но добавили аудит-лог и еженедельный отчёт по отклонениям. • Внедрили стоп-кран для экстренной остановки агента. Через два месяца после пересмотра процент отклонённых действий снизился с 45% до 15%, время на подготовку КП сократилось с 6 часов до 40 минут на сделку. Граница стала адекватной. FAQ: типовые вопросы ЛПР Мы хотим дать агенту доступ к CRM — с чего начать? Начните с инвентаризации действий менеджера: какие действия он выполняет в CRM ежедневно. Для каждого действия оцените обратимость, радиус поражения и стоимость задержки. Выберите 2–3 рутинных обратимых действия (обновление статусов, заполнение полей) и запустите их на уровне L3 (агент делает, человек видит потом). Обязательно настройте аудит-лог и стоп-кран. Подробный выбор инструмента для этапа воронки — в статье «Копилот продаж vs автономный агент». Какие действия агента автоматически требуют участия человека из-за 152-ФЗ? Любая передача персональных данных в облачную LLM, особенно на зарубежных серверах, требует явного согласия субъекта и локализации данных в РФ. Если агент обрабатывает ПДн (ФИО клиента, контакты) и отправляет их в LLM для генерации КП, человек должен контролировать этот процесс: либо данные предварительно обезличиваются, либо LLM развёрнута в российском контуре. Необратимые действия с ПДн (массовая рассылка, передача третьим лицам) всегда под HITL. Как часто пересматривать уровни автономности? Раз в квартал или после каждого инцидента с радиусом поражения выше порога. Анализируйте метрики: процент отклонённых действий, время апрува, стоимость ошибок. Если метрики стабильны в течение квартала, можно повышать автономность на один уровень для рутинных действий. Если инцидент произошёл — немедленно снижайте уровень и разбирайте причину. Что делать, если агент ошибается чаще, чем ожидалось? Сначала проверьте качество данных: агент, обученный на неразмеченных или устаревших данных, будет ошибаться. Затем проанализируйте типы ошибок: если они концентрируются на конкретных действиях, временно верните их на уровень L1 (агент предлагает, человек кликает). Если ошибки хаотичные — снизьте глобальный уровень до L1/L2 и начните заново с накопления качественных прецедентов. Как избежать approval fatigue (усталости от апрувов)? Не требуйте апрув на каждое действие. Сгруппируйте необратимые действия: один апрув перед отправкой договора вместо трёх на каждое поле. Используйте уровень L2 (делает — видит потом) для обратимых действий с низким радиусом поражения. Оптимизируйте интерфейс апрува: если время на один апрув превышает 2 минуты, люди начнут кликать не глядя — тогда апрув превращается в ритуал без контроля. Эволюция границы: от копилота к агенту Граница автономности не фиксируется навсегда. Правильный путь — progressive autonomy: начинать с L1/L2, накапливать данные о качестве решений агента, измерять процент отклонённых действий и стоимость ошибок. Когда метрики показывают стабильность, можно повышать уровень для отдельных действий. Если агент на L2 правильно обновляет CRM в 98% случаев, переведите это действие на L3. Если агент на L3 согласует скидки в рамках лимитов без ошибок три месяца подряд, можно расширить лимиты. Пересмотр границы — это не разовая настройка, а операционный процесс. Включите его в квартальный цикл: собрать метрики, разобрать инциденты, скорректировать уровни. Так вы получите не статичный «агент vs копилот», а управляемую систему, где автономность растёт по мере доверия, подкреплённого данными. Ключевые факты • 42% организаций уже столкнулись с инцидентами из-за ИИ-агентов (CNews, май 2026). • Автономный агент эффективен в сделках до $25k и широкой аудитории; в сложных B2B с несколькими ЛПР живые специалисты с ИИ приносят в 2,6 раза больше выручки (Хабр/МТС, 2026). • Оборотные штрафы за утечку ПДн с 30.05.2025 достигают 3% годовой выручки — это фактор, который сдвигает границу автономности при передаче данных в LLM. • Если более 30% действий агента отклоняется или корректируется человеком, граница автономности выставлена неверно.