Данные CRM для AI-агента: подготовка, доступы и проверка

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

Практический подход согласуется с рамкой NIST AI RMF: понимать контекст и риски, измерять их, управлять ими и назначать ответственность. Это не готовая инструкция для конкретной CRM, а полезная структура проверки. Ниже — прикладной чек-лист для команды, которая хочет запустить помощника без ложной уверенности в «волшебной» интеграции.

Один сценарий вместо доступа ко всему

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

Пример: помощник готовит резюме сделки для менеджера. Ему нужны текущая стадия, ответственный, задачи, письма и заметки в рамках этой сделки. Ему не нужна вся клиентская база и право менять договорную сумму. Такой минимальный набор проще проверить, защитить и объяснить пользователям. В статье про AI-агента в CRM разобраны сценарии работы; здесь внимание на готовности данных к конкретному сценарию.

Карта источников: что агент будет считать правдой

Составьте список систем и полей: CRM, база знаний, каталог услуг, документы, история чатов, телефония. Для каждого источника укажите владельца, дату обновления, формат, уровень доступа и правило разрешения конфликтов. Если цена в CRM и прайс-листе различаются, агент должен знать, какой источник авторитетен, либо запросить подтверждение. «Возьми всё, что найдёшь» — плохая политика для коммерческого ответа.

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

Оценка качества данных до пилота

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

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

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

Права на чтение: меньше и точнее

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

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

Проверьте негативные сценарии: пользователь просит «покажи все сделки директора», агент получает ссылку на документ вне своей группы, один клиент спрашивает о заказе другого. Ожидаемое поведение — отказ или запрос доступа, а не попытка обойти ограничение через другой инструмент. Права также должны обновляться после увольнения или смены роли.

База знаний: версии, цитаты и неизвестное

Если агент отвечает по регламентам, храните для документа владельца, версию, дату действия и дату следующего пересмотра. Старые версии не должны соревноваться с актуальными на равных. При ответе полезно показывать источник и дату, чтобы человек мог быстро проверить основание. Рекомендации по устройству поиска и оценки ответов есть в материале про RAG для корпоративной базы знаний.

Заранее определите, что делать при конфликте источников. Например, агент может брать утверждённый регламент выше личной заметки менеджера, а при расхождении цены — остановиться и попросить подтверждение. Не маскируйте неопределённость гладкой формулировкой. Отдельно тестируйте запросы, для которых в базе знаний ответа нет.

Права на запись: черновик, подтверждение, журнал

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

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

Тестовый набор: проверять не только красивый ответ

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

Тесты стоит повторять после изменения схемы полей, базы знаний, инструкций или подключённых инструментов. Средняя оценка скрывает редкую тяжёлую ошибку, поэтому используйте пороги по классам риска. Например, отсутствие ссылки на источник в черновике может быть замечанием, а раскрытие закрытого документа — блокером релиза. Принципы тестового набора подробнее разобраны в статье про оценку AI-агентов. NIST также подчёркивает необходимость измерять риски и качество с учётом контекста применения в разделе Measure.

Пилот и переход к рабочему использованию

1. Выбрать задачуОдин сценарий с понятным пользователем и наблюдаемым результатом.
2. Проверить срез данныхПоля, документы, права и спорные случаи именно для этой задачи.
3. Запустить в чтенииПоказывать черновики и источники без автоматической записи.
4. Собрать ошибкиРазбирать промахи по типам, а не править один удачный пример.
5. Открывать действия постепенноТолько после тестов, с подтверждением и журналом.

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

Ошибки подготовки, которые не исправит новая модель

Агенту дают доступ ко всей CRM «на будущее». Данные очищают один раз, но не назначают владельцев обновления. Старые PDF попадают в поиск без версий. Тестируют только успешные примеры, подготовленные командой внедрения. Действия на запись разрешают раньше, чем научились объяснять ошибку. Во всех случаях проблема лежит в данных и процессе, а не обязательно в выборе модели.

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