On this page
The dominant trend in platform engineering for the next three years is already visible.
KubeCon EU 2026 had thirty-eight platform engineering sessions, more than any other category. Gartner’s 2026 hype cycle positions AI agent management platforms as transformational. The CNCF survey shows production Kubernetes usage at 82%, with two-thirds of organisations running generative AI workloads on Kubernetes for at least some of their inference. Sixty-six percent of organisations hosting generative AI models are using Kubernetes for it.
The industry is not asking whether Kubernetes will be the AI control plane. The conversation has moved to how to operate it as one.
If you are running a platform team in 2026, this is the question you are about to be asked: is the platform ready?
What “AI Control Plane” Actually Means
The phrase sounds abstract until you list the things that have to be true for a platform to credibly serve production AI workloads.
It means the platform can:
- Schedule GPU and accelerator workloads alongside standard compute, with right-sizing, quota enforcement, and clear cost attribution per team and workload.
- Serve inference endpoints with appropriate latency, autoscaling behaviour, and capacity reservation patterns - none of which match the assumptions baked into standard horizontal pod autoscaling.
- Route, throttle, log, and govern requests to model endpoints through an AI gateway layer that is to AI what an API gateway is to traditional services.
- Surface observability that reflects how AI workloads actually behave: token throughput, model loading time, GPU memory pressure, cost per request, queue depth, accuracy drift.
- Apply security and policy controls to AI workloads that match the requirements of the data they consume and the actions they can take.
- Provide a clear, named ownership boundary for every AI workload running in production.
These are six distinct platform engineering capabilities. Most platforms built for stateless microservices have one or two of them. None of them are unusable without AI - they are just much more important once AI workloads start landing.
Why Most Platforms Are Not Ready
The reason most platforms are not ready is not a lack of capability. It is that the assumptions baked into how they work do not match how AI workloads behave.
Compute is no longer fungible
Standard Kubernetes scaling assumes that compute is interchangeable. If you need more capacity, the platform adds nodes. The nodes are roughly the same. The pods are roughly the same.
GPU compute is not fungible. There is no spare H100 down the hall. Scaling up means waiting for a specific accelerator type to become available, or negotiating a capacity reservation with a cloud provider. Scaling down means deciding whether to release a piece of expensive capacity that might be needed in twenty minutes.
The autoscaling primitives the platform team has spent five years tuning are not the right primitives for this problem.
Latency profiles are different
Standard microservices respond in single-digit milliseconds. Inference endpoints respond in hundreds of milliseconds, or seconds for large language models generating responses.
This breaks the timeout defaults, retry policies, health check intervals, load balancer settings, and capacity planning models that the platform inherited from its microservices roots. None of these break loudly. They break quietly, with elevated false positives, premature timeouts, and dashboards that misrepresent latency.
Failure modes are different
A standard service that fails throws an exception or returns a 500. AI workloads fail because a model artefact did not download correctly. Because GPU memory fragmented. Because a driver version was incompatible. Because the model loaded but the response was wrong in a way that nothing in the platform’s alerting can detect.
The platform’s runbooks, alert definitions, and incident response playbooks do not cover these scenarios. The first time an AI workload fails this way, the on-call rotation discovers it from a customer complaint.
Cost behaviour is different
A standard service has a reasonably predictable cost profile per request. An AI workload’s cost can vary by an order of magnitude depending on input size, model size, batch behaviour, cold-start state, and how aggressively the platform reserves capacity.
A platform without cost attribution per workload, per team, and per accelerator will not be able to answer the questions finance is about to start asking.
Ownership boundaries are unclear
For most services in a platform, the owning team is obvious. The team that wrote it owns it. The platform owns the infrastructure underneath it. The application engineering team owns the application logic.
AI workloads do not split this way cleanly. The model team owns the model. The platform team owns the cluster. The application team owns the integration. When the workload fails, the question of who owns what is genuinely ambiguous, and the first incident is when the organisation discovers that.
The Window for Choosing Deliberately
The reason this matters now is that AI workloads are landing on every Kubernetes platform whether the platform team wants them or not. The choice is not whether to support AI; it is whether to do it deliberately or to do it reactively.
The reactive path is the default. AI teams ship a workload on the existing platform. It works, in a way. The platform team gets pulled in when something breaks. Capabilities get bolted on one at a time, in response to specific failures. After a year, the platform supports AI through accumulated workarounds rather than through design.
This produces an AI platform that is technically operational but is expensive to run, hard to scale, and impossible to audit. The compound cost over three years is significant.
The deliberate path is more work in the short term. The platform team identifies the six capabilities listed earlier, designs the smallest set of changes to provide them, and gives AI teams a clear path to production. The platform absorbs AI as a first-class workload type rather than as an exception that accumulates.
The window for choosing deliberately is now, for most organisations. The cost of doing this work before the third or fourth production AI workload lands is much lower than the cost of doing it after.
What This Looks Like Operationally
The deliberate version of becoming an AI control plane usually involves a handful of specific investments:
- Define an AI workload onboarding model. Teams should know how to get a model into production the same way they know how to get a service into production today.
- Choose accelerator classes and a quota model. Three or four accelerator classes is usually enough. Per-team quotas force teams to think about right-sizing rather than requesting the largest accelerator available.
- Introduce an AI gateway. A request routing and policy layer for model endpoints. Logging, throttling, fallback, and audit. This is the AI equivalent of the API gateway.
- Extend observability to AI metrics. Token throughput, GPU memory, queue depth, cost per request, model loading times. Most of these are not in the existing observability stack and have to be added deliberately.
- Define ownership and on-call patterns for AI workloads. Before the first production AI workload, not after the first incident.
- Build a cost attribution model that includes GPU. Per team, per workload, per environment. The finance conversation about AI cost is already starting; the platform team needs to be able to answer it.
None of these are technically heroic. The difficulty is choosing to do them now, before the production AI workloads have landed and made the choice for you.
The Executive Frame
For engineering leaders presenting this to the board, the framing is straightforward.
The platform investment that supports AI is not separate from the AI investment. It is the operational layer that determines whether the AI investment converts into delivered capability or sits in a state of permanent partial readiness.
Organisations that recognise this early can make a small, focused platform investment now and ship AI workloads predictably for the next three years. Organisations that recognise it late will discover, somewhere in 2027 or 2028, that they have an estate of partially-functional AI workloads, no clear cost attribution, and no defensible operational model to present to auditors, regulators, or customers.
This is not a technology decision. It is a sequencing decision, and the cost of getting the sequencing wrong is high.
The Takeaway
Every credible industry signal in 2026 - KubeCon, Gartner, CNCF, the DORA findings on AI as an amplifier - points to the same conclusion. Kubernetes is becoming the AI control plane, platform engineering is the discipline that operates it, and the gap between organisations that did this deliberately and organisations that did not is going to widen sharply over the next three years.
The work to make a platform AI-ready is not enormous. It is six capabilities, sequenced deliberately, implemented in roughly the order that operational reality demands them. The cost of doing this work now is much lower than the cost of doing it under pressure after the third production AI workload has landed and the failures have started.
If you are a platform leader or engineering executive and you are not sure whether your platform is ready for what is about to land on it, we can help you find out.