CRM, ERP и 1С
ИИ может работать с данными о клиентах, сделках, заказах, товарах, финансах и внутренних операциях. Например, получать историю клиента из CRM, данные по заказу из 1С и формировать результат внутри привычного рабочего интерфейса.
Подключаем искусственный интеллект к CRM, 1С, ERP, базам данных, сайтам и внутренним сервисам компании.

ИИ работает с реальными данными бизнеса, выполняет задачи внутри существующих процессов и возвращает результат обратно в рабочие системы — без замены всей IT-инфраструктуры.
Для личных задач ChatGPT, Claude, GigaChat и других AI-чатов часто достаточно. Но постоянный бизнес-процесс нельзя строить на том, что сотрудник каждый раз вручную собирает данные, пишет промт, переносит результат обратно и сам оценивает, насколько хорошо сработала модель.
В таком сценарии сложно обеспечить одинаковое качество, контролировать контекст, отслеживать ошибки и системно улучшать результат.
При интеграции принцип меняется:
бизнес-система → данные → ИИ → проверка → результат → бизнес-система

ИИ получает нужную информацию автоматически, работает по заданной логике и возвращает результат туда, где с ним уже работает сотрудник или следующий этап процесса.
Интеграция ИИ в бизнес-процессы начинается не с выбора конкретной нейросети.
Главный вопрос — какую функцию бизнеса мы хотим сделать стабильной, управляемой и измеримой.
Один из наших проектов хорошо показывает, почему интеграция искусственного интеллекта редко заканчивается первым релизом.
Для INSAL мы разработали AI-навигатор, который определял задачу пользователя и переводил диалог в подходящий сценарий.
Для части запросов AI получал доступ к расчётным инструментам CRM, помогал получить предварительный результат, а данные и заявку передавал обратно в рабочую систему.
Получился единый контур:
пользователь → AI-роутер → профильный сценарий → расчёт → CRM
После запуска стало видно следующее ограничение: хорошей логики и промтов недостаточно, если системе не хватает накопленных знаний компании.
Так эксплуатация первого решения привела к следующему этапу — развитию корпоративной базы знаний.
Отдельные AI-инструменты начали переносить непосредственно внутрь CRM.
Появились пользовательские AI-сервисы и закрытые инструменты для сотрудников. В одном контуре можно управлять доступом, использованием сервисов и их дальнейшим развитием.
То, что начиналось как отдельный AI-эксперимент, стало частью рабочей системы:
пользователь → CRM → AI-сервис → результат → дальнейшее действие
Такой подход позволяет контролировать не только работу модели, но и использование AI-функций, доступ пользователей и развитие системы после запуска.
Сервис определения кода ТН ВЭД сначала проверяли как отдельную AI-гипотезу.
Это позволило оценить качество сценария до того, как встраивать его в более крупную систему.
Наш подход в таких проектах:
гипотеза → MVP → реальные результаты → оценка качества → интеграция → улучшение
Не каждый новый AI-сценарий нужно сразу превращать в большой проект. Иногда надёжнее сначала проверить одну функцию, увидеть реальные ошибки и только затем включать её в постоянный бизнес-процесс.
Интеграция может охватывать одну систему или связывать сразу несколько источников данных.
ИИ может работать с данными о клиентах, сделках, заказах, товарах, финансах и внутренних операциях. Например, получать историю клиента из CRM, данные по заказу из 1С и формировать результат внутри привычного рабочего интерфейса.
Документы, инструкции, регламенты, базы знаний, Excel-файлы, базы данных и корпоративные хранилища можно использовать как источники информации для AI-сценариев.
ИИ можно интегрировать в корпоративные сайты, интернет-магазины, личные кабинеты, веб- и мобильные приложения, формы и чаты.
AI-функция становится частью существующего интерфейса, а пользователю не приходится переходить в отдельный сервис.
Электронная почта, мессенджеры, внутренние чаты и системы обработки обращений могут передавать данные в AI-сценарий и получать обработанный результат обратно.
Корпоративное ПО, SaaS-сервисы, API партнёров и собственные приложения компании можно объединять в общий интеграционный контур. Например, ИИ может получить информацию о клиенте из CRM, данные по заказу из 1С, найти нужный регламент в базе знаний и вернуть сотруднику готовый результат внутри рабочей системы.
Для коммерческого использования мы смотрим на четыре ключевые характеристики: стабильность, контроль, измеримость и возможность постоянного улучшения.

Одинаковая задача должна выполняться по определённому сценарию, а не зависеть от того, насколько удачно сотрудник сформулировал очередной промт.
Система сама получает необходимые данные, формирует контекст и возвращает результат в заданном формате.
Можно управлять тем, какие данные получает модель, какие инструменты ей доступны и какие действия она имеет право выполнять.
Также можно выбирать разные модели под разные операции, управлять объёмом контекста, количеством запросов, повторными попытками и резервными сценариями.
Ограничения существуют у любых AI-моделей и API. Разница в том, что при собственной интеграции ими можно управлять на уровне архитектуры, а не подстраивать бизнес-процесс под ограничения пользовательского чата.
Фраза «ИИ вроде бы работает хорошо» для коммерческой системы ничего не значит.
Нужны показатели.
Если система классифицирует обращения, можно считать точность классификации и долю спорных случаев.
Если извлекает данные из документов — процент правильно обработанных полей.
Если отвечает сотрудникам — долю успешных ответов и количество ситуаций, когда понадобилось участие человека.
Результаты можно сохранять, сравнивать и оценивать на реальных данных.
После запуска работа не заканчивается.
Если качество снизилось или появились ошибки, можно определить причину: данные, контекст, промт, бизнес-логика, модель или сам сценарий.
После изменений систему снова проверяем по тем же критериям.
Запуск → измерение → анализ ошибок → улучшение → повторная оценка
Так AI-функция постепенно превращается из эксперимента в стабильную часть бизнес-процесса.
AI-модель — только один компонент решения.
Упрощённо архитектура выглядит так:
CRM / 1С / ERP / данные → API / MCP / интеграционный слой → AI → проверка → действие
Для подключения используем подходящий механизм.
API — прямой обмен данными и командами между AI-системой и CRM, 1С, ERP, сайтом, приложением или другим сервисом.
MCP — стандартизированный способ предоставить AI разрешённые данные, функции и инструменты.
Webhooks — запуск AI-сценария при определённом событии.
Базы данных — контролируемая работа с необходимой информацией.
Интеграционный backend — собственный слой для бизнес-логики, сложных сценариев и связи нескольких систем.
Если готового API или MCP нет, рассматриваем доступные интерфейсы, коннекторы, базы данных, файловый обмен или разработку промежуточного слоя.
Не нужно перестраивать всю инфраструктуру ради нейросети. Архитектура должна встраиваться в существующий IT-контур компании.
Принцип простой: AI получает не максимальный, а минимально необходимый доступ для выполнения конкретной задачи.
Можно настроить:
Если автоматическое действие несёт высокий риск, ИИ может только подготовить решение, а подтверждение останется за сотрудником.
шаг 1.
Определяем, где находятся необходимые данные, какие системы участвуют в процессе и какие способы подключения доступны.
шаг 2.
Фиксируем, что должен делать ИИ, какие данные ему нужны, какой результат считается правильным и куда этот результат должен попасть.
шаг 3.
Определяем API / MCP-интеграции, модель, права доступа, бизнес-логику, обработку ошибок и критерии качества.
шаг 4.
Подключаем системы и запускаем сценарий на реальных данных.
шаг 5.
Проверяем стабильность, качество, ошибки и количество случаев, в которых понадобилось вмешательство человека.
шаг 6.
Корректируем данные, контекст, промты, модели и бизнес-логику.
Если сценарий показывает стабильный результат — подключаем дополнительные функции и системы.
Не нужно начинать с попытки подключить к ИИ всю компанию.
Один процесс → одна система → один измеримый результат.
Если он работает — расширяем.
Покажите существующий процесс или IT-контур.
Разберём, какие данные можно использовать, где имеет смысл подключить AI и нужна ли интеграция вообще.
Если задачу рациональнее решить без искусственного интеллекта — это тоже должно стать понятно до начала разработки.
Интеграционный слой часто становится фундаментом для более сложных AI-решений.
Получают доступ к разрешённым данным и инструментам компании через API / MCP и могут выполнять последовательности действий.
Связывает модели, события, бизнес-логику и существующие системы в единый автоматический процесс.
Даёт ИИ доступ к корпоративным документам, базе знаний и другим внутренним источникам.
Извлекает и проверяет данные из документов, после чего передаёт результат в CRM, ERP, 1С или другую систему.
Если требуется не отдельная интеграция, а комплексное внедрение ИИ в бизнес, проектируем весь AI-контур: данные, модели, интеграции, интерфейсы, контроль качества и дальнейшую эксплуатацию.
Да, если система позволяет получать и передавать необходимые данные.
Конкретный вариант зависит от используемой платформы и доступных механизмов: API, MCP, webhooks, базы данных, коннекторы или собственный интеграционный слой.
Для закрытых и legacy-систем сначала проверяем технические возможности.
Обычно нет.
Смысл интеграции искусственного интеллекта как раз в том, чтобы добавить AI-функции в существующий рабочий контур, а не заменять всю инфраструктуру компании.
Проверяем другие способы обмена данными: webhooks, базы данных, готовые коннекторы, выгрузки, файловый обмен или возможность разработать собственный интеграционный backend.
Техническую возможность оцениваем до начала разработки.
Да.
Для разных функций можно использовать разные модели и провайдеров — российские или зарубежные, если это соответствует требованиям проекта.
При необходимости архитектуру можно строить так, чтобы критичный бизнес-процесс не зависел от одной модели или одного AI-сервиса.
Это зависит от выбранной архитектуры, моделей и требований компании.
Отдельно определяем, какие данные допустимо передавать внешнему AI-провайдеру, какие должны оставаться внутри корпоративного контура и какие ограничения доступа необходимы.
Да, если это предусмотрено архитектурой и допустимо по уровню риска.
Для критичных операций можно оставить обязательное подтверждение человеком или разрешить AI только подготовку данных и рекомендаций.
До запуска определяем измеримые критерии: точность, процент успешных операций, количество ошибок, стабильность результата и долю случаев, в которых требуется участие человека.
После запуска показатели отслеживаются, а система развивается по результатам реальной эксплуатации.