Shadow LLMOps: why platform teams should claim the AI pipeline before someone else does

The CNCF published a post on 13 August 2026 arguing that LLMOps is a distinct set of practices sitting on top of MLOps and DevOps, all competing for the same pipeline that platform engineering is supposed to run ^[1][4]. Its warning is the practical part: get the ownership model wrong and you recreate the shadow-IT problem platform engineering was built to prevent, only with prompts instead of Jenkinsfiles ^[5].

The case that this is not MLOps relabeled rests on what is being operated. A few years ago, production meant a data scientist, a DevOps engineer, and a narrow toolset: train, test, ship, watch the dashboards ^[2]. The thing now in production chains prompts, calls vector databases, and emits open-ended text judged on tone and safety rather than accuracy alone ^[3]. Google Cloud, per the post, classifies LLMOps as a specialised subset of MLOps, with the gap coming down to scale and evaluation: LLMs cost more to fine-tune and serve, and their output is far harder to score than a clean accuracy number ^[7][8]. The scope named is broad enough to make the point: data management, prompt engineering and fine-tuning, deployment and serving, monitoring and evaluation, and security and governance ^[6]. And it does not end at launch, because models drift, costs creep, prompts stop working as they used to, and the integrations tying a model to a CRM or an internal knowledge base need constant tending ^[9].

Read that lifecycle as infrastructure and the ownership answer gets less mysterious. Prompts as versioned artefacts, fine-tuning open foundation models with libraries such as Hugging Face Transformers, prompt and model lineage tracking, inference serving on GPU-backed endpoints, monitoring with human feedback for drift and cost: every stage needs compute, access controls, and a place to run, which is territory platform engineering already occupies for other workloads ^[10][11].

The failure mode is precedent, not speculation. The post describes delivery already fractured into three camps: DevOps teams buried under deployment tickets, platform teams building self-service golden paths in response, and MLOps teams who stood up a parallel stack of MLflow, Kubeflow and Weights & Biases because DevOps tooling never anticipated data versioning or drift monitoring ^[12]. Add LLMOps and you risk a third parallel stack for prompts, vector stores and RAG pipelines, invisible to whoever is meant to be governing the rest ^[13]. That is three toolchains by the post's own accounting ^[22].

The suggested framing is to stop asking who owns the pipeline and ask who owns which layer, and whether anyone is coordinating across them ^[15]. CNCF TAG App Delivery's Platforms Whitepaper offers the split: Products on top, Platforms in the middle as the thinnest reasonable integration layer, and Capability Providers at the bottom ^[16]. Fine-tuning jobs, vector databases, prompt registries and inference endpoints are, functionally, just another platform capability, needing the same API, versioning and clear ownership as anything else ^[17]. The tooling is named too: Backstage for golden paths at the product layer, Crossplane composing infrastructure at the bottom, and orchestration frameworks such as Kratix, KusionStack and KubeVela in the middle ^[18].

The stated risk is not a hallucinating chatbot but the sprawl around it: a team standing up its own RAG pipeline against an unreviewed vector store, invisible to whoever tracks what is actually running ^[20]. That is the same pattern that made the DevOps-versus-platform split painful, where a capability gets built outside the platform because the platform was not ready, and never gets folded back in ^[21].

Watch whether platform teams expose an LLM pipeline through the existing self-service interface, because the post's claim is that skipping this resurfaces the DevOps-versus-MLOps turf war one layer higher ^[19]. The tell in your own estate is an inventory question: if nobody can list the vector stores and prompt registries in production, the third stack already exists ^[13][20].