90% организаций уже используют внутренние платформы, а 76% держат отдельные платформенные команды, следует из исследования DORA от Google за 2025 год. Но эпоха ИИ быстро меняет правила: платформа, которую строили под людей и контейнеры, теперь должна выдерживать поток машинно сгенерированного кода, GPU-нагрузки и новых пользователей без человеческого лица. Для русскоязычных IT-команд это не абстрактная дискуссия, а проверка на зрелость инфраструктуры.
6 августа эту мысль в партнерской колонке Broadcom жестко сформулировал старший директор компании Панкадж Гупта: спор о том, нужны ли внутренние платформы, закончен; теперь вопрос в том, переживут ли они следующий виток автоматизации. В публикации, как пишет The Register, он исходит из простой вещи: корпоративные платформы последних лет проектировались под разработчика, который сам пишет код, сам гоняет пайплайн и выпускает контейнерное приложение в более-менее предсказуемом темпе. ИИ эту картину ломает, потому что ускоряет генерацию кода быстрее, чем компании успевают перестраивать доставку, рантайм и правила доступа.
Главный сдвиг здесь не в том, что программисты стали меньше писать руками. Гораздо важнее, что узкое место переехало дальше по цепочке: в CI/CD, тестовые среды, review, релизные окна и эксплуатацию. Если ассистенты делают черновую работу быстрее человека, разработчик превращается в рецензента и диспетчера машинного результата, а платформа начинает задыхаться на том объеме изменений, на который ее никто не рассчитывал. Отсюда и неприятный вывод для DevOps и платформенных команд: старый golden path может быть удобным, но этого уже мало, если он не переваривает возросший поток изменений.
Второй удар приходит от нового типа пользователя — ИИ-агента. Это уже не просто еще один сервисный аккаунт. Агенту нужны аутентификация и машинная идентичность, лимиты на токены, распределение GPU, совместимость с MCP, детальный аудит и жесткие границы полномочий. И все это желательно не после инцидента, а по умолчанию. Автор колонки прямо говорит: у большинства корпоративных платформ на такие сценарии нет нативного ответа. Для компаний, которые только начинают обсуждать агентные workflows, это важное предупреждение: если платформа умеет обслуживать только людей, она внезапно сама становится бутылочным горлышком.
Третье давление совсем земное: деньги. По собственному исследованию Broadcom Private Cloud Outlook 2026, 97% IT-руководителей уверены, что часть расходов на публичные облака у них утекает впустую, а 52% считают, что потери превышают четверть всего облачного бюджета. С ИИ счет становится еще грустнее: GPU-инстансы, inference endpoints и training jobs стоят заметно дороже привычных нагрузок, а поверх них появляется отдельная статья затрат на токены и повторные запросы. Месячный разбор счетов в духе классического FinOps тут не спасает: неправильно настроенная нагрузка способна сжечь бюджет за ночь.
С безопасностью та же история. Теневые AI-сервисы, prompt injection, отравление моделей и утечки данных на этапе inference плохо ловятся инструментами, которые создавались для веб-приложений и обычных пайплайнов. Гупта предлагает сдвиг не только влево, но и вниз по стеку: меньше надежды на дисциплину разработчика, больше встроенных политик в самой платформе и рантайме. Отдельный слой проблем добавляют регуляторы: в тексте упомянуты EU AI Act, указы властей США и требования к локализации данных. Для команд, работающих с зарубежными клиентами, это означает простую вещь: платформа должна доказывать управляемость ИИ-нагрузок, а не обещать ее в презентации.
При этом Broadcom не призывает сносить все до фундамента. Наоборот, идея в том, что платформенная инженерия 2.0 вырастает из старых принципов: platform as product, self-service IDP, golden paths и shift-left никто не отменял. Меняется поверхность применения. Внутренние платформы, по мысли автора, должны эволюционировать сразу по пяти направлениям: стать AI-native и воспринимать ИИ-нагрузки как штатных граждан; давать разные интерфейсы не только разработчикам, но и безопасникам, data science-командам, FinOps и бизнесу; показывать стоимость в момент выдачи ресурса, а не постфактум; прятать защитные меры глубже в рантайм; и собираться как конструктор из API-first-компонентов. Последний пункт особенно показателен на фоне CNCF: если в 2018 году в его экосистеме было около 50 проектов, то теперь их больше 200, и жесткая платформа просто не поспевает за такой скоростью выбора.
Практический вывод у текста довольно приземленный и поэтому полезный. На ближайшие 12 месяцев автор советует проверить три вещи: умеет ли текущая IDP выдавать GPU и другие ускорители, есть ли в ней нормальное управление нечеловеческими идентичностями и видно ли стоимость в момент provisioning, а не в конце месяца. Если проваливаются все три пункта, платформа уже отстала. Следующий большой вопрос для рынка звучит так: смогут ли платформенные команды сохранить обещанную разработчикам автономию и при этом взять под контроль агентов, токены и GPU, не превратившись в новый слой бюрократии. В исходной публикации есть ссылка на white paper Broadcom и Platformengineering.org: .