Отмена записи через AI-агента: права клиента и явное согласие

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

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

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

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

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

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

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

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

Согласие должно относиться к этому резюме, а не к произвольному «да» из истории диалога. В интеграции полезно хранить предложение действия с идентификатором, сроком действия и версией брони. Если клиент обсуждал две разные записи, нельзя использовать старое согласие для новой операции.

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

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

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

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

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

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