Когда AI-агент должен передавать диалог человеку

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

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

Обязательные причины передачи#

Клиент просит человека#

Прямая просьба «позовите оператора» не должна превращаться в ещё один круг убеждения. Агент может один раз уточнить тему, если это ускорит маршрутизацию, но не должен блокировать доступ к сотруднику.

Нет подтверждённого ответа#

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

Высокая цена ошибки#

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

Эмоциональная или конфликтная ситуация#

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

Повторная неудача#

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

Недоступное действие#

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

Какие сигналы использовать#

Правила можно разделить на три уровня.

Жёсткие правила#

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

Смысловая классификация#

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

Самооценка недостатка данных#

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

Что передать оператору вместе с диалогом#

Хорошая эскалация экономит время обеих сторон. Сотруднику нужны:

• краткая причина обращения;
• что хочет получить клиент;
• уже собранные данные;
• какие ответы и действия были предложены;
• почему сработала передача;
• ссылки или идентификаторы, необходимые для продолжения.

Не заставляйте клиента повторять весь рассказ. При этом резюме агента не заменяет исходную переписку: оператор должен иметь возможность проверить контекст.

Как объяснить передачу клиенту#

Сообщение должно быть конкретным и честным:

• что именно требует участия сотрудника;
• какие данные уже сохранены;
• что произойдёт дальше;
• когда ждать ответ, если срок действительно известен.

Не пишите «я уже всё решил», если задача только поставлена в очередь. Не называйте вымышленное время ожидания.

Как организовать очередь#

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

Для омниканальной поддержки важно сохранить происхождение сообщения и канал ответа. Обзор доступных точек входа есть на странице каналов Chatix. Агент и оператор должны продолжать один контекст, а не создавать параллельные несвязанные разговоры.

Метрики качества эскалации#

Отслеживайте:

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

Высокая доля передач не всегда плоха. На новом сценарии она может означать осторожную настройку. Опаснее низкая доля при большом числе фактических ошибок.

Что говорят исследования#

В исследовании NBER на данных клиентской поддержки AI-помощник предлагал ответы сотрудникам, которые могли принять или отклонить подсказку. Авторы наблюдали рост производительности и снижение числа просьб позвать руководителя, но эффект различался по опыту сотрудников. Это пример модели сотрудничества, а не доказательство, что человека можно убрать из процесса. Источник: Generative AI at Work.

Профиль рисков генеративного AI от NIST рекомендует управлять рисками на всём жизненном цикле: до запуска тестировать систему, измерять поведение и иметь процессы реагирования на инциденты. Для поддержки эскалация — один из таких процессов управления.

Как проверить правила до запуска#

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

Проверить поведение можно в тестовом режиме, а затем подключить один из каналов AI-агента. Если агент плохо находит известные факты, сначала устраните проблему по чек-листу поиска, а не отключайте эскалацию.

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