Как передавать данные от ИИ в CRM без неконтролируемой записи

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

Безопаснее разделить три результата:

1. Исходное сообщение — письмо, заявка или фрагмент диалога без изменений.
2. Структурированный черновик — значения, которые ИИ извлёк по заданной схеме, вместе с основаниями и статусами.
3. Подтверждённое изменение CRM — только разрешённые поля, прошедшие нужные проверки.

Маршрут будущего решения можно спроектировать так:

1. Получить сообщение и присвоить ему устойчивый идентификатор.
2. Извлечь сведения по заданной схеме.
3. Нормализовать форматы, не добавляя отсутствующие факты.
4. Проверить структуру и бизнес-смысл.
5. Передать спорные значения сотруднику или применить заранее согласованное правило.
6. Создать либо обновить выбранную сущность CRM.
7. Прочитать сохранённый объект и сравнить его с подтверждённым черновиком.

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

Сначала выберите сущность CRM и действие

До настройки ИИ решите, что именно должно произойти в CRM. Один и тот же текст можно использовать, чтобы создать лид, дополнить контакт, обновить сделку или подготовить черновик для менеджера. У этих действий разные последствия и требования к данным.

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

Зафиксируйте до разработки:

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

Не переносите особенности API Битрикс24 на другую CRM без проверки. В другой системе будут свои сущности, права, справочники, обязательные поля и ответы методов.

Составьте карту полей

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

Для каждого поля различайте четыре состояния:

• значение найдено и прошло проверку;
• значения нет в сообщении;
• значение не удалось извлечь;
• в источнике есть противоречивые варианты.

Допустимый null означает известное отсутствие значения. Он не должен скрывать ошибку извлечения. Если бюджет не указан, сохраняйте budget: null и отдельный статус отсутствия, а не ноль. Ноль — это уже конкретная сумма.

Отдельные правила понадобятся для разных типов данных:

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

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

Получите структурированный черновик по заданной схеме

ИИ должен возвращать не свободный пересказ, а объект с заранее определёнными полями и состояниями. В n8n узел Information Extractor предназначен для извлечения структурированной информации из входных данных. Структуру можно описать через атрибуты, пример JSON или JSON Schema.

У режима генерации схемы по примеру JSON есть ограничение: n8n считает каждое поле примера обязательным. Поэтому демонстрационный объект не должен определять бизнес-обязательность. Её задают отдельно — по правилам процесса, допустимым пропускам и последствиям отсутствующего значения.

Черновик полезно дополнить служебными сведениями:

• идентификатором исходного сообщения;
• фрагментом, на котором основано значение;
• состоянием проверки;
• причиной остановки;
• версией черновика.

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

Проверяйте формат отдельно от смысла

Техническая валидация отвечает на вопрос: «Соответствует ли объект заданной структуре?» Она проверяет наличие ключей, типы, формат даты или email и принадлежность значения разрешённому справочнику.

Бизнес-валидация отвечает на другой вопрос: «Разрешено ли использовать это значение в данном действии?» Она проверяет:

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

Объект может полностью соответствовать JSON Schema и при этом содержать неверные сведения. Схема не доказывает истинность данных и не определяет, к какому клиенту относится сообщение.

Для процессов с агентом документация n8n рекомендует передавать результат агента отдельной LLM-цепочке и уже там формировать структурированный объект. Это рекомендация для описанной архитектуры n8n, а не универсальное правило для всех платформ.

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

Задайте маршрут для неизвестных и спорных значений

У черновика должны быть понятные состояния:

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

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

Разделите подтверждение и запись

В одном процессе могут одновременно работать два режима:

• однозначные и разрешённые поля записываются автоматически;
• спорные или значимые изменения подтверждает сотрудник.

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

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

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

Учебный пример: заявка об автоматизации

Это условная демонстрация, а не клиентский кейс и не выполненный тест.

Исходное сообщение:

Добрый день. Нужна автоматизация обработки заявок для отдела продаж. Используем Битрикс24. Связаться можно по почте sales@example.test. Бюджет пока не определили.

Промежуточный объект интеграции:

{
  "source_text_id": "demo-message-001",
  "company_name": null,
  "contact_email": "sales@example.test",
  "crm_name": "Битрикс24",
  "task": "автоматизация обработки заявок",
  "budget": null,
  "budget_status": "not_provided",
  "validation_status": "needs_review"
}

Это внутренний черновик, а не запрос к API Битрикс24. Его поля нужны для извлечения и проверки. Перед записью интеграция отдельно сопоставляет подтверждённые значения с документированными полями выбранной CRM-сущности.

Проверка значений:

Статус needs_review означает, что запись пока не разрешена. В учебном сценарии сотрудник выбирает создание лида и подтверждает email и формулировку задачи. Название CRM остаётся в журнале интеграции: отдельное поле портала для него в примере не задано. company_name и budget не включаются в запрос, потому что подтверждённых значений нет.

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

{
  "source_text_id": "demo-message-001",
  "approved_draft_version": 1,
  "target": "bitrix24_lead",
  "approved_values": {
    "title": "Автоматизация обработки заявок",
    "contact_email": "sales@example.test"
  }
}

Этот конверт также не является параметрами crm.item.add. source_text_id и approved_draft_version остаются во внутреннем журнале, если для них не созданы и не согласованы поля CRM.

Из подтверждённых значений интеграция отдельно формирует запрос на создание лида в Битрикс24. Для email документация метода предусматривает массив мультиполей fm:

{
  "entityTypeId": 1,
  "fields": {
    "title": "Автоматизация обработки заявок",
    "fm": [
      {
        "valueType": "WORK",
        "value": "sales@example.test",
        "typeId": "EMAIL"
      }
    ]
  }
}

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

После записи интеграция читает созданный лид и сверяет только те значения, которые действительно отправила:

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

Проверьте не только успешный сценарий

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

Журнал должен связывать идентификатор сообщения, версию черновика, результаты проверок, принятое решение, запрос, ответ CRM и результат чтения сохранённого объекта. Для ошибки следует сохранять сведения, достаточные для продолжения, но не раскрывать секреты доступа.

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

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

Для первого разбора соберите:

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

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

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

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