Evolving platform engineering for AI

Platform Engineering 1.0 delivered real value. Golden paths accelerated deployment. Internal Developer Platforms (IDPs) reduced cognitive load for developers. Self-service infrastructure gave developers back hours they had been spending filing tickets. Pipelines provided a standard vehicle to shift security left. The foundations were sound and most platforms are Platform Engineering 1.0 today. The rapid adoption of AI technologies is creating new requirements for platform teams. Many existing platforms were designed primarily around developer-centric application delivery and may need to evolve to support these emerging workloads and operational models. Emerging challenges for today’s platform teams Many forces are pressing simultaneously on platforms architected for containerized, developer-centric, human-paced workflows: AI-driven coding acceleration. As AI coding assistants become increasingly common, some organizations are reporting faster code generation and higher delivery throughput requirements. As a result, software delivery pipelines may become a growing constraint. The agentic future. Applications are embedding autonomous AI agents. Platforms are next. Many existing platform implementations were not originally designed around requirements such as GPU provisioning, model lifecycle management, MCP integration, or governance for AI-driven systems. Sovereignty and compliance pressure. Regulatory requirements for data residency and continuous compliance can’t be treated as add-ons. Security as an afterthought no longer passes scrutiny. AI and Frontier models are widening the security gap faster than bolt-on controls can respond. The multi-persona enterprise. ML engineers, data scientists, FinOps practitioners, and AI agents all need the platform — not just developers. A developer-only focus leaves significant organizational value on the table. The FinOps reckoning. Many organizations continue to identify significant opportunities to improve cloud cost efficiency, particularly as AI infrastructure introduces new consumption patterns. The foundations of platform engineering remain highly relevant, but many organizations are exploring how those foundations can evolve to address AI-era requirements. Evolution to Platform Engineering 2.0 One way to think about this evolution is through what we refer to as “Platform Engineering 2.0″—a framework for discussing how platform capabilities may expand to support AI-era requirements. The core principles — Platform as Product, developer productivity, golden paths, shift-left security — remain essential. What changes is who the platform serves, what it must do, and how it must be built. That evolution is organized around five pillars: AI-Native Platform — The platform supports AI workloads natively — building, governing, and protecting them from the ground up. It provides first-class support for GPU/TPU allocation, model serving, MCP gateways, and agentic guardrails. AI-powered systems may increasingly become consumers of platform services and therefore require governance, access controls, and operational guardrails similar to those applied to human users. Multi-Persona Experience — Platform Engineering 2.0 extends beyond developers and platform engineers to serve four additional personas. Data scientists and ML engineers gain self-service GPU provisioning, model registries, and experiment tracking. Engineering and business leaders get real-time FinOps dashboards and DORA metrics. Security and compliance teams receive policy-as-code enforcement. AI agents are recognized as non-human platform consumers with their own access, scope, and governance needs. Embedded FinOps — Cost intelligence moves from bolt-on reporting to provisioning-time decisioning. Financial accountability becomes a platform primitive, not a dashboard. Every developer and operator makes cost-aware decisions by default, supported by real-time cost attribution, pre-deployment cost gates. Security Shifts Down — Security is embedded into platform and runtime layers, complementing shift-left practices and catching what they miss. Continuous compliance is enforced by design. Platform addresses AI-specific attack vectors — shadow AI sprawl, prompt injection, model poisoning, and inference data leaks — through model registry governance, data isolation, prompt security, and inference auditing. Composable by Design — Platform capabilities are delivered as modular, independently deployable, API-first building blocks. Teams can swap one CNCF-compliant tool for another with equivalent functionality without cascading changes. The result is a platform that can be repaved quickly and confidently as the ecosystem evolves. Infrastructure remains the essential core of any platform engineering strategy—providing the vital compute, storage, and specialized GPU resources that sustain the entire ecosystem. The shift toward Platform Engineering 2.0 necessitates a structural reimagining of this foundation, moving beyond legacy, human-paced provisioning toward a dynamic, AI-native substrate that empowers every persona while embedding governance directly into the runtime. Rather than mere plumbing, infrastructure serves as the platform’s most strategic layer, ultimately defining the boundaries and potential of your organizational evolution. Measuring progress: The maturity model and CNCF alignment Adoption of Platform Engineering 2.0 is a deliberate journey, not a binary switch. CNCF provided a structured maturity model for Platform Engineering 1.0, giving practitioners a vendor-neutral, community-backed framework for benchmarking and planning. Platform teams need to access their current platform in context of Platform Engineering 2.0 for AI era. With 200+ projects in the CNCF landscape across graduated, incubating and sandbox, the composability pillar in particular draws heavily on this ecosystem to deliver best-of-breed, interchangeable building blocks. CNCF Platform Engineering Technical Community Group is already working on the intersection of Platform Engineering and AI for what is next. As Atulpriya Sharma, Co-Organizer, CNCF Platform Engineering Technical Community Group puts it “What started as a developer productivity function is now the centralised governance layer for the enterprise – enforcing cost discipline, security posture, and AI readiness across every team. The platforms that can absorb that scope without structural debt aren’t the ones built around fixed architectures. They’re the ones built to be composable from day one.” The bottom line The AI era demands platforms that are agent-ready, cost-intelligent, security-embedded, and composable at scale. Platform Engineering 2.0 extends everything the community built in 1.0 — and closes the structural gaps that the new era has exposed. At the base of that evolution sits infrastructure — modernized, AI-ready, and composable. The platform teams that treat infrastructure as a strategic priority, not an operational afterthought, are the ones that will deliver on the full promise of Platform Engineering 2.0 The evolution is underway. The question is how deliberately your organization approaches it. Learn more in this detailed whitepaper by Broadcom and Platformengineering.org.