Las empresas están adoptando la IA más rápido de lo que pueden gestionar su economía de tokens

Por qué falló el antiguo modelo de costos

Durante la mayor parte de la era del software, el costo de una herramienta aumentaba proporcionalmente al número de personas que la utilizaban. Se compraban licencias: diez ingenieros costaban diez veces lo que uno solo, y el departamento de finanzas podía prever ese gasto con un año de antelación. Sin embargo, la facturación por tokens desmontó silenciosamente esa suposición y los sistemas basados en agentes remataron la faena.

Una interacción con un modelo de lenguaje grande (LLM) de un solo turno es breve y limitada: envías un prompt, recibes una respuesta y listo. Un flujo de trabajo agéntico es diferente: un LLM coordina un sistema más amplio de herramientas, planifica un curso de acción, invoca servicios externos, lee los resultados y recorre docenas de pasos, llevando adelante su historial cada vez más extenso en cada etapa. Ese historial es el costo. En un estudio sistemático de tareas de codificación con agentes, los investigadores descubrieron que estas tareas consumen aproximadamente 1.000 veces más tokens que el chat de código o el razonamiento habituales, y que el costo se debe principalmente a los tokens de entrada —el contexto que se retroalimenta al modelo en cada paso— más que a lo que el modelo escribe.

Una vez que un agente abre un archivo o ejecuta un comando, los resultados permanecen en su contexto de trabajo hasta que finaliza la tarea, por lo que cada nuevo paso vuelve a consumir todos los recursos. Un análisis de un agente de codificación popular reveló que, en un solo día de mucho trabajo, el 99 % de los tokens que procesó eran tokens de entrada acumulados a lo largo de la trayectoria del agente, y solo el 1 % fueron generados por el modelo. El trabajo visible, el código o la respuesta, es la parte barata. El scrollback invisible (el registro creciente de todo lo que el agente ha visto y hecho) es donde se gasta el dinero.

Hay otros dos factores que dificultan la estimación de costos. El primero es la variabilidad: ese mismo estudio reveló que una misma tarea, ejecutada dos veces, puede presentar una diferencia de hasta 30 veces en el número total de tokens, ya que un agente podría resolverla sin problemas en una ejecución y, en la siguiente, encontrarse con callejones sin salida. El segundo es el rendimiento decreciente: un análisis a nivel de sistema realizado por KAIST reveló que los agentes ganan en precisión a medida que se les permite utilizar más recursos computacionales, pero las ganancias disminuyen rápidamente mientras que el costo y la latencia siguen aumentando, lo que los autores describen como un problema de sostenibilidad inminente, no como una palanca gratuita. Un mayor número de tokens no garantiza mejores resultados.

Si juntamos todo eso, obtenemos exactamente la combinación que el modelo de presupuestación por puesto no puede reflejar: un gasto variable, no lineal y que solo guarda una relación muy vaga con el valor. Es por eso que, según se informa, los costos por desarrollador en algunas grandes compañías oscilaban entre unos pocos cientos y un par de miles de dólares al mes, y por lo que el director de tecnología de Uber describió que su equipo había tenido que volver a empezar desde cero. El modelo anterior no solo subestimaba la cifra; estaba midiendo lo que no debía.

Lo que no puedes ver, no puedes gestionarlo

La mayoría de los equipos no tienen ni idea de dónde van a parar sus tokens. El panel de control de facturación muestra un total mensual, pero no indica qué tarea, agente o paso lo generó. Esa brecha debe subsanarse primero, porque el ahorro reside en los detalles que el total oculta.

Un estudio reciente revela lo que un total mensual no puede mostrar. En "Tokenomics", investigadores de la Universidad de Concordia hicieron un seguimiento de 30 tareas de desarrollo de software de principio a fin a través de un marco multiagente y mapearon cada token a una etapa del ciclo de vida del desarrollo. El resultado es contrario a lo que cabría esperar. La parte costosa no fue escribir el código. La etapa iterativa de revisión del código, en la que un agente critica y otro revisa, representó un promedio del 59,4 % de todos los tokens. El costo principal del trabajo de software por agentes radica en el refinamiento y la verificación, los bucles que son fáciles de dejar en ejecución y difíciles de detectar en una factura.

No puedes actuar sobre nada de esto sin medirlo, y las métricas son simples de definir: recuento de tokens por tarea, costo por tarea completada, tasa de aciertos en caché, latencia y recuento de reintentos. Cada una de ellas señala una fuga diferente. Una baja tasa de aciertos en caché (la proporción de llamadas en las que el proveedor ha devuelto un resultado almacenado en lugar de volver a procesar el prompt) significa que estás pagando el precio completo por un contexto que podrías reutilizar. Un alto recuento de reintentos indica que un agente está saturado. Una relación entre entradas y salidas en aumento indica que el historial se acumula más rápido de lo que el trabajo justifica. Una factura de tokens que no puedes desglosar por tarea o paso no es un presupuesto; es una sorpresa a la espera de llegar. La industria está convergiendo en definiciones compartidas para estas medidas, pero ningún equipo necesita esperar a que haya un estándar para empezar a contar.

Gastar menos en cada llamada

Una vez que tienes una idea clara de los gastos, la primera medida es dejar de pagar por lo mismo una y otra vez. Hay dos técnicas que hacen la mayor parte del trabajo:

La primera es el almacenamiento en caché de los prompts, donde el proveedor almacena la forma procesada de un prefijo de prompt estable para que no sea necesario volver a computarlo en la siguiente llamada. Todos los principales proveedores lo admiten, con guías publicadas por OpenAI, Anthropic y Google. Cuánto ayuda esto en ejecuciones de agentes largas y de múltiples pasos era la pregunta pendiente, y Lumer y sus colegas la respondieron en "Don't Break the Cache". En más de 500 sesiones de agentes de tres proveedores, el almacenamiento en caché redujo los costos de las API entre un 41 % y un 80 % y disminuyó el retraso antes del inicio de la respuesta (tiempo hasta el primer token) entre un 13 % y un 31 %.

El título del artículo es, en sí mismo, una advertencia. Almacenar en caché solo las partes estables, como una metodología reutilizable para mantener el prompt del sistema y las instrucciones de las herramientas, proporcionó mejoras consistentes, ya que el prefijo del prompt permanece idéntico en todas las llamadas. Almacenar en caché el contexto completo de forma indiscriminada, incluidos los resultados dinámicos de las herramientas que varían en cada ejecución, rompe la coincidencia: la caché nunca se reutiliza, pero el sistema sigue soportando la sobrecarga de buscarla, lo que puede empeorar la latencia en comparación con no almacenar nada en caché. Almacena en caché lo estable y conserva lo que cambia al final del prompt.

La segunda medida es la disciplina en el uso del contexto: enviar menos datos al modelo desde el principio. El contexto extenso es el factor de costo más silencioso en cualquier sistema de agentes, ya que el agente envía todo su historial acumulado al modelo en cada paso y la API cobra por todo ese volumen cada vez. La compresión de prompts aborda esto directamente. El trabajo original de LLMLingua de Microsoft demostró que un prompt largo podía reducirse hasta 20 veces con solo una pequeña disminución en el rendimiento de la tarea, haciendo que un modelo pequeño eliminara los tokens con poca información antes de que el modelo costoso los viera. Sin embargo, esto no es gratuito.

Un estudio a gran escala realizado en 2026, "Prompt Compression in the Wild", reveló que el tiempo añadido en la compresión inicial debe verse compensado por el ahorro que genera en las etapas posteriores, pero eso no siempre ocurre. El hábito más confiable se encuentra antes de cualquier algoritmo: recuperar solo los archivos, registros o pasajes que necesita una tarea, resumir la evidencia en lugar de pegarla completa y resistirse a entregarle al modelo todo "por si acaso". El token más barato es el que nunca se envía.

Gastar en el modelo correcto en el momento adecuado

La última medida consiste en adaptar el trabajo al modelo, así como el tiempo de respuesta a la necesidad. Un enfoque útil lo ofrece el estudio "Token Economics for LLM Agents", el cual aborda la elección del modelo como una sustitución sujeta a restricciones presupuestarias: se busca el input más económico que siga haciendo el trabajo, no el modelo más potente por puro instinto.

En la práctica, eso se traduce en una estrategia de niveles. Tareas como el formateo, la refactorización, la clasificación rutinaria y la síntesis de un documento limpio funcionan perfectamente bien en un modelo más pequeño y barato, reservando el paso a un modelo de vanguardia para los razonamientos verdaderamente complejos: una decisión arquitectónica, una vulnerabilidad sutil, un hallazgo ambiguo que requiera criterio. Asignar por defecto todas las tareas al modelo más potente es la forma más común en que los equipos se exceden en los gastos, y es precisamente ese comportamiento el que ha convertido proyectos piloto modestos en facturas desorbitadas.

El tiempo de respuesta es la otra mitad de la estrategia. Una gran parte de los flujos de trabajo empresariales no necesita en absoluto una respuesta en tiempo real. La evaluación sin conexión, la clasificación de conjuntos de datos, el procesamiento masivo de documentos y la generación de informes nocturnos pueden ejecutarse de forma asincrónica, y los proveedores fijan el precio de esa flexibilidad en consecuencia. Las recomendaciones de costos de OpenAI, por ejemplo, apuntan a su Batch API para consolidar muchas solicitudes en un solo trabajo asincrónico y a un procesamiento flexible, lo que reemplaza respuestas más lentas y ocasionalmente interrumpidas por costos sustancialmente más bajos en tareas no urgentes. Reservar las llamadas en tiempo real al modelo de vanguardia para los momentos en que se necesitan y procesar el resto por lotes tiende a reducir los costos sin una caída visible en la calidad.

El lado de la seguridad de la economía de tokens

Aquí es donde esto deja de ser una cuestión financiera para convertirse en una cuestión de seguridad, un aspecto que la mayoría de los artículos sobre economía de tokens pasan por alto. Cada factor mencionado en las secciones anteriores modifica el perfil de riesgo del sistema, no solo su factura, y un equipo de seguridad debe analizar ambos aspectos de manera conjunta.

Tomemos el almacenamiento en caché de prompts, la técnica que, como dijimos hace un momento, reducía los costos hasta en un 80 %. Esta funciona procesando un prefijo compartido una sola vez y reutilizando el resultado, por lo que un prompt almacenado en caché retorna más rápido que uno sin almacenar. Esa diferencia de velocidad es perceptible y las diferencias de tiempo perceptibles constituyen un canal lateral clásico (una forma de extraer información no del contenido de un sistema, sino de su comportamiento).

En "Auditing Prompt Caching in Language Model APIs", Gu y sus colegas de Stanford demostraron que cuando un proveedor mantiene una única caché compartida entre todos los usuarios, esa diferencia de velocidad se convierte en una señal. Un atacante puede enviar prompts candidatos y medir cuánto tarda cada uno en responder. Una respuesta rápida indica un acierto de caché, lo que significa que alguien más ha enviado ese prefijo recientemente. Al probar sistemáticamente a los candidatos y anotar cuáles producen aciertos, un atacante puede deducir qué están preguntando otros usuarios, sin leer sus mensajes directamente.

Al auditar 17 proveedores, el equipo detectó almacenamiento en caché en ocho de ellos y el uso compartido global de caché entre usuarios en siete, entre los que figuraba OpenAI. La misma técnica incluso reveló un secreto arquitectónico: uno de los modelos de incrustación de OpenAI respondía de manera consistente únicamente con un diseño de decodificador puro, un detalle estructural que la empresa no había revelado. Los autores relacionan esto directamente con Meltdown y Spectre, los ataques de hardware que explotaban el mismo principio: el comportamiento del sistema filtra información que sus diseñadores nunca tuvieron la intención de exponer, y que ahora resurge en la capa de la API de LLM.

La lección no consiste en abandonar el almacenamiento en caché. Es que la configuración predeterminada más económica y la más segura no siempre coinciden. El almacenamiento en caché por usuario elimina la fuga entre usuarios, al tiempo que conserva la mayor parte del ahorro, pero alguien tiene que elegirlo de forma activa. Esa misma tensión se aplica a las demás medidas. La disciplina contextual ahorra dinero al recortar lo que se envía, pero la tentación opuesta, pegar un repositorio completo o un registro de cliente sin procesar en un prompt para saltarse un viaje de ida y vuelta, amplía silenciosamente la superficie de exposición de datos y expone registros sensibles a un modelo de terceros. Pasarse a un modelo más pequeño y barato ahorra tokens, pero las elecciones de modelo y marco no son neutras en cuanto a seguridad. Como mostramos en nuestra publicación anterior sobre la gobernanza de los sistemas agénticos, las tasas de rechazo para las mismas solicitudes maliciosas oscilaron entre el 30,8 % y el 52,3 % dependiendo únicamente del marco del agente. Cada optimización de costos es también una decisión de seguridad, y fingir lo contrario es la forma en que un sistema más barato se convierte en uno más expuesto.

También existe una trampa más sutil. Una reducción agresiva de costos puede borrar precisamente la evidencia de la que depende un equipo de seguridad para investigar incidentes, verificar que un agente se comportó según lo previsto y demostrar el cumplimiento normativo. La compresión del contexto, el resumen de los resultados de las herramientas y el recorte del historial reducen la información que llega a los registros. Sin un registro completo, no hay forma de reconstruir qué decidió un agente, a qué herramienta recurrió, a qué datos accedió o por qué llegó a una conclusión determinada. Como argumentamos en ese mismo trabajo, los registros de los agentes deben conservar los prompts, las llamadas a herramientas, los permisos y el razonamiento que subyace a una conclusión, no solo la respuesta final. Si optimizas ese registro, ahorras unos cuantos tokens a costa de tu rastro de auditoría. Una economía de tokens sólida trata la observabilidad y la auditabilidad como restricciones, no como más grasa para recortar.

Por qué esto pertenece a una política, no a un hábito

Todas estas ideas plantean una pregunta a la que se enfrentará cualquier equipo que adopte agentes: ¿Debería el uso económico de los agentes de IA regirse por una política interna explícita, tal como ya ocurre con el uso de la nube, el manejo de datos y la revisión de código? La respuesta sincera es que la alternativa —dejarlo en manos de los hábitos individuales— es precisamente lo que provocó los excesos presupuestarios en primer lugar.

Una política aquí no significa un documento extenso que nadie lee. Significa ponerse de acuerdo en torno a un puñado de valores predeterminados antes de que lleguen las facturas. Qué modelo es la opción estándar para el trabajo rutinario y qué justifica pasar a uno más avanzado. Qué contexto puede recibir un agente y qué categorías de datos (registros de clientes, información confidencial, registros completos) nunca deben pegarse en un prompt, independientemente de la conveniencia. Qué prompts se almacenan en caché y con qué nivel de acceso compartido. Qué se registra y qué debe conservar un registro para que sea útil en una auditoría. Cuándo se justifica una llamada en tiempo real y cuándo el trabajo debe procesarse por lotes. Ninguna de estas cuestiones requiere conocimientos especializados. Son decisiones que todos los equipos ya toman de manera informal cada vez que implementan un agente. Una política simplemente las pone por escrito una vez, para que se apliquen de manera consistente y puedan revisarse cuando cambien las circunstancias.

Aquí es donde la cuestión de los costos y la de la seguridad finalmente convergen. El estudio "Token Economics for LLM Agents" dedica una sección completa a la dimensión de la seguridad y llega a una conclusión sorprendente: la gobernanza funciona como infraestructura económica, ya que las reglas que se establecen sobre cómo se gastan los tokens son también las reglas que limitan la exposición al riesgo. El trabajo en torno a los estándares emergentes, desde la expansión de la comunidad FinOps hacia la IA hasta la nueva Tokenomics Foundation, representa el intento de la industria de definir esa política a gran escala. Para una empresa dedicada a la seguridad de aplicaciones o para cualquier organización de TI, tratar la economía de los agentes como una práctica regulada, en lugar de una preferencia personal, marca la diferencia entre adoptar la IA y controlarla.

Cómo luce esto en la práctica

Nada de esto es meramente teórico. A continuación, mostramos cómo se aplican las medidas mencionadas anteriormente en cuatro situaciones laborales de la industria tecnológica.

En las pruebas de seguridad, los elementos estables son precisamente aquellos que vale la pena almacenar en caché: el alcance de la prueba, la metodología y las instrucciones de la herramienta que un agente necesita en cada ejecución. Sin embargo, la materia prima no debería reintroducirse en el modelo en cada paso. Reintroducir un registro de escaneo completo o una captura de paquetes en el modelo en cada paso resulta costoso y supone una ampliación innecesaria de la superficie de exposición de datos. Por lo tanto, la mejor práctica consiste en sintetizar la evidencia en hallazgos concisos y utilizarlos en las siguientes etapas. Los modelos más robustos justifican su costo en decisiones difíciles, como confirmar una vulnerabilidad sutil o interpretar un resultado ambiguo, mientras que la priorización rutinaria se realiza con algo más ligero.

En el ámbito del desarrollo, el éxito radica en la disciplina de recuperar la información. Un agente de codificación rara vez necesita todo el repositorio en contexto; lo que necesita es unos cuantos archivos relevantes para la tarea, además de un conjunto almacenado en caché de convenciones del repositorio para reutilizar en todas las sesiones. El formateo, la refactorización y la generación de código repetitivo funcionan con facilidad en un modelo más pequeño, mientras que el modelo de vanguardia se reserva para decisiones arquitectónicas y razonamientos sobre vulnerabilidades, donde una respuesta incorrecta es costosa. El ciclo de revisión merece especial atención, ya que, como mostró el estudio de Concordia, es ahí donde los tokens se concentran silenciosamente.

El trabajo de diseño tiene su propio núcleo estable. Las directrices de marca y las reglas del sistema de diseño cambian lentamente y deben incluirse en un prompt almacenado en caché, mientras que la información variable es, por naturaleza, limitada: se trata de la pantalla o el componente específico que se está revisando, no de toda la biblioteca de diseño. Al enviar solo el contexto relevante, cada iteración resulta lo suficientemente sencilla como para repetirse rápidamente, lo cual suele ser la razón principal por la que se recurre a un agente en el diseño.

El trabajo de creación de contenido se beneficia de un enfoque por etapas en lugar de una única tarea gigantesca. Las guías de estilo y los perfiles de público se guardan una sola vez y se reutilizan; la investigación se resume en notas en lugar de pegarse tal cual a cada paso; y los borradores se construyen sección por sección para que el contexto nunca se desborde. Escribir este blog post por partes, por ejemplo, en lugar de hacerlo como una sola tarea gigantesca, no solo fue más fácil de manejar, sino que también resultó más económico de producir.

La adopción fue la parte fácil

Cada ola de innovación tecnológica acaba dando lugar a una disciplina encargada de gestionar sus costos. La gestión de gastos de telecomunicaciones surgió tras la expansión de las redes telefónicas corporativas; las FinOps en la nube aparecieron tras la migración a los principales proveedores de nube; la economía de tokens sigue el mismo patrón un ciclo más tarde, y es precisamente por eso que ahora existe la Fundación Tokenomics. Ese patrón resulta tranquilizador en cierto sentido: el problema tiene solución y el manual de estrategias ya está parcialmente escrito.

Sin embargo, la brecha es una realidad en este momento. McKinsey reveló que el 92 % de las compañías planea aumentar su inversión en IA durante los próximos tres años, mientras que solo el 1 % considera que sus implementaciones están maduras. La iniciativa NANDA del MIT informó que el 95 % de los proyectos piloto de GenAI en empresas no generaron un impacto medible en las ganancias y pérdidas, una cifra que ha suscitado críticas metodológicas; sin embargo, su conclusión principal concuerda con la evidencia general: la deficiencia no radica en los modelos, sino en cómo las organizaciones los integran. En otras palabras, la adopción fue la parte fácil. Convertirla en valor, sin perder el control de los costos ni de la superficie de ataque, es la tarea más difícil y decisiva.

Ese es el verdadero mensaje que se esconde tras los excesos presupuestarios. Las empresas que saldrán ganando no serán aquellas que cuenten con más agentes, sino aquellas que puedan ver en qué gastan sus agentes, gobernar cómo lo hacen y garantizar que tomen las medidas necesarias para gastar menos. Para una empresa de seguridad, esos tres aspectos no están separados entre sí. Son parte de una misma práctica. Una vez que consideras un token como algo que vale la pena contabilizar, estás gestionando los costos, reforzando la gobernanza y reduciendo el riesgo al mismo tiempo.