Итоги 2025 для российского ИТ: от скорости к экономике

Замедление после бурного роста, смещение фокуса на отказоустойчивость и стоимость владения.

Что произошло

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

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

Одновременно накопился опыт эксплуатации первой волны замен. Часть из них оказалась дороже замещённых систем, часть — менее надёжной, часть невозможно развивать, потому что подрядчик ушёл, а документации не осталось. Этот опыт — не статистика, а конкретные истории, которые ходят по рынку и формируют новые критерии выбора. Заказчик научился спрашивать не «отечественное ли это», а «сколько это будет стоить в год и кто это будет поддерживать».

Пять сдвигов, которые определили год

От темпов к экономике владения

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

Стоимость владения складывается из шести статей, и в 2025 году заказчики начали запрашивать их по отдельности:

Статья	Что в неё входит	Почему её раньше не считали
Лицензии и подписки	Стоимость права использования, включая рост при масштабировании	Считали, но только на первый год
Внедрение	Работы подрядчика, миграция данных, интеграции	Считали, но без доработок, которые выяснились позже
Инфраструктура	Серверы, хранение, сеть, резервирование, для ИИ — GPU	Относили на другой бюджет
Поддержка	Вендорская и подрядческая, SLA, обновления	Принимали за фиксированную, хотя она растёт
Люди	Внутренняя команда эксплуатации, обучение пользователей	Не считали вовсе
Следующая миграция	Стоимость выхода из решения, если вендор исчезнет или продукт перестанет развиваться	Не считали, потому что выбор казался окончательным

Последняя строка — самая недооценённая. Продукт, из которого нельзя выйти без переписывания всего вокруг, стоит дороже, чем показывает его ценник, и в 2025 году заказчики начали это учитывать при выборе.

От пилотов к закрытому контуру

В 2023–2024 годах ИИ-инициативы жили на внешних сервисах: быстро, дёшево, без инфраструктуры. В 2025 году они столкнулись с двумя ограничениями. Первое — регуляторное: данные, на которых нужно работать, не могут покидать контур. Второе — экономическое: стоимость пилота на внешнем API не имеет ничего общего со стоимостью промышленной эксплуатации, где к каждому запросу добавляется проверка, журналирование, резервирование и люди.

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

От вендорского стека к открытому

Первая волна замен часто копировала логику замещаемого: вместо одного закрытого вендора — другой закрытый вендор, только из реестра. В 2025 году заказчики стали предпочитать открытые основания: PostgreSQL как СУБД, Kubernetes как среда исполнения, Kafka как шина, модели с открытыми весами как основа ИИ-функций. Российские продукты в этой картине занимают место слоя поддержки, сертификации и дополнительных возможностей поверх открытого ядра.

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

Изменение критериев выбора подрядчика

Вместе с критериями выбора продуктов изменились критерии выбора исполнителей. Раньше решали присутствие в реестре, цена и обещанный срок. Теперь заказчики спрашивают о другом.

Заменяемость. Сможет ли другая команда продолжить работу, если эта уйдёт? Ответ проверяется по документации, по структуре кода, по тому, используются ли стандартные технологии или собственные наработки подрядчика.

Документация и передача знаний. Не как приложение к акту, а как результат работ, который проверяется отдельно. Заказчики начали включать в договор обучение своей команды и период совместной эксплуатации.

Права на код и данные. Условие, которое раньше считалось формальностью, стало предметом переговоров: заказчик хочет владеть результатом, а не арендовать его.

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

Дефицит инженеров как главный ограничитель

Все четыре сдвига упираются в один ресурс. Открытый стек требует инженеров по PostgreSQL и Kubernetes. Закрытый контур требует инженеров, умеющих держать модели в проде. Заменяемость подрядчика имеет смысл только при наличии тех, кем его можно заменить. Экономика владения требует внутренней команды эксплуатации.

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

Рынок перестал платить за замену. Он платит за систему, которую можно эксплуатировать, развивать и при необходимости заменить — своими силами или силами другого подрядчика.

Как это выглядит на практике

Производственный холдинг, замена учётной системы. В 2023 году конкурс решился бы по реестру и цене внедрения. В 2025 году заказчик запросил у участников расчёт стоимости владения на пять лет с разбивкой по статьям, описание целевой архитектуры и перечень стандартных технологий в основе. Выбран был не самый дешёвый на внедрении, а тот, чья оценка эксплуатации была прозрачной и чей стек позволял заказчику нанять собственных инженеров.

Банк из первой сотни, перенос ИИ-пилотов в контур. Шесть сценариев, отработанных на внешних сервисах, планировалось перенести в закрытый контур одним проектом. Расчёт стоимости эксплуатации — GPU, резервирование, люди, проверка результатов — показал, что четыре сценария из шести в контуре не окупаются. Перенесены два, остальные закрыты с сохранением наработок. Решение приняли за квартал, а не после года эксплуатации.

Розничная сеть, уход подрядчика. Система, внедрённая в первую волну, осталась без поддержки: подрядчик прекратил деятельность, документации не было, код содержал собственные библиотеки исполнителя. Новая команда потратила квартал на восстановление логики, прежде чем смогла вносить изменения. С тех пор в договорах сети появились требования к документации как к отдельному результату, к использованию стандартных технологий и к периоду передачи знаний.

Что это значит для российской компании

Регуляторика продолжает создавать спрос, но не бюджет. Срок перехода значимых объектов КИИ на отечественные решения — 1 января 2028 года — обязателен, но обязательность не отменяет экономику. Проект, который необходим по закону, всё равно должен быть спланирован по стоимости владения, иначе он превратится в источник постоянных расходов после дедлайна.

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

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

Отечественный стек — это не продукт, а способ его эксплуатировать. Российский рынок предлагает решения на открытом ядре с собственным слоем поддержки. Выбор между ними — это выбор того, кто и как будет сопровождать систему, а не того, чьё название в реестре.

Что делать: пошагово

Пересчитайте портфель ИТ-проектов по стоимости владения. Для каждого действующего и планируемого проекта — шесть статей из таблицы выше на горизонте нескольких лет. Проекты, где расчёт невозможен, — первые кандидаты на пересмотр.
Разделите обязательное и целесообразное. Что нужно сделать по регуляторным требованиям к сроку, а что — по экономике. Обязательное планируется от дедлайна назад, целесообразное — от окупаемости.
Сформулируйте целевую архитектуру. Какие открытые основания — СУБД, среда исполнения, шина, модели — составляют ядро, какие российские продукты работают поверх него, где допустимы проприетарные решения и почему.
Измените критерии выбора подрядчиков. В конкурсную документацию — требования к документации, стандартным технологиям, передаче знаний, правам на код и данные, фиксации состава команды.
Спланируйте внутренние компетенции. Какие роли нужны для эксплуатации целевой архитектуры, кого нанимать, кого обучать, где допустима внешняя поддержка. План по людям — с той же детализацией, что план по системам.
Проведите ревизию ИИ-инициатив. Каждый пилот — либо переносится в контур с расчётом эксплуатации и ответственным за результат, либо закрывается с сохранением наработок.
Введите отчётность по стоимости владения. Регулярный управленческий отчёт по каждой значимой системе: сколько стоит в год, что в этом растёт, когда следующая миграция. Без этой цифры решения снова будут приниматься по впечатлению.

Типичные ошибки

Выбор по реестру. Почему: присутствие в реестре — регуляторное условие, а не критерий качества и не гарантия существования вендора через три года. Что вместо: реестр как фильтр, стоимость владения и заменяемость как критерии.
Оценка проекта по стоимости внедрения. Почему: внедрение — меньшая часть затрат на горизонте эксплуатации. Что вместо: расчёт по шести статьям с обязательной строкой стоимости выхода.
Перенос пилота в контур как есть. Почему: экономика контура принципиально иная, часть сценариев в ней не окупается. Что вместо: пересчёт каждого сценария до переноса, готовность закрыть часть.
Ставка на подрядчика без внутренней команды. Почему: зависимость от единственного исполнителя воспроизводит вендорскую зависимость. Что вместо: собственная команда эксплуатации, подрядчик — для развития и пиковых нагрузок.
Закрытый продукт вместо закрытого вендора. Почему: замена одной зависимости на другую не снижает риск следующей миграции. Что вместо: открытое ядро с российским слоем поддержки.
Документация как приложение к акту. Почему: она либо не пишется, либо пишется формально. Что вместо: документация как отдельный проверяемый результат с приёмкой силами вашей команды.

Как понять, что вы на верном пути

По каждой значимой системе есть расчёт стоимости владения на несколько лет вперёд, и он обновляется.
В конкурсной документации заменяемость подрядчика и передача знаний — обязательные критерии.
Ядро целевой архитектуры — стандартные открытые технологии, и вы можете нанять под них людей на рынке.
У каждой системы есть внутренний владелец, который понимает её устройство и может принять работу подрядчика по существу.
ИИ-инициативы оцениваются по стоимости эксплуатации в контуре, а не по стоимости пилота.
Регуляторно обязательные проекты спланированы от дедлайна назад с запасом на людей.
Права на код и данные принадлежат вам по договору, а не по устной договорённости.

Вопросы, которые нам задают

Открытый стек дешевле проприетарного?

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

Нужно ли создавать внутреннюю команду, если есть надёжный подрядчик?

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

Замедление рынка — это временно?

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

Как обосновать проект, который не обязателен по закону?

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