La mayoría de los cuadros de mando de IA informan del coste por token o del coste por cada 1.000 llamadas. Esas cifras son fáciles de extraer de una API de facturación y fáciles de representar en una gráfica. También son casi inútiles para decidir si un flujo de trabajo merece la pena ejecutarse. Un CFO no compra tokens. Un CFO compra tickets resueltos, facturas conciliadas y borradores de memorandos. La unidad que se corresponde con el negocio es la tarea completada, y esa es la unidad que deberías estar midiendo.
Por qué el coste por token engaña en un flujo de trabajo agéntico
Para un único prompt y una única respuesta, el coste por token y el coste por tarea son aproximadamente lo mismo. Los flujos de trabajo agénticos rompieron esa equivalencia, y la rompieron en silencio.
Un agente moderno no hace una sola llamada al modelo para terminar un trabajo. Elabora un plan, llama a una herramienta, lee el resultado, decide que el resultado está incompleto, recupera más contexto, llama de nuevo al modelo y, a veces, entra en bucle. Ahora hay cuatro elementos entre “tarea iniciada” y “tarea terminada”, y cada uno infla el gasto en tokens sin aparecer en una vista ingenua por llamada:
- Reintentos. Una llamada a herramienta fallida, una salida JSON mal formada o un timeout desencadenan otro intento. Los reintentos consumen tokens y no producen nada que el negocio pueda vender.
- Llamadas a herramientas. Cada invocación de herramienta suele requerir que el modelo lea el resultado de la herramienta y razone sobre él. Una tarea con cinco herramientas puede suponer seis o siete idas y vueltas al modelo.
- Planes de varios pasos. Los patrones planificador-ejecutor gastan tokens en el propio plan, luego en cada paso y luego en una pasada de verificación.
- Recuperación (retrieval). Insertar los documentos recuperados en el prompt suele ser la partida individual más grande. Una pregunta de 2.000 tokens puede arrastrar 18.000 tokens de contexto.
El resultado: dos flujos de trabajo pueden tener tasas idénticas por token y costes por tarea terminada radicalmente distintos. El que tiene un 30 % de tasa de reintentos y una recuperación descuidada puede costar el triple por ticket resuelto y verse idéntico en un cuadro de mando de tokens. El coste por token mide el contador. El coste por tarea completada mide la factura.
Atribuir el coste a un flujo de trabajo, un rol y un equipo
No puedes calcular el coste por tarea completada si cada llamada al modelo cae en un único cubo indiferenciado. La atribución es el requisito previo, y el lugar para hacerla es el gateway.
Enruta cada llamada al modelo a través de un único gateway de IA, de modo que ningún equipo llame directamente a las APIs del proveedor. El gateway es el único punto de política de la arquitectura, así que también es el lugar natural para medir. En el gateway, etiqueta cada solicitud con al menos tres cosas:
- ID de flujo de trabajo (support-triage, invoice-clearing, memo-draft).
- Rol o paso dentro del flujo de trabajo (planner, retriever, drafter, verifier).
- Equipo propietario y un ID de correlación que vincule cada llamada de una tarea a una única traza.
El ID de correlación es lo que convierte llamadas dispersas en una unidad. Las trazas aterrizan en un trace lake dentro de tu propio entorno, escritas según las convenciones semánticas de OpenTelemetry GenAI para que el análisis de costes no quede rehén del formato de exportación de un único proveedor. Una traza reúne cada llamada al modelo, llamada a herramienta, recuperación y reintento de un intento de tarea bajo un único identificador. Suma el coste en tokens a lo largo de esa traza, divide entre el número de tareas que realmente se completaron (no las que se iniciaron) y tienes el coste por tarea completada de ese flujo de trabajo. Agrégalo por equipo para la vista de finanzas; profundiza en la traza para la vista de ingeniería. El gateway te da el gasto; la traza te da la estructura; la señal de finalización te da el denominador.
Regla práctica: si no puedes señalar la traza que produjo una cifra, la cifra es una estimación, no una medición.
La señal de finalización importa tanto como el coste. Una tarea está “completada” solo cuando cumple su criterio de aceptación: el ticket se resolvió y no se reabrió en 48 horas, la factura pasó la conciliación, el memorando superó la revisión. Contar tareas iniciadas en lugar de tareas completadas es la forma más común en que los equipos maquillan su propia economía.
Las cinco palancas que de verdad mueven la cifra
Una vez que puedes medir el coste por tarea completada, puedes moverlo. En nuestro trabajo, las mismas cinco palancas hacen la mayor parte, aproximadamente en orden de impacto.
1. Enrutamiento de modelos
La mayoría de los flujos de trabajo tienen una mayoría fácil y una minoría difícil. Alrededor del 80 % de los tickets de soporte son restablecimientos de contraseña, comprobaciones de estado y problemas conocidos. Enviarlos todos a tu modelo más grande es el hábito más caro de la IA en producción. Enruta el 80 % fácil a un modelo pequeño y rápido y reserva el modelo grande para los casos que un clasificador marque como ambiguos o de alto riesgo. Este único cambio suele reducir a la mitad el coste por tarea completada por sí solo.
2. Caché
Los prefijos de prompt, las instrucciones de sistema y los documentos recuperados con frecuencia se repiten en miles de tareas. La caché de prompts a nivel de gateway o de proveedor te permite pagar esos tokens una vez en lugar de una vez por llamada. La caché es más eficaz precisamente donde la recuperación es más pesada.
3. Calidad de la recuperación
Una recuperación mala cuesta el doble: una vez por los tokens desperdiciados que insertaste en el prompt, y otra por los reintentos cuando el modelo no pudo encontrar la respuesta entre el ruido. Ajustar la recuperación (mejor segmentación, reordenación, devolver tres pasajes relevantes en lugar de quince mediocres) reduce a la vez el tamaño del prompt y la tasa de fallos.
4. Tamaño del prompt
Los prompts de sistema largos y defensivos y los ejemplos few-shot prolijos se pagan en cada llamada. Recórtalos a lo que el modelo demostrablemente necesita. Mide la calidad antes y después; no recortes a ciegas.
5. Eliminar ejecuciones fallidas
Una ejecución que falla tras consumir tokens es coste puro con cero salida. La validación temprana, las salidas restringidas por esquema y los cortacircuitos que detienen a un agente en bucle tras N pasos eliminan ese desperdicio. Bajar la tasa de fallos del 30 % al 8 % reduce directamente el coste por tarea completada, porque el denominador (tareas completadas) deja de diluirse con intentos quemados.
Un ejemplo trabajado: triaje de soporte
Las cifras siguientes son ilustrativas, pero el patrón es uno que vemos repetidamente. El punto es la aritmética, así que la aritmética se muestra.
Un agente de triaje de soporte gestiona 10.000 intentos de ticket al mes. La primera versión enruta todo a un modelo grande, recupera quince pasajes de la base de conocimiento por ticket y tiene una tasa de fallos del 28 %: tickets que escalan a un humano después de que el agente se rinda, habiendo gastado ya tokens.
| v1 (antes) | v2 (con palancas) | |
|---|---|---|
| Tokens por intento | ~20.000 (recuperación pesada) | ~4.000 (enrutado + reordenado) |
| Coste mixto por intento | 1,01 $ | 0,35 $ |
| Tasa de fallos | 28 % | 9 % |
| Tickets completados / mes | 7.200 | 9.100 |
| Gasto mensual total | 10.080 $ | 3.486 $ |
| Coste por ticket completado | 1,40 $ | 0,38 $ |
Lee las dos columnas una contra la otra y las palancas se ven. El coste por intento cayó porque un clasificador envió el 80 % rutinario a un modelo pequeño y la reordenación recortó la recuperación de quince pasajes a tres, con los prefijos de sistema cacheados encima. El recuento de tickets completados subió porque un límite de pasos y un esquema de salida bajaron la tasa de fallos del 28 % al 9 %, de modo que menos intentos quemaron tokens sin producir un ticket resuelto. El denominador dejó de diluirse con desperdicio, y el numerador se aligeró al mismo tiempo.
La tasa por token apenas se movió en el 20 % difícil; el modelo grande sigue costando lo que cuesta. Lo que se movió fue la mezcla, el desperdicio y el peso del prompt. Ese es el punto. Optimizas el flujo de trabajo, no el token. La misma aritmética alimenta la capa de analítica de flujos de trabajo que finanzas y operaciones leen de verdad: coste por flujo de trabajo, tasa de éxito, razones de escalada, tiempo ahorrado y qué flujos de trabajo se han ganado el derecho a más autonomía.
La decisión de autonomía depende de esta métrica
El coste por tarea completada no es solo una cifra de finanzas. Es la puerta para aumentar la autonomía.
La tentación, una vez que un agente funciona, es ampliar su alcance y reducir la revisión humana. Hazlo basándote solo en datos de calidad y, tarde o temprano, pondrás en producción un flujo de trabajo que es preciso pero inasequible, o asequible pero que se degrada en silencio. La disciplina consiste en exigir ambas cosas:
- Calidad demostrada: el flujo de trabajo cumple su criterio de aceptación a la tasa objetivo, medido sobre tareas completadas, durante un periodo representativo.
- Coste demostrado: el coste por tarea completada es estable y se mantiene dentro del presupuesto que finanzas aprobó, sin deriva al alza oculta tras una tasa por token plana.
Solo cuando se cumplen ambas eliminas un punto de control o amplías el mandato del agente. Cada paso hacia más autonomía es una decisión que deberías poder defender con dos cifras de las mismas trazas: lo que cuesta terminar la tarea y con qué frecuencia la termina correctamente. Si solo puedes producir una de ellas, no estás listo para automatizar más.
Un cuadro de mando de tokens no puede responder a esa pregunta. El coste por tarea completada sí, que es exactamente por lo que es la métrica en la que confiará tu CFO y la que tus ingenieros deberían instrumentar primero.