Título original: Token Budget Wars
Autor original: Jaya Gupta
Compilación original: Peggy
Nota del editor: La IA empresarial está pasando de «si adoptarla» a «cómo hacer las cuentas».
En los últimos dos años, muchas empresas promovieron el uso de IA entre sus empleados, principalmente para mantenerse al día con las tendencias tecnológicas y la presión competitiva. Pero cuando el costo de la inferencia de IA pasa de ser un presupuesto experimental a un gasto operativo continuo, los CEO y CFO comienzan a plantear una pregunta más realista: ¿cuánto valor realmente crea la IA? Por cada dólar de costo en tokens, ¿qué resultado tangible obtenemos?
Este es precisamente el núcleo de la «Guerra del Presupuesto de Tokens». La llamada guerra del presupuesto de tokens no se trata solo de que las empresas quieran reducir su factura de IA, sino de reevaluar qué áreas de negocio merecen más potencia de cálculo, qué tareas deberían cambiarse a modelos más baratos, qué procesos podrían sustituirse por outsourcing o mano de humana, y cuáles son solo consumos ineficientes.
Lo más destacable del artículo es que el uso de la IA no equivale a valor. En la era del SaaS, el uso normalmente significaba que el software había sido adoptado; pero en la era de la IA, el consumo de tokens solo indica que «el taxímetro está corriendo». Un mismo flujo de trabajo puede generar diferencias de costos de varias veces debido a variaciones en el prompt, el contexto, la selección del modelo y el número de reintentos. Una factura más alta puede significar que la IA está realmente trabajando, o que el sistema está perdiendo el tiempo de manera ineficiente.
Por lo tanto, la siguiente fase de la IA empresarial no se centra solo en las capacidades del modelo, sino en la capacidad de vincular el costo de los tokens con los resultados del negocio. La primera fase demostró que la IA puede realizar el trabajo; la segunda fase debe responder: ¿vale realmente la pena pagar por este trabajo?
A continuación, el texto original:
La IA empresarial ha pasado de «si adoptarla» a «cómo distribuirla».
En los niveles altos de la empresa, la nueva «moneda» es tu capacidad para cuantificar el ROI de la inversión en IA. A cada unidad funcional se le hace la misma pregunta: ¿Qué produces? ¿Cuál es el costo? En los últimos dos años, los CEOs, mientras se despertaban por la mañana y veían a Jim Cramer en CNBC (#bearish) y observaban a los competidores anunciar mejoras de productividad, exigían a toda la empresa que usara IA. Lo que realmente genera presión ahora es la pregunta de seguimiento: Demuéstrame el valor.
Claude se lanzó en noviembre de 2025, y para entonces la mayoría de las empresas ya habían cerrado sus presupuestos anuales para 2026. En el primer trimestre, el uso real de las empresas ya superaba con creces lo planeado. El costo de inferencia dejó de ser solo una partida presupuestaria para experimentos y se convirtió en un costo operativo recurrente. Surgió entonces una nueva pregunta: ¿Dónde está la IA creando realmente valor?
Esta pregunta es difícil de responder porque la utilidad de los tokens no está cuantificada. La factura no te dice si ese gasto sustituyó mano de obra, generó ingresos, redujo riesgos, aceleró procesos, o si solo fue un grupo de ingenieros haciendo un uso excesivo de tokens por el ranking (#metamates). Cuando el gasto es de solo unos cientos de miles de dólares, todavía parece un experimento. Pero más allá de un punto crítico, por ejemplo, al alcanzar siete cifras, se convierte en infraestructura. Las diferencias técnicas comienzan a tener un impacto tangible en la cuenta de resultados: un mismo flujo de trabajo, con el mismo conjunto de entradas, puede tener un costo en tokens entre 5 y 10 veces mayor en dos ejecuciones, sin que superficialmente parezca haber ningún problema. A escala experimental, esta volatilidad ya es costosa; pero a escala de infraestructura, se convierte en un número que el CFO debe explicarle al CEO.
Podríamos llamarlo «utilidad marginal del token»: el valor comercial creado por cada dólar adicional gastado en costo de inferencia. Este es el número que realmente importa en la fase de escalamiento, y que la mayoría de las empresas no pueden ver en este momento.
En las juntas directivas, la pregunta está pasando de «¿Es útil la IA?» a «¿Dónde está la IA generando realmente palanca?». Precisamente por eso, la llamada guerra del presupuesto de tokens es, en esencia, una lucha por el poder de asignación de tokens.
Y la lucha por la propiedad de los tokens se está calentando rápidamente porque choca con un instinto ejecutivo de treinta años de antigüedad: un equipo grande significa un puesto importante, un gran ámbito de responsabilidad y más poder. En el pasado, un indicador visible del éxito de un alto directivo era el tamaño del equipo que gestionaba: reportes directos, reportes indirectos y el número de personas en el organigrama.
Pero cuando la inteligencia se convierte en un recurso escaso, el nuevo indicador es: cuánta inteligencia puedes desplegar.
El gasto en IA está compitiendo esencialmente con el costo laboral.
La mayoría de las solicitudes de presupuesto de IA son, en esencia, una de tres propuestas: sustituir mano de obra externalizada (BPO), sustituir mano de obra interna o generar nuevos ingresos.
Un empleado tiene un salario. Un contrato de BPO tiene un precio por ticket, reclamación, factura o revisión. Los humanos entienden estas unidades de medida. Pero el costo de inferencia es más complejo, porque el costo final de completar una tarea depende de cómo se ejecute el sistema durante el proceso. Una tarea de procesamiento de reclamaciones que requiere tres reintentos, correcciones manuales y llama a un modelo de vanguardia, puede ser más cara que la mano de obra externalizada que pretendía sustituir. Precisamente por eso, la discusión está virando hacia: ¿Cuál es el costo por resultado obtenido? Por ejemplo, el costo por ticket resuelto, por reclamación procesada, por contrato revisado, por factura completada, por puesto de trabajo evitado, por cliente retenido, o por cada dólar de ingresos convertido.
Los ejecutivos ya se han dado cuenta de que el BPO es el lugar más fácil para establecer una base de comparación, porque ese trabajo ya está tarificado por «unidad completada». En cambio, la comparación entre empleados internos e IA es mucho más difícil, porque un empleado hace muchas cosas al día, incluido navegar por TikTok durante la pausa del almuerzo; las ganancias de productividad suelen materializarse como la evitación de contrataciones o la liberación de capacidad dispersa; y los gerentes también se resisten a reducir el tamaño del equipo basándose solo en una automatización parcial. El BPO proporciona a los equipos de negocio una línea de base cuantificable.
Esto es diferente a la lógica del SaaS. El SaaS entrenó a las empresas para que vieran el uso como un proxy del valor.
Pero la IA rompe esto. La cantidad de recursos de inferencia que consume un mismo flujo de trabajo puede variar enormemente debido al prompt, al contexto recuperado, al modelo seleccionado, a las herramientas invocadas, al número de reintentos y a si el agente se atasca. La unidad en la factura –el token– es estable, pero la cantidad de trabajo que representa no lo es.
Para ser más precisos: la señal y el ruido usan la misma unidad de medida. Un aumento en la factura de tokens puede significar que se está realizando trabajo real; pero también puede significar que el poder de cálculo se está desperdiciando en prompts deficientes, contextos irrelevantes, llamadas a herramientas innecesarias, inferencias repetitivas y modelos con capacidades excesivas. Dos empresas pueden tener facturas de tokens idénticas, pero con operaciones subyacentes completamente diferentes: una está convirtiendo la inferencia en resultados, la otra está pagando por chapuceos ineficientes, y ambos casos se ven exactamente iguales en las líneas de la factura.
El uso de SaaS te dice: el software ha sido adoptado. El uso de IA solo te dice: el taxímetro está corriendo. No te dice si la empresa realmente está funcionando.
¿Por qué es difícil ver la utilidad marginal del token?
Principalmente por tres razones.
La primera es la cola larga de los reintentos. Si la probabilidad de que un agente complete correctamente un flujo de trabajo en el primer intento es p, entonces el consumo esperado de tokens por flujo de trabajo resuelto se ampliará aproximadamente según T/p, donde T es el costo base. Si la tasa de éxito cae del 90% al 70%, el costo efectivo por problema resuelto aumentará aproximadamente un 28%, no un 20%, porque los fallos tienen un efecto compuesto. En los flujos de trabajo empresariales, las entradas suelen ser desordenadas y los casos excepcionales son importantes. El fracaso no solo reduce la precisión, sino que también cambia la ecuación económica.
La segunda es la inflación del contexto. Para operaciones altamente dependientes de mecanismos de atención, el costo de inferencia crece aproximadamente de manera O(n²) con la longitud del contexto. Por lo tanto, duplicar la longitud del contexto cuadruplica aproximadamente el costo de inferencia. Todo el mundo quiere que el modelo tenga suficiente información, por lo que los sistemas tienden a sobreproveer: donde cinco documentos bastaban, la recuperación extrae cincuenta; los conectores vierten hilos de correo electrónico completos; los agentes continúan ejecutándose con historiales de conversación ya obsoletos.
La tercera es el enrutamiento. Cuando un equipo no sabe qué modelo es «suficientemente bueno», por defecto usa el modelo más potente. Una tarea básica de clasificación puede ejecutarse en el mismo modelo diseñado para razonamiento complejo. Cuando los volúmenes de llamadas alcanzan millones, elegir un modelo pequeño para tareas simples frente a usar el modelo de vanguardia para todo, a menudo marca la diferencia entre una factura manejable y un problema a nivel de junta directiva.
Las industrias no relacionadas con el software sentirán este dolor en forma de «transformación». Las empresas de software serán las primeras en ver el problema, porque el trabajo que se está optimizando ya está altamente instrumentado. Los equipos de ingeniería tienen métricas de PR, commits, despliegues, incidentes, tiempo de ciclo, MTTR, etc., y estas métricas están vinculadas al producto. Aunque no son perfectas, este tipo de trabajo es más fácil de medir.
Las empresas no relacionadas con el software sentirán este problema más profundamente porque su trabajo es operativo. Por ejemplo, reclamaciones, suscripción, tickets de servicio al cliente, revisiones de cumplimiento, anomalías en la cadena de suministro, disputas de pagos. O aquellas empresas con activos en el mundo físico también enfrentarán el mismo problema. Estos flujos de trabajo solían medirse por mano de obra, tiempo de ciclo, cumplimiento de SLA y tasa de errores, y a menudo tienen requisitos más altos, necesitando ser defendibles en auditorías, no solo correctos en promedio. La unidad de trabajo y la unidad de costo no hablan el mismo idioma, ni están en la misma organización. El equipo técnico ve el consumo de tokens, el departamento de negocio ve los cambios en el flujo de trabajo, pero conectar ambos requiere que múltiples equipos primero se pongan de acuerdo sobre «qué estamos midiendo exactamente».
Creo que las empresas de software experimentarán la guerra del presupuesto de tokens como un problema de medición de productividad, que se corresponde con los numerosos «despidos por IA» anteriores; mientras que las empresas no relacionadas con el software lo experimentarán como un problema de transformación.
La capa que falta es la atribución desde los tokens hasta los resultados. Las empresas necesitan una capa de conversión que conecte el gasto en inferencia con el trabajo completado y los resultados comerciales generados. Esta capa debe responder tres preguntas: ¿Cuál es el costo real de este flujo de trabajo, incluidos reintentos y correcciones? En la trayectoria de ejecución del agente, ¿qué partes fueron realmente importantes y cuáles fueron solo chapuceos ineficientes? ¿Cambió este trabajo el modelo operativo (por ejemplo, menos tickets por agente de servicio, ciclos de reclamación más cortos, presupuesto de BPO más pequeño, contrataciones pospuestas)? La siguiente capa es hacer la atribución de resultados en lenguaje de negocio. No es solo decir «este flujo de trabajo costó 2.13 dólares», sino decir: este tipo de reclamación es más barata con un agente que con BPO, pero si la póliza requiere documentos de excepción adicionales, la cola larga de reintentos destruye la economía.
La medición se convertirá en memoria. Para conectar un token con un resultado, las empresas deben capturar todo lo intermedio: qué vio el agente, qué recuperó, qué herramientas llamó, qué ignoró, dónde reintentó, cuándo fue sobrescrito por un humano, qué regla de excepción se aplicó, qué precedente influyó, y por qué una ruta tuvo éxito y otra falló. La capa de medición debe registrar la trayectoria de decisión, y esto es precisamente algo que las empresas casi nunca han tenido realmente. Los sistemas de registro pueden capturar qué sucedió, pero rara vez capturan por qué. Por ejemplo, un CRM puede decirte que una venta se retrasó, pero no puede capturar los juicios no escritos detrás del pronóstico de ventas.
El razonamiento detrás de las decisiones es uno de los activos más corruptibles y efímeros de una empresa, porque reside en hilos de Slack, cadenas de correo, reuniones de escalamiento y en las mentes de las personas. El problema es que la gente se va y los procesos cambian.
La IA cambia esto, porque los agentes generan trazas. Cada recuperación, llamada a herramienta, reintento, escalada, corrección manual y decisión final se convierte en parte de la ruta desde el contexto a la acción y al resultado. Inicialmente, las empresas capturarán estas trazas para justificar el gasto. Pero una vez capturadas, estas trazas serán más valiosas que los propios informes de costos, porque se convertirán en un registro duradero de cómo la organización realmente toma decisiones. (Ahem, grafo de contexto, aunque últimamente estoy realmente cansado de esa palabra).
La capa de asignación es el verdadero premio. Si la inferencia se convierte en un recurso de pago por uso dentro del modelo operativo del cliente, entonces cada dólar debe demostrar que vale la pena gastarlo. ¿Qué proveedores pueden explicar cuándo un token se convirtió en resultado, cuándo no, y por qué?
Las empresas no resolverán esto completamente por sí mismas. Lo comprarán como una transformación. Las empresas Fortune 500 han pasado por este guion repetidamente antes: abróchense los cinturones, contraten a McKinsey, recluten a todos los ex empleados de Palantir del mercado, y luego que el CEO impulse el cambio desde arriba. La atribución de tokens a resultados también llegará de manera similar a los ERP, BI y la transformación digital: como un «proyecto» respaldado por la alta dirección, con una infraestructura subyacente, que finalmente se convierte en la nueva fuente de la verdad. Los fundadores que puedan lograr esto formarán equipos fundacionales de un tipo diferente, y ellos mismos también diferirán del arquetipo tradicional de emprendedor.
Quien controle la atribución de tokens a resultados podrá tomar decisiones de asignación: qué flujos de trabajo merecen más potencia de cálculo, cuáles deben limitarse, cuáles deben cambiarse a modelos más baratos, cuáles continuarán siendo realizados por humanos, cuáles pueden sustituir al BPO. Y una vez que puedes tomar esas decisiones, controlas hacia dónde fluye el gasto en IA dentro de la empresa y obtienes la confianza necesaria para asignar ese recurso.
La primera fase de la IA empresarial demostró que: los modelos pueden realizar el trabajo. La próxima fase decidirá: cuánto de ese trabajo realmente merece la pena pagar. Como dijo Charlie Munger: Muéstrame los incentivos y te mostraré los resultados.
Enlace al artículo original
