Привет, Хабр. Меня зовут Виктор Овчинников, я руковожу разработкой интеграционной платформы Digital Q.Integration в компании Диасофт. 

Больше двадцати лет моя команда занимается обменом данными между корпоративными системами. Все эти годы интеграция оставалась скучной технической прослойкой, которую в бюджетах по привычке записывали в строку «поддержка». В 2026 году ситуация изменилась, и не потому, что шины вдруг стали красивее или модными, а потому, что ИИ‑проекты начали массово застревать именно в интеграционном слое. В этой статье разберу, почему так происходит, какие архитектурные подходы ломаются первыми на ИИ‑нагрузке и что мы в Диасофт выбрали в качестве рабочего варианта. Будет кейс крупного банка, три грани, на которых интеграция включает или выключает всю ИИ‑стратегию, и честный ответ, когда интеграционная платформа вам не нужна.

Главный тормоз корпоративных ИИ‑проектов в 2026 году это не выбор модели, не мощности GPU и не цена за токены. Это банальный обмен данными между корпоративными системами. В апрельском исследовании Integrate.io 95% ИТ‑директоров назвали проблемы интеграции главным барьером внедрения ИИ. Отчет Anthropic State of AI Agents 2026 фиксирует ту же картину с другого угла: среди инженеров, которые уже строят агентные системы на продакшене, 46% называют интеграцию с существующими корпоративными системами главным техническим вызовом — она обошла и вопросы безопасности, и надежность самих моделей.

Почему это стало горячей темой именно сейчас

В 2024-м ИИ‑проекты запускались точечно. Команда берет один датасет, один процесс, обучает модель, показывает pilot demo, получает премии. Интеграция в таком сценарии даже не упоминается в техническом задании: данные выгружаются в CSV раз в сутки, модель живет в отдельном контуре, все счастливы.

В 2025-м начался переход от точечных кейсов к агентам и мульти‑модельным архитектурам. Агент, в отличие от чат‑бота, должен читать и писать в корпоративные системы, а их у среднего российского банка сто с лишним, у промышленного холдинга иногда больше трехсот. Ему нужен доступ в реальном времени, с гарантированной доставкой, с контролем прав и со сквозной трассировкой. Протокол MCP (Model Context Protocol), появившийся в конце 2024-го, сделал LLM полноценным интеграционным узлом. Следом подтянулись A2A‑протоколы, которые завязывают несколько агентов в один рабочий процесс.

И тут выяснилось, что корпоративный ИТ‑ландшафт к этой новой жизни не готов. Пока все спорили о выборе модели и тонкостях промптинга, бутылочное горлышко сидело уровнем ниже, в слое, на который годами смотрели по остаточному принципу. Локальный чат‑бот на одном хорошо подготовленном датасете работает. Агент, которому нужно собрать контекст из CRM, биллинга, хранилища документов и пары внешних API, ломается на первом же шаге, еще до того, как запрос дойдет до LLM. А пилоты, о которых с гордостью отчитывались на советах директоров, массово застревают в песочнице: Gartner прогнозирует, что к концу 2026-го половина всех агентных ИИ‑инициатив до промышленной эксплуатации не доживет. И не потому, что где‑то закончились идеи, а потому, что данные не добрались до моделей.

Что ИИ‑агент требует от интеграционного слоя

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

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

Второе требование — семантическая нормализация. У агента нет времени и ресурсов разбираться, что в CRM клиент хранится под ID одного формата, в биллинге под другим, а в скоринговой системе под третьим. Интеграционный слой должен приводить данные к единому виду заранее, до того, как они попадут в контекст модели. Иначе агент будет галлюцинировать не от слабости LLM, а от того, что ему скормили три разные версии одной и той же сущности.

Третье требование — двусторонность. Агент должен не только читать, но и писать в системы: менять статусы, резервировать остатки, создавать заявки. И делать это под аудитом, с контролем прав и с возможностью откатить изменение, если что‑то пошло не так. Интеграции, исторически построенные как «выгрузка раз в сутки», такой сценарий даже обсуждать не умеют.

Четвертое, и самое неочевидное, — гарантированная доставка для автономных процессов. Когда агент работает без человека в контуре, у вас нет менеджера, который заметит, что сообщение не дошло, и перезапустит процесс вручную. Либо интеграционный слой сам обеспечивает гарантии at‑least‑once или exactly‑once, либо цепочка молча рвется, и вы узнаете о проблеме из жалобы клиента через три дня.

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

Три подхода к интеграции, и почему каждый спотыкается на ИИ

Самый старый и самый очевидный способ связать системы между собой — точечные каналы по принципу «точка‑точка». Между каждой парой систем создается прямой интерфейс. Пока систем в ландшафте мало, все хорошо: легко понять, кто с кем общается, быстро починить, быстро добавить новую связь. Проблема в том, что количество каналов растет как квадрат от количества систем. На десяти системах их может быть до сорока пяти, на пятидесяти — уже за тысячу. Для ИИ‑агента, которому регулярно нужен контекст из десятка‑другого систем, это означает десятки отдельных коннекторов со своими форматами и своей авторизацией, и каждый из них надо трогать при любом обновлении модели или добавлении нового сценария.

На рубеже нулевых появилась Enterprise Service Bus, классическая шина. Идея красивая: поставить в центр посредника, через которого все системы общаются друг с другом, и взвалить на него маршрутизацию, трансформацию форматов и гарантию доставки. Тогда же расцвели крупные вендоры: IBM WebSphere Message Broker, Tibco ActiveMatrix, Oracle Service Bus, Mule, WSO2. К середине 2010-х стало понятно, что у классической ESB есть свои, уже собственные грабли. Ядро получилось монолитным, и изменение одного маршрута требует деплоя всей шины. Нагрузка централизована, и шина превращается в единую точку отказа для всего ландшафта. На ИИ‑сценариях добавляются еще два неприятных эффекта. Монолитное ядро плохо переваривает потоковые данные с низкой задержкой, которые нужны агентам: модель ждет ответа секундами вместо миллисекунд, и пользователь уходит раньше, чем получает персонализированное предложение. А проприетарный DSL, в котором описаны интеграционные потоки, не дает подключить LLM как стандартный узел: коннектор приходится писать под конкретный вендор, а при смене модели переписывать заново.

После 2022-го к этому добавилась отдельная российская проблема. Tibco, Mule, WSO2, IBM MQ либо ушли с рынка, либо перестали поставляться и нормально поддерживаться. Указ Президента № 309 от мая 2024 года зафиксировал для субъектов КИИ конкретный срок замены иностранных интеграционных решений, а Приказ Минцифры № 21 с 2025 года и вовсе прекратил закупки зарубежного ПО. Для многих банков и промышленных холдингов это означало простую вводную: интеграционный слой надо переписать или мигрировать за 12–18 месяцев, причем силами команд, у которых весь опыт наработан именно в экосистеме ушедшего вендора. А поверх этой миграции еще и ИИ‑стратегию запустить.

Параллельно в мире набирал популярность API‑first подход. Каждый сервис выставляет наружу REST или gRPC API, все общаются через API‑gateway без посредников. Для ландшафтов, собранных с нуля, это работает. Для legacy с core‑банкингом на COBOL и десятком самописных систем без документации вариант не работает вовсе. А для ИИ‑сценариев есть отдельная проблема: если каждый агент должен знать, как устроены все системы и как к ним авторизоваться, это не масштабируется. Десять агентов на сотне систем — это тысяча точек интеграции, которые надо поддерживать на стороне агентов. Роль оркестратора, от которого API‑first пытался отказаться, в итоге возвращается с черного хода.

Отдельная история это event‑driven стек на Apache Kafka. Для высоконагруженных сценариев он стал стандартом де‑факто: события публикуются в топики, подписчики их читают, производительность уходит далеко за пределы классической шины. Но Kafka транспорт, а не интеграционная платформа. Она не решает задач трансформации данных, контроля бизнес‑правил, маппинга семантики. Агенту нужны не сырые события, а нормализованные сущности с бизнес‑смыслом, и этот слой Kafka не дает.

Умные сервисы и надежные каналы

Когда мы в Диасофт проектировали Digital Q.Integration, решили отказаться и от идеи монолитной центральной шины, и от чистого API‑first. Подход, который в итоге получился, команда называет «умные сервисы и надежные каналы», и он был изначально заточен под сценарии, где в интеграционном ландшафте живут не только люди и системы, но и автономные агенты.

Вместо одного большого ядра для каждой интегрируемой системы создается отдельный микросервис‑коннектор. Вся логика взаимодействия именно с этой системой — протокол, формат, маппинг полей, обработка ошибок и ретраи, бизнес‑правила преобразования данных — живет внутри ее собственного коннектора. Сами коннекторы общаются между собой через гарантированный транспорт с единым реестром всех проходящих сообщений, сквозным мониторингом и встроенным механизмом сверки данных между системами.

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

Главное отличие для ML‑команды в том, что данные приходят в модель в подготовленном виде, в реальном времени, с нужной семантикой. ETL‑пайплайн под каждую модель отдельно строить не приходится, он уже работает на уровне интеграционной платформы. А сама LLM подключается к ландшафту как обычный адаптер: локальная модель или внешняя через MCP — это просто еще один сервис, к которому другие системы обращаются за ответом или которому передают свои события на обработку.

В рейтинге ESB‑решений CNews за 2025 год платформа заняла первое место. В марте 2026-го Диасофт выложил бесплатный дистрибутив Digital Q.Integration с ограничением в 5–10 интеграционных потоков на одном микросервисе. Его можно скачать без бюрократии и демостендов, поставить на свою виртуальную машину и за пару часов понять, подходит подход или нет.

Три грани, на которых интеграция включает или выключает ИИ

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

Первая роль — экосистемная. ИИ‑стратегия в 2026 году это не только собственные модели, которые крутятся внутри периметра. Это еще и внешние специализированные сервисы: отраслевые модели скоринга, провайдеры генеративного видео, маркетплейсы агентов, внешние инструменты анализа неструктурированных данных. Подключение каждого такого сервиса через точечную интеграцию занимает месяцы. Через стандартный адаптерный слой — недели или дни. Если у вас амбициозная ИИ‑стратегия, но интеграционный контур сделан в логике десятилетней давности, вы физически не сможете собрать эту стратегию из внешних кирпичиков достаточно быстро, чтобы успеть за рынком.

Вторая роль — ускорение продуктов. Внутри компании платформа интеграции работает как каталог сервисов. Продуктовая команда, которая хочет выкатить новую ИИ‑функцию в мобильное приложение, не заказывает разработку с нуля. В каталоге уже лежат сервис проверки клиента, сервис расчета стоимости, сервис персонализации предложения — каждый из них закрыт собственным адаптером с известным интерфейсом. Продукт собирается из готовых блоков, и цикл «от идеи до релиза» схлопывается с кварталов до недель. На рынке, где конкурент с нормальной платформой выкатывает новый ИИ‑продукт за месяц, команды без такого каталога просто не успевают.

Третья роль — фундамент для данных. И это та самая роль, вокруг которой рушатся пилоты у большинства компаний. Главный барьер внедрения ИИ сегодня не отсутствие алгоритмов и не дефицит GPU — это разрозненность данных, которые заперты в legacy‑системах в разных форматах, с разным качеством, с разной свежестью. Интеграционная платформа решает именно эту задачу: собирает события со всех систем, нормализует, сверяет и подает на вход моделям в реальном времени. Без этого слоя инвестиции в ИИ оборачиваются точечными экспериментами, которые в принципе нельзя масштабировать на уровень предприятия, сколько бы моделей вы ни закупили.

Отсюда следует прикладной вывод для ИТ‑директора. Когда вы следующий раз будете защищать бюджет на ИИ‑трансформацию, первым слайдом должна идти не ведомость по лицензиям на LLM, а схема вашего интеграционного слоя с честной оценкой: готов ли он отдавать данные в нужном виде, с нужной задержкой и с нужными гарантиями. Если ответа «да» у вас пока нет, начинать надо не с закупки моделей, а с наведения порядка в связях между системами. Иначе эти модели будут очень дорогими витринами, которые никто не сможет наполнить живыми данными.

Розничный банк: как интеграция разблокировала ИИ‑продукты

Поделюсь опытом внедрения Digital Q.Integration в крупном розничном банке. Цифры обобщены по нескольким проектам, но механика типовая для российского банкинга, и любой архитектор из отрасли ее узнает.

Банк хотел запустить то, что на рынке обобщенно называют гипер‑персонализацией: предложения в реальном времени, скоринг второго уровня с использованием ML‑моделей, динамическое ценообразование партнерских продуктов. Все это требовало собирать контекст клиента из пяти‑шести систем и отдавать моделям с задержкой в доли секунды.

Исходный ландшафт у банка выглядел так. Core‑банкинг на импортной АБС, кредитный конвейер собственной разработки, CRM, фронт‑офис мобильного банка, веб‑канал, риск‑система, хранилище документов. Между ними за десять с лишним лет накопилось около сорока точечных интеграций, написанных разными командами в разное время и на разных технологиях. Половина крутилась на SOAP, четверть на REST, остальное ходило через кастомные транспорты и файловый обмен по расписанию. Документация местами отсутствовала вовсе, а ответственных за часть legacy‑коннекторов внутри банка было уже не найти. ML‑команда дважды пыталась запустить персонализацию, и оба раза проект останавливался на этапе подготовки данных: модель ждала ответов из трех систем по сорок минут, а клиент за это время успевал закрыть приложение и уйти к конкурентам.

Запуск нового партнерского кредитного продукта с внешним агрегатором, который должен был стать флагманом персонализации, требовал собрать данные из CRM (профиль клиента), кредитного конвейера (скоринг), ядра (лимиты и остатки), риск‑системы (правила отсечения) и передать результат в канал партнера вместе с результатом работы ML‑модели. Для каждой из пяти систем приходилось писать отдельный коннектор, согласовывать форматы, отдельно проходить проверку безопасников. Средний Time‑to‑Market доходил до пяти‑шести месяцев. А ИИ‑модель, ради которой все это затевалось, так и не получила нужных данных.

Переход на Digital Q.Integration занял полгода. Параллельно шли три потока работ: создание адаптеров для каждой из систем банка, перенос существующих интеграционных потоков на новую платформу без остановки продакшена (здесь работали в режиме strangler fig — новые сценарии через новую платформу, старые постепенно мигрировали) и внедрение реестра сообщений со сквозным мониторингом.

После перехода запуск нового партнерского продукта, от постановки задачи до релиза в проде, сократился до трех‑четырех недель. Цифра не волшебная, а объяснимая: адаптеры к пяти системам уже готовы, маршрутизация настраивается в low‑code редакторе, тестирование идет на реестре реальных сообщений без подключения прод‑систем. Затраты на поддержку интеграционного слоя упали на 40% — экономия набралась из отказа от уникальной разработки под каждого нового партнера, унификации протоколов на стороне адаптеров и автоматического контроля доставки вместо ручного разбора падений.

Но самым важным для бизнеса оказалось то, ради чего все затевалось. Данные стали доступны для ML‑моделей в реальном времени, и банк наконец‑то запустил скоринг второго уровня и персонализацию предложений прямо в момент общения с клиентом. Модель получала свежий контекст за сотни миллисекунд, успевала пересчитать ставку и вернуть персональное предложение до того, как пользователь пролистнет экран. Конверсия выросла, просрочка на выданных продуктах снизилась. Проект, который два года буксовал на уровне «не дошли данные», наконец‑то зажил в проде. Именно интеграция разблокировала ИИ, а не наоборот.

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

Когда интеграционная платформа вам не нужна

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

Самый очевидный случай, когда платформа не нужна, это небольшой ландшафт, в котором всего три‑пять систем, у всех современные API, нагрузка низкая, и серьезных ИИ‑амбиций тоже нет. Прямые вызовы через обычный API‑gateway в такой ситуации дешевле и в разработке, и в поддержке, а интеграционная платформа превращается в пушку по воробьям. Похожая логика работает там, где все ключевые системы уже живут в одной экосистеме одного вендора. Нативные интеграции внутри платформы Диасофт, 1С или SAP (до его ухода с российского рынка) работают без отдельной шины, и добавление еще одного слоя сверху значит платить за одну и ту же работу дважды.

Отдельная ситуация это новый продукт, который строится с чистого листа, без какого‑либо legacy. Начинать в этом случае стоит с event‑driven архитектуры на Kafka и API Gateway. К полноценной интеграционной платформе имеет смысл приходить позже, когда ландшафт вырастет до пятнадцати‑двадцати самостоятельных сервисов, или когда в контур зайдут серьезные ИИ‑сценарии с требованиями к семантике и real‑time. Раньше — это преждевременная оптимизация, за которую потом платят техдолгом.

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

Мой практический критерий звучит так. Если в ИТ‑ландшафте пятнадцать и больше самостоятельных систем, у вас есть реальные планы по ИИ‑сценариям с обращением к нескольким системам в real‑time, и хотя бы у трех источников данных нет современных API, единый интеграционный слой окупается за 12–18 месяцев. При меньшем размере ландшафта или при отсутствии ИИ‑нагрузки стоит подумать дважды и посчитать TCO на горизонте нескольких лет, не пропуская расходов на людей.

Что остается в сухом остатке

Когда спросят, почему ИИ‑стратегия уехала вправо по срокам, ответ с высокой вероятностью окажется не про выбор модели и не про мощности GPU. Он будет про то, что данные не доехали до модели в нужное время и в нужном формате, а корпоративный ландшафт никто заранее не готовил к тому, что в нем заведутся автономные агенты, которым разом нужен real‑time доступ к полутора десяткам разных систем.

Интеграция перестала быть расходной статьей на поддержку. В 2026 году это либо драйвер ИИ‑стратегии, либо ее главный тормоз — среднего не осталось. Инвестиции в LLM без инвестиций в интеграционный слой это оплата билета на поезд, на который вы не сможете сесть, потому что вокзала еще не построили.

А как с интеграцией у вас в компании в свете ИИ‑проектов? В комментариях интересны не лозунги, а цифры: сколько систем в ландшафте, какой процент связан через единый слой, сколько времени занимает подключение новой системы или ИИ‑сервиса. Где ломается, там и тема для следующего разбора.