ИИ в CRM: что агенту можно делать самому, а где нужна кнопка «Подтвердить»
Представьте предпринимателя, который подключил к CRM «умного ассистента», неделю радуется жизни, а потом замечает неприятное: клиенты получили вежливые письма о закрытии обращения, а сделки уехали в «Проиграна». Клиенты при этом не отказывались — они написали, что вернутся к разговору после совета директоров. Такой сценарий может произойти, если сформулировать задачу как «дать агенту доступ к CRM, пусть работает». Ошибка здесь не в том, что модель плохо написала письмо. Ошибка в том, что ей выдали один общий переключатель там, где нужна лестница операций разной цены.
«Доступ к CRM» — это десятки разных действий
В голове «доступ к CRM» выглядит как допуск в комнату. На деле внутри комнаты лежит несколько десятков принципиально разных операций. Прочитать карточку клиента обычно менее рискованно, чем что-то в ней изменить или отправить клиенту письмо, — но и чтение требует границ: только нужные поля и только те права, которые действительно нужны. Подготовить черновик письма — тоже, пока черновик остаётся черновиком. А отправить письмо от имени компании, поменять сумму сделки или перевести её в «Проиграна» — действия с последствиями, часть которых кнопкой «назад» не отменяется.
Разница особенно заметна на переходах стадий. Смена стадии в CRM может запускать настроенные автоматизации: уведомления, изменения в отчётах и рабочих очередях, другие связанные процессы. Агент нажал одно поле, а сдвинулось несколько процессов, и часть из них он вообще не видит.
Именно поэтому профильные рекомендации говорят не про «доступ», а про границы. NIST в фреймворке управления рисками ИИ предлагает заранее фиксировать назначение системы, допустимый уровень риска, распределение ролей между человеком и машиной и процедуры человеческого контроля. OWASP в описании риска чрезмерной автономности агентов идёт дальше в практическую сторону: проверять права должна исполняющая система — CRM, API-шлюз или отдельный сервис политик, — а не сама языковая модель. Проще говоря, вопрос «а можно ли мне это сделать?» агент задаёт не себе.
Дальше начинается самая скучная и самая важная часть — подтверждение. Оно бесполезно, если человек, нажимающий кнопку, не видит адресата, канал, точный текст и то, какие поля на какие значения изменятся. Подтверждение без предварительного просмотра — ритуал, а не контроль.
Лестница полномочий: шесть ступеней
Дальше идёт не официальный стандарт NIST или OWASP, а прикладная матрица, собранная из их принципов и из того, как уровни автоматизации сделаны в реальных продуктах вроде Microsoft Dynamics 365. Считать её обязательной нормой нельзя, использовать как рабочий черновик для своей настройки — можно.
Читать данные — самостоятельно, но в минимальном объёме. Чтение обычно менее рискованно, чем изменение или отправка, но и оно требует границ: агент получает доступ только к тем сделкам, контактам и полям, которые нужны для его задачи, работает в контексте конкретного пользователя, а не с учётной записью администратора, а доступ к персональным и финансовым данным ограничивается отдельно. Массовое чтение или выгрузка базы — самостоятельное действие с отдельным решением: утечка клиентской базы по последствиям не сравнима с чтением одной карточки.
Классифицировать лид — самостоятельно. Внутренняя метка «горячий», «требует уточнения», «нецелевой» — хороший кандидат на автономию, но только если она не запускает отправку сообщений, смену ответственного, исключение из воронки или другие значимые автоматизации. Если запускает, это уже не безобидная пометка, а спусковой крючок. Разумная предосторожность — на первом этапе гонять классификацию в теневом режиме и сравнивать с решениями менеджеров. И метка не должна сама расширять агенту права: поставил «горячий» — не получил этим право самому писать клиенту.
Готовить черновик — самостоятельно. Письмо, резюме разговора, предложение следующего шага можно создавать без подтверждения: пока текст не ушёл наружу, внешнего последствия нет. Перед тем как черновик станет чем-то большим, проверяются адресат, факты, персональные данные, суммы и обещания клиенту.
Создавать внутреннюю задачу — самостоятельно в заданных пределах. «Связаться завтра, вот ссылка на лид» — нормальная автоматическая операция, если есть журнал, лимит на количество задач и защита от дублей. Массовое назначение задач или смена ответственного — уже действие с последствиями, его лучше проводить через подтверждение.
Отправлять сообщение — по подтверждению. Человек должен видеть адресата, канал и окончательный текст, а не абстрактное «агент хочет отправить письмо клиенту». Полностью автоматическую отправку можно обсуждать только для узкого класса сообщений: утверждённый шаблон, понятный тип запроса, никаких скидок и юридически значимых обещаний, лимит повторов и возможность мгновенной эскалации. Причина простая: отправленное письмо не «откатишь» как поле в CRM. Контроль обязан стоять до операции, а не после.
Изменять сделку — разделить по полям. Заметки и технические метки можно добавлять самим, но только если они не перезаписывают важные данные и не запускают значимые сторонние автоматизации; прежнее значение при этом сохраняется. Сумма, скидка, ответственный, вероятность, дата закрытия, стадия — по подтверждению. Закрытие сделки как проигранной, удаление карточки, массовое изменение записей и экспорт базы — только с отдельным разрешением, а не «заодно». Каждое изменение должно нести с собой автора-агента, основание и старое с новым значением.
Порядок именно такой, потому что он отражает не алфавит, а цену ошибки. Чтение и метка не выходят никуда. Письмо выходит к клиенту. Смена стадии выходит в отчёты, воронки и чужие рабочие очереди. Чем необратимее действие и чем дальше оно выбирается за пределы карточки, тем нужнее человек.
Один разговор, две ветки
Клиент пишет: «Сейчас договор подписать не можем. Бюджет согласован, вернёмся после совета директоров в следующем месяце». Безопасная последовательность выглядит скучно, и это хороший признак: агент читает переписку в пределах этой сделки, классифицирует лид как «отложенный, но перспективный», готовит черновик ответа, создаёт менеджеру задачу проверить статус через три недели и предлагает сдвинуть ожидаемую дату закрытия. Перед отправкой письма и перед изменением стадии он останавливается и показывает человеку точный текст и точные значения полей: было так, станет так.
Опасная последовательность отличается не злым умыслом, а отсутствием пауз. Агент принимает отсрочку за отказ, сам отправляет сообщение о закрытии обращения и переводит сделку в «Проиграна». Изменение стадии может запустить настроенные автоматизации, из-за которых сделка исчезнет из активной воронки, рабочих очередей и отчётов. Дальше начинается самое неприятное: задачу можно удалить, а дату и карточку — вернуть только если для них заранее настроен механизм версий, резервного копирования или компенсирующей операции. А письмо клиент уже прочитал.
Подтверждение, журнал и откат — три разных механизма
Подтверждение работает до операции. Правильно спроектированный механизм должен фиксировать, кто именно подтвердил, какой инструмент будет вызван, над каким объектом, с какими параметрами и на какой срок действует разрешение, — чтобы «да» не растянулось на всю сессию. Для критических операций разумно требовать предварительный просмотр, отдельную проверку полномочий и запрет выполнения, если механизм подтверждения или журналирования недоступен: отказ системы в такой ситуации должен быть безопасным по умолчанию.
Журнал работает после. Он отвечает на вопрос, кто, когда и что изменил. Salesforce, например, описывает Field History Tracking именно так: фиксируются автор, время и содержание изменения. Это нужно и полезно, но само по себе не возвращает запись в прежнее состояние.
Откат — третий, отдельный механизм. Он обеспечивается восстановлением из версии или резервной копии либо компенсирующей операцией; сама резервная копия откат не выполняет. Аудит, восстановление и резервное копирование — не синонимы. Рассчитывать, что «у нас же есть история изменений» заменяет откат, опасно: история покажет, кто сломал, но не починит.
В продуктах это уже настройка, а не теория
Лестница полномочий звучит как аккуратная теория, пока не посмотреть, как устроены реальные CRM. В Microsoft Dynamics 365 у Case Management Agent есть режимы Full, Require agent confirmation, Shadow mode и Disabled — то есть степень автономии там настройка, а не свойство «подключили ИИ». В режиме подтверждения агент готовит письмо, но представитель должен его проверить и отправить. Отдельно существуют политики governance для исходящих сообщений: в зависимости от настроек система может предупредить отправителя, заблокировать письмо, зарегистрировать нарушение или отправить его на ручное согласование.
Похожая логика, только с другого конца воронки, видна у Market-GPT. Там ИИ-продавец получает контекст заявки, задаёт уточняющие вопросы, фиксирует ответы и готовит сводку для менеджера, а момент передачи клиента человеку выделен отдельно — вплоть до статуса «Нужен человек». Оговорка важная: платформа сама называет этот модуль mini-CRM, а не полноценной заменой CRM, так что речь именно о разделении этапов, а не об универсальной архитектуре прав. Но идея ровно та, к которой приводит вся предыдущая логика: передача горячего клиента менеджеру — отдельный контролируемый шаг, а не побочный эффект разговора. Подробнее о подходе продукта можно узнать на market-gpt.ru.
Правильный вопрос при подключении агента к CRM звучит не «что ему разрешить», а «что он делает без нас, что показывает нам на подтверждение и что мы сможем отменить». Если ответ есть на все три части, доступ давать можно. Если хотя бы на третью ответа нет, то, на мой взгляд, это уже не автоматизация, а лотерея с клиентской базой.
