Cuando la factura de la nube sube, el primer reflejo es buscar a un culpable. «¿Quién pidió esta m5.4xlarge?», «¿por qué este servicio tiene 8 GB de memoria para una carga de 200 MB?». Un modelo cómodo, y falso. El sobregasto en la nube casi nunca es consecuencia de la negligencia. Es la suma previsible de muchas decisiones localmente racionales que, juntas, dan un resultado colectivamente irracional. Y mientras FinOps intente curarlo con sermones, nada cambia.
Sobreaprovisionamiento defensivo: cada uno tiene razón por separado
Veamos un escenario típico. Un servicio murió una vez por OOM a las tres de la madrugada. El ingeniero de guardia duplicó el memory request — y tenía razón: nadie quiere ser aquel cuyo nombre firma el incidente. Otra vez la latencia se disparó durante una campaña publicitaria, así que subieron la CPU «con margen en toda la línea». También razonable: un pico cuesta más que el hardware.
Cada una de estas decisiones, por sí sola, es prudente y justificada. Pero si sumas N decisiones así a lo largo de cientos de servicios durante un par de años, obtienes la imagen que revela cualquier auditoría: el 70–80 % de la capacidad aprovisionada está ociosa. Nadie actuó de forma tonta. Lo tonto fue el sistema que premiaba la cautela y nunca mostraba su precio.
De ahí la conclusión que cambia toda la práctica: culpar a un ingeniero por el sobreaprovisionamiento es inútil. No es un problema individual, sino sistémico — y hay que resolverlo de forma sistémica:
- Visibilidad en el punto de la decisión. Una anotación de coste en el propio PR: «este cambio añade 40 $/mes». No un informe dos meses después, cuando el contexto se ha olvidado, sino una cifra en el momento en que el ingeniero todavía tiene el cambio en la cabeza.
- Defaults sensatos en el paved path. HPA target 70 %, requests dimensionados según P95/P99 y no según el pico máximo. La mayoría de la gente acepta el default — así que haz que el default sea correcto.
- VPA en modo advisory. «Solicitado 1 GB, P99 observado — 200 MB». No un recorte automático, sino información: la decisión sigue siendo del ingeniero, solo que ahora es una decisión informada.
- Responsabilidad colectiva en lugar de personal. Una mecánica al estilo del error budget: un equipo supera su objetivo de coste trimestral, así que el siguiente sprint reserva tiempo para un rightsizing. La responsabilidad recae en el equipo, no en un chivo expiatorio.
Showback antes que chargeback
De la misma lógica nace una regla de orden. El chargeback — cargar realmente el gasto al presupuesto del equipo — parece el mecanismo «honesto». Pero desplegado sin preparación genera billing friction: la gente empieza a discutir las cifras, a esconder recursos bajo etiquetas ajenas, a ver FinOps como la agencia tributaria.
El showback — «esto es lo que gastó vuestro equipo», sin cargo — casi siempre logra una reducción de costes significativa por sí solo. La visibilidad funciona sin coerción: basta con mostrarle a un ingeniero el coste de su servicio y él mismo empezará a optimizarlo, porque el orgullo profesional es más fuerte que el miedo al presupuesto. Primero mostrar; luego, si la madurez llega, cobrar. El chargeback sin showback previo es un dolor que nadie firmó.
El LLM como nueva línea de coste variable
En 2026 esta lógica ganó una dimensión nueva. Los agentes de IA en DevOps — triaje, bots de Slack, workflows agénticos — convirtieron las llamadas a las API de LLM en una línea visible de la factura de la nube. Y aquí está la misma trampa de la racionalidad local, solo que invertida: caro no porque alguien se sobreasegurara, sino porque se eligió la herramienta sin atender a la tarea.
Un modelo de razonamiento a 75 $ por millón de tokens de salida, lanzado sobre un rutinario kubectl get pods, es «un ingeniero principal al que llaman para cambiar una bombilla». Por separado — «es que es más listo». En conjunto — una factura que nadie presupuestó. La disciplina es la misma que con la infraestructura:
- Enrutado de modelo por tarea. Las operaciones frecuentes y repetitivas van a modelos baratos/gratuitos; el razonamiento se reserva para investigaciones profundas y poco frecuentes.
- Detección de desajuste — un modelo caro en una tarea barata es un buen indicador de gasto oculto.
- Etiquetas de coste en las claves de API. Trata una clave como una instancia EC2: team / service / cost-center son obligatorios. De lo contrario, dentro de medio año nadie recordará qué agente quemó el presupuesto.
Un caso real: cuatro crons de monitorización que lanzaban cientos de llamadas al día sobre un modelo de razonamiento caro lograron un −80–85 % de coste de LLM tras mover la rutina a un free tier. La arquitectura no cambió — lo que cambió fue el ajuste entre herramienta y tarea.
Qué se deduce de esto
FinOps no es un «equipo de recorte de costes» al que los ingenieros empiezan a resistirse. Es una disciplina de ingeniería que reconoce: la gente en la nube actúa de forma racional dentro de la información que tiene. ¿Quieres un resultado distinto? Cambia no a las personas, sino su entorno de información. Visibilidad en el momento adecuado, defaults correctos, feedback a nivel de equipo. El coste pasa a ser parte de la decisión de ingeniería — y no una sorpresa a fin de mes.