El desperdicio cloud llevaba cinco años bajando, y en 2026 ha vuelto a subir

Hay una satisfacción concreta en vaciar un trastero.  

Se tarda años, se hace a ratos, y un día por fin se ve el suelo. Lo que nadie cuenta es lo que pasa después, cuando llega una reforma en casa y en dos fines de semana el trastero vuelve a estar lleno de cajas sin etiquetar, porque había que sacarlas de en medio y no había tiempo de decidir qué se quedaba. El esfuerzo de los años anteriores no fue inútil; simplemente no estaba pensado para lo que vino después. 

Al gobierno del gasto cloud le está pasando algo parecido, y conviene mirarlo de frente porque cambia bastante las prioridades de los próximos meses. 

De dónde sale el dato 

Flexera pregunta cada año a las organizaciones qué porcentaje de su gasto cloud consideran desperdiciado. En su informe de 2026 la cifra es del 29%. Tomada suelta no dice gran cosa; lo relevante es la trayectoria: venía bajando durante cinco años consecutivos y este ejercicio ha vuelto a subir. Flexera atribuye el giro a la complejidad que han traído las cargas de IA y los nuevos servicios de IaaS y PaaS. 

Merece la pena detenerse en lo que eso significa, porque admite dos lecturas y solo una la sostienen los datos. La primera es que FinOps no funciona. La segunda es que funcionaba —el desperdicio bajó cinco años seguidos, y no por casualidad— y que ha aparecido una capa nueva que la disciplina existente no cubre bien todavía. No es un fracaso de método, es un cambio de terreno. 

Por qué el gasto en IA es más difícil de leer 

La primera particularidad es la velocidad. En dos años, la gestión del gasto en IA ha pasado del 31% al 98% de los equipos de FinOps, según el informe State of FinOps 2026 de la FinOps Foundation. Casi nada en la historia del cloud se ha generalizado tan rápido, y desde luego no lo ha hecho la práctica necesaria para gobernarlo: en el mismo informe, la gestión del coste de IA aparece como la capacidad que más equipos dicen necesitar, un 58%. La adopción va por delante del criterio, que es la receta habitual del desperdicio. 

La segunda es la unidad de consumo. Un servidor se dimensiona una vez y su coste es previsible; un modelo se paga por uso, y el uso no lo determina una previsión de capacidad sino el comportamiento de quien usa el producto. Eso convierte el gasto en algo que crece con el éxito, que es buena noticia para el negocio y mala para quien tenga que presupuestarlo con los métodos de antes. A ello se añade que los precios de las cargas de IA son menos transparentes y bastante más variables que los del cloud tradicional, y que cambian de un trimestre a otro. 

La tercera es el precio del error. El hardware de IA es caro y se aprovecha peor: Cast AI sitúa la utilización media de GPU en torno al 5%. Sobredimensionar una instancia estándar es un error barato, y por eso se comete a menudo; sobredimensionar una GPU es el mismo error con un cero más. Los hábitos que el cloud clásico toleraba, la IA no los perdona igual. 

Y la cuarta es la atribución. Un modelo suele dar servicio a varios productos y equipos a la vez, de modo que repartir su coste entre ellos no es una operación evidente. Sin ese reparto no hay coste por servicio, y sin coste por servicio no hay manera de discutir si lo que se gasta vale lo que cuesta. 

Cuál es el problema de fondo 

Todo lo anterior es específico de la IA, pero por debajo sigue estando el mismo mecanismo que explica el desperdicio cloud desde hace una década: el gasto no se decide cuando llega la factura, sino semanas antes, cuando alguien diseña, dimensiona o levanta algo. Y quien toma esas decisiones rara vez ve en ese momento lo que van a costar. En una encuesta de Harness a 700 responsables de ingeniería, solo el 33% dispone de información en tiempo real sobre si una carga de trabajo está sobredimensionada, y apenas el 39% puede identificar recursos huérfanos y olvidados; la misma encuesta cifra en 31 días el tiempo medio en detectar y eliminar un recurso que ya no aporta nada. 

No es dejadez, es aritmética de incentivos: si un servicio se queda corto y falla, el problema es inmediato y tiene nombre y apellidos; si va sobrado, el coste es invisible y no le pasa nada a nadie. El resultado se mide. Según el informe State of Cloud Costs de Datadog, la instancia EC2 mediana funciona entre el 7% y el 12% de utilización de CPU, y los clústeres de Kubernetes promedian en torno a un 10% de CPU y un 20% de memoria. 

De ahí la consecuencia que de verdad importa para los próximos meses. Quien todavía no tiene claridad sobre su gasto cloud clásico no va a heredar esa niebla tal cual sobre su gasto en IA: la va a heredar amplificada, sobre una base de coste más alta y con muchas menos referencias donde apoyarse. La deuda de visibilidad no espera quieta a que alguien la resuelva. 

Qué conviene hacer distinto ahora 

La disciplina no cambia. Cambia dónde se aplica y con qué unidades. 

Lo primero es no esperar. La tentación razonable es ordenar antes el cloud tradicional y abordar la IA cuando el gasto sea grande, y es justo al revés: es ahora, mientras las cargas son pequeñas y las decisiones de arquitectura siguen abiertas, cuando gobernar sale barato. Dentro de dos años esas decisiones serán infraestructura heredada, y entonces cada cambio se pagará dos veces. 

Lo segundo es llevar el coste al momento del diseño, que en IA significa algo muy concreto. Elegir modelo, fijar el tamaño de contexto, decidir si la inferencia tiene que ser en tiempo real o puede ir en batch, valorar si hace falta un modelo grande o basta uno pequeño para el 80% de los casos: todas son decisiones de arquitectura con impacto directo y medible en la factura. Si el equipo no ve ese impacto mientras decide, lo verá el mes siguiente alguien que ya no puede cambiarlo. 

Lo tercero es cambiar la unidad de medida. El gasto mensual en GPU o en tokens no es un indicador de gestión, es un total. El indicador es el coste por unidad de valor: por conversación atendida, por documento procesado, por consulta resuelta. El sector va en esa dirección: según Flexera, el 49% de las organizaciones está adoptando unit economics para entender el coste por servicio, y el 64% ya usa el valor entregado a las unidades de negocio como métrica principal de progreso en cloud, doce puntos más que el año anterior. 

Conviene decir también lo que este enfoque cuesta, porque no es gratis y venderlo como si lo fuera es la mejor forma de que no se adopte. Añade una variable más a equipos que ya tienen unas cuantas, exige inversión en tooling y sobre todo en cultura, y no da resultados en el primer trimestre. En IA hay además un problema de inmadurez: no existen todavía buenos benchmarks de referencia, las buenas prácticas se están escribiendo mientras se aplican, y el propio instrumentado para medir tiene su coste. 

Y hay un trade-off que se pasa por alto y que en IA es el más importante de todos. Apretar el coste demasiado pronto mata la experimentación, y la experimentación es donde está el valor de esta tecnología ahora mismo. La respuesta no es fricción cero ni fricción máxima, sino presupuesto explícito y acotado para la fase de descubrimiento: un techo conocido, una fecha, y la obligación de que lo que pase a producción salga con su coste unitario calculado. Explorar sin límite y gobernar sin explorar son dos formas distintas de perder dinero. 

Un último matiz, agnóstico a propósito. En IA el coste de salida es más sutil que en infraestructura: no son máquinas, son prompts afinados contra un modelo concreto, evaluaciones construidas sobre su comportamiento y, a veces, ajustes finos que no se llevan puestos a otro sitio. Elegir un proveedor propietario o componentes abiertos es una decisión legítima en ambos sentidos, pero conviene tomarla sabiendo qué parte del trabajo se queda clavada a esa pared. 

Tres preguntas para comenzar 

Si esto te suena a tu organización, hay una forma rápida de situarse.  

Si no puedes responder a las tres lo que tienes es un problema de gobierno que la factura se limita a hacer visible cada mes. Con una diferencia respecto al cloud clásico, que es que en IA la factura crece más rápido que la capacidad de la organización para entenderla. 

Conclusiones 

En Clober diseñamos, gestionamos y operamos entornos cloud con requisitos exigentes de soberanía, rendimiento y coste. Y en esa última palabra insistimos: coste no significa recortar, significa comprender. Saber qué se paga, por qué se paga y qué devuelve a cambio. 

Volviendo al trastero del principio, la conclusión no es que ordenar fuera inútil. Es que el criterio con el que se ordenó sigue siendo bueno y hay que aplicarlo antes, a las cajas que están entrando ahora, mientras todavía se puede decidir cuáles llevan etiqueta. Los cinco años de mejora en el gasto cloud dejaron método, vocabulario y hábitos; lo que la IA obliga a cambiar es el momento en que se usan. 

Nada de esto es urgente en el sentido de que algo se vaya a caer mañana. Es urgente en el otro sentido, el que no avisa: cada trimestre que pasa sin gobernar el gasto en IA es un trimestre de decisiones que después habrá que deshacer.