Как проверять ответы ИИ перед отправкой клиенту

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

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

Где должна стоять проверка ответа

Проверку ставят после подготовки черновика, но до действия, которое отправляет сообщение во внешний канал:

1. Клиент задаёт вопрос.
2. Помощник готовит финальный черновик.
3. Система проверяет именно эту редакцию.
4. Правила определяют исход.
5. Разрешённый ответ отправляется, остальные останавливаются или передаются сотруднику.

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

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

Составьте карту допустимого ответа

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

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

Разделите проверки по способу выполнения

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

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

Модельные проверки оценивают смысл: относится ли ответ к разрешённой теме, нарушает ли пользовательское правило, которое нельзя выразить точным шаблоном. Для LLM-проверок Guardrails в n8n требуется подключённый Chat Model. Такие проверки могут ошибаться, а выбранный порог не становится универсальной мерой надёжности.

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

Задайте три исхода: допустить, заблокировать, передать

Три исхода не должны сливаться в один общий статус «ошибка».

Операция Check Text for Violations в Guardrails направляет элемент с обнаруженным нарушением в ветку Fail. Это подтверждает возможность разветвить workflow, но не создаёт последующие действия автоматически. Статусы, запрет внешней отправки, уведомление и ручной маршрут нужно спроектировать отдельно.

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

Не смешивайте блокировку и маскирование

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

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

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

Передайте сотруднику контекст, а не только тревогу

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

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

Клиенту в это время показывают нейтральный статус без обещания срока, если срок ответа не установлен.

В документации n8n есть демонстрационный workflow: когда агент не может ответить, он запрашивает адрес электронной почты и отправляет сообщение в Slack с просьбой о помощи человека. Это пример документации, а не готовое внедрение Switch On AI и не обязательный выбор канала. В реальном процессе канал, состав карточки и действия сотрудника определяют отдельно.

Учебный пример: цена и внутренний контакт

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

Клиент спрашивает: «Подтвердите стоимость дополнительной интеграции и пришлите контакт ответственного».

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

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

Зафиксируйте решение и фактическую отправку

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

Предусмотрите отдельные записи:

1. Результат проверки и сработавшие правила.
2. Решение сотрудника, если он участвовал.
3. Разрешённая версия текста.
4. Результат попытки отправки.

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

Проверьте маршрут и закрепите ограничения

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

В проверку стоит включить:

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

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

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

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

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

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

Switch On AI разрабатывает ИИ-агентов под конкретные операции компании: от требований и прототипа ключевого сценария до проверки, внедрения и передачи кода в согласованном объёме. ИИ-агент выбирает следующий шаг из разрешённых действий; чат-бот служит интерфейсом диалога, а обычная интеграция выполняет заранее заданную последовательность. Для предсказуемого маршрута без выбора модели может быть достаточно фиксированной автоматизации.

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