Los equipos que gestionan Kubernetes automatizan despliegues de código con total naturalidad. Las canalizaciones de integración y entrega continua (CI/CD) se activan decenas de veces al día, el autoscaling modifica réplicas sin intervención humana, y las reversión a versiones previas se maneja casi de memoria muscular. Sin embargo, cuando se trata de que un sistema modifique automáticamente las solicitudes de CPU y memoria en cargas de trabajo en ejecución, la confianza desaparece.
Esta desconfianza se hace aún más palpable con la llegada masiva de cargas de trabajo de inferencia de inteligencia artificial (IA) a Kubernetes, lo que incrementa tanto la complejidad técnica como el coste de error.
Automatización: confianza para el cambio, dudas para la restricción
Un reciente estudio llevado a cabo con 321 profesionales que trabajan con Kubernetes en grandes organizaciones ha desvelado una marcada asimetría en la confianza hacia la automatización. El 82% confía total o bastante en los controles automatizados para la entrega de código. Sin embargo, el 71% todavía exige una revisión humana antes de que se apliquen recomendaciones para optimizar recursos y solo un 27% permite que cambios en CPU y memoria se apliquen automáticamente, incluso con salvaguardas establecidas. 
Este contraste se entiende cuando se observa la naturaleza de las operaciones. El despliegue de código se percibe como una función acumulativa: se añade valor, hay rutas claras para revertir cambios y suelen detectarse problemas con rapidez. En cambio, la optimización de recursos parece un proceso de sustracción, ya que reduce los márgenes de seguridad de servicios en ejecución. Este tipo de ajustes modifica la relación invisible entre la carga de trabajo y el programador (scheduler) de Kubernetes, algo que no es fácilmente observable o detectable a corto plazo.
Como explicó uno de los encuestados: «La optimización automática lleva un riesgo específico porque afecta directamente a la estabilidad subyacente del entorno de ejecución, modificando un contrato tácito entre el scheduler y la carga que no ocurre en un despliegue de código tradicional».
Por ello, un error en la configuración automatizada puede pasar desapercibido hasta varias semanas después, cuando un aumento inesperado de tráfico sobrepasa recursos ajustados, dificultando la identificación precisa de la causa. Los responsables saben que pueden recibir alertas en horarios intempestivos, lo que refuerza su precaución a la hora de delegar estos cambios.
La IA eleva el nivel de exigencia
La inseguridad ante la automatización ya existía antes, pero el auge de las cargas de trabajo de IA ha multiplicado el coste de mantenerla. Durante años, los equipos aceptaron manualmente sobreaprovisionar recursos para garantizar estabilidad, asumiendo el gasto extra como un precio razonable. Esto cambia radicalmente con los trabajos de inferencia acelerados por GPU, cuyo coste por hora es mucho más elevado que el de la CPU tradicional.
Además, la naturaleza de estas cargas es más volátil y menos predecible. El tráfico puede ser brusco o cambiar de patrón a medida que los modelos se actualizan y evolucionan, llevándoles a enfrentarse a la sintonización de dimensiones de recursos que no dominan a fondo. La optimización ya no se limita a escalar horizontalmente, sino que exige ajustar varios parámetros (CPU y memoria tanto en solicitudes como límites) en cientos o miles de cargas por clúster.
El estudio señala que la supervisión manual ya no es viable cuando se superan unas 250 modificaciones al día, un umbral que las cargas de inferencia de IA sobrepasan fácilmente por la frecuencia y criticidad de estas configuraciones.
Actualmente, la automatización para ajustar recursos merece mayor inversión y desarrollo, pero la aceptación se ve frenada por la falta de historia y experiencia con estas cargas nuevas y complejas.
Perspectivas y soluciones para recuperar la confianza
Según la encuesta, casi la mitad de los profesionales (48%) valoran la visibilidad y transparencia en cómo se toman las decisiones automatizadas como la clave para incrementar la confianza. Un cuarto (25%) exige reglas claras que limiten automáticamente los cambios (guardrails), y un 23% pide la capacidad de revertir ajustes al instante.
Contrario a lo que pudiera pensarse, pocos piden control totalmente manual o autonomía irrestricta. En cambio, demandan sistemas que ganen confianza gradualmente y permitan operar en diferentes modos: desde recomendaciones informativas en entornos de desarrollo hasta ejecuciones automatizadas con límites en producción, hasta optimizaciones totalmente autónomas en escenarios con historial comprobado.
Este enfoque evolutivo ya se ha seguido con éxito con las canalizaciones CI/CD: ninguna organización pasó de cero a plena confianza instantáneamente. En cuanto a la automatización de recursos de Kubernetes, especialmente bajo la presión de la IA, el proceso es más lento y cuidadoso para construir este historial.
Diseño adaptativo de la automatización: clave para la adopción
Algunas arquitecturas de automatización requieren el control completo para funcionar óptimamente, lo que puede generar rechazo si se impone a equipos que aún no confían plenamente. En cambio, sistemas diseñados para adaptarse a cada etapa del ciclo de confianza —ofreciendo modos de solo lectura, limitación con reglas y autonomía progresiva— facilitan la adopción.
Esto es aún más relevante para las cargas de IA, donde los costes de error son mayores y la curva de confianza comienza prácticamente desde cero.
Además, garantizar la seguridad en el despliegue es fundamental: comenzar con cargas que muestran espacio para optimización, realizar cambios pequeños y controlados, tener un sistema rápido de reversión apoyado en señales de salud ya monitorizadas, y adoptar un modelo de inscripción voluntaria favorece que los primeros equipos acumulen experiencia y sirvan de ejemplo.
Una visión más profunda del fenómeno
El que el 71% exija revisión humana no implica rechazo a la automatización, sino que refleja la naturaleza del desarrollo de confianza operacional: el proceso es condicional, gradual y varía según el impacto potencial.
La llegada masiva de cargas de trabajo de IA implica mayores riesgos y costes, por lo que el recorrido hacia sistemas automatizados plenamente confiables adquiere una nueva urgencia.
Como concluye un experto: «El mayor desafío en la optimización de Kubernetes no es la capacidad de las herramientas, que es notable, sino el factor humano». Por ello, si los equipos están gestionando cargas de IA y solo pueden usar herramientas automatizadas en modo lectura, la cuestión no es si confiar o no, sino si el sistema facilita construir esa confianza paso a paso, empezando con casos de bajo riesgo y avanzando a cargas donde el coste de error es históricamente más alto.
