ИИ-пилоты буксуют не из-за модели, главный тормоз — интеграция

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

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