Cuánto cuesta usar un LLM en una empresa

La factura que nadie vio venir

El equipo de soporte llevaba semanas pidiendo ayuda para no ahogarse en tickets repetidos, y alguien por fin consiguió que finanzas aprobara un piloto con un LLM: trescientos dólares al mes, según la calculadora que mandó el proveedor con un precio por millón de tokens que sonaba insignificante. El bot arrancó bien. Resolvía consultas simples, el equipo respiraba, y en la segunda semana alguien decidió, sin pedir permiso, que también atendiera consultas de facturación, más largas y con más idas y vueltas. A los veinte días llegó la factura: casi el triple de lo aprobado. Nadie había cambiado una línea de código. Nadie había firmado nada nuevo. Lo único que cambió fue el tipo de conversación que el modelo tenía que sostener, y eso, que en la calculadora del proveedor no aparecía en ningún lado, terminó decidiendo el costo real.

Esa escena se repite con variaciones en casi toda empresa que prueba un LLM por primera vez, y el problema no es que el modelo sea caro. El problema es que nadie tradujo el precio por token a lo único que finanzas entiende: cuánto cuesta resolver un caso, cuántos casos se resuelven al mes y qué pasa cuando el modelo falla y hay que reintentar o pasarle el caso a una persona. Sin esa traducción, cualquier número que apruebes es una apuesta, no un presupuesto.

Cómo se factura realmente el uso de un LLM

Un LLM no se factura por “consulta” ni por “usuario”, se factura por tokens procesados, que son los fragmentos de texto (partes de palabras, signos, espacios) en los que el modelo trocea todo lo que entra y todo lo que sale. Cada llamada a la API cuenta dos cosas por separado: los tokens de entrada (el prompt del sistema, el historial de la conversación y la pregunta del usuario) y los tokens de salida (la respuesta que el modelo genera). En casi todos los proveedores el token de salida cuesta más que el de entrada, porque generar texto exige más cómputo que leerlo, y esa asimetría importa: un modelo que responde largo y detallado sale más caro por caso que uno que responde corto, incluso si el precio “por token” que anuncia el proveedor es idéntico.

Hay un segundo detalle que sorprende a quien viene de pagar licencias por usuario: el modelo no “recuerda” la conversación entre un mensaje y el siguiente. Cada llamada reenvía todo el historial relevante como contexto, así que una conversación de diez turnos no cuesta diez veces lo del primer turno, cuesta la suma acumulada de reenviar cada vez más historial. Por eso qué son los tokens en IA y cómo se cobran es la primera pieza que hay que entender antes de estimar cualquier gasto: el precio por token es un dato de catálogo, pero el costo real depende de cuántos tokens exige tu caso de uso concreto, no del anuncio del proveedor.

Del precio por token al costo por caso atendido

El precio por token es el número que aparece primero en cualquier comparación entre modelos, y es también el que menos predice el gasto real. Dos modelos con el mismo precio nominal pueden salir muy distintos en la factura si uno necesita el doble de tokens para explicar lo mismo, o si uno acierta a la primera y el otro necesita dos o tres intentos antes de resolver el caso. La pregunta que de verdad mueve el presupuesto no es “¿cuánto cuesta el token?”, es “¿cuánto cuesta resolver este caso, con todo lo que hace falta para resolverlo bien?”.

Esa traducción cambia el orden de las decisiones. Un modelo más caro por token, pero que resuelve el caso en un solo intento y sin que un humano tenga que revisar la respuesta, puede terminar costando menos por caso que un modelo barato que falla una de cada cuatro veces y obliga a repetir la llamada o a escalar a una persona. Qué LLM elegir para una empresa no es una pregunta de marca ni de quién tiene el precio más bajo en la lista de precios: es una pregunta de cuál modelo produce el costo total más bajo para tu caso de uso específico, y esa respuesta cambia según el tipo de tarea.

Las 4 variables que mueven la factura, no el precio del modelo

Cuando el gasto de un LLM se dispara, la reacción típica es cambiar de modelo. Casi siempre el problema está en otro lado. Hay cuatro variables que determinan la factura mucho más que el precio por token, y las cuatro dependen de decisiones de producto y de proceso, no del proveedor:

• El volumen de operaciones al mes: cuántas conversaciones, documentos o tareas pasan por el modelo. Es la variable más obvia y la que casi todos calculan bien; el problema aparece cuando el volumen crece por éxito del piloto y nadie actualizó la proyección de gasto.
• La longitud típica del intercambio: cuántos tokens de contexto arrastra cada llamada (historial, documentos adjuntos, instrucciones del sistema) y cuán larga es la respuesta esperada. Duplicar el contexto promedio duplica buena parte de la factura sin que el volumen de casos cambie en absoluto.
• La tasa de reintento o de fallo: qué porcentaje de casos necesita una segunda llamada porque la primera respuesta no sirvió, estuvo incompleta o el usuario tuvo que reformular. Cada reintento vuelve a pagar el contexto completo, así que una tasa de fallo alta multiplica el costo por caso sin que se vea reflejado en el precio por token.
• La proporción de revisión humana: cuántos casos, antes de salir, pasan por una persona que verifica, corrige o aprueba la respuesta. Ese tiempo humano tiene un costo tan real como el cómputo, y en las primeras semanas de cualquier proyecto suele ser mayor, no menor, de lo que el equipo asumió.

Estas cuatro variables interactúan entre sí, y por eso usar varios modelos de IA en una empresa o estandarizar en uno es también una decisión de costo: un modelo más caro para las tareas complejas y uno barato para las simples suele mover menos la factura total que forzar un solo modelo a cubrir todo el rango de dificultad.

El costo que nadie presupuesta: reintentos, contexto largo y pruebas

Hasta acá el cálculo asume que el modelo se usa una sola vez por caso y que el presupuesto arranca el día que el producto sale a producción. En la práctica hay varios bloques de gasto que casi ningún presupuesto inicial contempla, y aparecen antes de que el primer usuario real toque el sistema o siguen creciendo después.

• Las pruebas antes de producción: ajustar un prompt bien no se hace en un intento. Se prueba, se mide, se ajusta y se vuelve a probar, muchas veces sobre cientos o miles de casos de ejemplo para verificar que el cambio no rompió algo que sí funcionaba. Cada corrida de esas pruebas consume tokens igual que un caso real, y un equipo serio corre docenas de rondas antes de publicar un cambio.
• El contexto que crece con el tiempo: si el producto agrega memoria, historial de conversación o documentos de referencia para que el modelo responda con más contexto de la empresa, el tamaño promedio de cada llamada sube mes a mes aunque el número de usuarios se mantenga igual. Es un gasto que se instala solo, sin que nadie tome la decisión de subirlo.
• Los reintentos que no se ven como reintentos: un usuario que reformula la pregunta porque la primera respuesta no le sirvió genera una llamada nueva que el sistema de monitoreo suele contar como “otro caso”, no como el fallo del primero. Esa contabilidad optimista esconde la tasa real de fallo y, con ella, buena parte del gasto.
• La revisión humana como costo estructural, no como parche temporal: en la mayoría de los proyectos serios, alguien sigue revisando una parte de las respuestas mucho después del lanzamiento, no solo durante el piloto. Ese tiempo tiene salario, y hay que sumarlo al costo por caso con la misma seriedad que se suma el cómputo.

Nada de esto es exótico ni depende de que el proyecto salga mal. Es el costo normal de operar un sistema que sigue ajustándose sobre la marcha, y por eso conviene mirar cuánto cuesta mantener un agente de IA al mes como una curva que sigue moviéndose después del lanzamiento, no como un número que se fija una vez y queda quieto.

El costo por operación, línea por línea (ejemplo aritmético, no precio de mercado)

El ejercicio que de verdad ordena la decisión es armar el costo por operación como una lista de líneas, igual que se arma el costo de cualquier otro proceso de la empresa. Para ilustrar la mecánica uso números inventados y una unidad monetaria de ejemplo, a la que llamo simplemente “U”, sin ninguna relación con un precio real de ningún proveedor: el punto no es el número, es el método para llegar a él con tus propios datos.

• Tokens de entrada por caso: por ejemplo 1.500 tokens, que incluyen las instrucciones del sistema, el historial reciente de la conversación y la pregunta del usuario.
• Tokens de salida por caso: por ejemplo 400 tokens, la respuesta que genera el modelo.
• Costo unitario de ejemplo: supongamos U 1 por cada 1.000 tokens combinados, una cifra inventada solo para el ejercicio. El costo de cómputo de ese caso, a la primera, sería de cerca de U 1,9.
• Tasa de reintento: supongamos que un 20% de los casos necesita una segunda llamada completa porque la primera respuesta no bastó. Eso suma, en promedio sobre el total de casos, cerca de U 0,4 adicionales por caso.
• Revisión humana: supongamos 3 minutos en un 15% de los casos, a un costo de ejemplo de U 0,3 por minuto. Prorrateado sobre el total de casos, agrega cerca de U 0,15 adicionales, una línea que en muchos proyectos pesa más de lo que parece.
• Costo total por caso resuelto: la suma de las líneas anteriores, cerca de U 2,45 en este ejercicio, no el costo unitario aislado del tercer punto. Es esa suma, y no la tarifa de catálogo, la que hay que comparar contra el costo de la alternativa.

El ejercicio completo, con tus propios números de volumen, longitud de contexto, tasa de fallo y minutos de revisión, es lo único que te dice si el proyecto es barato o caro. Hacerlo antes de comprometer presupuesto evita la sorpresa del tercer mes; hacerlo solo después de la primera factura alta es la forma más cara de aprender el método.

Cómo se pone un techo de gasto sin frenar el proyecto

Poner un techo de gasto no es negociar un descuento con el proveedor, es diseñar el sistema para que no pueda salirse del presupuesto aunque el uso crezca más rápido de lo previsto. Las palancas están del lado de quien construye el producto, no del lado de la tarifa:

• Un tope mensual duro con corte automático, no una alerta que alguien puede ignorar un viernes por la tarde. Si el sistema llega al límite, deja de responder o cae a un modo degradado, en vez de seguir facturando sin que nadie lo autorice.
• Un límite de tokens por llamada, tanto de entrada como de salida, para que ninguna conversación individual pueda irse a un tamaño desproporcionado. Un límite razonable en la longitud de la respuesta también mejora la experiencia: nadie quiere leer un párrafo larguísimo para una pregunta simple.
• Una ventana de contexto acotada, en vez de reenviar todo el historial completo en cada llamada. Se manda el resumen de lo relevante, no la transcripción entera, y ese solo cambio suele recortar una parte considerable del gasto en productos con conversaciones largas.
• Alertas escalonadas antes del tope, al 50% y al 80% del presupuesto mensual, dirigidas a una persona con autoridad para decidir si sube el límite o si frena el volumen, no a una bandeja de correo que nadie revisa.
• La tasa de reintento como métrica de producto, no solo de infraestructura. Si esa tasa sube, el costo por caso sube con ella aunque el precio del modelo no se haya movido, y es la señal más temprana de que algo en el diseño del prompt o del flujo dejó de funcionar.

Ninguna de estas medidas depende de negociar mejor con un proveedor: dependen de decisiones de diseño que cualquier equipo puede tomar antes de lanzar, y son las mismas que separan un proyecto con un TCO de un proyecto de IA predecible de uno que solo aguanta el presupuesto mientras nadie use demasiado el sistema.

La comparación honesta: contra el costo de la operación manual

El error más común al justificar un proyecto de IA es compararlo contra cero, como si la alternativa fuera no hacer nada. La alternativa real casi siempre es una persona haciendo esa tarea hoy, con un costo que la empresa ya paga y rara vez desglosa por caso. Para que la comparación sea honesta hay que ponerle número a ambos lados con el mismo criterio: cuánto cuesta resolver un caso con una persona (una fracción de su salario según el tiempo que le dedica, más el costo de sus errores) contra cuánto cuesta resolverlo con el modelo, incluidos los reintentos y la revisión humana que todavía hace falta.

Con esa comparación hecha bien, el resultado casi nunca es el que se anuncia en las presentaciones de venta. En las primeras semanas, con una tasa de fallo alta y mucha revisión humana, el costo por caso del LLM puede ser parecido o incluso mayor al de la persona que reemplaza, y quien prometió ahorro inmediato queda mal parado. El ahorro real aparece después, a medida que el prompt mejora, la tasa de reintento baja y la proporción de revisión humana se reduce a los casos que de verdad la necesitan. Ese es el tramo en el que conviene evaluar los agentes de IA empresariales como una inversión que madura, no como un interruptor que se enciende y ya sale barato desde el primer día.

Mi criterio: la pregunta correcta no es si es caro