El servicio de IA ya tiene SLOs, alertas, postmortems y un golden set que se corre cada semana. Entonces llega la conversación con finanzas: “La factura de modelos subió 40% este trimestre. ¿Eso es bueno o malo?” Si el equipo solo puede responder con el total mensual del proveedor, no hay forma de saberlo. Puede ser señal de adopción sana o de un prompt que creció sin control.
Esta pieza da el siguiente paso del arco operativo que venimos construyendo: después de la evaluación continua con golden sets y umbrales de degradación, toca conectar la calidad con el costo. Hablamos de FinOps de IA: la práctica de medir, asignar y optimizar el gasto de modelos, infraestructura y operación humana por unidad de valor de negocio, sin sacrificar la calidad que ya sabes medir.
Por qué el total mensual no sirve para decidir
La factura del proveedor de modelos, la de la nube y la nómina del equipo que revisa excepciones viven en tres lugares distintos. Cuando se suman al final del mes, el número no dice qué caso de uso lo generó, si el volumen creció o si cada transacción se volvió más cara. Tres patrones aparecen una y otra vez en empresas de México y LatAm:
- Costo invisible por caso de uso. Varios copilotos comparten la misma llave de API y nadie sabe cuál consume más.
- Deriva silenciosa del prompt. Cada mejora agrega contexto, ejemplos o documentos recuperados. Meses después, cada llamada consume el triple de tokens y nadie lo decidió explícitamente.
- Costo humano fuera del cálculo. La cola de excepciones y la revisión manual cuestan más que el modelo, pero no aparecen en el tablero de IA.
La salida no es recortar a ciegas. Es cambiar la unidad de medida: del gasto total al costo por transacción exitosa.
La métrica central: costo por transacción exitosa
Una transacción es la unidad de trabajo que el negocio reconoce: un ticket resuelto, una factura conciliada, una cotización enviada, una solicitud de crédito pre-evaluada. El costo por transacción exitosa suma todo lo que cuesta producir esa unidad y lo divide entre las que realmente cumplieron el criterio de calidad.
| Componente | Qué incluye | Fuente típica |
|---|---|---|
| Inferencia | Tokens de entrada y salida, llamadas a embeddings, reintentos | Logs del gateway o del proveedor de modelos |
| Recuperación y datos | Búsqueda vectorial, almacenamiento, integraciones con ERP o CRM | Facturación de nube por etiqueta |
| Infraestructura propia | Cómputo, colas, observabilidad, entornos de evaluación | Facturación de nube por proyecto |
| Operación humana | Revisión de excepciones, auditoría de calidad, soporte de segundo nivel | Horas registradas por la cola de excepciones |
El denominador importa tanto como el numerador. Si divides entre todas las transacciones, premias al sistema que responde rápido y mal. Si divides solo entre las que pasan la rúbrica de calidad, el costo de un error queda visible: cada respuesta fallida es costo sin valor.
Paso 1: etiquetar cada llamada desde el primer día
No puedes asignar lo que no etiquetaste. Antes de optimizar, asegúrate de que cada llamada al modelo lleve, como mínimo, estas etiquetas en el log del gateway:
- Caso de uso y versión del prompt.
- Modelo y proveedor usados.
- Área de negocio o centro de costo que se beneficia.
- Identificador de la transacción de negocio, para unir costo con resultado.
- Resultado: aprobada, escalada a humano, reintento o fallo.
Con eso puedes construir un tablero semanal por caso de uso. Si ya tienes la observabilidad de IA en producción montada, se trata de agregar campos al mismo pipeline, no de crear uno nuevo.
Paso 2: presupuesto de tokens por caso de uso
Así como el error budget limita cuánta mala calidad toleras, un presupuesto de tokens limita cuánto puede crecer el consumo por transacción sin una decisión explícita. Funciona en dos niveles:
- Techo por transacción. Un máximo de tokens de entrada y salida por llamada típica. Si un cambio de prompt o de retrieval lo supera, pasa por change control como cualquier otro cambio relevante.
- Presupuesto mensual por caso de uso. Un monto acordado con finanzas y con el dueño del proceso, con alertas al 70% y al 90% de consumo.
El objetivo no es frenar la adopción. Si el volumen sube porque más áreas usan el servicio y el costo unitario se mantiene, la conversación con finanzas es sobre ampliar el presupuesto con evidencia. Si el costo unitario sube sin mejora de calidad, es una regresión y se trata como tal.
Paso 3: dibujar la curva costo-calidad
Cada configuración del servicio (modelo, longitud del prompt, cantidad de documentos recuperados, número de pasos del agente) tiene un costo y una calidad medible con tu golden set. Si corres el golden set con tres o cuatro configuraciones y las pones en una gráfica, casi siempre aparece la misma forma: una curva que sube rápido y luego se aplana.
Esa zona plana es donde se pierde dinero. Pasar de un modelo grande a uno todavía más grande puede duplicar el costo por transacción para ganar uno o dos puntos de calidad que el negocio no percibe. Al revés, bajar demasiado puede ahorrar centavos y disparar la cola de excepciones, que es mucho más cara.
La decisión se vuelve explícita: ¿cuál es la configuración más barata que cumple el SLO de calidad con margen? Esa es tu configuración de referencia. Todo lo que esté por encima necesita una justificación de negocio.
Paso 4: palancas de optimización, en orden de riesgo
Con la curva a la vista, las optimizaciones dejan de ser intuición. Este es un orden razonable, de menor a mayor riesgo para la calidad:
| Palanca | Qué hace | Riesgo para la calidad |
|---|---|---|
| Caché de respuestas y de contexto | Reutiliza resultados para preguntas o documentos repetidos | Bajo, si se invalida cuando cambia la fuente |
| Recorte de prompt y retrieval | Elimina instrucciones redundantes y documentos poco relevantes | Bajo a medio; validar con golden set |
| Ruteo por complejidad | Casos simples a un modelo pequeño, casos difíciles al grande | Medio; requiere un clasificador confiable |
| Procesamiento por lotes | Agrupa tareas no urgentes en horarios o tarifas más baratas | Bajo para calidad, medio para latencia |
| Cambio de modelo base | Migra a un modelo distinto o a uno propio | Alto; tratar como cambio mayor con modo sombra |
Cada palanca se valida igual que cualquier cambio: corrida del golden set antes y después, revisión de la rúbrica en los ejes bloqueantes y, si el impacto es grande, un periodo en modo sombra. Ahorrar sin medir calidad no es FinOps; es apostar.
Ejemplo hipotético: conciliación de facturas en una distribuidora
Para aterrizarlo, pensemos en un caso ilustrativo (no es un cliente real): una distribuidora en el Bajío usa IA para conciliar facturas de proveedores contra órdenes de compra en su ERP. El servicio cumple su SLO de calidad, pero la factura de modelos crece cada mes.
Al etiquetar las llamadas, el equipo descubre que cada conciliación envía al modelo el catálogo completo de productos del proveedor. Además, una de cada cinco transacciones se reintenta por timeouts de integración, no por errores del modelo. Las acciones son tres: recuperar solo las partidas de la orden relevante, corregir el timeout en la integración y rutear las facturas con coincidencia exacta de montos a una regla determinística, sin modelo.
Después de validar con el golden set, la calidad se mantiene en verde y el costo por transacción exitosa baja de forma visible. Más importante: el equipo ahora puede explicarle a finanzas por qué el gasto sube cuando sube el volumen y por qué eso es una buena noticia.
Gobierno: quién decide sobre el costo
FinOps de IA falla cuando el costo es “problema de TI” y la calidad es “problema del negocio”. Define roles desde el inicio:
- Dueño del caso de uso: responde por el costo por transacción y por el SLO de calidad al mismo tiempo.
- Equipo de plataforma: mantiene etiquetado, tablero, caché y ruteo como capacidades compartidas.
- Finanzas: aprueba presupuestos mensuales y revisa la tendencia del costo unitario, no solo el total.
Un ritual mensual de 45 minutos basta: tendencia de costo unitario por caso de uso, consumo contra presupuesto, posición en la curva costo-calidad y decisiones de optimización para el siguiente mes, registradas en el backlog.
Checklist para arrancar esta semana
- Definir la transacción de negocio de cada caso de uso de IA en producción.
- Agregar etiquetas de caso de uso, versión de prompt, modelo y transacción a cada llamada.
- Calcular el primer costo por transacción exitosa, incluyendo operación humana.
- Fijar techo de tokens por transacción y presupuesto mensual con alertas.
- Correr el golden set con al menos tres configuraciones y dibujar la curva costo-calidad.
- Elegir la configuración de referencia y la primera palanca de optimización de bajo riesgo.
- Agendar el ritual mensual con dueño del caso, plataforma y finanzas.
Cierre
La pregunta correcta no es cuánto cuesta la IA, sino cuánto cuesta cada resultado de negocio que entrega con la calidad acordada. Cuando el costo por transacción exitosa está en el mismo tablero que el SLO de calidad, las decisiones de modelo, prompt y arquitectura dejan de ser debates de opinión y se vuelven decisiones de inversión. Es la pieza que conecta la operación de IA con el ROI que el comité directivo quiere ver.
¿Quieres saber cuánto te cuesta cada resultado de tu IA?
En NextWave AI ayudamos a equipos B2B en México y LatAm a montar etiquetado de costos, presupuestos de tokens y curvas costo-calidad sobre servicios de IA que ya están en producción. Escríbenos a contacto@nextWaveAI.AI o llámanos al +52 (33) 3126 6969.
Add comment