La Cloud Native Computing Foundation publicó una guía esta semana con un argumento específico e importante para cualquiera que despliegue cargas de LLM en Kubernetes: las primitivas de infraestructura que K8s provee (ruteo, aislamiento de red, RBAC a nivel de pod, gestión de secretos) son necesarias pero no suficientes para seguridad de LLM. La observación de fondo es que un LLM no es una carga de cómputo sin estado. Es un sistema que acepta input no confiable y decide qué hacer con él, incluyendo si invocar herramientas, emitir datos sensibles, o seguir instrucciones que aparecen dentro de su prompt. Ese modelo de amenaza es distinto a "containerizá este microservicio y aislalo", y necesita controles que viven en la capa de aplicación y prompt, no en la capa de cluster.
La lista específica de la CNCF sobre lo que Kubernetes no puede hacer es útil. Kubernetes no puede determinar si un prompt debería pasar al modelo, si una respuesta contiene datos sensibles que deberían redactarse antes de llegar al usuario, o si el modelo debería tener acceso a una herramienta particular para una request particular. La capa de infraestructura maneja ruteo y aislamiento de pods. La capa de aplicación tiene que manejar autenticación, autorización, validación de input, filtrado de output, decisiones de acceso a herramientas, y logging de auditoría de lo que el modelo de hecho hizo. El OWASP Top 10 para aplicaciones LLM es el mejor checklist actual de los modos de falla que los controles a nivel aplicación necesitan abordar: inyección de prompt, divulgación de información sensible, ataques de cadena de suministro, envenenamiento de datos y modelos, manejo impropio de output, agencia excesiva, leak de prompt de sistema, debilidades de vectores y embeddings, desinformación, y consumo no acotado. Si tu despliegue de LLM no tiene controles explícitos para cada uno de estos ítems, el hecho de que corra en un cluster Kubernetes seguro no lo hace seguro.
Esto encaja en el patrón más amplio de 2026 que atravesó las piezas cubiertas acá toda la semana: la capa de gobernanza para cargas de agentes y LLM se vuelve una categoría de primera clase, separada de la capa modelo y separada de la capa de infraestructura. El Agent Registry de AWS envía la versión de catálogo-y-auditoría empresarial de esto; la CNCF publica la versión de estándares abiertos para cualquiera que corra infraestructura LLM basada en Kubernetes. El programa Kubernetes AI Conformance se expande más adelante en 2026 para incluir estándares Sovereign AI, lo cual se ata directamente al Sovereign AI Fund del Reino Unido y al patrón de soberanía más amplio en la industria. Para constructores que quieran desplegar LLMs en entornos regulados o self-hosted, el camino open-source K8s-plus-AI-conformance es una opción real que te deja esquivar el lock-in de hyperscaler mientras conseguís estructura real de seguridad. Para empresas comprometidas con un hyperscaler, el Agent Registry de AWS con Bedrock AgentCore es la versión administrada. Los dos stacks van a competir por los mismos dólares de procurement empresarial.
Para equipos corriendo cargas de LLM en Kubernetes, se siguen tres movimientos. Primero, auditá tu despliegue actual contra el OWASP Top 10 para aplicaciones LLM; si no tenés controles nombrados para cada uno de los diez ítems, empezá con los que cubren validación de input, filtrado de output, y autorización de acceso a herramientas, porque esos cierran la mayor superficie de ataque. Segundo, separá la postura de seguridad de infraestructura de la postura de seguridad a nivel aplicación en tu documentación interna; una auditoría de compliance que dice "nuestro cluster K8s está CIS-benchmarkeado" no es lo mismo que "nuestro despliegue LLM es production-safe", y los dos pertenecen a equipos distintos con habilidades distintas. Tercero, vigilá el programa CNCF AI Conformance durante el resto de 2026; los estándares Sovereign AI que vienen más adelante este año probablemente se van a volver la arquitectura de referencia de facto para despliegues de LLM en industria regulada, y estar temprano en esa spec vale más que alcanzar después que sale. Para equipos en stacks administrados por hyperscalers, los mismos principios aplican con nombres de productos distintos: Bedrock, Vertex AI, y Azure AI Foundry todos tienen superficies equivalentes de control a nivel aplicación que necesitan configurarse, no asumirse.