La adopción de la IA generativa en las empresas ha superado la fase de experimentación y ha comenzado a integrarse en procesos con impacto directo en la productividad, la atención al cliente, el crédito, riesgo, compliance, marketing y las operaciones. En este contexto, la pregunta deja de ser “¿funciona?” para convertirse en “¿funciona de manera sostenible, con costos previsibles y control de riesgo?”.
Es en este punto donde muchos programas de IA encuentran fricción.
La organización invierte en modelos, pilotos e integraciones, valida que la solución responde bien y decide ponerla en producción. Cuando el uso crece, el presupuesto comienza a desviarse sin una explicación clara, y el debate se convierte en una disputa entre tecnología, finanzas y las áreas usuarias.
El origen de este desajuste suele ser una variable que no aparece en el discurso ejecutivo con la misma frecuencia con la que aparece en la factura: los tokens. Como resume Thiago de Moraes Dutra, Director Ejecutivo de Investigación y Desarrollo de MATH Group, el mercado centra su energía en elegir modelos, pero rara vez trata el costo recurrente como parte del diseño de la solución.
Hay un cambio estructural en curso.
Con la IA generativa, el costo no es solo el de la infraestructura tradicional ni el de una licencia por usuario. Se comporta como un consumo variable por interacción, influenciado por el contexto, el historial, los documentos adjuntos, la calidad de los datos, las reglas del agente y el patrón de uso de los equipos. Este modelo de consumo se asemeja más a una operación continua que a un proyecto puntual.
El desafío es que, en muchas empresas, la gobernanza de la IA todavía se trata como un conjunto de principios abstractos. Falta transformar la gobernanza en mecanismos operativos: límites, mediciones, asignación de costos, alertas, criterios de arquitectura y responsabilidad por las decisiones. Sin estos mecanismos, la organización no logra responder preguntas simples, pero decisivas: cuánto cuesta mantener un caso de uso en producción, por área y por jornada, y qué valor se está capturando a cambio.
Los tokens se convierten, entonces, en una especie de “costo invisible”, no porque sean misteriosos, sino porque entran en la operación antes de entrar en la hoja de cálculo. Nacen en el design del prompt, en la forma de componer el contexto, en la decisión de mantener el historial, en la política de adjuntos, en la manera en que el agente consulta documentos y en lo cuánto tolera la organización respuestas largas, redundantes o sin foco.
Para quienes no viven el día a día de la tecnología, “token” suele asociarse con la autenticación. En la IA generativa, los tokens son las unidades mínimas de texto procesadas por los modelos de lenguaje. Pueden ser palabras, partes de palabras, números, símbolos e incluso espacios. En cada interacción, hay consumo de tokens de entrada, que incluyen el prompt, las instrucciones y el contexto, y el consumo de tokens de salida, que corresponden a la respuesta generada.
El punto crítico es que, en un contexto corporativo, casi todo pasa a formar parte de ese paquete de entrada. Si el producto o la solución conserva el historial completo por defecto, cada interacción resulta más costosa que la anterior. Si el usuario adjunta documentos extensos y el sistema inserta ese contenido en la conversación sin filtrarlo, la organización está pagando para que el modelo lea material que no siempre es necesario para tomar una decisión. Si las instrucciones del sistema son extensas, repetitivas y poco modularizadas, el costo se vuelve recurrente y difícil de reducir sin una reingeniería.
Por eso, los tokens no deben tratarse únicamente como un detalle técnico.
Se convierten en una métrica operativa comparable al tiempo de atención, el costo por transacción, el retrabajo y la tasa de error. Si el objetivo es incorporar la IA en flujos críticos, los tokens deben formar parte del mismo plan de gestión: medición, asignación, límites y mejora continua.
En un piloto, el volumen de uso es bajo, los usuarios son pocos, el alcance es limitado y casi siempre existe una supervisión cercana por parte del equipo técnico. En producción, la realidad cambia. El caso de uso se extiende a áreas con rutinas diferentes, horarios diferentes, niveles de madurez diferentes y necesidades que incrementan el volumen de contexto. Lo que era “una conversación” se convierte en decenas de miles de interacciones, y pequeñas ineficiencias de design se multiplican.
Hay un patrón que se repite. La solución funciona bien en una primera etapa, genera confianza, entra en la operación y comienza a utilizarse con libertad. Sin límites ni observabilidad, el costo crece de forma silenciosa hasta convertirse en un tema de comité, y el proyecto pierde respaldo político al no poder explicar la desviación.
Algunas causas aparecen con frecuencia en este punto de inflexión:
1. Una política de contexto que siempre incorpora más información que lo necesario, por seguridad y no por criterio.
2. Prompts extensos y poco estandarizados, con instrucciones repetidas en cada turno.
3. Historial acumulado sin resumen y sin criterio de relevancia, lo que hace que la conversación “engorde” indefinidamente.
4. Agentes con autonomía para iterar y consultar fuentes sin una regla de detención, generando loops caros.
5. Documentos adjuntos sin indexación ni recuperación bajo demanda, lo que transforma la lectura en un costo fijo.
En muchos casos, la empresa paga para que el modelo procese redundancia. La tecnología no falla, pero la arquitectura incentiva un consumo elevado sin una garantía proporcional de valor.
FinOps suele recordarse como una disciplina de control del gasto en cloud. En IA, debe incorporarse antes, como parte de la arquitectura y del modelo operativo del producto, y no como un ajuste posterior realizado para “contener la factura”. La lógica es simple: si el costo es determinado por la forma en que la solución utiliza los tokens, entonces el control debe ocurrir en el design.
Cuando una empresa trata el costo de la IA como un problema exclusivamente financiero, llega tarde. El área financiera puede ver el gasto total; lo que no puede hacer sola es descomponer ese total por caso de uso, por jornada, por patrón de contexto, por equipo, por agente, por modelo y por tipo de interacción. Esa descomposición es una decisión de instrumentación y gobernanza técnica.
En la práctica, FinOps de IA comienza con tres acciones:
Instrumentar: registrar el consumo de tokens y el costo asociado por interacción, con tags de usuario, área, aplicación, caso de uso, flujo y modelo utilizado.
Asignar: crear un modelo de chargeback o showback que permita visualizar dónde ocurre el consumo, sin convertir el tema en una disputa política. El objetivo no es “castigar” a las áreas, sino permitir una priorización racional.
Optimizar: diseñar mecanismos que reduzcan el desperdicio, como el enrutamiento de modelos según su complejidad, límites por sesión, compresión de contexto, caché de respuestas para preguntas recurrentes y recuperación de conocimiento bajo demanda en lugar de adjuntar documentos completos.
Entre las recomendaciones más consistentes para reducir la variabilidad y aumentar la previsibilidad se encuentran el design consciente de los tokens, los prompts concisos y reutilizables, el contexto mínimo viable, el monitoreo por usuario y caso de uso, las alertas en tiempo real, el uso de modelos más económicos cuando sea posible y la correlación explícita entre el costo y el valor de negocio.
Una discusión madura sobre el costo de los tokens no termina en “reducir tokens”. Comienza con “¿qué decisión permite esta interacción?” y “¿qué valor captura esa decisión?”. Sin ese puente, el programa de IA cae en dos errores simétricos: reducir costos a cualquier precio y perder calidad, o mantener la calidad sin gobernar los costos y perder sostenibilidad.
Un enfoque práctico consiste en traducir cada caso de uso en una unidad de valor que tenga sentido para el negocio. En lugar de medir únicamente el volumen de mensajes, la empresa mide el costo por resultado: costo por ticket resuelto, costo por análisis de riesgo completado, costo por propuesta generada y revisada, costo por conciliación finalizada y costo por minuto de retrabajo evitado. A partir de ahí, es posible comparar eficiencias entre flujos y priorizar dónde invertir.
Un ejemplo realista: imagínese un agente de atención al cliente que responde dudas sobre contratos. Si siempre carga el contrato completo, además de las políticas internas y el historial completo del cliente, el costo por respuesta aumenta, incluso cuando la pregunta es sencilla. Si la arquitectura se rediseña para recuperar únicamente los fragmentos relevantes, resumir el historial y aplicar un patrón de respuesta más directo, el costo por resolución disminuye sin reducir la tasa de acierto. El beneficio no es solo financiero. Es previsibilidad para escalar.
Otro ejemplo: un agente interno de apoyo a analistas que consulta informes extensos. Sin indexación y recuperación bajo demanda, el equipo tiende a adjuntar documentos completos, y el sistema tiende a “leerlo todo” para responder cualquier pregunta. Con una capa de búsqueda y recorte de contexto, la organización paga para que el modelo razone sobre lo necesario, no sobre lo disponible.
El indicador decisivo pasa a ser el “costo por respuesta que genera una decisión” y, sobre todo, el “costo por respuesta que evita trabajo humano relevante”. Es en esa relación donde el ROI deja de ser una narrativa y se convierte en un criterio.
Este tema se relaciona con el artículo “La era de las pruebas con IA ha terminado”, que analiza el momento en que la IA deja de ser un experimento y pasa a exigir disciplina operativa.
Sin gobernanza, los tokens se convierten solamente en una variable de consumo. Con gobernanza, los tokens se convierten en un instrumento de control del riesgo operativo. Esto ocurre porque el costo y el riesgo avanzan juntos cuando la IA entra en flujos críticos.
Si el consumo crece sin control, la empresa pierde previsibilidad presupuestaria. Si pierde previsibilidad, comienza a restringir el uso de forma indiscriminada, lo que reduce el valor. Si no puede explicar las variaciones de costo por flujo, pierde la capacidad de priorizar y de justificar inversiones. En paralelo, la ausencia de límites y trazabilidad abre espacio para errores de arquitectura que también incrementan el riesgo: agentes que acceden a más datos de los necesarios, logs incompletos, decisiones sin rastro de auditoría y respuestas con baja consistencia.
El paralelismo con cloud es útil como advertencia. Muchas organizaciones aprendieron, en la práctica, que el consumo variable exige disciplina de gobernanza y observabilidad. En IA, ese aprendizaje debe acelerarse, porque la velocidad de adopción y el volumen de interacciones tienden a crecer más rápidamente.
Un modelo de gobernanza aplicable suele incluir:
Cuando esto existe, la pregunta deja de ser “qué modelo es mejor” y pasa a ser “cuánto cuesta cada respuesta, qué valor entrega y qué controles garantizan que ese costo no se convierta en una variable fuera del presupuesto”.
Los tokens son la unidad que conecta arquitectura, consumo y gobernanza en la IA generativa. Ignorarlos no evita el costo; solo traslada la discusión al momento en que ya existe tensión entre equipos y cuando el presupuesto ya ha sido impactado. Medir y gobernar los tokens no es una obsesión por el detalle técnico. Es lo que permite sostener la IA en producción sin convertir las ganancias iniciales en frustración recurrente.
Si tiene sentido, MATH puede apoyar el mapeo de los flujos y la definición de la capa de orquestación y observabilidad necesaria para poner la IA en operación con previsibilidad utilizando la MATH AI Platform.