Подключение ИИ-агента к CRM упирается не в ИИ, а в три обычных вопроса: есть ли у системы пригодный API, какие права выдать агенту и какие -операции он может выполнять без подтверждения. Ответы на них определяют и стоимость проекта, и его выполнимость — иногда выясняется, что задача в разумные деньги не решается, и лучше узнать это до начала работ.
Что проверить до старта
1. API и его качество
Наличия API мало, важно его состояние:
- Покрывает ли нужные операции. Прочитать сделку можно почти везде, а вот создать её с нужным набором полей или изменить статус — не всегда.
- Документирован ли. Недокументированный API означает разбор методом проб, а это время и риск сломать что-то на рабочих данных.
- Есть ли лимиты запросов. Агент делает больше обращений, чем человек, и упирается в ограничения там, где интерфейс работал нормально.
- Что с версионированием. Меняется ли API при обновлениях и предупреждает ли поставщик.
Если API нет вовсе, честный ответ — агент к этой системе не подключается. Автоматизация через эмуляцию интерфейса технически возможна, но ломается от любого изменения вёрстки и обходится дороже в сопровождении, чем даёт пользы.
2. Права доступа
Агенту заводится отдельная учётная запись, а не используется чужая. Это не формальность: в журнале CRM должно быть видно, что сделал агент, а что человек. Без разделения разбор любого инцидента становится невозможным, а действия агента невозможно отозвать выборочно.
Права выдаются по минимуму: только те объекты и операции, которые нужны сценарию. Соблазн дать администраторский доступ «чтобы не мешало» — самая частая и самая дорогая ошибка на этом этапе.
3. Обратимость операций
По каждой операции нужно ответить: можно ли откатить результат и заметен ли он сразу.
| Операция | Обратимость | Как обычно решается |
|---|---|---|
| Чтение данных | полная | без ограничений |
| Создание записи | простая | автономно, с пометкой источника |
| Изменение статуса | простая | автономно в рамках разрешённых переходов |
| Изменение суммы, скидки | сложная | подтверждение человеком |
| Отправка сообщения клиенту | невозможна | подтверждение обязательно |
| Удаление | сложная | запретить агенту |
Строка про сообщения клиенту — ключевая. Отправленное письмо не отзывается, и агент, самостоятельно пишущий клиентам, создаёт репутационный риск, несопоставимый с экономией. Разбор — в статье «Автономный агент или с подтверждением».
Как выглядит подключение
Инструменты вместо прямого доступа. Агенту не выдаётся возможность «выполнить произвольный запрос к CRM». Каждая операция описывается отдельной функцией с проверяемыми параметрами: «создать заявку» принимает конкретный набор полей и валидирует их до вызова. Механика — в статье «Function calling».
Разница принципиальна. Универсальный доступ означает, что любая ошибка модели может превратиться в произвольное изменение данных. Узкие инструменты ограничивают ущерб конструктивно, а не уговорами в промпте.
Проверки на стороне интеграции, а не модели. Лимиты сумм, допустимые переходы статусов, обязательные поля — всё это проверяется кодом перед вызовом CRM. Полагаться на то, что модель «не станет» делать неправильное, нельзя: она вероятностная.
Пометка источника. Записи, созданные агентом, должны быть отличимы — отдельным полем или тегом. Это нужно и для разбора ошибок, и для оценки эффекта.
Что ломается на практике
- Лимиты API. Агент делает десятки обращений там, где человек делал одно, и упирается в квоту. Обнаруживается обычно на пилоте под нагрузкой.
- Обязательные поля. CRM требует поле, которого нет в исходных данных. Агент либо не может создать запись, либо заполняет его выдуманным значением — второе хуже.
- Дубликаты. Агент создаёт вторую заявку по тому же обращению, потому что не проверил существующие. Защита — идемпотентность: перед созданием проверяется, нет ли уже такой записи.
- Изменение API поставщиком. Работавшая интеграция перестаёт работать после обновления. Лечится мониторингом и договорённостью о версионировании.
- Права шире, чем нужно. Агент технически может то, чего не должен, и однажды это делает.
Локальные и облачные CRM
Для облачных систем (Битрикс24, amoCRM и подобные) вопрос сводится к качеству API и лимитам — доступ по сети есть по определению.
Для локальных установок добавляется сетевой контур: агент должен получить доступ к системе, не открывая её наружу. Обычно это внутренний сервис-посредник, который агент вызывает, а тот уже обращается к CRM. Заодно это удобная точка для проверок и журналирования.
Если в CRM есть персональные данные — а они там есть почти всегда, — выбор между облачной моделью и локальным развёртыванием определяется требованиями закона, а не удобством. См. «152-ФЗ и нейросети».
Разбор ситуации: агент упёрся в лимит API
Типичный инцидент, который обнаруживается на пилоте под нагрузкой.
Что настроили. Агент обрабатывает заявки: на каждую делает поиск клиента, проверку дубликатов, создание записи и назначение ответственного — четыре обращения к CRM.
Что посчитали. 500 заявок в день, четыре запроса на каждую — 2 000 запросов. Лимит CRM — 2 запроса в секунду, то есть 172 800 в сутки. Запас кажется огромным.
Что произошло. В понедельник утром пришло 180 заявок за час. Агент обрабатывает их параллельно, и в пиковые секунды выходит далеко за 2 запроса. CRM начинает отвечать ошибкой превышения лимита. Агент воспринимает её как временный сбой и повторяет вызов — нагрузка растёт, ошибок больше.
Почему расчёт по суткам обманул. Лимит действует посекундно, а поток неравномерен. Суточный запас ничего не говорит о пиковой секунде — это самая частая ошибка при оценке нагрузки.
Что помогает:
- очередь с ограничением скорости на стороне интеграции: агент кладёт запросы в очередь, та отдаёт их в CRM не быстрее разрешённого;
- кеш справочников. Список ответственных и статусов меняется редко, а запрашивается на каждой заявке — его достаточно обновлять раз в час;
- объединение запросов. Многие CRM умеют отдавать данные пакетом, и четыре обращения превращаются в два;
- обработка кода превышения лимита как отдельного случая — не повторять сразу, а ждать с нарастающей паузой;
- потолок параллельных задач: не больше N заявок в обработке одновременно.
Что проверить до разработки. Не суточную квоту, а ограничение в секунду, поведение при его превышении (ошибка или замедление) и наличие пакетных методов. Эти три вопроса задаются на этапе обследования и определяют архитектуру интеграции.
Частые вопросы
Можно ли подключить агента к CRM без API?
Практически нет. Автоматизация через эмуляцию пользовательского интерфейса возможна технически, но ломается от любого изменения вёрстки, работает медленно и требует постоянного сопровождения. Стоимость поддержки такой интеграции обычно превышает пользу. Если у системы нет API, разумнее выбрать другой процесс или сменить систему.
Какие права выдавать агенту?
Минимально необходимые для сценария и обязательно через отдельную учётную запись. Общий доступ или чужая запись лишают возможности разобрать инцидент: в журнале не видно, кто выполнил действие. Удаление записей агенту обычно не выдаётся вовсе, изменение сумм — только с подтверждением.
Как не допустить, чтобы агент создавал дубликаты?
Проверкой перед созданием: прежде чем завести заявку, агент ищет существующую по признакам обращения. Дополнительно помогает идемпотентность на стороне интеграции — повторный вызов с тем же ключом не создаёт вторую запись. Полагаться на то, что модель сама вспомнит о проверке, нельзя.
Что делать, если CRM ограничивает число запросов?
Заложить лимиты в проект: кешировать справочные данные, объединять запросы, ставить очередь. Проблему стоит выяснить на этапе обследования, а не на пилоте — иногда квота такова, что сценарий приходится перепроектировать или отказаться от части шагов.
Нужно ли помечать записи, созданные агентом?
Да, отдельным полем или тегом. Без пометки невозможно ни разобрать ошибку, ни оценить эффект внедрения: непонятно, какие записи появились благодаря агенту, а какие завели люди. Это дешёвая мера, которую потом трудно добавить задним числом.
Что дальше
Как устроен вызов внешних систем — «Function calling» и «MCP». Что агенту разрешать — «Ограничение действий ИИ-агента». Типовой сценарий на базе CRM — «ИИ-агент для обработки заявок».
Проверка API, прав и обратимости операций входит в аудит процессов перед разработкой и внедрением ИИ-агента.