Сценарии ИИ для клиентской поддержки: что автоматизировать, а что передавать человеку

Автор: Виталий Дильдин · Опубликовано 15 июля 2026 года

Короткий ответ

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

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

Для каждого сценария зафиксируйте вход, источник, допустимое действие, проверку и маршрут к человеку. Отсутствие основания должно вести к отказу или эскалации. Хорошая эскалация переносит контекст и не заставляет клиента повторять историю.

Отличие от курса и внедрения

Курс ChatGPT и AI-инструментов для команды отвечает на вопрос, какие навыки и правила нужны сотрудникам. Эта страница помогает выбрать конкретный сценарий поддержки. После выбора используется отдельный план внедрения ИИ в поддержку: источники, эталонный набор, журнал ошибок, эскалация и остановка.

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

Карточка сценария

Заполните карточку до обсуждения поставщика и интерфейса.

NIST AI RMF Core предлагает определить контекст, задачи, владельцев и воздействия, затем способы измерения и управления. Это помогает сравнивать не «бота» и «агента», а конкретные операции.

Сравнительная таблица сценариев

Сценарии внизу таблицы не «лучше» верхних. Они просто требуют более зрелого контура.

Практические сценарии

1. Поиск по базе знаний

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

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

2. Черновик ответа оператору

Вход — обращение и выбранный источник. Выход — черновик в заданном тоне без новых фактов, обещаний и действий. Оператор сверяет условия, учитывает контекст клиента и отправляет или отклоняет.

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

3. Классификация и маршрутизация

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

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

4. Сводка длинной переписки

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

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

5. Подсказка следующего шага

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

Критерий — соответствие регламенту, а не убедительность. При отсутствии основания результатом становится вопрос владельцу процесса.

6. Контроль ответа по чек-листу

Система сравнивает черновик с источником и правилами: есть ли основание, не потеряно ли ограничение, не появилось ли обещание, указана ли эскалация. Итоговое решение остаётся у специалиста.

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

7. Прямой ответ по узкой теме

Возможен только после устойчивого режима помощника на ограниченном классе. Пользователь должен понимать роль автоматизации и иметь доступ к человеку. GOV.UK Service Manual рекомендует для AI-чатботов предупреждать о возможной неточности и предоставлять способ контакта с человеком. Конкретные обязанности зависят от сервиса и юрисдикции.

8. Действие в CRM или платёжной системе

Это отдельный сценарий, а не естественное продолжение генерации текста. Для каждого действия нужны минимальные права, авторизация, подтверждение, журнал и откат. Возврат, изменение адреса и добавление заметки имеют разные последствия.

Британская CMA в официальном руководстве об AI-агентах и потребительском праве подчёркивает, что использующая агента организация отвечает за его действия перед потребителями. Этот источник не устанавливает правила вне своей юрисдикции, но хорошо показывает: технический поставщик не забирает операционную ответственность.

Безопасность входа и полномочий

Обращение клиента — недоверенный вход. В нём могут быть случайные или намеренные инструкции, ссылки, вложения и чувствительные сведения. OWASP Top 10 for LLM and GenAI Applications выделяет prompt injection и sensitive information disclosure среди ключевых рисков.

Практические следствия:

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

Системный промпт важен, но сам по себе не заменяет архитектурные ограничения.

Как выбрать первый пилот

Шаг 1. Соберите операции, а не идеи

Попросите операторов назвать повторяемые действия: поиск статьи, копирование контекста, разметка темы, подготовка сводки. Фраза «сделать умного бота» не является операцией.

Шаг 2. Оцените источник

Есть ли утверждённый документ, владелец, версия и область применения? Если нет, сначала исправьте знания. ИИ не превращает хаотичный корпус в надёжное основание автоматически.

Шаг 3. Оцените проверяемость

Может ли оператор быстро обнаружить неверный источник, пропуск или обещание? Если проверка требует полного повторения работы, сузьте сценарий.

Шаг 4. Оцените последствия

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

Шаг 5. Спроектируйте эскалацию

Определите триггеры, очередь, набор передаваемого контекста и ожидаемое время реакции. Эскалация должна работать до автоматического ответа.

Шаг 6. Проверьте на эталонных случаях

Возьмите нормальные, неполные, конфликтующие, провокационные и требующие отказа обращения. После этого переходите к плану внедрения.

Что не отдавать без отдельного контура

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

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

Метрики сценария

Не переносите чужие цифры экономии или CSAT. Посчитайте полный процесс на собственных данных с калькулятором ROI, включая проверку, поддержку, инциденты и обновление базы знаний.

Ошибки и ограничения

Один интерфейс — один риск. Внутри чат-окна могут скрываться поиск, генерация и действие с разными последствиями.

Старт с самого сложного. Универсальный бот мешает локализовать источник ошибки.

База знаний без владельцев. Устаревший контент становится быстрым неверным ответом.

Нет отказа. Система заполняет пробел правдоподобной формулировкой.

Эскалация теряет историю. Клиент повторяет вопрос и не получает преимущества.

Слишком широкие права. Ошибка текста превращается в операционное действие.

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

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

Какой сценарий обычно лучше для старта?

Поиск по управляемой базе знаний или черновик оператору часто проще проверить, чем прямой ответ. Но выбор зависит от качества источников и цены ошибки.

Нужен ли отдельный чат-бот?

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

Можно ли оценивать успех по доле автоматических ответов?

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

Когда нужен AI-агент?

Когда задача действительно требует нескольких действий и состояние процесса определено. Но агентность увеличивает последствия ошибок; сначала полезно изучить курс по AI-агентам и ограничить инструменты.

Что делать, если источники конфликтуют?

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

Следующий шаг

Выберите одну строку таблицы и заполните карточку сценария. Если источник, проверка или эскалация не определены, пилот преждевременен. Если определены — переходите к контролируемому внедрению ИИ в поддержку.