Cuánto cuesta de verdad una función con IA en producción

Una función con IA que cuesta céntimos en la demostración cuesta un sueldo con mil usuarios. El problema no es que nadie lo sepa: es que el coste no aparece hasta que ya está en producción, y para entonces el precio del producto ya está publicado.

Esto es lo que hemos aprendido poniendo a cobrar el planificador de contenido de PlanVortex, que escribe publicaciones y genera imágenes, y lo que preguntamos antes de presupuestar cualquier función parecida.

La unidad no es el token, es la operación

Nadie compra tokens. El cliente compra «una semana de publicaciones», «este documento clasificado» o «esta factura extraída». Esa es la unidad que hay que medir, y casi nunca es una sola llamada al modelo.

Una operación de verdad incluye:

• la llamada visible (la que genera el texto o la imagen),
• las pasadas intermedias que el usuario no ve (la que decide qué se va a generar, la que valida el resultado),
• la entrada, que suele ser lo que más crece y lo que menos se mide,
• y los reintentos, que son parte del coste aunque sean culpa del proveedor.

Medir por llamada da un número más bonito y sin utilidad. Medir por operación da el número que se puede poner en un precio.

El coste no lo decide el modelo, lo decide la fuente

Este es el hallazgo que más nos ha cambiado el diseño, y no tiene que ver con qué modelo se use.

En nuestro planificador, la misma petición («hazme un plan de publicaciones para esta semana») cuesta cosas muy distintas según de dónde salga el material:

• Si las imágenes las genera la IA, un plan de siete publicaciones ronda los 519 créditos.
• Si las fotos las pone el cliente (las suyas, o las del catálogo de su tienda), el mismo plan cuesta 48.

Diez veces menos, y la diferencia no es el modelo ni el prompt: es una decisión del usuario en el primer paso del asistente. La entrada también pesa, y tampoco es evidente: un artículo largo como fuente son varios miles de tokens de entrada añadidos, y cada imagen que entra en una pasada multimodal cuesta más o menos lo mismo que un párrafo generado.

La consecuencia práctica es que una tarifa plana por operación miente en cuanto la fuente cambia. O la tarifa distingue la fuente, o se está subvencionando el caso caro con el barato hasta que llegue un cliente que solo use el caro.

Estimar y cobrar no son lo mismo (y tienen que cuadrar)

Hay dos aritméticas, y conviene tenerlo claro desde el principio:

• La estimación, antes de ejecutar, para enseñarle al usuario lo que va a gastar y para comprobar que le llega el saldo. Es obligatoriamente aproximada: todavía no se sabe cuántos tokens va a devolver el modelo.
• El cobro, después, con el coste real que reporta el proveedor en esa llamada.

Las dos tienen que salir de la misma tabla de tarifas. Cuando no es así (cuando la estimación vive en el panel y el cobro en el servidor) se separan solas con el primer cambio, y una estimación que no coincide con lo que se cobra es peor que no estimar: el cliente la lee como un presupuesto y la factura la desmiente.

Nosotros lo resolvemos teniendo la tabla duplicada a propósito en los dos lados, con una prueba a cada lado que falla si dejan de decir lo mismo. No es elegante; es lo que impide el fallo caro.

La unidad que ve el cliente no puede ser el dólar

El precio de los modelos cambia varias veces al año, casi siempre a la baja, y la tarifa del producto no puede cambiar cada vez. Por eso el consumo se traduce a una unidad propia (créditos, en nuestro caso) con una equivalencia que se mantiene por dentro.

Dos efectos, los dos buenos:

1. El cliente ve una cifra estable y puede comparar meses. Un texto son 2 créditos y una imagen 70, y eso le dice de un vistazo dónde se le va el consumo.
2. El proveedor se puede cambiar sin tocar el precio de cara al cliente, que es justo lo que no se puede hacer si has publicado una tarifa en dólares por millón de tokens.

Y un aviso, porque es donde se rompen los números de muchos productos: si el coste está en dólares y el precio en euros, el tipo de cambio es parte del margen. No es un detalle contable, es una variable que se mueve sola.

El tope por cuenta no es una protección, es lo que hace el precio posible

Sin tope, el peor mes posible de un cliente no tiene límite: un bucle mal hecho, una integración que reintenta sin freno o simplemente un cliente que usa la función mucho más de lo previsto. Y lo descubres en la factura del proveedor, que llega cuando ya no se puede hacer nada.

Con un tope por cuenta y periodo, comprobado antes de cada llamada y no después, el peor mes posible es una cifra concreta. Eso es lo que permite escribir un precio y sostenerlo.

Conviene además dejar una salida para el cliente que se pasa del tope de forma legítima: que ponga su propia clave del proveedor y pague él directamente. Deja de consumir tu bolsa, deja de ser un problema de margen, y sigue siendo tu producto.

Cambiar de modelo no es cambiar una línea

Cada pocos meses sale un modelo más barato o mejor, y la tentación es cambiar el identificador y desplegar. El efecto en la factura se ve al día siguiente; el efecto en la calidad no se ve hasta que se queja un cliente, y para entonces nadie sabe si empeoró por el modelo o por otra cosa.

Lo que lo hace decidible es tener un conjunto de casos propios: veinte o treinta ejemplos reales, con lo que se considera una buena respuesta, guardados desde el principio. Con eso, cambiar de modelo es una comparación de media hora. Sin eso, es una apuesta que se paga en soporte.

Y lo que no se presupuesta: la revisión humana

Lo que genera un modelo entra como borrador. Publicarlo, enviarlo o darlo por bueno sigue siendo la decisión de una persona, y eso hay que contarlo en el coste de la función: alguien revisa, y ese alguien tarda.

También es el motivo por el que hay tareas donde hoy no compensa automatizar: si revisar lo que sale cuesta más que hacerlo a mano, la función es un gasto disfrazado de ahorro. Es lo primero que miramos cuando alguien nos pide una, y cuando la respuesta es esa, lo decimos en la primera conversación.

Qué preguntar antes de encender una función con IA

1. ¿Cuál es la operación que compra el cliente, y cuánto cuesta entera?
2. ¿Cuánto cambia ese coste según lo que aporte el usuario?
3. ¿La estimación que ve y lo que se le cobra salen del mismo sitio?
4. ¿Cuál es el peor mes posible de un solo cliente?
5. ¿Con qué se compara el día que cambiemos de modelo?

Las cinco se contestan antes de escribir la función, no después. Es lo que incluye nuestro servicio de IA aplicada: la función concreta, medida por operación y con un techo, no «IA» en abstracto.