Доступ ИИ к CRM и почте: как выдать нужные права и проверить их отзыв
Помощник умеет читать карточку клиента и готовить ответ. Но под чьей учётной записью он работает, какие ещё данные видит и что произойдёт после отключения доступа? Эти вопросы стоит закрыть до подключения к рабочей CRM. Иначе удобная интеграция может превратиться в общий ключ к данным отдела.
AWS 14 сентября описала Consent portal в Amazon Bedrock AgentCore Identity. Сотрудник входит через корпоративную систему, отдельно подключает нужные сервисы и подтверждает запрошенные разрешения. Портал связывает выданный доступ с конкретным пользователем, а токены хранятся в AgentCore Identity. В примере AWS подключения GitHub и Slack независимы: разрешение для одного сервиса не включает второй. Компания также описывает отключение подключения и повторное согласие, когда прежнее разрешение больше не действует.
Для руководителя это повод проверить собственный порядок подключения агентов. Ниже — предлагаемый сценарий пилота для CRM и почты. Он требует настройки в используемых системах и не означает, что описанный сервис AWS уже подключён к вашей инфраструктуре.
Опишите права через рабочую задачу
Начните с одного действия: например, подготовить для менеджера сводку по его клиенту. Запишите, какие поля нужны для результата: история обращений, текущий этап сделки, согласованный следующий шаг. Отдельно перечислите действия, которые пилот не выполняет: отправка писем, изменение реквизитов, удаление карточек, выгрузка всей клиентской базы.
Получится понятное задание для интегратора. Требование «подключить CRM» слишком широко: оно не определяет ни набор данных, ни допустимые операции. Для каждого разрешения должна существовать проверяемая связь с задачей. Если система выдаёт права крупными пакетами, команда должна увидеть этот избыток до запуска и выбрать способ ограничения на стороне интеграции.
Согласие на подключение сервиса и подтверждение конкретной операции решают разные вопросы. Даже при техническом праве отправлять сообщения можно оставить отправку на утверждение менеджеру. В карточке согласования покажите адресата, окончательный текст и вложения. Изменение любого из этих полей после проверки требует нового подтверждения.
Проверьте разделение сотрудников
Для теста заведите две учебные учётные записи с разными наборами клиентов. Дайте каждой доступ к собственным карточкам. Затем выполните одинаковый запрос от обоих сотрудников и сравните результат с их правами в CRM. Проверяйте не только видимую ссылку, но и текст ответа: сведения о чужом клиенте могут попасть в резюме без ссылки на карточку.
Добавьте отрицательные проверки. Попросите первого сотрудника открыть точный номер карточки второго, продолжить его диалог и найти клиента по фрагменту названия. Ожидаемый результат — отказ в недоступной операции без раскрытия содержимого. Если агент возвращает чужие данные, увеличение числа пользователей нужно отложить до исправления причины.
Проверьте также выход из аккаунта и вход другого человека на том же устройстве. История диалога, сохранённые ответы и промежуточные результаты не должны становиться общими только потому, что сотрудники использовали один браузер. Для каждого слоя хранения назначьте правило доступа и срок жизни данных.
Связь агента с внешним сервисом подробнее разобрана в статье СибБро о заявках прямо в чате и MCP. К проверке выполнения операции полезно добавить проверку личности сотрудника, от имени которого она выполняется.
Испытайте отзыв доступа до запуска
Сначала выполните разрешённый запрос, затем отключите подключение и повторите его в новой сессии. Проверьте также уже запущенную задачу: она может держать временное разрешение или ранее полученный результат. Установите, через какое время отключение реально блокирует новые обращения, и зафиксируйте это как критерий приёмки.
Удаление подключения не следует автоматически считать удалением ранее скопированных данных. Отдельно разберите кэш, журналы, историю переписки и сформированные документы. Если рабочая политика запрещает возвращать старые сведения после отзыва доступа, испытайте именно этот сценарий, включая повторный вопрос без нового обращения к CRM.
Для отказа нужен понятный маршрут. Агент сообщает, что операция недоступна, сохраняет безопасный статус задачи и предлагает сотруднику восстановить разрешение через установленный процесс. Неудачная попытка не должна запускать бесконечные повторы или переключение на чужую служебную учётную запись.
Что включить в акт приёмки
Сохраните таблицу «роль — данные — операция — ожидаемый результат». Для каждого сценария приложите результат проверки и запись журнала без секретов. Ответственный за процесс должен уметь объяснить, кто выдал разрешение, кому оно принадлежит, как его отключить и как проверить прекращение доступа.
Пилот готов к расширению, когда разрешённые задачи выполняются, запрещённые обращения блокируются, пользователи разделены, а отзыв доступа проверен на новых и уже начатых задачах. При изменении интеграции или набора прав эту подборку нужно выполнить повторно.
Видео: как MCP связывает помощника с инструментами
Александр Бындю объясняет устройство MCP и подключение инструментов к ИИ. Видео помогает понять, где проходит связь между помощником и сервисом; конкретные права и порядок согласования для CRM команда определяет отдельно.
