Escalar capacidad sin escalar costos: por qué FinOps dejó de ser un tema financiero

Las conversaciones sobre escalar en las organizaciones casi siempre son sobre capacidad: cuántos equipos, cuánta infraestructura, cuánto volumen puede soportar el sistema.

Falta la otra mitad. Escalar capacidad sin entender cómo escalan los costos es peligroso incluso en infraestructura tradicional, donde al menos la relación entre uso y gasto es relativamente lineal. En sistemas con modelos, agentes, aceleradores, bases vectoriales, observabilidad y múltiples proveedores, esa relación deja de ser intuitiva.

El resultado que hay que evitar es específico y perfectamente alcanzable: mejorar la productividad de los equipos y destruir simultáneamente la economía unitaria del servicio.

Por qué el costo se volvió una variable de arquitectura

En una arquitectura tradicional, el costo es en gran medida consecuencia del volumen: más usuarios, más servidores, más gasto. La optimización es un ejercicio de eficiencia posterior.

En una arquitectura con modelos, el costo se determina en decisiones de diseño que se toman mucho antes de que exista volumen:

• Qué modelo se invoca para cada tipo de tarea.
• Cuánto contexto se envía en cada llamada.
• Si hay caché y qué proporción de solicitudes evita.
• Cuántos intentos se hacen antes de dar por fallida una tarea.
• Cuánta traza se almacena y por cuánto tiempo.
• Si el agente reintenta automáticamente y con qué límite.

Cada una de esas decisiones puede cambiar el costo por operación en órdenes de magnitud. Y todas se toman durante la implementación, generalmente sin que nadie calcule su efecto económico, porque en el piloto el volumen es bajo y el costo es irrelevante.

El problema aparece al escalar: la decisión que era irrelevante con cien casos diarios se vuelve dominante con cien mil.

Lo que hay que poder ver

Una organización que gestiona esto bien puede desagregar su costo en varias dimensiones simultáneas:

Por producto o cadena de valor. Cuánto cuesta operar cada producto. Sin esto no hay conversación posible sobre rentabilidad por línea.

Por ambiente. Cuánto se gasta en producción, en pruebas, en desarrollo. Los ambientes que no son producción concentran una proporción del gasto que suele sorprender, especialmente cuando quedan recursos activos que nadie usa.

Por modelo. Qué proporción del gasto va a cada modelo. Habitualmente revela que una fracción del volumen consume la mayoría del presupuesto, generalmente por usar el modelo más caro para tareas que no lo requieren.

Por agente. Cuánto consume cada agente. Sin esta desagregación, un agente con un defecto que genera reintentos infinitos es invisible hasta que llega la factura.

Por tarea exitosa. El número que integra todo lo anterior con la calidad del resultado.

Los mecanismos de control

Ver el costo es la mitad. La otra mitad es acotarlo por diseño.

Presupuestos y cuotas. Límites por agente, por equipo, por período, aplicados por el sistema. Un límite que depende de que alguien revise un tablero no es un límite.

Enrutamiento de modelos. Dirigir cada tipo de tarea al modelo adecuado en vez de usar el más capaz para todo. La mayoría de las tareas de clasificación, extracción o resumen no requieren el modelo más costoso disponible.

Caché. Muchas solicitudes se repiten o se parecen mucho. Una capa de caché bien diseñada puede eliminar una proporción sustancial del volumen facturado sin ningún efecto sobre la experiencia.

Alternativas ante fallas. Qué pasa cuando un proveedor no responde. Sin una alternativa definida, la falla se convierte en indisponibilidad o en reintentos que multiplican el gasto.

Análisis de desperdicio. Qué proporción del gasto no produjo ningún resultado utilizable: intentos fallidos, ambientes ociosos, datos almacenados que nadie consulta, agentes que quedaron corriendo.

Showback antes que chargeback

Hay una decisión organizacional sobre cómo se distribuye la visibilidad del costo, y el orden importa.

Showback significa mostrar a cada equipo cuánto cuesta lo que opera, sin cargarlo a su presupuesto. Chargeback significa cargarlo efectivamente.

Empezar por showback funciona mejor por un motivo práctico: la mayoría de los equipos no conoce el costo de lo que construye, y el simple hecho de mostrárselo produce optimizaciones que nadie tuvo que pedir. La reacción típica ante el primer reporte es descubrir algo evidentemente desproporcionado y arreglarlo esa misma semana.

Pasar a chargeback antes de que exista esa visibilidad convierte la conversación en un conflicto de asignación presupuestaria y consume la energía que debería ir a optimizar.

Dónde ubicar esta capacidad

El error organizacional más frecuente es tratar FinOps como una función financiera que revisa el gasto después de que ocurrió. En ese lugar, la capacidad no puede hacer casi nada: las decisiones que determinan el costo ya se tomaron meses antes, en el diseño.

La ubicación efectiva es junto a producto, plataforma y portafolio. En producto, porque el costo de servir es un componente de la propuesta de valor. En plataforma, porque las decisiones de arquitectura determinan la estructura de costos de todos los equipos. En portafolio, porque la asignación de capital debería considerar el costo operativo esperado, no solo el de construcción.

Del piloto a producción: donde la economía cambia

Hay un momento específico en que la economía de un sistema con modelos deja de comportarse como en el piloto, y conviene anticiparlo porque toma a mucha gente por sorpresa.

En el piloto, el volumen es bajo, el uso es de personas entusiastas que formulan buenas consultas, y el costo total es lo bastante pequeño como para que nadie lo mire. Las decisiones de diseño se toman optimizando calidad, que es lo correcto en esa etapa.

Al pasar a producción cambian cuatro cosas a la vez.

El volumen se multiplica, y con él todo lo que se decidió sin considerar su costo unitario.

La calidad de las consultas baja. Los usuarios generales formulan peor que los entusiastas del piloto, lo que aumenta los reintentos, las respuestas insatisfactorias y las conversaciones largas para llegar al mismo resultado.

Aparece uso no anticipado. La gente usa el sistema para cosas que nadie diseñó, algunas de las cuales son mucho más costosas que el caso previsto.

La cola larga domina. En el piloto se prueban casos representativos. En producción, una fracción considerable del volumen son casos raros, que suelen consumir más contexto e intentos.

El efecto combinado es que el costo por operación en producción suele ser sustancialmente mayor que el medido en el piloto, y esa diferencia rara vez está en la proyección con la que se aprobó el despliegue.

Hay tres protecciones que se pueden aplicar antes de escalar y que cuestan poco.

Estimar el costo unitario con los casos peores del piloto, no con el promedio. Definir un presupuesto máximo por operación que el sistema aplique, de modo que una consulta anómala se detenga en vez de consumir sin límite. Y establecer un umbral de volumen a partir del cual se revisa la arquitectura de costos, decidido de antemano y no cuando llegue la factura.

Esa tercera es la más valiosa y la más fácil de omitir. Sin un punto de revisión definido, la conversación sobre costos ocurre cuando el número ya duele, que es también cuando cambiar el diseño es más caro.

Una pregunta para el próximo diseño

Cuando un equipo proponga una nueva capacidad con modelos, además de las preguntas habituales sobre funcionalidad y riesgo, conviene agregar una: ¿cuál es el costo estimado por operación a volumen esperado, y qué decisiones de diseño lo dominan?

Si nadie puede responderla, la respuesta se va a descubrir en la factura del tercer mes. Y para entonces, las decisiones que la determinaron ya están incorporadas al sistema y cambiarlas cuesta bastante más de lo que habría costado pensarlas antes.