Интеграция ИИ с CRM, 1C и ERP: как сделать без хаоса

Интеграция ИИ с CRM, 1C или ERP - это не просто «подключить API к нейросети». В рабочем сценарии AI-система получает контекст из карточки клиента, сделки, документа или заказа, затем предлагает действие: ответить, классифицировать, заполнить поле, создать задачу, поменять статус, подготовить комментарий.

Чем ближе действие к боевым данным, тем строже должны быть правила. Одно дело - показать менеджеру черновик письма. Другое - изменить статус сделки, выставить счёт или отправить клиенту обещание по срокам. Поэтому архитектура должна различать чтение, черновики, подтверждение и запись.

В продажах AI полезен на входящей квалификации: понять потребность, вытащить отрасль и бюджет, предложить следующий шаг, заполнить поля CRM, подсветить приоритет. В поддержке - найти ответ в базе знаний, подготовить черновик, классифицировать обращение, определить SLA и эскалацию. В back-office - извлечь поля из документов и подготовить запись в учётную систему.

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

Рабочий сценарий AI-агента для 1С ERP почти всегда раскладывается на одну и ту же цепочку: прочитать, собрать, предложить, дождаться подтверждения, записать в журнал. Агент читает данные — карточку контрагента, историю поставок, остатки, условия договора, предыдущие документы того же типа. На чтении права заканчиваются, и это правильная точка старта: read-only режим даёт увидеть качество ответов, ничего не ломая.

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

Затем согласование. Агент может собрать сопроводительный контекст для того, кто утверждает: чем этот документ отличается от типового, какие поля он взял из нестандартного источника, где не хватило данных и что он подставил по умолчанию. Это превращает проверку из перечитывания всего документа в просмотр отличий.

И только после подтверждения человеком документ проводится. Кнопку нажимает сотрудник с соответствующими правами в 1С — теми же, что и раньше, без агента. Каждое действие пишется в журнал: что предложил агент, какие данные использовал, кто подтвердил, что изменил перед проведением. Изменения человека — самый ценный материал: по ним видно, где агент систематически ошибается.

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

Отдельно стоит запретить агенту менять собственные права и настройки интеграции. Это звучит очевидно, но на практике роль для интеграции часто создают с избыточными полномочиями «чтобы не мешало на старте», и она такой и остаётся. Роль под агента заводится отдельно, с явным перечнем объектов и операций, и пересматривается, когда сценарий расширяется.

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

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

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

На пилоте разумно начать с read-only и draft. Система читает данные, предлагает действие и пишет подробный лог, но запись в боевую систему делает человек. После проверки качества можно расширять права: сначала запись в тестовый контур, затем approval flow, и только потом ограниченный write в production.

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

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

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

После 2-4 недель видно, где агент экономит время, где ошибается, какие поля нужно добавить, какие действия можно доверить, а какие всегда должны идти через человека. Такой пилот даёт основу для production, а не просто красивую демонстрацию.