Qué son los tokens en IA y cómo se cobran

La factura que nadie supo estimar, y por qué casi siempre sorprende

El primer contacto de una empresa con la IA generativa suele ser entusiasta y barato. Alguien prueba un asistente, resuelve en segundos algo que antes tomaba media hora, y la conclusión es inmediata: esto hay que llevarlo a toda la operación. El problema aparece después, cuando el piloto pasa de tres personas curiosas a doscientos casos por día y la factura deja de parecerse a la de una suscripción y empieza a parecerse a la de la luz: variable, difícil de predecir y casi siempre más alta de lo que alguien dijo al inicio.

La raíz del malentendido es que la mayoría llega con el modelo mental de una licencia de software: pago fijo por usuario, uso ilimitado. La IA generativa casi nunca se cobra así. Se cobra por consumo, y la unidad de ese consumo es el token. Mientras nadie en la mesa entienda qué es un token y qué lo hace subir, cualquier proyección de costo es una adivinanza, y cualquier intento de ahorrar se hace a ciegas, apagando funciones útiles por miedo a una factura que no se sabe leer.

Qué es un token en criterio de negocio, no de ingeniería

Un token no es una palabra ni una letra, es el pedazo en que el modelo parte el texto para procesarlo. En español, una palabra común suele ser un token, pero las palabras largas, los nombres propios, los números y los signos se parten en varios. Una regla gruesa que sirve para estimar: cien palabras rondan los ciento treinta o ciento cuarenta tokens. No necesitas contarlos a mano, sí necesitas saber que todo lo que entra y todo lo que sale se mide en esta unidad.

Lo que importa para el negocio es esto: el modelo no ve tu texto como tú, lo ve como una secuencia de tokens, y cada token cuesta. Cuenta el token de tu pregunta, el de las instrucciones que van detrás, el de los documentos que le adjuntas y el de cada palabra de su respuesta. Todo lo que el sistema lee y todo lo que escribe pasa por el contador. Por eso dos casos de uso que ‘hacen lo mismo’ pueden tener costos muy distintos: no depende de la tarea en abstracto, depende de cuánto texto mueve cada vez.

Cómo se cobran: entrada, salida y por qué no valen lo mismo

Los proveedores separan el precio en dos: tokens de entrada, que es todo lo que el modelo recibe, y tokens de salida, que es todo lo que genera. Casi siempre la salida cuesta bastante más que la entrada, a veces tres, cuatro o cinco veces más. La razón práctica para el negocio no es técnica: significa que una tarea que lee mucho y responde poco (clasificar, extraer un dato, decidir sí o no) es barata, mientras que una que responde con textos largos (redactar informes, generar contenido extenso) es cara aunque la pregunta sea corta.

• Entrada: tu instrucción, el historial de la conversación, los documentos adjuntos y las reglas de sistema. Todo eso se cobra en cada llamada, no una sola vez.
• Salida: cada palabra que el modelo genera. Pedir ‘resúmelo en tres líneas’ en lugar de ‘desarróllalo’ no es solo un tema de estilo, es una decisión de costo.
• Precio por modelo: los modelos más capaces cuestan por token varias veces más que los livianos. El mismo caso de uso puede multiplicar su costo solo por elegir el modelo grande ‘por si acaso’.

El detalle que descoloca a casi todos: en una conversación larga, el historial se reenvía completo en cada turno. Cuando preguntas la décima cosa, el modelo vuelve a leer las nueve anteriores, y todas se cobran otra vez como entrada. Una charla de veinte turnos no cuesta veinte veces una pregunta, cuesta bastante más, porque el contexto se arrastra y se paga en cada paso.

Dónde se va de verdad el presupuesto en un caso real

En un proyecto que consulta documentos internos (un RAG, por ejemplo), la mayor parte del gasto no está en la pregunta del usuario ni en la respuesta, está en los fragmentos de documentos que el sistema adjunta para que el modelo responda con información tuya. Cada consulta puede arrastrar varias páginas de contexto, y todas cuentan como entrada. Por eso un asistente que ‘solo responde preguntas’ puede tener una factura desproporcionada respecto a lo poco que el usuario escribe.

El mismo efecto aparece en las instrucciones de sistema. Muchas empresas escriben un prompt de sistema enorme, con reglas, ejemplos y tono de marca, y lo mandan en cada llamada. Si ese bloque tiene mil palabras y el sistema recibe cinco mil consultas al día, estás pagando cinco millones de palabras de instrucción diarias, aunque el usuario solo haya escrito una línea cada vez. No es que esté mal tener buenas instrucciones, es que hay que saber que se pagan en cada uso y diseñarlas con esa conciencia.

• Historial de conversación: crece en cada turno y se reenvía completo. En asistentes de charla larga es el costo que más se subestima.
• Documentos y contexto adjunto: en casos con recuperación de documentos suele ser la mayor parte de la entrada. Traer diez fragmentos cuando bastaban tres multiplica el costo sin mejorar la respuesta.
• Instrucciones de sistema repetidas: el mismo bloque largo enviado miles de veces al día, se escriba una vez y se pague siempre.
• Respuestas largas por defecto: cuando no se limita el tamaño de la salida, el modelo tiende a extenderse, y la salida es lo más caro de toda la operación.

Lo que necesitas definir antes de estimar el costo

Estimar la factura de tokens no es un cálculo que hace el proveedor por ti, es una decisión de negocio que exige conocer tu propio caso de uso. Antes de pedir una cotización o aprobar un piloto, esto es lo que reviso con un cliente:

• Volumen real esperado: cuántas consultas por día, no en el mejor mes, en el mes normal. Sin ese número, cualquier costo mensual es ficción.
• Tamaño típico de entrada y salida: una consulta con dos frases y respuesta corta no se parece en nada a una que adjunta cinco documentos y pide un informe.
• El modelo mínimo que resuelve la tarea: no el más potente del catálogo, el más barato que da la calidad que el negocio acepta. Esa prueba se hace antes de escalar, no después.
• Un tope de gasto y una alerta: casi todos los proveedores permiten fijar un límite mensual. No ponerlo es dejar la puerta abierta a la factura sorpresa.
• Una medición del ahorro que genera: cuánto tiempo o cuánto costo de personal reemplaza el caso de uso. El token solo tiene sentido comparado con lo que evita.

Ninguno de estos puntos es técnico. Todos son decisiones de dueño o gerente, y sin ellos el precio por token es un dato suelto que no dice si el proyecto conviene o no. Por eso el trabajo de definir el caso va antes que el de elegir modelo: no se presupuesta lo que no se ha dimensionado.

Errores comunes al presupuestar por tokens

El entusiasmo con la IA generativa hace que muchos aprueben el gasto sin entender qué lo mueve. Estos son los errores que se repiten con una regularidad que ya no es casualidad:

• Probar con diez casos y proyectar en línea recta a diez mil. El costo escala con el volumen, pero el historial y el contexto lo hacen crecer más rápido de lo que sugiere una regla de tres.
• Elegir el modelo más caro ‘por calidad’ sin medir. Muchas tareas de negocio (clasificar, extraer, responder preguntas simples) se resuelven igual de bien con un modelo liviano que cuesta una fracción.
• Ignorar la salida. Se obsesionan con acortar la pregunta y dejan que el modelo responda párrafos enteros, cuando la salida es lo que más pesa en la factura.
• No poner tope de gasto. Un error en el código que llama al modelo en bucle, sin límite, puede generar una factura de miles en una sola noche.
• Confundir tokens con valor. Gastar menos tokens no es el objetivo. El objetivo es resolver el caso de negocio al menor costo que mantenga la calidad. Recortar tokens hasta romper la utilidad es ahorrar mal.

Qué NO mide un token, y por qué conviene tenerlo claro

El token es una unidad de consumo, no una medida de valor ni de calidad. Confundir las dos cosas lleva a decisiones malas en las dos direcciones: gastar de más por miedo o recortar hasta inutilizar el sistema. Esto es lo que un token no dice:

• No mide calidad. Una respuesta de cien tokens puede ser mucho mejor que una de mil. Más tokens no es más valor, a veces es solo más relleno que igual pagas.
• No mide dificultad. Una pregunta trivial y una crítica pueden costar lo mismo en tokens. El costo depende del texto que se mueve, no de lo que está en juego en la decisión.
• No refleja el retorno. Un caso que cuesta más en tokens puede ser el más rentable si reemplaza horas caras de trabajo. El token se juzga contra el ahorro que produce, nunca solo.
• No es un problema que se optimiza una vez. El consumo cambia cuando cambia el uso. Es un número que se vigila cada tanto, no una casilla que se marca y se olvida.

Dicho de otro modo: contar tokens es útil para pagar la cuenta, pero no sirve para decidir si un proyecto vale la pena. Esa decisión se toma con el costo del caso completo comparado con lo que hoy cuesta resolverlo a mano.

Cómo lo miro yo cuando me piden estimar el costo de un proyecto

El token es el final de la conversación, no el principio

La pregunta útil nunca es ‘¿cuánto cuesta un token?’. Es ‘¿qué proceso de mi empresa consume tiempo y dinero hoy, cuántas veces al día ocurre, y cuánto me costaría resolverlo con IA comparado con lo que me cuesta ahora?’. El precio por token entra al final de ese razonamiento, cuando ya sabes el dolor, el volumen y la calidad que necesitas. Empezar por el precio del token es como elegir un auto por el precio de la gasolina antes de saber cuántos kilómetros vas a manejar al año.

Entender los tokens no te vuelve más técnico, te vuelve más difícil de sorprender. Te deja leer una cotización, pedir el tope de gasto correcto, cuestionar por qué el proveedor propone el modelo más caro y saber que una factura alta casi siempre se explica por contexto que se arrastra, respuestas sin límite o un modelo elegido por comodidad. Ese es el orden que defiendo: primero el dolor, después el proceso y el volumen, después el dato de cuánto texto mueve cada caso, y recién al final el precio por token. El token importa, pero es el último número de la conversación, no el primero.