Пленарную дискуссию вел Юрий Семенюков, директор центра инфраструктурных решений «Инфосистемы Джет». На сцене представители крупного бизнеса — Алексей Шкирмановский, технический директор «ВсеИнструменты»; Константин Коваленко, Manager Technology & Platforms, Infrastructure, Philip Morris Russia; Артем Ерофеев, начальник отдела системной архитектуры ОТП Банка, а также Денис Кривенцев, заместитель директора по инфраструктуре компании АЛРОСА.

Модератор начал с описания привычного мира, в котором большинство корпоративных ИТ-служб прожили последние полтора десятилетия: метрокластер, standby, аппаратная репликация СХД. «Был определенный набор технологических стандартов, которые все хорошо знали и умели применять», — напомнил Семенюков. Вопрос «Как разворачивать инфраструктуру под новую систему?» долгие годы не был вопросом вовсе: метрокластер уже есть — расширяем, со standby работать умеем — делаем такой же. «Но пока мы этим занимались, ИТ-индустрия ушла далеко вперед», — констатировал он. С 2010 года начали появляться контейнеры, к 2015-му Kubernetes всерьез замаячил в продуктиве, а к 2020-му стало ясно, что container-first (подход, ориентированный на контейнеры) — одна из основных парадигм разработки. «Это уже далеко не монолиты с одним инстансом базы данных и одним инстансом приложения», — описал модератор современный ландшафт: микросервисные, горизонтально распределенные, слабосвязанные модули с большим количеством middleware и open source.

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

Смена парадигмы, а не замена компонента

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

Второе наблюдение куда важнее для распределения ответственности внутри компаний. Если раньше за то, что бизнес-сервис работает и восстанавливается после сбоя, отвечала именно инфраструктурная часть, то сегодня эта зона ответственности размывается. Приложение само должно быть разработано в логике геораспределенности и нескольких зон доступности: если одна зона отвалилась, именно приложение обеспечивает консистентность и перенос данных в другой ЦОД. Для CIO это означает, что «непрерывность» перестает быть строчкой в бюджете ИТ-департамента и становится требованием к архитектуре продукта.

ИИ, который смотрит в дашборды вместо человека

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

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

Между прошлым и будущим: точка перехода

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

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

Как правильно оценивать работу оборудования в эпоху ИИ

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

Долгое время обслуживание развивалось по цепочке: от планового регламентного сервиса через реактивное устранение аварий к предиктивному анализу. Как рассказал Владимир Манихин, руководитель группы комплексного обслуживания и эксплуатации инженерных систем компании «Инфосистемы Джет», сегодня этого уровня недостаточно, поэтому на первый план выходит риск-ориентированное техническое обслуживание, которое оценивает не просто состояние отдельного датчика или насоса, а совокупный финансовый ущерб и приоритеты бизнеса.

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

В этих условиях инженерная система перестает быть фоновым поддерживающим сервисом и превращается в равноправный элемент вычислений: потеря охлаждающей способности мгновенно влечет за собой падение вычислительной мощности графических ускорителей. При этом окно реакции инженерной службы катастрофически сокращается. Если при отказе вентиляции в воздушном дата-центре запас времени составляет три или четыре часа, то в контурах прямого жидкостного охлаждения критический перегрев наступает за 10-20 минут. Это подтверждается реальными инцидентами, когда остановка охлаждения приводила к скачку температуры с 21 до 51 °C за полчаса, а отдельные компоненты разогревались выше 120 градусов.

Бизнес-контекст и реальная стоимость отказа

По словам эксперта, одинаковая вероятность поломки одной и той же детали несет абсолютно разную угрозу в зависимости от операционного контекста. При наличии схемы резервирования, умеренной загрузке процессоров, доступном окне обслуживания и наличии детали на складе ущерб от сбоя минимален и сводится к базовым затратам на плановую замену. Если же этот узел обслуживает графические процессоры, загруженные на полную мощность, резерв отсутствует, технологических окон нет, а срок поставки запчасти составляет двенадцать недель, потенциальные потери бизнеса вырастают в десятки раз. Стоимость сбоя в ИИ-ЦОД складывается не из цены сломанного насоса или клапана, а из аварийных работ, срочной логистики, каскадных отключений, неустоек по сервисным соглашениям и многомиллионных потерь от простоя вычислений. По данным индустриальных отчетов, крупный сбой в современном ЦОД все чаще обходится компаниям в миллионы долларов, а сутки простоя гигаваттного дата-центра экстремального масштаба оцениваются более чем в 100 миллионов долларов.

Что делать: архитектура риск-ориентированного управления и безопасность

Для перехода к управлению техническими рисками не требуется тотальная установка новых датчиков, поскольку ключевые данные уже присутствуют в существующих системах управления зданием, программируемых контроллерах, системах учета оборудования и корпоративных ERP. Архитектура решения собирает телеметрию, накладывает ее на схему топологии и резервирования, сопоставляет текущую нагрузку на стойки с обязательствами перед заказчиками и рассчитывает динамический риск каждого узла в реальном выражении.

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

Эксперт предложил свою прикладную модель эксплуатации AI-ЦОД, которая позволяет объединить вероятность отказа, текущую топологию и резервирование, загрузку, бизнес-последствия, стоимость вмешательства и риск самого вмешательства, чтобы выбирать действие по критерию максимального снижения финансового риска на вложенный рубль. При оценке любого инцидента модель сравнивает сценарий полного бездействия, сопровождающийся максимальным риском убытков, с несколькими вероятными сценариями действий. Например, алгоритм полного бездействия сравнивается со сценарием оперативного дневного вмешательства и с переносом нагрузки на другой сектор в паре с проведением ночного вмешательства. Любая работа инженеров сама по себе несет определенный операционный риск ошибки, поэтому прямолинейный дневной ремонт оборудования не всегда является оптимальным шагом. Перенос вычислительных задач на альтернативные вычислительные узлы и проведение регламентных работ в ночные часы позволяет радикально снизить риски человеческого фактора при незначительном росте стоимости самих работ, что в итоге обеспечивает максимальную ценность для бизнеса.

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

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

Все новое — хорошо забытое старое

Ключевую идею Александр сформулировал так: без качественной спецификации, без структурированных знаний о проекте любой агент будет просто автоматизировать некий хаос — нужной информации в нем просто не найти.

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

Правило контура в три строки

Самая практичная часть доклада — предельно короткая формула, которая помещается в три строки. Агент пишет в репозиторий спецификаций. Человек решает на гейтах. CI проверяет контракт.

Разворачивается эта формула в понятный маршрут: от потребности к story, затем гейт спецификации, затем гейты архитектуры и merge request, и финальный гейт демо — старт, спека, код, приемка. Человек в этой схеме стоит на четырех гейтах, а без репозитория спецификаций агенты попросту не стартуют. Для бизнес-читателя здесь важна не терминология, а распределение ответственности: ИИ не принимает решений о том, что и зачем делается, — он движется по заранее проложенным рельсам, а точки принятия решений остаются за людьми.

Роли спикер распределил жестко и без романтики. Харнес — это рельсы: скиллы, чек-листы, атомарные задачи, контроль контекста. Агенты (в проекте использовался Cline и исполнители) сами процесса не знают. Модель — это только двигатель: on-prem LLM «умеет в синтаксис», но рельсы не строить умеет. Правда живет в git, а человек утверждает на входе и на выходе.

Модель в периметре — еще не поставка

Отдельный блок Петрушин посвятил развенчиванию популярного заблуждения, особенно распространенного среди тех, кто только начинает импортозамещение ИИ-стека. Свой инференс действительно закрывает контур, но процесс, гейты и обвязку он не заменяет. «Сервер модели не автоматизирует SDLC», — сформулировал спикер. Ollama, vLLM, NIM — это класс систем, это движок; без обвязки он лишь быстрее производит технический долг.

Честный разбор компромиссов on-prem-подхода прозвучал в трех измерениях. Своя модель слабее frontier — и спикер этого не скрывал: Qwen3.6-27B на собственном железе «не прощает пустой чат», и на frontier-модели тот же контур поехал бы легче. При этом цифру разрыва он принципиально не назвал, прямо оговорившись, что A/B-тестирование не проводилось, — редкая для конференций аккуратность в обращении с метриками.

Зато в плюсах — безопасность и надежность: веса, код и спецификации остаются в периметре, нет ни внешней политики провайдера, ни риска остановки SaaS. Для regulated-контура, подчеркнул Петрушин, это не идеология, а условие работы. Третий аргумент — экономика на дистанции: свое железо и свои токены вместо вечной облачной ренты, но с оговоркой, что часть выигрыша съедает наладка обвязки, и это заранее заложено в модель, потому что «бесплатного ИИ» не существует. Общий вывод: харнес все равно придется изготавливать, иначе слабая модель просто быстрее плодит мусор.

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

Чтобы концепция не осталась набором слайдов, спикер перешел к коммерческому проекту, на котором подход и был доказан. Главная цифра прозвучала без пафоса: концепция позволила на треть снизить себестоимость, а вместе с этим сократилось количество людей, привлеченных на проект. Для бизнес-аудитории это, вероятно, самый убедительный аргумент в пользу того, что инвестиции в «скучную» обвязку окупаются быстрее, чем покупка более мощной модели.

Что это значит для заказчика

Рынок вышел из фазы «давайте подключим модель и посмотрим, что получится» и уперся в вопрос инженерной дисциплины. Локальный инференс решает проблему безопасности и суверенности, но не решает проблему качества — качество дает контур: спецификации в git, гейты с человеком в точках принятия решений и CI, который проверяет контракт.

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

Если выступление Александра Петрушина было про то, как ИИ меняет инженерный конвейер, то доклад Александры Царевой, старшего специалиста машинного обучения «Инфосистемы Джет», был про территорию, о которой на конференциях говорят куда реже, — про бухгалтерию, договорную работу, обработку писем и сканов. Название первого блока спикер вынесла почти как манифест: простые задачи ≠ неважные.

Ключевая архитектурная идея доклада: ИИ берет на себя не финальное бизнес-решение, а трудоемкую и монотонную подготовку — распознает, извлекает, классифицирует, нормализует и резюмирует. Схема пути данных выглядит так: на входе сырье — документы и сканы, переписка и вложения; дальше слой OCR и мультимодальных моделей, затем LLM, отвечающая за смысл и сущности; после этого нормализация в пайплайне, валидация и fallback. На выходе — JSON-контракт, аннотация с цитатами, маршрут и статус, которые уходят в корпоративные системы: ERP, CRM, ticketing, 1С.

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

Завершающей сессией второго дня стал круглый стол о железе, собравший на одной сцене тех, кто его производит, и тех, кто его эксплуатирует. Модерировал разговор Константин Рябкин, директор департамента пресейла и контроля поставок «Инфосистемы Джет». Со стороны производителей выступили Олег Марин, руководитель продуктового продвижения и развития группы компаний «Аквариус»; Евгений Лагунцов, руководитель группы технологических решений «Гравитон»; Михаил Михеев, директор по продукту «Серверы стандартной архитектуры» компании YADRO. Со стороны эксплуатации и заказчиков — Александр Власов, руководитель управления исследований и разработки новых решений РТК-ЦОД; Иван Елисеев, руководитель центра компетенций по ИТ-инфраструктуре «Газпромнефть ИТО»; и Максим Ткачев, директор департамента комплексной поддержки «Инфосистемы Джет».

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

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

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

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

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

Что касается предоставления прошивок и патчей для оборудования, то, как отметили эксперты, ответственность за доведение до заказчика обновлений BIOS и BMC, которым раньше занимались глобальные вендоры, во многом перешла к интеграторам. Но, как заметил Ткачев, скорость выпуска патчей мало влияет на скорость их установки: у всех бизнес, который нельзя останавливать, и технологические окна неизвестно когда. Патчи пишут — ставят их немногие.

Комментарии Константина Рябкина и Максима Ткачева

Константин Рябкин отметил зрелость самого разговора: еще недавно рынок обсуждал, чем и как срочно заменить ушедшие бренды, а теперь на одной сцене производители и заказчики спокойно говорят о горизонте в пять-семь лет. Российские процессоры, по его мнению, будут — естественно, не так массово, как Intel и AMD, но в ряде случаев на них уже можно будет строить инфраструктуру. Основную сложность он видит не в кремнии, а в программном обеспечении: нужно «подружить» софт именно с этими процессорами, и это вопрос коллаборации программистов и «железячников». Софт, считает Рябкин, в основном уже есть, потому что многое тестируется; реальный барьер — востребованность перехода, то есть готовность компаний завязать свои процессы так, чтобы поднять их на этих платформах.

Что касается ПАКов, то с позиции интегратора Рябкин честно признает: бизнеса только в их продажах он пока не видит. Для его заказчиков ПАК — скорее базовый кирпичик для построения большой инфраструктуры, который все равно приходится наращивать и донастраивать: по сути та же поставка базового сервера, что и в прежние времена, только с собственной экспертизой и ПО сверху и с «бумажкой» о соответствии, если речь о доверенном комплексе. Совет заказчикам с горизонтом на 2027 год он сформулировал оптимистично: на рынке уже есть игроки с достаточно зрелыми командами, и на проекты стоит смотреть комплексно, планируя инфраструктуру на годы вперед.

Максим Ткачев смотрит на те же сюжеты со стороны эксплуатации, и его акценты заметно другие. Главным критерием для отечественных процессоров он считает не совместимость софта, а доступность — возможность быстро закупить, эксплуатировать и поддерживать: даже полностью совместимая платформа не поедет в продуктив, если ее нельзя оперативно получить, а потом годами обслуживать и добывать запчасти. Ценность ПАКа он, в отличие от Рябкина, видит вполне измеримую, ссылаясь на опыт работы с иностранными комплексами уровня Exadata: главное, что они дают, — уверенность, что следующее обновление протестировано вместе с платформой и характеристики после апдейта как минимум не ухудшатся.

Неотъемлемой частью программы конференции IT Elements являются не только теоретические доклады и дискуссии, но и мастер-классы, на которых участники могут проверить свои знания на практике. Одним из наиболее примечательных стал мастер-класс, посвященный кризисному реагированию на инциденты в сфере информационной безопасности. Его провел Аскар Мусаев, который занимается направлением непрерывности бизнеса в «Инфосистемы Джет».

Отправной точкой Мусаев сделал фреймворк антихрупкости. Его отличие от классических подходов к кибербезопасности спикер сформулировал просто: в него включены процессы business continuity, disaster recovery и кризисного реагирования. Логика понятна — важно не только предотвратить инцидент, но и уметь управлять им, когда он все-таки случился: от первых линий реагирования до масштабного кризисного управления, связанного уже с восстановлением деятельности компании.

Дальше спикер разложил кризисное реагирование на составляющие и показал, где у рынка провал. Тестирование DR-планов и восстановления — понятная для ИТ и ИБ история, о ней много говорили и на самой конференции. Тестирование защищенности — тоже понятная вещь, от классических пентестов до программ bug bounty. А вот кризисное реагирование и принятие управленческих решений — зона, которую тренируют куда реже, хотя именно там решается, сколько будет стоить инцидент.

Как был устроен сценарий

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

Самое показательное событие: что говорить рынку

Ярче всего управленческая природа кризиса проявилась в событии про коммуникации. Вводные были узнаваемыми до неприятного: в сеть утекают скриншоты из внутренних чатов, а в пиар-службу стекаются запросы журналистов.

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

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

Повторное голосование показало главное: «молчуны» практически исчезли. Клиентоцентричная стратегия победила снова — и ее признали вполне рабочей для PR-стратегии при кризисном реагировании.

Разбор: план — это не бумага, а заранее принятые решения

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

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

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