AI и автоматизация

AI-агент и 1С/CRM: как устроена интеграция под капотом

«Интегрируется с 1С и CRM» — фраза, которая встречается почти в каждом описании AI-агента и почти никогда не объясняется. На практике за ней стоят конкретные технические решения: как агент читает данные, где хранится состояние диалога, что происходит, если данные в системе изменились за секунду до ответа. Разбираем это не на уровне маркетинга, а на уровне архитектуры.

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

Три способа подключения к 1С и CRM

• Через открытый API системы (REST, OData). Большинство современных конфигураций 1С и CRM предоставляют программный интерфейс — агент обращается к нему так же, как обращалось бы любое стороннее приложение. Это самый безопасный и предсказуемый способ: система сама контролирует, что можно читать и менять.
• Через доработку — отдельный модуль-обработчик. Если готового API не хватает для конкретной задачи (например, нужен нестандартный отчёт или специфичная выборка), в 1С или CRM добавляют небольшой модуль, который открывает именно нужный агенту интерфейс — не трогая остальную систему.
• Через промежуточный слой (интеграционная шина). Когда агенту нужно работать сразу с несколькими системами — 1С, CRM, документооборотом, — между ними ставится связующий сервис, который знает, как обратиться к каждой, и отдаёт агенту данные в едином формате. Это усложняет архитектуру, но избавляет агента от необходимости знать особенности каждой системы отдельно.

Чего лучше избегать — прямого доступа к базе данных 1С в обход её собственного API. Внутренняя структура данных 1С сложнее, чем кажется снаружи, и запись в обход штатной бизнес-логики системы — частая причина рассинхронизации данных, которую потом сложно найти и починить.

Где хранится состояние диалога и данные

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

Чтение и запись — разные по риску операции

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

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

Как выбрать подрядчика

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

• Объясняет, через какой именно интерфейс агент будет обращаться к 1С или CRM — а не отвечает общей фразой «интегрируем с чем угодно» без деталей.
• Разделяет операции чтения и записи в архитектуре и обсуждает это с вами до начала разработки, а не постфактум.
• Не предлагает копировать данные из 1С внутрь агента «для скорости» без объяснения, как эта копия будет оставаться синхронизированной с оригиналом.
• Показывает работающую интеграцию на реальных, а не тестовых демо-данных — на реальной структуре данных всегда всплывают нюансы, которых нет в идеальном демо-примере.