cd /news/mlops/the-real-llmops-risk-isn-t-the-model… · home topics mlops article
[ARTICLE · art-96503] src=dev.to ↗ pub= topic=mlops verified=true sentiment=· neutral

The real LLMOps risk isn't the model. It's shadow AI.

CNCF's Daniel Bryant argues that LLMOps should be integrated into existing platform engineering rather than treated as a separate stack, warning that shadow AI pipelines built outside governance pose a greater risk than model hallucinations. The CNCF Platforms Whitepaper frames model fine-tuning, vector databases, prompt registries, and inference endpoints as standard platform capabilities requiring unified API, versioning, and ownership.

read2 min views1 publishedAug 14, 2026

Large language models broke the clean "train it, test it, ship it" model of production ML. The thing being operated is now a system that chains prompts, queries vector databases, and produces output judged on tone and safety — not just accuracy. That's LLMOps. And it's currently landing on top of your existing DevOps and MLOps workflows without a clear owner.

CNCF's Daniel Bryant has a clear take on who should own it — and the argument is sharper than it sounds.

"LLMOps doesn't need its own kingdom. It needs a well-run platform willing to let it in."

LLMOps isn't just MLOps with a new label. The gap is real:

MLOps teams have already built a parallel stack (MLflow, Kubeflow, Weights & Biases) because DevOps tooling never anticipated data versioning or drift monitoring. Without intervention, LLMOps becomes a third parallel stack, invisible to whoever governs the rest.

The bigger operational risk isn't a hallucinating chatbot. It's a team standing up its own RAG pipeline against an unreviewed vector store, outside any platform governance. Same pattern that made the DevOps-versus-platform split painful: a capability gets built outside the platform because the platform wasn't ready, and it never gets folded back in.

Bryant's framing via the CNCF Platforms Whitepaper is clean: model fine-tuning jobs, vector databases, prompt registries, and inference endpoints are just another platform capability. They need the same API, versioning, and ownership as anything else.

The tooling already exists in the CNCF ecosystem — Backstage at the product layer, Crossplane at the infrastructure layer, Kratix/KubeVela/KusionStack in the middle, exposing LLM pipelines through the same self-service interface as everything else.

If you're a platform engineer:

If you're on an MLOps or AI team:

If you're in platform leadership:

The CNCF TAG App Delivery Platforms Working Group is actively working on this. If your org is sorting out LLMOps ownership, it's worth following.

Source: CNCF Blog — LLMOps and platform engineering: Who should own the AI pipeline? ✏️ Drafted with KewBot (AI), edited and approved by Drew.

── more in #mlops 4 stories · sorted by recency
── more on @cncf 3 stories trending now
sponsored brought to you by zahid.host 4,200+ EU-deployed projects
reading about agents? ship yours in a single git push.

Run your AI side-project on zahid.host

EU-based hosting, git-push deploys, automatic HTTPS, no cold starts. Free tier with a custom domain — perfect for shipping the agent you just read about.

$git push zahid main
Live at https://your-agent.zahid.host
Get free account → Pricing
from €0/mo · no card required
LIVE [news/the-real-llmops-risk…] indexed:0 read:2min 2026-08-14 ·