Привет, Хабр. Меня зовут Виктор Овчинников, я руковожу разработкой интеграционной платформы 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 без инвестиций в интеграционный слой это оплата билета на поезд, на который вы не сможете сесть, потому что вокзала еще не построили.
А как с интеграцией у вас в компании в свете ИИ-проектов? В комментариях интересны не лозунги, а цифры: сколько систем в ландшафте, какой процент связан через единый слой, сколько времени занимает подключение новой системы или ИИ-сервиса. Где ломается, там и тема для следующего разбора.