IASeguridad

Kubernetes como sistema operativo por defecto de IA: los clústeres como cuestión de cumplimiento normativo

Gartner pronostica una adopción del 80 % de plataformas para finales de 2026.

Por Alec Chizhik 10 junio 2026 6 min de lectura

Kubernetes como sistema operativo por defecto de IA: los clústeres como cuestión de cumplimiento normativo

Gartner prevé que, para finales de 2026, ocho de cada diez empresas operarán una plataforma interna de desarrolladores. Lo que en 2022 sonaba a comodidad en la experiencia de desarrollo (DevEx), hoy soporta inferencia de IA, pruebas de cumplimiento y previsión de costes en un único stack de clúster. Quien no gestione ahora el clúster como infraestructura crítica para el negocio, estará planificando para 2027 con las categorías equivocadas.

La ola de inferencia ha llegado a Kubernetes

Quien en 2024 aún debatía sobre «cargas de trabajo de IA sí o no en el clúster», en 2026 está discutiendo otra cosa: qué pipelines de inferencia pueden seguir fuera de la plataforma. Las respuestas de los equipos que veo en auditorías DACH son sorprendentemente similares. Los experimentos en notebooks en Sagemaker, Bedrock o Vertex están permitidos. La inferencia productiva con datos de clientes termina en el clúster interno, o se detiene antes de pasar a producción.

¿Qué significa Kubernetes como sistema operativo por defecto para IA? El término describe el momento en que la inferencia de IA productiva se ejecuta de forma estándar en el clúster Kubernetes interno, en lugar de en un SaaS separado. Así, el clúster se convierte en infraestructura crítica para el negocio, que agrupa en un solo lugar la programación de GPU, los almacenes de vectores persistentes y las pruebas de cumplimiento, en lugar de distribuirlos en varias plataformas.

El impulsor no es la elegancia. El impulsor es la postura de los auditores. NIS2, la Ley de IA de la UE y DORA exigen pruebas sobre flujos de datos, derechos de modelos y cadenas de acceso. Si la IA reside en un SaaS separado, toda la cadena de auditoría debe construirse allí de forma independiente. Quien ya aplique estos controles en el clúster, obtiene las pruebas de IA prácticamente gratis. Esta es la justificación operativa detrás de la cifra de Gartner, no un eslogan de DevEx.

80 %

de las grandes organizaciones de ingeniería de software establecerán un equipo interno de plataforma para 2026 (en 2022 eran el 45 %) – para la mayoría, esto significa que el clúster soportará entonces la inferencia de IA y las pruebas de cumplimiento asociadas.

Fuente: Gartner

La IA con estado rompe los supuestos sin estado

La antigua doctrina de las plataformas era sencilla: los pods son ganado, el estado reside en el backend y el clúster solo orquesta. Las cargas de trabajo de inferencia no se atienen a esto. Un LLM grande tarda entre siete y doce segundos en cargarse antes de responder. Una base de datos vectorial pierde localidad cuando su pod migra más allá del límite del nodo. La afinidad con la GPU significa que el mismo pod debe permanecer en el mismo nodo, o la latencia se vuelve inutilizable.

Los equipos de plataforma están respondiendo a esto de tres formas. En primer lugar: pools de nodos dedicados para inferencia, con taints, tolerations y slots de GPU garantizados. En segundo lugar: almacenes vectoriales persistentes como StatefulSet, no como pod. En tercer lugar: planificación con conciencia de topología, para que las cachés no tengan que calentarse de nuevo con cada escalado. Quien no tenga estos tres componentes en su stack en 2026, replicará los problemas en cada nuevo servicio de IA.

El cumplimiento se traslada a la configuración del pod

La verdad operativa que los consejos de administración rara vez quieren oír: los auditores se interesan por los manifiestos de Kubernetes. Quien no gestione las políticas de egreso, NetworkPolicies, PodSecurity y la procedencia de las imágenes como código en el clúster, no podrá responder en una hora de auditoría a la pregunta «¿con qué endpoint habla vuestra IA?». La mayoría de los equipos DACH lo han entendido, pero la inversión va dos trimestres por detrás de los requisitos.

En concreto, esto significa: Policy-as-Code con OPA Gatekeeper o Kyverno debe estar en cada clúster que maneje datos de clientes. Las firmas Sigstore en las imágenes ya no son un juego: son la única prueba de que en el clúster solo se ejecuta lo que la pipeline ha aprobado. Y el cifrado en tránsito entre pods no será una opción en 2026, sino el valor por defecto. Los equipos de plataforma que no estandaricen estas capas frenarán a todos los equipos de producto que deban impulsar la historia de la IA.

Qué deben decidir ahora los equipos de plataforma

Llevo semanas posponiendo tres decisiones en las revisiones porque resultan incómodas en la hoja de ruta de la plataforma. No desaparecen por ignorarlas.

En primer lugar: la cuestión del presupuesto de GPU. Quien agrupe las GPU de forma centralizada gana en utilización, pero pierde autonomía de equipo. Quien asigne GPU por equipo pierde eficiencia, pero gana claridad sobre los responsables. Ambos modelos funcionan; el modelo mixto, no. Hay que decidir, no hablar en círculos.

En segundo lugar: la cuestión del multitenancy para IA. Una pipeline RAG con datos de tres áreas de negocio es un almacén vectorial con tres riesgos. La separación por namespaces no es suficiente: se necesita hardening en clases de almacenamiento, políticas de service mesh y un claro default-deny. Quien lo posponga, sufrirá un incidente que no estaba planeado en las diapositivas trimestrales.

En tercer lugar: la cuestión de saltarse la IA. Algunas cargas de trabajo de IA no pertenecen al clúster propio. La inferencia por lotes no crítica en latencia y con datos no sensibles puede ejecutarse de forma más barata y estable en una plataforma gestionada. Quien, por orgullo, lo lleve todo al clúster propio, se priva de la optimización más sencilla y bloquea al equipo de plataforma con cargas de trabajo que nadie echaría de menos.

Preguntas frecuentes

¿A partir de cuándo un clúster de Kubernetes es obligatorio para cumplir con la compliance en IA?

En cuanto la inferencia en producción se ejecute sobre datos personales o críticos para el negocio. NIS2 y la Ley de IA de la UE vinculan la obligación a la función, no a la arquitectura. Quien realice inferencia en el clúster asume la carga de auditoría para el mismo, incluyendo manifiestos, políticas y flujos de datos.

¿Qué estrategia de GPU es la adecuada para 2026?

No existe una respuesta universal. Las cargas de trabajo con fluctuaciones pronunciadas funcionan mejor en pools centrales con cuotas y preemption. Los productos estables con su propia demanda ganan con pools dedicados por equipo. Lo decisivo es que la elección se tome de forma consciente y no se mezcle por inercia.

¿Necesitamos un service mesh para cargas de trabajo de IA?

Si conviven varios inquilinos o clases de datos en el clúster, un mesh ayuda notablemente con mTLS, el control de egreso y la telemetría. Con un único tenant, la complejidad rara vez está justificada. La cuestión del mesh no es una cuestión de fe, sino de los flujos de datos reales.

¿Cómo es la migración si la IA ha funcionado hasta ahora fuera del clúster?

Es recomendable hacerlo en tres pasos: primero congelar los modelos y documentar los flujos de datos, luego trasladar el almacenamiento y el vector store al clúster, y finalmente reconfigurar los caminos de inferencia. Quien migra primero los modelos paga con riesgo de caída: los datos suelen ser el activo más complicado.

¿Cuándo es legítimo ejecutar IA fuera del propio clúster?

Cuando la latencia no es crítica, los datos no son sensibles y la plataforma gestionada ofrece las rutas de auditoría requeridas. Una inferencia de marketing sobre textos públicos no pertenece al clúster propio. En cambio, una evaluación de riesgos con datos de clientes, sí.