Kubernetes ante el aluvión de agentes de IA: qué implica

La conversación sobre agentes de IA ha dejado de ser una promesa de futuro para convertirse en un problema de infraestructura. En el ecosistema cloud-native ya se habla abiertamente de que una sola petición humana puede desencadenar alrededor de una veintena de peticiones de agentes. Y esas peticiones, además, esperan respuestas por debajo de los 200 milisegundos, mientras que un pod nuevo de Kubernetes solo tiene garantizado arrancar en torno a un segundo. Esa brecha entre expectativa y realidad es la que está empujando a que el orquestador evolucione.

Los directores de la CNCF Bob Killen y Daniel Krook lo han puesto sobre la mesa en una entrevista de la serie Udienza de Luca Berton. La idea central que transmiten es que Kubernetes se está convirtiendo en el sistema operativo de la IA: la capa base por defecto sobre la que se construyen proyectos más específicos. Para una pyme, esto no significa que haya que montar un clúster mañana, pero sí entender hacia dónde va el suelo sobre el que se apoyarán muchas herramientas.

El cuello de botella ya no es el modelo, es la plataforma

Durante los últimos dos años, la conversación sobre IA en la empresa se ha centrado en el modelo: qué proveedor, qué ventana de contexto, qué precio por token. Sin embargo, cuando se pasa de una demo a un uso real, el problema se desplaza. Los agentes no son una consulta puntual; son procesos que se llaman entre sí, consultan herramientas, esperan confirmaciones y vuelven a arrancar. Ese patrón multiplica la carga y exige una plataforma capaz de escalar, aislar y observar.

De ahí que la propia CNCF esté señalando proyectos emergentes en distintas capas de la pila. Por un lado, llm-d, orientado a la inferencia distribuida de modelos de lenguaje. Por otro, Agent Substrate, un runtime pensado para despliegues de agentes a gran escala. No son piezas que una pyme vaya a instalar por su cuenta, pero sí indican qué problemas están intentando resolver los proveedores: latencia, distribución y control.

kagent: agentes como recursos de Kubernetes

Otro de los movimientos interesantes es kagent, un proyecto en sandbox de la CNCF que permite ejecutar agentes de IA como recursos personalizados de Kubernetes. La idea es sencilla de describir: se declara un agente con su prompt de sistema, su modelo y una lista de herramientas, se aplica y un controlador lo convierte en un pod en ejecución que habla el protocolo A2A. Como explican Antonio Berben (Solo.io) y Felipe Vicens (Telefónica) en el blog de la CNCF, el tutorial se puede ejecutar en un portátil con un modelo local mediante Ollama, aunque también admite proveedores como OpenAI, Anthropic, Azure OpenAI o Gemini.

Hay un detalle que merece la pena subrayar: los propios autores reconocen que los modelos más pequeños tuvieron dificultades para generar manifiestos válidos. Es decir, la barrera no está en la infraestructura, sino en la capacidad del modelo para producir artefactos correctos. Además, el agente constructor está limitado por una lista blanca de tres herramientas, exige aprobación humana antes de aplicar nada y usa RBAC para que solo pueda escribir recursos de tipo Agent. Es un buen ejemplo de cómo se está diseñando la seguridad en este terreno: el agente propone, el humano aprueba y los permisos acotan.

Compliance: el hueco que nadie quiere cubrir

En paralelo al debate técnico, hay un asunto organizativo que afecta de lleno a las pymes europeas. Matteo Bisi, de Reevo, lo resumía con una frase contundente en el blog de la CNCF: «Seguridad puede escribir la política. Seguridad no puede fusionar el Helm chart». El problema es quién asume la responsabilidad de que una plataforma Kubernetes cumpla con normativas como NIS2 o DORA. Su propuesta pasa por construir «cadenas de trazabilidad» en las que riesgo, legal y seguridad definen el alcance y las evidencias, y luego se entregan artefactos concretos y tareas recurrentes a los equipos de plataforma y aplicación.

Si tu empresa no tiene claro quién firma el cumplimiento de la plataforma, el problema no es Kubernetes: es el reparto de responsabilidades.

Esto conecta con una conversación que ya hemos tratado en el blog: el CISO ante la IA ya no puede medir el riesgo activo a activo. Con agentes que se llaman entre sí y plataformas que cambian de forma continua, el control tiene que ser de proceso, no de inventario.

Qué miramos desde ForgeNEX

Para una pyme, la lectura práctica de todo esto es la siguiente. Primero, no confundir la infraestructura con el caso de uso. Kubernetes es potente, pero no es un fin en sí mismo; si tu carga de agentes es pequeña, quizá no lo necesites. Segundo, si ya tienes servicios gestionados o contenedores en producción, empieza a pensar en la observabilidad de los agentes como algo distinto de la de tus aplicaciones: latencias, número de saltos y coste por petición. Tercero, aplica el principio de mínimo privilegio también a la IA: listas blancas de herramientas, aprobación humana y permisos acotados.

Y cuarto, no dejes el compliance para el final. NIS2 y DORA no son un trámite de despacho; afectan a cómo documentas, quién aprueba y qué evidencias guardas. Si estás construyendo sobre Kubernetes o vas a hacerlo, conviene definir ahora quién es el dueño de esa cadena de trazabilidad. En un terreno donde una petición humana se convierte en veinte, la claridad organizativa vale tanto como el mejor orquestador.

Fuente: The New Stack. Análisis y adaptación: ForgeNEX.