Как разделить диалоги клиентов в ИИ-ассистенте

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

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

Почему смешение диалогов — отдельная задача внедрения

В маршруте сообщения участвуют как минимум три разных объекта:

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

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

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

Спрос и поисковая выдача по этой теме не измерялись. Связь материала с проектированием ИИ-ассистента — редакционная оценка, а не доказанная конверсия.

Какие идентификаторы нужны в маршруте сообщения

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

В Chat Trigger платформы n8n загрузка предыдущих сообщений использует sessionID. В embedded chat можно передавать дополнительные данные через metadata, например идентификатор пользователя. Однако metadata поступает вместе с запросом: документация не объявляет его доказательством личности или встроенной границей доступа.

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

Как привязать историю к сессии и не подменить проверку памятью

Безопасный маршрут строится до вызова модели:

1. Система принимает сообщение и фиксирует message_id.
2. Сервер проверяет канал и, если требуется, вход пользователя.
3. Сервер определяет сессию, доступную этому контексту.
4. Хранилище возвращает историю только этой сессии.
5. Система формирует контекст для модели.
6. Перед внешним действием принадлежность проверяется ещё раз.

Simple Memory в n8n сохраняет историю чата. У узла есть ключ сессии, но назначение памяти не означает, что узел самостоятельно устанавливает владельца разговора, защищает идентификатор от подбора или разграничивает права клиентов.

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

Доступ к чату и доступ к истории — разные проверки

Chat Trigger в n8n поддерживает несколько режимов доступа: без аутентификации, с Basic Auth и с n8n User Auth. При отсутствии аутентификации чатом может пользоваться любой посетитель. Basic Auth использует общие имя и пароль для пользователей. n8n User Auth допускает вошедших пользователей n8n и может дополнительно учитывать право запуска workflow.

Ни один из этих вариантов сам по себе не отвечает на вопрос: «Имеет ли этот пользователь право читать именно эту историю или менять именно эту заявку?» Вход в чат и доступ к объекту — разные решения.

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

Новая беседа, завершение сессии и срок хранения

Опишите состояния разговора до разработки. Например:

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

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

Действия ассистента во внешних системах

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

Модель и исполняющая система выполняют разные роли. Модель может предложить намерение и параметры: например, «получить статус заявки A-41». Исполняющая часть проверяет, разрешено ли текущему пользователю читать эту заявку, и только затем вызывает нужный инструмент.

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

Условный пример с двумя одновременными диалогами

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

Клиент А начинает разговор о заявке A-41, клиент Б — о заявке B-72. Интерфейс получает отдельный непрозрачный session_id для каждого разговора. account_id появляется только после входа пользователя.

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

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

Как проверить изоляцию перед запуском

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

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

Для архитектуры на n8n есть отдельное документированное ограничение: Simple Memory не работает в активном production-workflow при queue mode, потому что вызовы могут попасть к разным workers. Это ограничение относится к Simple Memory в указанном режиме, а не ко всем возможным хранилищам. Если проект использует queue mode, способ хранения истории нужно выбрать и проверить отдельно.

Ограничения и подготовка проекта

Официальная документация подтверждает функции Chat Trigger и Simple Memory, но не готовую защищённую архитектуру конкретного ассистента. Итоговое решение зависит от канала, способа входа, модели данных, хранилища, прав внешних систем и режима размещения.

До обсуждения проекта подготовьте:

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

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

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

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