Разбор задачи: почему AI нельзя давать полный доступ к CRM

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

Что означает полный доступ на практике

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

Права определяются не промптом «не трогай лишнее», а настройками CRM и серверного слоя.

Ошибки модели становятся действиями

Модель может перепутать двух клиентов с одинаковой фамилией, извлечь неверную сумму, повторить вызов после таймаута или решить, что пользователь просил удалить запись. В обычном чате это плохой ответ; в CRM — повреждение рабочего процесса.

Поэтому AI предлагает параметры, а детерминированный сервис проверяет типы, идентификаторы, версию записи и полномочия.

CRM содержит больше данных, чем нужно

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

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

Замените доступ узкими инструментами

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

Модель не формирует произвольный запрос к CRM и не выбирает поля, которых нет в инструменте. Сервер снова читает актуальные данные перед записью.

Разделите чтение и запись

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

Такая архитектура позволяет отключить рискованную функцию, не останавливая безопасные ответы.

Подтверждайте значимые изменения

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

Для низкорисковой метки подтверждение можно снять после стабильных evals. Каждое новое действие проходит отдельную проверку.

Защититесь от повторов и гонок.

1. Назначить уникальный ключ операции.
2. Проверить текущую версию записи.
3. Не повторять необратимый запрос вслепую.
4. Вернуть существующий результат при дубле.
5. Журналировать прежнее и новое значение.
6. Иметь способ отката или компенсации.

Если CRM недоступна, агент не подтверждает успех. Он сохраняет черновик по резервному маршруту или передаёт сотруднику.

Регулярно пересматривайте права.

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

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

Алиса может помочь спроектировать узкие CRM-инструменты и план поэтапного расширения прав после проверки.