Копилот продаж vs автономный агент: где провести границу для менеджера

Почему граница важнее выбора продукта

Рынок называет «копилотом» и «агентом» почти всё подряд. Продукт с названием Copilot может работать в режиме control loop — то есть фактически быть агентом. И наоборот. Поэтому первое правило playbook: оценивать архитектуру, а не маркетинговое название.

Копилот работает по схеме request-response: менеджер инициирует запрос, система возвращает рекомендацию или черновик, человек принимает решение и действует. Копилот не имеет доступа к исполнению — он советует.

Автономный агент работает в control loop: получает цель, планирует шаги, вызывает инструменты (CRM API, почта, календарь, 1С), проверяет результат и итерирует — без подтверждения каждого шага. Человек задаёт цель и смотрит на результат, а не на процесс.

Разница не в интеллекте модели, а в том, кто держит право исполнения. Это и есть граница, которую нужно провести явно — для каждого шага воронки отдельно.

Три gate-критерия перед выбором режима

Data Gate: данные как предусловие {#data-gate}

Агент на грязных данных — это не медленный агент. Это уверенный агент, который делает неверные вещи в промышленных масштабах. По оценке Digital Applied (2026), 80–90% усилий при запуске AI SDR уходит именно на «data plumbing» — очистку и связку данных, а не на настройку модели.

Чеклист Data Gate — 5 вопросов перед запуском агента:

• Полнота карточек: Более 80% сделок в CRM имеют заполненные обязательные поля (отрасль, размер компании, ЛПР, стадия, сумма)?
• Актуальность контактов: Контактные данные верифицированы за последние 6 месяцев — нет «мёртвых» email и телефонов из 2022 года?
• История взаимодействий: Звонки, письма и встречи залогированы в CRM, а не хранятся в головах менеджеров или в личных почтах?
• Синхронизация с 1С: Данные об остатках, ценах, статусах отгрузки и дебиторке синхронизируются с CRM в реальном времени или хотя бы с SLA не хуже 4 часов?
• 152-ФЗ и облачный LLM: Если агент обрабатывает персональные данные физлиц, есть ли правовое основание для передачи в облачный LLM? Если нет — деперсонализация или on-premise?

Если хотя бы два пункта получают «нет» — агент преждевременен. Начинайте с копилота и параллельно чините данные.

Process Gate: формализованность как предусловие {#process-gate}

Агент ускоряет то, что уже работает. Неформализованный процесс он ускоряет тоже — только в сторону хаоса.

4 признака готовности процесса к агенту:

• Задокументирован: Шаг воронки описан в регламенте или скрипте — менеджер может объяснить процесс новичку без «ну, это зависит от ситуации».
• Повторяем: Разные менеджеры выполняют шаг одинаково — дисперсия результата объясняется данными, а не личным стилем.
• Измерим: Есть метрика успеха шага (конверсия, время реакции, процент заполненности карточки), которую считают регулярно.
• Ошибка обратима: Если агент сделал неверное действие на этом шаге, его можно исправить без потери сделки или репутационного ущерба.

Risk Gate: цена ошибки × частота задачи {#risk-gate}

Примеры для B2B-продаж: обновление стадии сделки после звонка — высокая частота, низкая цена ошибки → агент. Финальное согласование условий с крупным клиентом — низкая частота, высокая цена ошибки → только копилот.

Матрица: шаги воронки × режим автономности

Важное наблюдение: в длинном B2B-цикле (6+ месяцев, кастомный продукт, несколько ЛПР) граница сдвигается влево — больше копилота, меньше агента. В коротком цикле (типовой SaaS, SMB, повторные покупки) — вправо.

Метрики перехода: как понять, что копилот вырос до агента

Переход — не событие, а процесс. Вот минимальный observability-набор для РОПа (не для ML-инженера):

Еженедельный мониторинг — 4 метрики:

• Human override rate — доля задач агента, скорректированных менеджером. Снижение ниже 15% на протяжении 4 недель = сигнал к расширению автономности. Выше 40% = агент не готов или данные плохие.
• Task completion rate — % задач, завершённых без эскалации на человека. Порог для go-live: >70% на пилоте из 50–100 реальных задач.
• Data freshness SLA — доля карточек CRM с актуальными данными (контакт, стадия, история). Порог: >80% стабильно 4 недели подряд.
• Pipeline quality delta — изменение конверсии лид→квал и квал→КП после внедрения. Это метрика результата, не активности. Объём отправленных писем не считается.

Дополнительно для IT-директора: error rate by type — классификация ошибок агента (галлюцинация данных / неверная маршрутизация / выход за границы guardrails). Нужна для точечной настройки, а не для общей оценки.

Топ-5 антипаттернов при выборе режима

1. Автоматизация хаоса. Агент запускается на процессе, который менеджеры выполняют по-разному. Результат: агент воспроизводит худшие практики в масштабе. Диагностика: попросите двух менеджеров описать шаг — если описания расходятся, Process Gate не пройден.

2. Запуск без audit trail. Агент действует, но логов нет. Когда что-то идёт не так (а это произойдёт), разбор инцидента невозможен. Минимум: каждое действие агента логируется с timestamp, входными данными и результатом.

3. Over-constraining. Агент с одобрением каждого шага — это медленный копилот, не агент. Если менеджер кликает «подтвердить» 20 раз в день не думая, friction есть, а safety benefit нет. Пересмотрите guardrails.

4. Under-constraining. Агент без границ «галлюцинирует успех» — имитирует выполнение задачи вместо реального выполнения. Исследование IdeaForge (2026) показывает: unconstrained агент чаще сообщает о завершении задачи, чем завершает её. Guardrails — не ограничение скорости, а условие корректности.

5. Измерение активности вместо качества. «Агент отправил 300 писем за неделю» — не метрика успеха. Метрика: сколько из них привели к квалифицированному следующему шагу. Дрейф ICP при автономном агенте без надзора происходит тихо — pipeline quality падает через 3–4 недели, когда уже сложно связать причину со следствием.

Доверие команды: что агент делает без менеджера, что — только с ним

Менеджеры саботируют агентов не из-за страха перед технологией — а из-за неопределённости границ. «Агент написал клиенту от моего имени — я не знал» разрушает доверие быстрее любого технического сбоя.

Практическое решение — явная карта автономности, которую РОП показывает команде до запуска:

• Агент делает сам, менеджер видит в логе: обновление стадии сделки, напоминания по задачам, обогащение карточки из открытых источников.
• Агент готовит, менеджер одобряет одним кликом: черновик письма, предложение следующего шага, заполнение полей квалификации.
• Агент не трогает без явного запроса менеджера: отправка КП, изменение суммы сделки, коммуникация с клиентом по спорным вопросам.

Эта карта — не технический документ. Это договор между командой и системой. Без него adoption провалится независимо от качества модели.

Российская специфика: 1С, amoCRM, Битрикс24 и 152-ФЗ

Западные материалы по теме ориентированы на Salesforce + ZoomInfo + LinkedIn Sales Navigator. В российском B2B стек другой, и это меняет практику.

1С как источник данных для агента. Агент, принимающий решения по сделке (цена, наличие, условия отгрузки), должен иметь актуальные данные из 1С. Если синхронизация 1С↔CRM настроена через ночной батч — агент работает на вчерашних данных. Для агента в upsell или подготовке КП это критично. Минимальный SLA синхронизации для агентного сценария: 4 часа, оптимально — real-time через API.

amoCRM и Битрикс24 как среда копилота. Обе системы имеют API и webhook-интеграции, достаточные для агентных сценариев низкой сложности (обновление карточек, создание задач, отправка шаблонных писем). Для сложных multi-step агентов потребуется промежуточный оркестратор.

152-ФЗ и облачный LLM. Если агент обрабатывает данные с ФИО, должностями и историей переговоров — это персональные данные. Передача в зарубежный облачный LLM без правового основания создаёт регуляторный риск. Практические варианты: деперсонализация данных на входе в LLM, использование российского облачного хостинга модели, on-premise развёртывание.

Выбор между копилотом и агентом — это не технический вопрос и не вопрос бюджета. Это вопрос готовности: данных, процесса и приемлемого риска на конкретном шаге воронки. Три gate-критерия дают РОПу и IT-директору общий язык для этого решения — без зависимости от маркетинговых названий продуктов и без автоматизации того, что ещё не работает руками.

По теме в блоге brezatech:

• Если вопрос стоит раньше — нужен ли вообще ИИ или достаточно BI — см. статью про когда BI достаточно и ИИ не нужен.
• Если решение принято и нужен технический gate запуска LLM в продакшн без ML-отдела — см. чеклист LLM в продакшне.