Что спросить у поставщика ИИ-агента до доступа к CRM
Вопросник поставщику ИИ-агента перед подключением к CRM: данные, права, журнал, остановка и поддержка. Матрица доступа и учебный пример пилота.
До подключения согласуйте, какие записи агент может читать, что вправе менять, кто подтверждает действия и как остановить работу. Затем попросите поставщика показать эти ограничения на тестовых данных: выполнение разрешённой операции, отказ в выполнении запрещённой и отзыв доступа. Ответы в вопроснике и результаты показа дадут основание решить, какой доступ вы готовы выдать для пилота.
Это руководство для владельца небольшой компании, который обсуждает подключение ИИ к CRM. Оно поможет подготовить встречу с поставщиком и вашим администратором. Сам вопросник не подтверждает безопасность сервиса: конкретные настройки, обработку данных и договорные условия нужно проверить отдельно.
Сначала опишите одну операцию
Запишите задачу так, чтобы у неё были вход, результат и ответственный. Например: «По тексту нового обращения подготовить краткую сводку для менеджера. Не менять карточку и не отвечать клиенту». С этим описанием уже можно обсуждать необходимые поля и права.
Фраза «агент помогает отделу продаж» оставляет слишком много открытых вопросов. Требуется ли ему читать вложения? Нужны ли контакты других клиентов? Должен ли он создавать задачи? Каждое дополнительное действие отдельно внесите в матрицу ниже и объясните, зачем оно нужно выбранной операции.
Если задача решается по заполненным полям — например, назначить ответственного по городу, — сначала рассмотрите правила CRM. Для небольшого потока сводку можно пока готовить вручную. Сравнивайте варианты на одной операции, с одинаковым результатом и проверкой.
Возьмите на встречу вопросник: ответ нужно подтвердить
Скопируйте таблицу в рабочий документ. В колонке ответа запишите согласованное условие, имя ответственного и ссылку на документ или результат показа. Секреты доступа в этот документ не включайте.
| Что спросить | Что попросить показать или предоставить | Ответ поставщика и ответственный |
|---|---|---|
| Какие объекты и поля CRM нужны этой операции? | Перечень полей, выборку для пилота и способ ограничения доступа; отдельно — вложения и переписку | ___ |
| От чьего имени агент обращается к CRM? | Учётную запись, область API-доступа и фактические права; секреты при показе скрыть | ___ |
| Какие действия разрешены и где проверяется запрет? | Разрешённый вызов и отказ в чтении чужой записи, изменении или удалении вне согласованных прав | ___ |
| Как человек подтверждает запись или отправку? | Экран или запись согласования с конкретным текстом, адресатом и действием; поведение при отсутствии ответа | ___ |
| Что остаётся в журнале? | Пример: время, ID обращения, операция, результат, подтверждение человека и ошибка; правила доступа к журналу | ___ |
| Как прекратить работу? | Отзыв доступа, остановку очереди и поведение задачи, которая уже началась | ___ |
| Как исправить ошибочное действие? | Порядок восстановления для каждого разрешённого действия, ограничения и владельца исправления | ___ |
| Куда передаются и где хранятся данные? | Схему с моделью, сервисами, подрядчиками, журналами и копиями; сроки хранения, удаления и условия использования для обучения | ___ |
| Кто помогает при сбое и что оплачивается отдельно? | Канал поддержки, согласованный срок реакции, ответственного, условия исправления, изменений интеграции и завершения пилота | ___ |
Не принимайте ответ «у нас всё защищено» как заполненную строку. Уточните, какое условие действует именно в вашем пилоте и чем его подтвердить. Если нужного ограничения нет в выбранной CRM или коннекторе, попросите предложить другой технический способ либо сократите пилот до работы вне CRM на подготовленных данных.
Различайте правила в инструкции и реальные права
Попросите администратора объяснить путь одного действия: от запроса агента до проверки разрешения в CRM или интеграционном сервисе. В рекомендациях OWASP об избыточных полномочиях агента авторизацию предлагается выполнять в системах, где исполняются операции, вместо того чтобы полагаться на решение языковой модели. Для вашей встречи это означает простой вопрос: «Что отклонит запрещённый вызов, даже если агент его предложит?»
У конкретных способов интеграции есть свои условия. Например, входящий вебхук Битрикс24 выполняет запросы в пределах выбранной области доступа — scope — и с правами сотрудника, который его создал. Это описано в официальной REST-документации. Поэтому попросите показать и настройки вебхука, и права его владельца. Эти условия относятся к входящему вебхуку Битрикс24; для приложения, другой CRM или собственного коннектора нужен отдельный разбор.
Не выдавайте широкие рабочие права ради демонстрации, которую обещают «после подключения». Согласуйте показ на синтетических записях в отдельном тестовом окружении. Если ограничение обеспечивается интеграционным сервисом, а его собственный доступ к CRM шире, это тоже внесите в документ: кто администрирует сервис, как проверяются его права и кто имеет доступ к данным.
Заполните матрицу прав до выдачи доступа
Для каждой операции определите четыре вещи: доступные записи, разрешённое действие, подтверждение человека и проверку ограничения. Формулировки «доступ к CRM» недостаточно: чтение обращения и изменение суммы сделки требуют разных решений.
| Операция и записи | Разрешённое действие | Кто подтверждает | Как проверяем границу |
|---|---|---|---|
| ___ | Читать / подготовить черновик / создать / изменить / другое: ___ | Не требуется для согласованного чтения / имя и роль: ___ | Разрешённый пример: ___; запрещённый: ___; результат: ___ |
| ___ | ___ | ___ | ___ |
| ___ | ___ | ___ | ___ |
Рядом запишите владельца пилота, срок доступа и способ его отзыва. У каждой разрешённой операции должен быть понятный результат в журнале. Требуйте только необходимые для разбора сведения: заранее решите, кто видит журнал и нужно ли сохранять полный текст обращения. Не записывайте туда ключи и токены.
Для изменения карточки отдельно согласуйте, как сохранить прежнее значение и кто вправе его восстановить. Для отправки сообщения попросите описать действия после ошибочной отправки. Условие «всё можно отменить» не принимайте без разбора конкретной операции и её ограничений.
Учебный пример: сводка обращения без записи в CRM
Ниже вымышленный пилот, а не клиентский кейс и не результат испытания сервиса. Владелец хочет проверить, помогает ли менеджеру краткая сводка обращения, написанного в свободной форме. Администратор готовит синтетические карточки в отдельном тестовом окружении; реальных контактов и клиентской переписки в них нет.
Матрицу можно заполнить так:
| Операция и записи | Разрешённое действие | Подтверждение | Проверка |
|---|---|---|---|
| Обращения из списка пилота; поля «ID», «текст», «категория» | Читать согласованные поля и выводить сводку в тестовом окне | Менеджер проверяет сводку; запись в CRM запрещена | Разрешённую карточку прочитать; карточку вне списка не выдавать |
| Любая карточка, задача или сообщение | Изменение, создание и отправка запрещены | Право не выдано | Попытка записи отклонена; рабочих изменений нет |
Поставщик должен показать, как эти условия исполняются. Если его коннектор не умеет ограничивать записи выбранным способом, предложенная матрица ещё не согласована: меняйте архитектуру или проводите первый тест на подготовленном файле вне CRM.
Во время показа менеджер просит сводку разрешённой карточки и сравнивает её с исходным текстом. Затем администратор проверяет запрос к карточке вне списка и попытку изменить поле. В журнале должно быть понятно, какая операция разрешена, какая отклонена и почему. Это ожидаемые результаты пилота; их нельзя считать достигнутыми без проверки.
Последний шаг — остановка. Администратор отзывает доступ, поставщик останавливает очередь, затем вместе проверяют новый запрос и уже начатую задачу. Заранее определите, что делать с результатом задачи, которая завершилась во время остановки: например, сохранить его только для разбора, без записи и отправки. Зафиксируйте фактическое поведение и расхождения с договорённостью.
Решите, какой доступ вы готовы выдать
Продолжайте обсуждение подключения, когда у каждой разрешённой операции есть граница, проверка и ответственный. Остановите выдачу доступа, если поставщик не может объяснить права, показать запрет, дать пример журнала или проверить прекращение работы. Сначала устраните конкретный пробел.
Этот вопросник проверяет условия подключения. Качество самой сводки, ответы на сложные обращения и пользу для менеджера оцените отдельно — для этого пригодится протокол проверки ИИ-помощника на десяти сценариях. Начните встречу с одной заполненной строки матрицы: так поставщику будет понятно, какую операцию и какое ограничение требуется показать.