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

Что значит интегрировать ИИ с бизнес-системой

Модель не должна жить отдельно от процесса.

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

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

Сценарии, которые чаще всего окупаются

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

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

• квалификация и оценка заявки входящих заявок
• черновики ответов и комментариев в CRM
• подготовка данных для 1C, ERP и учётных систем

ИИ-агент в 1С и ERP: что он делает по шагам

Агент готовит операцию, проводит её человек.

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

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

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

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

• чтение справочников и истории — стартовый режим без права записи
• Черновик документа появляется непроведённым и помечен как подготовленный агентом
• проводит документ сотрудник со своими обычными правами
• журнал хранит предложение агента, источники данных и правки человека

Что агенту нельзя разрешать без подтверждения

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

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

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

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

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

Как проектировать права доступа

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

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

Логи: без них агент превращается в чёрный ящик

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

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

• журнал действий для расследований и безопасности
• журнал качества для исправления ошибок агента
• журнал бизнес-событий для расчёта эффекта и SLA

Как выглядит безопасная пробная версия

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

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