Cuánto cuesta de verdad meter IA dentro de tu producto
Hay una distancia incómoda entre enseñar una demo con IA y facturar un producto que la lleva dentro. La demo la paga tu curiosidad. El producto lo paga un cliente todos los meses, y entre una cosa y otra aparece una línea en la cuenta de resultados que casi nadie mira hasta que duele: cuánto te cuesta servir a ese cliente.
Stack Overflow publicó esta semana la segunda parte de su análisis sobre la economía de los agentes a escala, y GitHub contó cómo abarata su propio *coding* asistido sin bajar la calidad. Las dos piezas van de lo mismo desde lados distintos: el coste por token dejó de ser un detalle de infraestructura para convertirse en una decisión de producto.
Nosotros operamos Projekt Republic, un SaaS de gestión y finanzas que además usamos para llevar nuestra propia operación. Eso nos coloca en los dos lados del problema: somos quienes escriben la factura y quienes la reciben. Lo que sigue es cómo miramos el coste desde ahí.
No es infraestructura: es coste de ventas
El error de encuadre más caro es meter la IA en la misma casilla mental que el servidor. El servidor es un coste fijo: pagas lo mismo tengas diez clientes o doscientos, y cada cliente nuevo mejora tu margen. La IA no funciona así. Cada usuario que abre el asistente consume tokens que no habrías gastado si no hubiera entrado.
Dicho en el idioma de la cuenta de resultados: la IA es coste variable, y el coste variable va en coste de ventas, no en gastos generales. En cuanto lo mueves de casilla, el margen bruto de tu producto cambia, y con él todo lo que colgaba de él: el precio, el punto de equilibrio, cuánto puedes gastar en captar un cliente.
Es una conversación que ya tuvimos con el software a medida, aunque con otro nombre. Escribimos sobre ella en cuánto cuesta el software a medida: el precio no sale de las horas, sale de entender qué parte del coste se repite.
Las tres preguntas antes de escribir una línea
Antes de integrar un modelo en una funcionalidad que vas a cobrar, hay tres números que conviene tener. No estimaciones bonitas: números.
- ¿Cuánto consume una interacción típica? No la mejor ni la peor: la mediana. Y medida sobre uso real, no sobre tu prueba de escritorio, que siempre es más corta y más limpia.
- ¿Cuántas interacciones hace al mes un usuario que le saca partido? El que lo usa mucho es el que define tu coste, no el promedio. El promedio lo hunden los que abrieron la función una vez.
- ¿Qué pasa cuando el modelo se equivoca? Un reintento es otra llamada. Un flujo con tres pasos donde el segundo falla la mitad de las veces cuesta bastante más que la suma de sus pasos.
La tercera es la que más gente se salta y la que más sorpresas da. El coste de un agente no es el coste de su camino feliz.
El modelo más caro rara vez es el correcto
El reflejo de conectar el modelo más capaz a todo es comprensible y es un error caro. La mayoría de las tareas dentro de un producto no son abiertas: clasificar un correo entrante, extraer cuatro campos de una factura, resumir un hilo. Son tareas con forma, y un modelo pequeño bien encajado las hace igual de bien por una fracción.
El artículo de GitHub va justo por ahí: el ahorro no vino de recortar calidad, vino de dejar de usar el martillo grande para clavos pequeños. La consecuencia práctica es que el enrutado entre modelos es una decisión de arquitectura, no una optimización de después. Si lo dejas para cuando la factura duela, ya tienes el modelo caro cableado en veinte sitios.
Lo mismo aplica a lo que no necesita modelo. Buena parte de lo que la gente automatiza con IA es transporte de datos con reglas fijas: mover un campo, generar un PDF, avisar cuando se cumple una condición. Eso lo resuelve una integración determinista, más barata y más fiable. Lo contamos con más detalle en automatizar tareas repetitivas con IA.
Qué medimos nosotros
En Projekt Republic la pregunta operativa no es «cuánto gastamos en tokens este mes». Es cuánto gastamos por organización, porque es la unidad que factura. Un coste agregado te dice que algo sube; un coste por cliente te dice cuál.
De ahí sale una segunda cosa que no esperábamos: la distribución es muy desigual. Unos pocos usuarios intensivos generan la mayor parte del consumo, y son casi siempre los que más valor obtienen. Eso no es un problema a recortar, es información de precio. Un plan plano sobre un coste tan asimétrico transfiere margen de los usuarios ligeros a los intensivos, y tarde o temprano alguien nota la diferencia.
Un coste variable que no sabes repartir por cliente no es un coste: es una sorpresa a plazo.
Lo que no cambia
Nada de esto es nuevo. Es la misma disciplina que cualquier negocio con coste marginal ha tenido siempre: saber qué te cuesta atender a un cliente más y cobrar en consecuencia. Lo único que ha cambiado es que ahora también aplica al software, que llevaba dos décadas con la comodidad de un coste marginal cercano a cero.
El sector se está encontrando con esto a la vez. Mientras el gasto en cómputo sigue creciendo —el CEO de Iren, socio de Nvidia, dice que la demanda puede no saciarse nunca—, quien construye producto encima tiene que decidir cuánto de ese gasto absorbe y cuánto repercute.
Nuestra posición es simple: la IA entra en un producto cuando podemos decir qué cuesta servirla, no cuando queda bien en la demo. No es prudencia, es la única forma de que la funcionalidad siga existiendo dentro de dos años.
