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

Горизонт сжался до трех месяцев

Раньше жизнь ИТ-интеграторов строилась понятно: стратегии заказчиков строятся на три года вперед, август — начало стратегического цикла, где-то в ноябре старт пресейлов, и к марту мы понимали, какой у нас объем контрактов на год. Были бюджеты, были скоупы, были методологии.

Сегодня этой реальности не существует. Бизнес-архитектуры пересматриваются буквально как живой организм. Крупный бизнес перешел на адаптивное бюджетирование: 20–30% фиксируется в начале года, остальное перераспределяется поквартально. Крупные инициативы из серии «давайте изменим существенную часть ИТ-ландшафта нашего крупного бизнеса» и бюджеты в сотни миллионов рублей стали экзотикой. Проекты согласовываются в логике быстрой проверки гипотезы — за три месяца, а не за год.

Для интегратора это означает следующее: классическая модель продажи человеко-часов перестала работать, потому что заказчик больше не готов покупать фиксированный объем работ, который через два месяца может оказаться ненужным. Fixed price, как и модель time & material, постепенно теряет актуальность. Они становятся гораздо более рискованными.

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

ИИ-native или вымирание

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

Я вижу два направления, где это уже работает на практике.

Первое — автоматизация discovery. Сбор требований, бизнес-анализ, описание интеграционных потоков, архитектурное проектирование — все это традиционно занимало огромное количество человеко-часов. LLM-агенты, правильно собранные в цепочку, способны существенно ускорить этот процесс. Люди никуда не уходят — они остаются на валидации — но объем ручного труда резко сокращается.

При этом реальное применение ИИ сегодня выглядит не как полностью автономная система по принципу «попроси и получи готовый продукт». Скорее это похоже на цех, в котором есть станки для разных задач. Аналогично есть набор специализированных AI-инструментов для разных этапов работы. Один агент «слушает» встречи с заказчиком и формирует структурированный бэклог. Другой по описанию процессов рисует схему интеграций. Третий сверяет новые требования с уже написанной архитектурой и сигнализирует о конфликтах. Раньше всю эту связку вручную собирали аналитики и архитекторы, теперь это берут на себя мультиагентные системы — собирается цепочка правильно подготовленных LLM-агентов.

Второе — разработка с использованием ИИ-инструментов. То есть разработчик уже не просто пишет код, а становится инженером, который работает с ИИ-инструментами. Сами инструменты, позволяющие так работать, появились совсем недавно — по сути, в конце прошлого года; до этого это была зона энтузиастов и экспериментаторов. Сейчас это становится массовым: на рынок вышли Copilot-подобные решения, Cursor, Antigravity и другие. Они достигли уровня, при котором ими могут пользоваться не только разработчики, но и условные пользователи без опыта в программировании.

Показательный кейс из практики: крупный ритейлер планировал внедрить таск-трекер для 7 тысяч сотрудников ИТ-подразделения. При расчетах выяснилось, что внедрение одного из популярных решений обойдется почти в 100 млн рублей в год. В итоге команда пошла другим путем: взяли документацию и лучшие практики по ведущим системам управления задачами, пропустили через аналитический LLM-процесс — и за месяц разработали и внедрили собственный инструмент для всей команды.

Это не столько история про экономию, сколько про смену парадигмы: теперь не бизнес подстраивается под SAP, Oracle или Jira — наоборот, он описывает свои процессы и создает решение под них. Именно так сегодня выглядит реальное применение ИИ в крупных компаниях: не в виде чат-ботов на сайте, а как переосмысление самого подхода к разработке и внедрению. Единственный выход — AI-native модель, то есть не просто использование ИИ «поверх» существующих процессов, а их изначальное проектирование с учетом возможностей ИИ.

Главный тормоз — не технологии

При этом рисков и неопределенности во внедрении AI-driven development по-прежнему много: пока это больше похоже на гипотезу, которую активно проверяют и ищут ответ на вопрос, как именно встроить это в практику. Да, код создается быстрее. Но одновременно растут расходы на инфраструктуру, модели и вычислительные ресурсы. Возникают вопросы безопасности, предсказуемости результата и качества сгенерированного кода в enterprise-среде. Но на практике главный барьер сегодня — даже не технологии, а культурный разрыв внутри команд.

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

Это меняет в том числе кадровую логику. Сейчас для ИИ-инженера важно не умение писать код, а архитектурное мышление: понимание того, каким должен быть результат. И здесь возникает болезненный вопрос: переобучать старых специалистов или нанимать новых? Рынок перегрет: middle-разработчик с зарплатными ожиданиями 300 тыс. рублей в месяц — следствие нескольких лет господдержки ИТ и стратегии крупных компаний «пылесосить» рынок. Это породило иллюзию стоимости, которая не всегда подкреплена реальной компетенцией.

Простого решения здесь нет. Нужны стандарты, регламенты, контролируемый доступ к инструментам. Меняется стек инструментов, меняются подходы. PRINCE2, Agile, Scrum, Waterfall, PLM — по сути, все они сломались под новым укладом, и нам нужно заново их переизобретать.

Что будет дальше

Рынок ИТ-интеграции сейчас переживает то, что можно назвать «кратковременной остановкой сердца». Бюджетные циклы сдвинулись, крупные проекты зависли, выручка просела. Крупные игроки почувствовали это сильнее мелких — потому, что у них больше людей, и эти люди дорогие.

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

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

Источник: