La factura que nadie vio venir: business case y tokens para que tu feature de IA escale sin arruinarte

Lunes, 9:07 de la mañana. Mensaje en Slack: "Oye, ¿podemos revisar el coste de la feature de IA?". Ese mensaje llegó solo una semana después del despliegue, y nos pilló con la euforia todavía encima. En el piloto todo había ido bien: pocos usuarios, consumo contenido y feedback muy positivo. Parecía una de esas historias donde todo encaja a la primera.

Pero cuando entró tráfico real, la película cambió. Aparecieron más usuarios de los previstos, más frecuencia de uso y prompts bastante más largos que los del entorno controlado. El consumo dejó de parecerse al del piloto y, casi sin darnos cuenta, pasamos de hablar del valor de la funcionalidad a hablar de la factura.

Lo frustrante fue descubrir que no era un bug ni un problema de estabilidad. La implementación funcionaba. Lo que falló fue el diseño económico de la decisión: no teníamos un business case sólido para escalar.

El business case no es burocracia, es protección

Con la IA hay una trampa muy común: una demo brillante te hace sentir que el problema está resuelto. Y es normal, porque cuando ves respuestas buenas y rápidas, el equipo entra en modo "vamos".

El problema es que una demo no paga producción, y un piloto casi nunca representa el comportamiento de una base completa de usuarios. Además, el coste de un LLM no es fijo como una licencia tradicional: depende del uso real y de los tokens que envías en cada llamada.

Por eso el business case tiene que responder tres preguntas antes de desplegar:

1. ¿Cuánto cuesta cada invocación en escenario real?
2. ¿Qué pasa si el uso se multiplica x2 o x3?
3. ¿Dónde deja de ser rentable?

Si no puedes responder esas tres preguntas por escrito, todavía no estás listo para escalar sin sobresaltos.

Tres errores que cometimos (y que tú puedes evitar)

1. Extrapolar desde el piloto sin ajustar

Asumimos que "si en piloto va bien, en producción será parecido". Ese fue el primer error.

En producción aparecieron usuarios intensivos, con más interacciones por sesión y más contexto por petición. El consumo no creció de forma lineal; empezó a subir por tramos, y eso rompió nuestras previsiones en muy poco tiempo.

Regla práctica: no escales con una sola estimación. Trabaja con tres escenarios (base, alto y estrés) y toma decisiones con el alto.

2. No separar el coste por componente

Al principio solo mirábamos una métrica agregada de tokens y, vista desde lejos, parecía razonable. Cuando nos obligamos a descomponer por componentes, apareció el problema real: un system prompt enorme y demasiado historial en cada llamada.

Ahí encontramos una mejora inmediata: pasamos de ~2.000 tokens de system prompt a ~800, manteniendo una calidad percibida muy alta.

Regla práctica: separa siempre input de sistema, contexto de usuario y output. Si no, no sabes qué optimizar.

3. No definir un techo de gasto

Tampoco teníamos definido un "a partir de aquí no compensa". Y sin ese número no hay alertas claras ni decisiones automáticas; solo reacción, discusión y prisa.

Regla práctica: define unit economics por usuario y por transacción, y ata alertas a esos límites.

Playbook para bajar coste en tokens sin matar la calidad

El business case te dice cuánto puedes gastar; este bloque va de cómo gastar menos sin perder calidad de respuesta.

Sé quirúrgico con el system prompt

Cada token de system prompt se paga en todas las llamadas. Por eso es una de las palancas más potentes. Si mandas 2.000 tokens de sistema en 100.000 llamadas/día, estás pagando 200 millones de tokens diarios solo en instrucciones base.

Nosotros recortamos de ~2.000 a ~800 tokens y la calidad percibida se mantuvo prácticamente igual, con una reducción clara de coste desde el primer día.

Cuándo no aplicarlo: cuando dependes de instrucciones legales/compliance extensas que no puedes resumir.

Gestiona el historial de conversación con cabeza

No envíes todo el historial en cada turno por defecto. En muchos casos funciona mejor mantener un resumen acumulativo del contexto y añadir solo las últimas 3-4 interacciones completas.

Cuándo no aplicarlo: en flujos donde la trazabilidad completa del texto sea requisito funcional.

Clasifica antes de procesar

No todas las peticiones merecen el mismo modelo ni el mismo contexto. Si introduces un router ligero (reglas o modelo pequeño), puedes reservar el modelo caro para los casos complejos y dejar las consultas simples en una ruta mucho más eficiente.

Esto no es solo técnica; es priorización de producto aplicada al coste.

Cuándo no aplicarlo: al principio de una POC, cuando la simplicidad importa más que la eficiencia.

Cachea lo que puedas

Si hay consultas repetitivas, una caché semántica puede evitar llamadas completas al LLM. Implementarla bien no es trivial, pero cuando hay repetición real se amortiza rápido y baja mucho la variabilidad de la factura.

Cuándo no aplicarlo: si tus inputs son muy volátiles o hiperpersonalizados.

Mide, mide, mide

Sin observabilidad, estás a ciegas. Como mínimo deberías tener tokens por tipo de petición, coste por usuario activo, percentiles de consumo y alertas por umbrales. Si no mides eso, solo te enteras de los problemas cuando ya son caros.

El punto donde producto e ingeniería se encuentran

Este es el aprendizaje grande: los costes de IA no son un tema solo de backend ni solo de producto. Son un punto de encuentro entre ambos.

Cuando ingeniería entiende unit economics, diseña mejor; cuando producto entiende tokens, prioriza mejor. En nuestro caso, al recortar contexto y enrutar mejor, no solo bajó el coste: también mejoró la respuesta, con menos ruido y más foco.

Qué haría diferente la próxima vez

Si volviera a empezar, antes de sacar una feature de IA en producción dejaría esto por escrito:

Sobre el negocio: ¿cuál es el valor que genera esta feature por usuario? ¿Cuánto estoy dispuesto a pagar por ese valor? ¿Cuál es mi techo de gasto mensual aceptable? ¿A partir de qué punto deja de ser rentable?

Sobre la escala: ¿cuántos usuarios van a usar esto? ¿Con qué frecuencia? ¿Qué pasa si el uso es el doble o el triple de lo estimado? ¿Tengo mecanismos de control (rate limiting, cuotas por usuario)?

Sobre la optimización técnica: ¿puedo reducir mi system prompt? ¿Estoy enviando contexto innecesario? ¿Puedo clasificar peticiones para usar modelos diferentes? ¿Tengo métricas de consumo en tiempo real?

Vuelvo al mensaje de Slack de las 9:07. Ojalá ese aviso nos hubiese llegado antes del despliegue, cuando todavía era barato corregir.

Sin business case, una feature de IA no es producto. Es una apuesta.

Pregunta para ti: ¿Cuál es la métrica que más te ha ayudado a controlar costes de IA en producción?