El precio por millón de tokens es un dato de proveedor. No sirve para decidir nada. La pregunta de dirección es otra: cuánto cuesta resolver una tarea completa —tramitar una factura, contestar una reclamación, preparar una propuesta— y cuánto costaba antes hacerla a mano.
La tokeneconomics es traducir el consumo de modelos a esa unidad.
Del precio por token al coste por tarea
Una tarea rara vez es una llamada. Suele ser una cadena: leer un documento, extraer datos, consultar un sistema, redactar, revisar. Cada paso consume entrada y salida, y algunos se repiten cuando el primer intento no vale.
El coste por tarea se calcula sumando esa cadena completa, incluidos los reintentos, y dividiendo por las tareas efectivamente resueltas —no por las intentadas. Un sistema con un 30% de repeticiones cuesta bastante más de lo que dice el cálculo optimista.
Con esa cifra en la mano ya se puede hacer la comparación que importa: coste por tarea automatizada frente a coste por tarea manual, incluyendo el tiempo de la persona que revisa.
Las palancas que mueven la factura
Caché de contexto. Cuando muchas peticiones comparten un bloque grande e idéntico —un manual, un catálogo, unas instrucciones largas—, pagarlo en cada llamada es tirar dinero. La caché de contexto lo cobra una vez y lo reutiliza a precio reducido durante un tiempo. Es la palanca con mejor relación entre esfuerzo y ahorro.
Procesamiento por lotes. Lo que no necesita respuesta inmediata —clasificar el correo de la noche, resumir documentación, enriquecer un catálogo— puede enviarse en lote con un descuento notable a cambio de esperar. Buena parte de la carga de una empresa no es interactiva y se factura como si lo fuera.
Tamaño del prompt. Las instrucciones crecen solas: cada incidencia añade una frase y nadie quita nunca nada. Revisarlas y podarlas baja el coste de todas las llamadas a la vez.
Ventanas largas. Meter un expediente entero en el contexto es cómodo y a veces es lo correcto, pero se paga en cada llamada. Frente a recuperar solo lo relevante con RAG, la ventana larga gana en tareas puntuales de análisis profundo y pierde en volumen alto.
Enrutado. Mandar cada tarea al modelo que le corresponde es, en la mayoría de los casos, la palanca de mayor recorrido. Tiene página propia.
El presupuesto como decisión de negocio
Un sistema de IA sin techo de gasto es un riesgo abierto. Lo mínimo razonable: coste máximo por ejecución, coste máximo por día, alerta cuando el coste medio por tarea se desvía de lo previsto y responsable identificado de esa partida.
El coste por tarea también fija el punto en el que un caso de uso deja de tener sentido. Si automatizar cuesta más que hacerlo a mano, la respuesta correcta es no automatizarlo, y conviene saberlo antes de construir.
Cuándo merece la pena entrar en esto
Sí, cuando:
- Ya hay uno o varios casos de uso en producción y la factura crece cada mes
- Se está decidiendo si escalar un piloto: el coste por tarea es el dato que sostiene la decisión
- Hay que defender la inversión en IA ante un comité con números, no con impresiones
No, cuando:
- Se está en prueba de concepto y el gasto es marginal: primero valida el valor
- El volumen es tan bajo que cualquier optimización ahorra menos de lo que cuesta implantarla
Cómo lo abordamos
Instrumentamos primero: cada llamada etiquetada por caso de uso, con su coste y su resultado. Con dos o tres semanas de datos reales aparece el reparto —normalmente unas pocas operaciones se llevan la mayor parte del gasto— y ahí es donde se actúa: caché, lotes, poda de instrucciones y enrutado. El resultado se mide contra la factura del mes anterior a igual volumen y calidad.
En Madrid la pregunta llega pronto al comité porque las corporaciones con sede en la ciudad suelen tener ya varios sistemas en producción y una función de control de gasto que exige imputación por unidad de negocio. El coste por tarea resuelta es el lenguaje con el que se defiende esa partida.
Preguntas frecuentes sobre tokeneconomics
¿Cuánto se puede ahorrar sin tocar la calidad? Depende del punto de partida. Donde no se ha optimizado nada, la caché y los lotes suelen dar el primer recorte grande sin cambiar el modelo ni el resultado. La cifra honesta solo aparece después de medir.
¿Esto no lo resuelve el proveedor? El proveedor ofrece los mecanismos —caché, lotes, tamaños de modelo—, pero decidir dónde aplicarlos es trabajo de arquitectura y depende de tus tareas.
¿Cómo se lleva esto al comité de dirección? Con dos números por caso de uso: coste por tarea resuelta y ahorro frente al proceso manual. Todo lo demás es detalle técnico.