La facilidad para desplegar infraestructura cloud ha trasladado buena parte del problema desde el aprovisionamiento hacia la gestión económica. Crear máquinas virtuales, clústeres Kubernetes, almacenamiento, bases de datos o servicios de inteligencia artificial puede llevar minutos; determinar después quién los utiliza, cuánto cuestan realmente y qué valor producen es bastante más complicado. Ahí entra FinOps, una disciplina que intenta incorporar el coste a las decisiones técnicas antes de que la factura se convierta en una sorpresa.

Las claves de FinOps y el gasto cloud en 30 segundos

• El 85 % de las organizaciones considera la gestión del coste cloud uno de sus principales retos y estima un 29 % de gasto desperdiciado en IaaS y PaaS.
• FinOps combina ingeniería, finanzas y negocio para relacionar consumo tecnológico y valor.
• Rightsizing, etiquetado, presupuestos, compromisos de consumo y eliminación de recursos ociosos siguen siendo prácticas básicas.
• El siguiente paso son las economías unitarias: medir coste por cliente, transacción, servicio o incluso token de IA.
• La infraestructura estable también obliga a comparar cloud público, privado, dedicado y modelos híbridos antes de intentar optimizar una arquitectura mal elegida.

La situación resulta especialmente llamativa porque las empresas llevan años trabajando en optimización. El informe State of the Cloud 2026 de Flexera, elaborado a partir de 753 profesionales y responsables cloud, sitúa en el 29 % la estimación media de gasto desperdiciado en IaaS y PaaS, después de cinco años de descenso. Además, el 85 % señala la gestión del gasto como uno de sus principales problemas, por delante incluso de la seguridad, citada por el 82 %.

La inteligencia artificial está complicando todavía más la ecuación. GPU, inferencia, almacenamiento, APIs, bases de datos vectoriales y nuevos servicios PaaS incorporan unidades de consumo diferentes a las tradicionales. La factura ya no depende únicamente de cuántas máquinas virtuales permanecen encendidas.

Por eso FinOps está evolucionando desde el simple ahorro hacia una pregunta bastante más útil: ¿qué obtiene la empresa a cambio del dinero que destina a tecnología?

FinOps empieza antes de que llegue la factura

La FinOps Foundation define actualmente su marco alrededor de capacidades que incluyen entender uso y coste, cuantificar valor empresarial y optimizar tanto el consumo como el precio. Dentro de ellas aparecen planificación, previsión, presupuestos, indicadores, unit economics, arquitectura, colocación de cargas, licencias y sostenibilidad.

Esto cambia la forma de interpretar el problema.

Una factura cloud de 100.000 euros mensuales no es necesariamente peor que otra de 70.000. Si la primera soporta diez veces más clientes, transacciones o ingresos, puede representar una infraestructura económicamente más eficiente.

De ahí la importancia de las economías unitarias.

En lugar de preguntar únicamente cuánto cuesta AWS, Azure, Google Cloud, un cloud privado o la plataforma Kubernetes, la organización puede medir indicadores como coste por cliente, pedido, transacción, máquina virtual, API atendida o servicio prestado.

La FinOps Foundation incorpora precisamente Unit Economics como una capacidad para relacionar el uso y coste de la tecnología con el valor producido por los servicios y actividades de una organización.

La tendencia ya aparece en las empresas. Según Flexera, el porcentaje de organizaciones que utilizan métricas de economía unitaria aumentó del 40 % al 49 % en un año.

Es una diferencia importante.

Reducir el gasto cloud un 10 % puede parecer un éxito. Pero si para conseguirlo aumenta la latencia, empeora la disponibilidad o se limita un producto que estaba creciendo, el supuesto ahorro puede destruir más valor del que genera.

Visibilidad: saber quién está gastando

Antes de optimizar hay que poder atribuir el consumo.

Eso requiere una política consistente de etiquetas, cuentas, proyectos, propietarios y centros de coste. Un recurso debería poder responder, como mínimo, a cuestiones básicas: quién es responsable, a qué aplicación pertenece, en qué entorno funciona y qué unidad empresarial paga por él.

El etiquetado manual suele deteriorarse rápidamente. Por eso las organizaciones más maduras incorporan estas reglas al aprovisionamiento y a la infraestructura como código.

La ausencia de propietario es, de hecho, una señal especialmente útil. Una máquina virtual, volumen, snapshot, dirección IP o balanceador que nadie reconoce merece ser revisado independientemente de que su coste individual parezca pequeño.

El problema aparece por acumulación.

Rightsizing: pagar por lo que realmente se necesita

Otra práctica clásica es el rightsizing, es decir, adaptar los recursos asignados al consumo real.

Una máquina con 32 vCPU y 128 GB de RAM que utiliza de forma sostenida una pequeña parte de esa capacidad puede estar sobredimensionada.

Pero tampoco debería reducirse mirando exclusivamente el promedio de CPU.

Hay que considerar memoria, almacenamiento, IOPS, ancho de banda, latencia, picos de demanda, reservas de capacidad, requisitos de alta disponibilidad y margen operacional.

Una base de datos puede consumir poca CPU y depender intensamente de memoria y almacenamiento. Un servicio puede permanecer casi inactivo durante horas y multiplicar su carga durante unos minutos.

FinOps necesita por tanto métricas técnicas, no únicamente datos de facturación.

Los recursos olvidados también pagan factura

La infraestructura ociosa adopta muchas formas: máquinas de desarrollo funcionando durante noches y fines de semana, discos que permanecen después de eliminar una instancia, snapshots antiguos, IP públicas sin uso, balanceadores vacíos, clústeres sobredimensionados o entornos de pruebas que nadie recuerda haber creado.

En estos casos el ahorro puede llegar simplemente eliminando lo que ya no aporta ningún servicio.

También conviene revisar el almacenamiento. Los datos activos, backups, históricos y archivos a largo plazo no necesitan necesariamente la misma clase de almacenamiento ni las mismas prestaciones.

Y hay costes que pasan más desapercibidos: transferencia entre zonas y regiones, egress, NAT gateways, observabilidad, soporte, licencias comerciales o servicios gestionados cuyo precio depende del número de peticiones.

La factura de infraestructura es mucho más que CPU y RAM.

Kubernetes y la IA complican las cuentas

Kubernetes representa perfectamente el nuevo problema económico.

Una factura puede indicar cuánto cuesta un conjunto de nodos, pero una empresa necesita saber qué parte corresponde a cada namespace, aplicación, equipo o cliente.

Proyectos open source como OpenCost proporcionan una metodología independiente del proveedor para medir y asignar costes de infraestructura y contenedores dentro de Kubernetes.

La inteligencia artificial lleva este problema un paso más lejos.

OpenCost 1.121.0 añadió en agosto de 2026 capacidades dirigidas a relacionar los costes de Kubernetes con cargas de inferencia. La integración con llm-d y vLLM permite acercarse a métricas como el coste por modelo y por token teniendo en cuenta la utilización real de los recursos.

Aquí aparece una distinción especialmente útil: coste de disponibilidad frente a coste de utilización.

Un modelo de lenguaje cargado en una GPU puede estar preparado para responder inmediatamente y, al mismo tiempo, pasar largos periodos con muy poca actividad. Aunque no produzca tokens, mantiene ocupada memoria de la GPU y capacidad que sigue teniendo un coste.

Ese gasto puede ser perfectamente razonable si la aplicación necesita una latencia muy baja.

Lo importante para FinOps es hacerlo visible.

Una plataforma de IA podría terminar midiendo cuánto cuesta mantener disponible cada modelo, cuánto cuesta realmente cada millón de tokens procesados y qué parte corresponde a capacidad ociosa mantenida para garantizar determinados tiempos de respuesta.

Es un ejemplo claro de por qué optimizar costes no equivale siempre a minimizar recursos.

El mejor FinOps también puede consistir en cambiar de arquitectura

Hay una cuestión que debería plantearse antes incluso del rightsizing:

¿está cada carga ejecutándose en el modelo de infraestructura adecuado?

El pago por uso tiene ventajas claras cuando existe una demanda impredecible. Una aplicación que necesita multiplicar su capacidad durante unas horas puede beneficiarse enormemente de la elasticidad.

La situación cambia con una carga que mantiene prácticamente los mismos recursos las 24 horas durante años.

Una base de datos empresarial, un ERP, un clúster de virtualización o una plataforma interna estable pueden justificar comparar el coste real del cloud público con alternativas de cloud privado, servidores dedicados, infraestructura propia o arquitecturas híbridas.

La comparación tampoco debería reducirse al precio de una vCPU.

Hay que incluir almacenamiento, tráfico, licencias, soporte, backups, redundancia, operaciones, personal, seguridad, recuperación ante desastres y coste de capacidad ociosa.

Precisamente Flexera señala que entre los desafíos de las migraciones está ganando peso la comparación económica entre infraestructura local y cloud, mientras las organizaciones intentan incorporar el coste antes en las decisiones arquitectónicas, una práctica conocida como shift-left FinOps.

Esto introduce una idea relevante: una organización puede realizar un rightsizing impecable y seguir pagando demasiado si la arquitectura de partida no encaja con el comportamiento de la carga.

También puede suceder lo contrario. Trasladar una aplicación variable a infraestructura fija exclusivamente porque el coste mensual parece inferior puede obligar a sobredimensionarla para cubrir sus picos.

FinOps debería ayudar a decidir qué modelo encaja con cada carga, no defender uno de ellos por defecto.

De showback a responsabilidad económica

La atribución del gasto también puede cambiar la relación entre departamentos.

Con showback, cada equipo conoce cuánto consume aunque el presupuesto siga centralizado. Un departamento puede descubrir que sus entornos representan 18.000 euros mensuales aunque la factura continúe pagándose desde IT.

El chargeback va un paso más allá: esos costes se imputan al presupuesto correspondiente.

Ambos modelos pueden cambiar comportamientos porque acercan la decisión técnica a su consecuencia económica.

Pero la atribución debe ser fiable. Si una plataforma compartida presta servicio a veinte aplicaciones, repartir arbitrariamente su coste entre ellas puede producir indicadores aparentemente precisos pero poco útiles.

Las economías unitarias intentan resolver la siguiente etapa.

Una empresa de comercio electrónico puede medir coste de infraestructura por pedido. Una plataforma SaaS, coste por cliente activo. Una aplicación de IA, coste por conversación o millón de tokens. Una plataforma interna, coste por entorno o servicio.

Así se puede distinguir entre gastar más porque el negocio está creciendo y gastar más porque la infraestructura es menos eficiente.

La IA abre un nuevo frente para FinOps

Los datos de 2026 muestran por qué este asunto va a adquirir todavía más importancia.

El 58 % de los encuestados por Flexera ya utiliza servicios de IA generativa en cloud público y el porcentaje de gasto desperdiciado en IaaS y PaaS ha vuelto a subir hasta el 29 %.

Otro estudio de la compañía centrado en gestión de activos tecnológicos encontró que únicamente el 31 % de las organizaciones afirma tener visibilidad sobre su software de IA, mientras que el 59 % asegura que el gasto desperdiciado relacionado con IA aumentó durante el último año.

Esto introduce nuevas preguntas para los equipos de infraestructura.

¿Cuánto cuesta realmente cada modelo? ¿Qué GPU está infrautilizada? ¿Compensa mantener un modelo cargado para reducir latencia? ¿Sale más económico utilizar una API externa o ejecutar inferencia propia? ¿Qué departamento está generando los tokens? ¿Cuánto cuesta cada petición después de sumar GPU, almacenamiento, red y plataforma?

Son problemas FinOps aunque ya no se parezcan demasiado a revisar una factura de máquinas virtuales.

La disciplina está evolucionando porque también lo está haciendo la infraestructura.

El objetivo final sigue siendo relativamente sencillo: que el coste deje de descubrirse después de tomar la decisión técnica.

Cuando arquitectura, ingeniería, operaciones, negocio y finanzas pueden conocer previamente cuánto cuesta una decisión y medir después el valor que produce, FinOps deja de ser una campaña periódica para rebajar la factura.

Pasa a formar parte del diseño de la infraestructura.

Preguntas frecuentes

¿Qué es FinOps?

FinOps es una práctica de gestión que relaciona el consumo tecnológico con su coste y el valor obtenido por la organización. Requiere colaboración entre ingeniería, operaciones, finanzas y negocio y no se limita a reducir la factura cloud.

¿Qué costes cloud deberían revisarse además de CPU y memoria?

Almacenamiento, snapshots, transferencia de datos, egress, direcciones IP, balanceadores, servicios gestionados, observabilidad, soporte y licencias pueden representar una parte relevante. En Kubernetes e IA también resulta importante atribuir capacidad compartida y GPU a aplicaciones, equipos y modelos concretos.

¿Qué son las economías unitarias en FinOps?

Consisten en relacionar el coste tecnológico con una unidad útil para el negocio. Algunos ejemplos son coste por cliente, transacción, pedido, servicio, conversación de IA o millón de tokens procesados.

¿FinOps sirve también para cloud privado y centros de datos?

Sí. El marco actual de FinOps se centra en el valor de la tecnología y puede utilizarse para comparar diferentes modelos de infraestructura. Una decisión madura puede combinar cloud público, privado, dedicado y recursos propios según elasticidad, utilización, requisitos técnicos y coste total.