- 1Банк России рекомендует давать клиенту возможность отказаться от взаимодействия с ИИ и перейти к сотруднику. Кодекс этики следует отличать от обязательных норм закона.
- 2Наличие кнопки ещё не доказывает, что маршрут работает. Проверяют регистрацию обращения, передачу диалога, очередь и дальнейшее уведомление клиента.
- 3Для спорных и повторно неудачных диалогов полезны отдельные правила передачи. Модель не должна единолично решать, получит ли клиент помощь человека.
Правовые выводы проверены и актуализированы 3 октября 2026 года. Примеры условные; рекомендации по организации работы отделены от обязательных требований.
Что рекомендует Банк России
Кодекс этики в сфере ИИ на финансовом рынке, приложенный к письму от 09.07.2025 № ИН-016-13/91, содержит рекомендации о возможности отказаться от взаимодействия с ИИ и общаться с сотрудником. Он также предусматривает рекомендованный пересмотр решения сотрудником по запросу клиента. Это разные сценарии: передача разговора и пересмотр уже принятого решения.
В разъяснениях на своём сайте регулятор подтверждает этот подход и напоминает, что применение ИИ не освобождает финансовую организацию от ответственности за нарушение прав клиента. При этом рекомендательный кодекс нельзя описывать как отдельный закон, обязывающий любой российский чат-бот немедленно соединять пользователя с оператором.
Для конкретного обращения дополнительно проверяют обязательные правила соответствующей услуги и процедуры. Вопрос о спорной операции, жалобе или данных клиента не решается одной ссылкой на добровольность кодекса. Сначала устанавливают, что именно хочет сделать человек и каким способом организация должна принять и рассмотреть его обращение.
Разделите справку и юридически значимое обращение
Ответ о расположении офиса и сообщение о списании без согласия требуют разного маршрута. В первом случае автоматическая справка часто закрывает задачу. Во втором клиенту может понадобиться регистрация обращения и дальнейшие действия в установленные сроки. Бот, который продолжает объяснять общий порядок вместо приёма сообщения, создаёт ненужный риск.
Для настройки полезна карта клиентских намерений: справка, помощь с интерфейсом, претензия, спорная комиссия, подозрение на мошенничество, запрос о персональных данных. Это практическая классификация, а не установленный законом перечень. Для каждого сценария определяют допустимые действия модели и момент, после которого вопрос принимает сотрудник или специализированный процесс.
Если в чате нельзя совершить нужное действие, клиенту сообщают рабочий способ обращения. Ссылка должна вести к подходящей форме, а инструкции — соответствовать реальным возможностям сервиса. Нельзя обещать, что заявление принято, если система сохранила только историю разговора и не создала обращение.
Сделайте запрос человека самостоятельным событием
Слова «соедините с оператором» полезно обрабатывать отдельно от обычного запроса к модели. Тогда изменение инструкции, обновление провайдера или неверная классификация не будут единственным препятствием между клиентом и сотрудником. Это рекомендация по архитектуре: конкретную реализацию выбирает команда с учётом каналов обслуживания.
Дополнительными основаниями передачи могут стать повторная неудача, сообщение об ошибке, конфликт с предложенным решением и признаки чувствительного сценария. Необязательно использовать одинаковый порог для всех вопросов. Важно, чтобы ответственный за процесс мог объяснить правила и проверить их на примерах, включая нетипичные формулировки клиента.
В тестах стоит проверить опечатки, короткие сообщения, голосовой ввод и просьбу о сотруднике посреди длинного диалога. Полезна и негативная проверка: модель не должна заявлять, что «операторов нет», лишь потому, что так получилось в генерации. Сведения о доступности и очереди получают из контролируемого источника.
Проверьте передачу от начала до конца
После запроса человека система должна сформировать понятное состояние: обращение передано, сотрудник подключён либо клиенту предложен иной доступный способ связи. Если обслуживание ограничено по времени, об этом сообщают достоверно. Нельзя подменять реальную очередь бесконечным сообщением «ожидайте» без созданной задачи.
Сотруднику передают сведения, необходимые для работы: суть вопроса, существенные ответы бота и уже выполненные действия. Это снижает вероятность повторной ошибки и необходимость заново расспрашивать клиента. При этом доступ к банковской информации и персональным данным ограничивают по ролям; удобство оператора не оправдывает передачу всей истории всем сотрудникам.
Для разных каналов важна связность. Если клиента перевели из приложения в телефонный контакт, организация должна понимать, как будет найдено предыдущее обращение. Условный тест прост: другой сотрудник открывает задачу и может установить, что произошло, что осталось сделать и кто отвечает за следующий шаг.
Сохраняйте достаточно сведений для проверки
При жалобе полезно восстановить текст ответа, время запроса сотрудника, событие передачи и итог рассмотрения. Иногда потребуется определить версию модели и правил обработки. Набор сведений выбирают по задаче; он не должен превращаться в бесконтрольный архив всех данных, которые доступны системе.
Сроки хранения, доступ, маскирование и возможность получить записи проверяют вместе с информационной безопасностью и юристами. Логи ценны, если их можно связать с обращением и достоверно объяснить. Большой объём разрозненных технических записей не помогает, когда невозможно установить, какой ответ фактически увидел клиент.
Проверьте условия внешней платформы
Для поставщика чат-бота в договоре стоит описать возможность задавать правила передачи, доступные события и интерфейсы, сохранение необходимых сведений и порядок изменения модели. Заказчику нужен контроль над маршрутом обращения, а не только обещание качественно отвечать на вопросы.
Отдельно согласуют реакцию на сбой: как отключить автоматические ответы, куда направить клиента, кто расследует ошибку и какие сведения предоставляет исполнитель. Условия использования диалогов провайдером проверяют с учётом данных и договоров организации. Коммерческий тариф сам по себе не доказывает запрет обучения на клиентской переписке.
Начните с нескольких реальных маршрутов
Для первой проверки можно взять спорное списание, несогласие с комиссией и прямую просьбу о сотруднике. Пройдите каждый сценарий в приложении, веб-версии и других используемых каналах. Посмотрите не только экран клиента, но и задачу, которую получил оператор. Затем проверьте, как человеку сообщают результат.
Результатом такой проверки должны стать конкретные изменения: исправленный маршрут, правила обработки чувствительных сообщений, ответственные и сценарии испытаний. Автоматизация остаётся полезной, когда клиентская задача решается предсказуемо. Передача сотруднику — часть сервиса, которая позволяет остановить неудачный диалог и продолжить работу.