La estructura de costos de un producto con IA: por dónde se escapa el margen

Hay un patrón que se repite en las empresas que lanzan su primer producto con IA: el costo por consulta de la demo era despreciable, el del piloto era manejable, y el de producción se comió el margen. No es que los precios de los modelos hayan subido. Es que la factura del modelo es solo una línea de un costo total que nadie modeló.

Lo que sí es obvio: tokens de entrada y salida

Es el costo directo y el único que aparece en la mayoría de las estimaciones. Dos advertencias:

La salida cuesta bastante más que la entrada en prácticamente todos los proveedores. Un caso de uso que redacta respuestas largas tiene una economía muy distinta a uno que devuelve una etiqueta, aunque el volumen de consultas sea idéntico.

Y la entrada crece de formas que no se anticipan. Instrucciones de sistema que empiezan con 200 palabras y terminan con 2.000 tras seis meses de parches. Historial de conversación que se arrastra completo en cada turno. Documentos recuperados que se inyectan "por si acaso". El costo por consulta sube de forma silenciosa mientras nadie mira.

Lo que se olvida: los reintentos

Cada llamada que falla por formato inválido, cada respuesta que no pasa la validación y se pide de nuevo, cada verificación con un segundo modelo, cada paso extra de un agente que anduvo en círculos. En sistemas con validación estricta, el costo real por tarea completada puede ser varias veces el de una llamada exitosa. Esa es la cifra que hay que presupuestar, no la del caso ideal.

Lo que casi nadie mide: la evaluación

Mantener un producto con IA que no se degrada exige un conjunto de casos de prueba que se corre en cada cambio de prompt y en cada cambio de modelo. Correr esa evaluación cuesta tokens, y correrla seguido cuesta bastante. Es el gasto más fácil de recortar y el que más caro sale recortar: sin evaluación, la única forma de detectar una regresión es que la reporte un cliente.

Lo que se subestima: el humano en el circuito

Si el flujo incluye revisión manual —y en la mayoría de los casos serios la incluye— ese tiempo es parte del costo unitario del producto. La pregunta relevante para el negocio no es cuánto cuesta la llamada al modelo, sino cuánto baja el tiempo humano por caso. Un sistema que reduce 40 minutos de trabajo a 8 justifica un costo de inferencia alto. Uno que reduce 10 minutos a 9, no lo justifica a ningún precio.

Las tres palancas que sí mueven la aguja

Caché de prompts. Si tus instrucciones de sistema o tus documentos de contexto se repiten entre consultas, el ahorro es sustancial y la implementación es de horas, no de semanas. Es la primera optimización que hay que hacer, antes de cualquier cambio de modelo.

Enrutamiento por dificultad. La mayoría de las consultas de un producto real son fáciles. Resolverlas con un modelo pequeño y escalar al grande solo cuando hace falta cambia la estructura de costos sin tocar la calidad percibida. Requiere una señal confiable de dificultad, que es la parte difícil.

Recortar el contexto. Enviar los tres fragmentos relevantes en lugar de veinte por si acaso suele mejorar la calidad y bajar el costo al mismo tiempo. Es la optimización con mejor relación esfuerzo-resultado y la que más se posterga.

La métrica que hay que reportar

No el costo por llamada ni el costo por token: el costo por tarea completada y aceptada, incluyendo reintentos, verificación y tiempo humano. Es más difícil de calcular y es la única que permite responder si el producto tiene margen.

Cualquier proyección hecha sobre el costo de una llamada exitosa está, por construcción, mirando el mejor caso.