FinOps para IA: el costo de modelos y agentes en producción

Un piloto de IA generativa suele costar poco. Unas cuantas personas prueban un asistente, la factura del proveedor apenas se mueve y nadie se preocupa. El problema aparece cuando ese mismo asistente pasa a producción, se convierte en un agente que encadena pasos y llamadas a herramientas, y atiende a miles de usuarios. La factura deja de ser una línea menor y, sobre todo, se vuelve difícil de explicar: nadie sabe con certeza qué agente, qué caso de uso o qué cambio de instrucciones la hizo crecer.

FinOps ya resolvió una versión de este problema para la nube: hacer visible el gasto, atribuirlo a quien lo genera y decidir con datos. La FinOps Foundation trabaja desde hace tiempo en extender esas prácticas a la IA. Este artículo baja esa idea a la operación: de qué se compone el costo de un agente, cómo medirlo por unidad de negocio, cómo atribuirlo y qué palancas lo controlan.

Por qué la IA no se comporta como el resto de la nube

En la nube tradicional, el costo sigue de cerca a la capacidad: máquinas, almacenamiento, tráfico. Si sabes cuántos servidores tienes y cuánto tiempo están encendidos, tienes una buena estimación. Con modelos de lenguaje consumidos como servicio, el costo sigue al uso, y el uso depende de factores que no se ven en un inventario:

• Se cobra por token, la unidad en que el modelo divide el texto. Los proveedores publican precios distintos para tokens de entrada (lo que envías) y de salida (lo que el modelo genera), y la salida suele costar varias veces más por token.
• Lo que se envía es mucho más que la pregunta del usuario. Cada llamada incluye instrucciones del sistema, historial de la conversación, documentos recuperados y resultados de herramientas. Ese contexto crece en cada paso.
• Un agente hace varias llamadas por solicitud. Planifica, consulta una herramienta, evalúa el resultado y vuelve a llamar al modelo. Una sola pregunta puede generar diez llamadas.
• El comportamiento cambia sin cambiar la infraestructura. Una modificación en las instrucciones, un modelo nuevo o un documento más largo en la base de conocimiento pueden duplicar el consumo sin que nadie toque un servidor.

Por eso los controles clásicos (rightsizing, reservas, apagado fuera de horario) siguen siendo útiles para la infraestructura que rodea al modelo, pero no alcanzan. Si ya trabajas el rightsizing continuo, la disciplina es la misma; cambia la unidad que hay que vigilar.

De qué se compone el costo de una solicitud

Conviene descomponer el costo de una solicitud a un agente en sus partes, porque cada una tiene una palanca distinta.

• Tokens de entrada. Instrucciones del sistema, historial, documentos recuperados y resultados de herramientas. En agentes suele ser el componente más grande, porque el contexto se reenvía en cada llamada.
• Tokens de salida. Lo que el modelo genera, incluido el razonamiento intermedio cuando el modelo lo factura. Menos volumen, mayor precio unitario.
• Inferencia y capacidad. Si el modelo se consume bajo demanda, este costo está dentro del precio por token. Si usas capacidad reservada o GPU propias, se paga por hora, se use o no, y el riesgo pasa a ser la capacidad ociosa.
• Recuperación. Generar embeddings de documentos y consultas, almacenarlos en una base vectorial y consultarla. Suele ser un costo menor por solicitud, pero fijo y creciente con el volumen de documentos.
• Llamadas a herramientas. APIs internas o de terceros que el agente invoca. Algunas tienen costo propio; todas agregan tokens de entrada cuando su resultado vuelve al modelo.
• Reintentos y bucles. Errores de formato, tiempos de espera o un agente que no logra cerrar la tarea repiten llamadas completas. Es el componente más fácil de pasar por alto y el que produce los picos.
• Registro y evaluación. Guardar trazas para auditoría y evaluar calidad, a veces con otro modelo que actúa como evaluador. Es un costo necesario, pero hay que presupuestarlo.

Un ejemplo ilustrativo, con precios hipotéticos que no corresponden a ningún proveedor: un agente de soporte hace 6 llamadas al modelo por conversación, con 8.000 tokens de entrada y 500 de salida en promedio cada una. Son 48.000 tokens de entrada y 3.000 de salida. Si la entrada costara 3 USD por millón y la salida 15 USD por millón, la conversación costaría unos 0,14 USD de entrada y 0,05 USD de salida. Observa que la entrada pesa más del triple que la salida, aunque su precio por token sea cinco veces menor.

Métricas de costo unitario

El costo total mensual responde a "cuánto gastamos", pero no a "si vale la pena". Para eso hace falta un costo unitario ligado a algo que el negocio reconozca. Recomendamos tres niveles:

1. Costo por solicitud o por llamada. Útil para ingeniería: detecta cambios de comportamiento después de un despliegue.
2. Costo por conversación o por tarea. Útil para el dueño del producto: refleja la experiencia completa del usuario.
3. Costo por resultado. Por ticket resuelto, por solicitud cumplida, por documento procesado. Es la métrica que se compara con el valor.

Siguiendo el ejemplo anterior: si la conversación cuesta 0,19 USD y solo el 60% de las conversaciones resuelve el ticket sin intervención humana, el costo por ticket resuelto es de unos 0,32 USD (0,19 / 0,6). Si una mejora de calidad sube la tasa de resolución, el costo por resultado baja aunque el costo por conversación se mantenga. Esa es la razón para medir por resultado: evita optimizar el gasto a costa de la calidad.

Dos advertencias. Primero, "resuelto" tiene que estar definido antes de medir, con un criterio de calidad explícito. Segundo, el costo de un agente varía mucho entre solicitudes, así que conviene reportar distribuciones (mediana y percentil 95), no solo promedios. El valor que se compara contra este costo se mide con el mismo rigor que cualquier automatización; lo tratamos en cómo medir el valor de la automatización.

Atribución y etiquetado

Sin atribución no hay responsables, y sin responsables el gasto solo crece. El reto con la IA es que la factura del proveedor suele mostrar el consumo por modelo y por cuenta, no por agente ni por caso de uso. La atribución hay que construirla en dos capas:

• En la infraestructura: cuentas, proyectos o suscripciones separadas por entorno y unidad de negocio, y etiquetas obligatorias (agente, caso de uso, dueño, centro de costo, entorno) en todos los recursos que lo permiten: endpoints, bases vectoriales, almacenamiento de trazas.
• En la aplicación: cada llamada al modelo registra quién la hizo, para qué agente, en qué conversación y cuántos tokens consumió. Esta telemetría es la que permite repartir el costo de un endpoint compartido entre varios agentes.

Un punto de entrada común para todas las llamadas (un gateway de modelos) facilita las dos cosas: aplica etiquetas, mide tokens y hace cumplir límites en un solo lugar. Es el mismo patrón que recomendamos para gobernar agentes y sus herramientas con MCP.

Para consolidar datos de varios proveedores, la especificación FOCUS de la FinOps Foundation (versión 1.0, publicada en 2024) define un formato común para datos de facturación, con columnas como el costo facturado, el costo efectivo, el servicio, la cantidad consumida y las etiquetas. Normalizar a FOCUS permite unir la factura de la nube, la del proveedor de modelos y la de otros servicios en un mismo análisis.

Presupuestos y límites por agente

En la nube, un presupuesto que avisa al superar el 80% suele ser suficiente. Con agentes no lo es: un bucle puede consumir el presupuesto de un mes en horas. Recomendamos límites en varios niveles, aplicados por el gateway o la plataforma del agente:

• Por solicitud: máximo de pasos, de llamadas al modelo y de tokens de salida. Al alcanzarlo, el agente se detiene y escala a una persona.
• Por conversación o tarea: un tope de costo acumulado, con el mismo comportamiento.
• Por agente y período: cuota diaria o mensual con alertas al 50%, 80% y 100%, y una decisión explícita sobre qué ocurre al llegar al tope (degradar a un modelo más económico, pasar a modo solo recomendación o detenerse).
• Detección de anomalías: comparar el costo por solicitud con su línea base y alertar ante desvíos, por ejemplo después de un cambio de instrucciones o de modelo.

Estos límites son también controles de seguridad: un agente manipulado para que repita acciones queda acotado por los mismos topes. Lo desarrollamos en barreras de seguridad para agentes de IA.

Palancas para bajar el costo sin perder calidad

Ninguna palanca se aplica a ciegas. Cada cambio se valida con el mismo conjunto de evaluaciones de calidad antes de llegar a producción.

Palanca	Qué hace	Cuándo conviene	Riesgo a vigilar
Elección y enrutamiento de modelo	Usa un modelo pequeño para tareas simples y reserva el grande para las complejas	Cuando hay tareas de clasificación, extracción o resumen	Caída de calidad en casos límite
Caché de prompts	Reutiliza el prefijo repetido (instrucciones, catálogo de herramientas) a un precio menor	Instrucciones largas y estables entre llamadas	Cambios frecuentes del prefijo anulan el ahorro
Tamaño de contexto	Recorta historial, resume conversaciones y recupera menos fragmentos pero más relevantes	Agentes con conversaciones largas o muchos documentos	Perder información que el modelo necesitaba
Procesamiento por lotes	Envía trabajos no urgentes en modo batch, que algunos proveedores cobran más barato	Clasificación masiva, evaluaciones, reprocesos nocturnos	Mayor latencia; no sirve para interacción en vivo
Límite de salida	Pide respuestas estructuradas y breves, con tope de tokens	Respuestas que consume otro sistema	Respuestas truncadas
Control de reintentos	Valida el formato antes de reintentar y limita los pasos por tarea	Siempre	Escalar demasiado pronto a una persona
Capacidad reservada	Paga capacidad fija a cambio de precio o disponibilidad garantizada	Volumen alto y estable	Capacidad ociosa si la demanda cambia

Para entender el modelo de cobro de tu proveedor, revisa su página de precios: la mayoría distingue tokens de entrada y salida, ofrece modalidades por lotes y de capacidad reservada, y algunas cobran aparte la lectura y escritura de caché. Las condiciones cambian con frecuencia, así que conviene revisar la estimación cada vez que cambies de modelo.

Un último criterio: cuando el costo de un agente afecta un presupuesto material o un servicio regulado, la decisión sobre límites y degradación no es solo de ingeniería. Conviene acordarla con Finanzas y, si el servicio toca clientes, con Riesgo.