Автосогласование или ручное: права AI-агента

Четверг, 16:40. Агент поддержки, запущенный три часа назад, показывает в журнале выполнения 41 действие: 22 обновления карточки, 11 меток, 6 созданных задач и 2 письма клиенту. Первые 39 никто не заметил — они были верными. Последние два сообщили клиенту, что «настройка завершена», хотя установку перенесли на следующий день. Вечером команда выключила агента и больше не включала. Дело было не в том, насколько хорошо агент рассуждает: всем 41 действию выдали одинаковые права.

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

Почему права настраивают раньше самого агента

Большинство команд идёт в обратном порядке: сначала настраивают агента, несколько дней наблюдают, а после первой ошибки урезают права. Такой порядок дорог, потому что цену обучения платит клиент. Проектирование прав — это на самом деле не про то, что агент может сделать, а про то, что произойдёт, когда он ошибётся. Точность агента может быть девяносто процентов или девяносто девять; куда попадёт остаток, решаете вы: в поле карточки или во входящие клиента.

В Rocketly это часть настройки, а не продвинутая опция. Агент выполняет внутри CRM 74 автономных действия, и настройка контроля согласования задаёт вопрос отдельно для каждого типа действия: работать самостоятельно или ждать вашего подтверждения. Состояния «агент включён» просто не существует — вы включаете список прав, отмеченный построчно. Оставить этот список без изменений — тоже решение, и обычно неверное.

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

По какому критерию действие переводят на автомат

Обсуждение обычно начинается с вопроса «доверяем ли мы агенту» и ни к чему не приводит, потому что доверие не измеряется. Измеряется само действие. Три вопроса делят почти любой список надвое.

Обратимо ли оно? Ошибочную метку снимают, лишнюю задачу закрывают, поле возвращают к прежнему значению. Отправленное сообщение вернуть нельзя. Если стоимость отката близка к нулю, действие — кандидат на автомат.

Выходит ли оно наружу? Результат видит только ваша команда или ещё клиент, поставщик, рекламная платформа? Любое внешнее действие в случае ошибки говорит от имени компании.

Заметно ли оно? Если действие выполнено неверно, это увидят в течение нескольких часов или обнаружат в квартальном отчёте? Тихие ошибки опаснее громких: они накапливаются.

Действия, прошедшие все три проверки, работают автоматически. Всё, что не проходит хотя бы одну, идёт через согласование. Простое правило вместо интуиции — и спор в команде заканчивается: выиграть его фразой «я доверяю» уже нельзя.

Какие действия можно автоматизировать с первого дня

Первым в списке идёт обогащение внутренних записей. Агент заполняет пустое поле отрасли в карточке лида, вписывает размер компании, отмечает источник — обратимо, наружу не выходит, видно прямо в карточке. Вся логика автозаполнения неполных карточек и так живёт в этой безопасной зоне; агент не создаёт здесь нового риска, он просто работает быстрее.

Второй безопасный блок — резюме и заметки. Итог разговора попадает в карточку, результат звонка получает код, следующий шаг записан. Всё внутреннее. Автоматическое занесение заметок по встречам и звонкам — естественная первая задача для агента: даже если он ошибётся, читающий человек это исправит.

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

Какие действия требуют согласования, потому что их видит клиент

Граница проходит чётко: всё, что отправляет сообщение, касается денег или объявляет статус. Письмо или сообщение в мессенджере клиенту, создание коммерческого предложения, размер скидки, закрытие сделки как выигранной, увеличение рекламного бюджета. Общее у них одно: они опираются на то, чего агент знать не может — на контекст в комнате. О переносе установки знает человек в команде, а не агент.

Есть блок, требующий особой осторожности: сообщения клиенту, которые выглядят безобидно. Автоматическая благодарность, приглашение в опрос, просьба об отзыве. Сценарии сбора отзывов после покупки именно поэтому строят с условиями: сообщение «оцените ваш опыт», отправленное клиенту с задержанной доставкой, хуже, чем отсутствие сообщения. Агент сам такое условие не добавит — его добавляете вы.

Скидки и цены — отдельная категория. Подготовить черновик предложения агент может, определять размер скидки — нет. Если у вас записано, кто согласует предложение со скидкой для сотрудников, то же правило действует и для агента. Сделать агента исключением — значит фактически отменить правило.

Таблица решений: какой режим для какого действия

Таблица ниже применяет три критерия к группам действий. Она рассчитана на то, чтобы держать её на экране во время настройки; строки дополняются под список действий в вашей CRM.

Группа действий	Обратимо?	Выходит наружу?	Рекомендуемый режим
Поля карточки, метки, скоринг лида	Да	Нет	Автоматически
Заметки, резюме, результаты звонков	Да	Нет	Автоматически
Внутренние задачи и встречи	Да	Нет	Автоматически, владелец обязателен
Сообщения и письма клиентам	Нет	Да	Ручное согласование
Создание предложения и размер скидки	Частично	Да	Согласование по порогу
Рекламный бюджет и статус кампании	Частично	Да	Ручное согласование

Слово «порог» здесь важно. Права не обязаны быть двоичными: до определённой величины автоматически, выше — с согласованием. Для большинства команд это самый реалистичный баланс, и на стороне сотрудников вы его уже применяете.

На ком должен стоять шаг согласования

Привяжите согласование к одному человеку — и в его отпуск агент фактически остановится. Откройте всем — и шаг потеряет смысл. Рабочая схема: согласование привязано к роли. Подтверждает тот, кто сейчас доступен в роли руководителя продаж; если доступных нет, запрос не пропадает, а ждёт в очереди. Урок автоматизации согласований действует и здесь: задержка чаще возникает не из-за сложности решения, а из-за неясности, кто его принимает.

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

Третье — как запрос попадает на экран. Запрос, пришедший в командный чат вместе с контекстом, закрывают за минуты; запрос в отдельной консоли согласования ждёт часами. Поскольку в Rocketly агент работает и в командном чате, запрос можно привести туда, куда люди и так смотрят.

Что делать с согласованиями вне рабочих часов

Самые ценные для агента часы — те, когда за экраном никого нет. Ответить на ночное обращение, удержать лид до утра, разобрать заявку в выходной. И именно в эти часы согласовывать некому. Если проект прав игнорирует этот разрыв, агент на практике работает только с девяти до шести.

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

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

Защитные границы и согласование — это одно и то же?

Нет, и путать их — распространённая ошибка. Согласование говорит: «это можно, но сначала спроси». Защитная граница говорит: «этого не делай ни при каких условиях». Первое — задержка, второе — запрет.

В Rocketly guardrails задают этот второй слой декларативно, и границы принудительно соблюдаются во время выполнения: агент не спрашивает разрешения, путь просто закрыт. Сюда обычно пишут корпоративные обязательства: не толковать юридические формулировки, не обещать сроки гарантии, не объявлять решение о возврате. За согласованием остаются бизнес-решения: скидка, отправка, закрытие.

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

Как проверить, что агент сделал

Без проверки проект прав остаётся списком предположений. Понять, правильно ли выставлены настройки, можно только по выполнениям. Для этого есть журнал выполнения: запуски всех агентов в одном потоке, где по каждому действию зафиксированы параметры, результат, длительность и согласовавший. Поле согласовавшего появилось там не случайно — прошло ли действие автоматически или его кто-то подтвердил, спрашивают первым.

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

Чтобы превратить эти три сигнала в еженедельную привычку, отдельный экран не нужен: запланированные автоматические отчёты принесут сводку по очереди согласований прямо вам. Дашборд сам по себе никто не откроет, а пришедшую сводку прочитают.

Когда пересматривать решение о правах

Правильный подход — поэтапное расширение. Первая неделя: автоматически работают только действия с внутренними записями. Вторая и третья: типы, которые подтверждают каждый раз, переводятся на автомат по одному, а не пакетом. Тогда при сбое сразу понятно, какое изменение его вызвало.

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

Заранее определите и данные, по которым принимаете решение о расширении. Числа закрытых обращений, доля передач человеку и доля отклонённых согласований для этого достаточны. Кому и в какой разбивке показывать метрики — отдельная задача; главный вопрос дизайна дашборда здесь тот же: какое решение примет человек, смотрящий на этот экран?

Как ограничить расходы по мере роста автономии

Чем больше автономии, тем больше запусков, а запуски прямо отражаются на потреблении. Расширять без потолка — значит остановить агента в середине месяца. Лимит кредитов на агента позволяет задать месячный потолок каждому агенту; запуск, который его превысит, останавливается до начала. Это не тормоз, а бюджетное решение: команда сама распределяет лимиты между агентами.

Вторая статья расходов невидима — лишние запуски. Если агент реагирует не на каждое сообщение, а на заданные триггеры, падает и потребление, и шум. Тот же эффект даёт пошаговый плейбук: порядок действий описан явно, а условные шаги и режим репетиции без побочных эффектов не дают агенту блуждать.

И наконец, ещё раз подумайте, где в процесс входит человеческое решение. Автономия агента и шаг ожидания согласования в процессе — два ответа на одну потребность: первый ставит ворота перед решением модели, второй ставит на паузу правило-ориентированный сценарий. Разделив, какая задача к чему относится, вы улучшите оба механизма.

Когда список прав выстроен верно, агент перестаёт быть источником риска и становится мощностью; чтобы составить собственный список действий, откройте бесплатный аккаунт Rocketly и запустите первого агента только с правами на внутренние записи.

Частые вопросы

Что я теряю, если поставлю на согласование все действия?

Скорость и покрытие вне рабочих часов. Основная ценность агента в том, что он двигает работу, когда никто не смотрит. Согласование всего сводит его к генератору черновиков — тоже способ применения, но заметно уже. Перевод обратимых внутренних действий на автомат оставляет шаг подтверждения свободным для важного.

Сколько агент держит действие в ожидании подтверждения?

Это определяете вы, и определить нужно. Бессрочно ждущий запрос умирает в очереди. Рабочая схема: по истечении заданного срока запрос сгорает, агент передаёт разговор человеку, и это отмечается в журнале. Отсутствие решения — тоже решение, и система не должна проглатывать его молча.

Как откатить действие, в котором агент ошибся?

Обратимость — свойство самого действия, а не системы. Обновление поля и метку вернуть можно, отправленное сообщение — нет. Именно поэтому разделение делается заранее. По журналу выполнения вы увидите параметры и результат действия, поймёте, что изменилось, и вручную исправите то, что исправимо.

Если агентов несколько, права задаются для каждого отдельно?

Да, и так и должно быть. Риск у агента продаж и агента поддержки разный. Отдельные права на действия, отдельный доступ к источникам знаний и отдельный лимит кредитов для каждого агента безопаснее и измеримее, чем один агент, который делает всё. Попадание запроса к нужному агенту решается отдельно, на стороне маршрутизации.