La era post tokenmaxxing

Hace unos años trabajé en una empresa que decidió medir la adopción de un sistema nuevo por la cantidad de acciones que se realizaban dentro de él. Si había hits a la página de la app, significaba que la estaban usando. Y los hits se pueden contar. Sonaba razonable.

Los empleados hicieron un archivo .bat que abría varias páginas de la aplicación. El número subió pero nadie usó el sistema. Me acordé de eso cuando empecé a ver empresas poniendo el consumo de tokens de inteligencia artificial dentro de los objetivos de sus equipos.

Qué es el tokenmaxxing y por qué apareció en 2026

Un token es la unidad con la que se mide el texto que procesa un modelo de lenguaje: cada pregunta y cada respuesta consumen tokens, lo que permite contar cuánta inteligencia artificial usa una persona. El tokenmaxxing es consumir la mayor cantidad posible de tokens y presentar ese volumen como prueba de productividad.

La palabra se volvió corriente alrededor de abril de 2026, cuando se supo que Meta tenía un tablero interno llamado Claudeonomics que rankeaba a más de 85.000 empleados por consumo, con un top 250 de "power users" y títulos gamificados tipo "Token Legend". En treinta días esos empleados consumieron 60,2 billones de tokens. A precio de lista eso son unos 900 millones de dólares. Meta dio de baja el tablero después de que The Information lo publicara.

Pero no fue un caso aislado.

En Disney, cerca de 5.000 empleados de producto y tecnología tuvieron acceso a un tablero con formato de ranking. Business Insider reportó que un solo empleado invocó al asistente unas 460.600 veces en nueve días hábiles, alrededor de 51.000 por día. Esa cifra no la produce una persona escribiendo: la produce un agente corriendo solo.

En Amazon el mandato fue que más del 80 por ciento de los desarrolladores usara herramientas de inteligencia artificial todas las semanas, con el uso expuesto en tableros por equipo. Los empleados empezaron a delegar tareas innecesarias a agentes en la plataforma interna, no porque necesitaran automatizar algo sino porque necesitaban el número. Un empleado se lo resumió al Financial Times: cuando miden el uso, se crean incentivos perversos.

En Salesforce el objetivo se puso directamente en dólares, con un mínimo mensual de gasto por persona y un widget de escritorio que se actualiza cada quince minutos para recordarte cuánto te falta gastar. En Microsoft el memo interno de la vicepresidenta de la división de desarrolladores fue explícito: usar inteligencia artificial dejó de ser opcional y pasa a ser parte de la evaluación de desempeño de cada rol y cada nivel.

Cómo se gana un ranking de tokens sin hacer nada útil

Los ejemplos documentados son mejores que cualquier hipótesis:

🔹 Preguntarle a la herramienta cosas que ya estaban en la documentación, para que la lea, la procese y conteste diez veces más lento consumiendo mucho más.

🔹 Pedirle prototipos de funcionalidades que no se pensaba trabajar, para después descartarlos.

🔹 Dejar agentes corriendo de noche mientras la persona duerme.

🔹 Mirar el gasto de los compañeros para calibrar el propio apenas por encima del promedio.

El último es el más revelador, porque no es fraude. Es lo que hace cualquier persona sensata cuando le miden algo que no tiene relación con su trabajo: averigua cuál es el mínimo aceptable y se queda ahí. Es la misma conducta que produjo aquel archivo .bat.

Conviene ponerle contexto. El estudio de MIT Project NANDA de agosto de 2025, sobre más de 300 implementaciones empresariales, encontró que el 95 por ciento de los pilotos de inteligencia artificial generativa no producen retorno medible. Su diagnóstico no fue que los modelos sean malos: fue que las organizaciones gestionan mal la adopción. Uno de los culpables que nombran es la ausencia de un resultado definido antes de empezar a construir.

Un ranking de tokens es, literalmente, empezar a construir sin haber definido el resultado.

Esto no es nuevo, es la ley de Goodhart otra vez

La ley de Goodhart dice que cuando una medida se convierte en objetivo, deja de ser una buena medida. No es una teoría de management moderna: es lo que pasa siempre que se premia una actividad en lugar de un resultado.

El caso de manual del mundo del software son las líneas de código. Durante años se midió la productividad de un programador por cuántas líneas escribía. El resultado no fue más software: fue código verboso, inflado y más difícil de mantener, porque el incentivo premiaba el volumen. La crítica más citada es de Bill Gates: medir el progreso de la programación por líneas de código es como medir el progreso de la construcción de un avión por su peso.

Un avión más pesado no es un avión mejor. Suele ser peor.

Y no hace falta ir al software para encontrar el mismo mecanismo con consecuencias más graves. Wells Fargo tuvo durante años un objetivo interno de vender al menos ocho productos financieros por cliente. Lo llamaban internamente la "Gr-eight initiative". Los empleados, bajo esa presión, abrieron al menos 3,5 millones de cuentas fraudulentas sin consentimiento de los titulares, incluso inventando direcciones de correo para dar de alta accesos. La multa combinada de los reguladores fue de 185 millones de dólares. En enero de 2017 el banco eliminó la métrica.

Poné los tres al lado y el patrón salta a la vista. Un .bat que abre ventanas, código inflado, cuentas inventadas y agentes corriendo de noche son la misma respuesta a la misma clase de estímulo. La diferencia entre un caso y otro no es el tipo de métrica: es cuánto tiempo la dejaron corriendo antes de darse cuenta.

Si vas a medir la adopción de una tecnología, el número que elijas va a ser optimizado. La pregunta no es si tu equipo va a jugar con la métrica. Es si optimizarla mejora tu negocio.

Lo que hizo Uber después de quemar el presupuesto

Uber consumió todo el presupuesto de inteligencia artificial de 2026 en los primeros cuatro meses del año. En junio, Bloomberg reportó que la empresa había capado el uso de herramientas para contener el costo. En agosto, su CTO Praveen Neppalli Naga declaró que la era del tokenmaxxing se estaba terminando.

Hasta ahí es una historia de control de gastos. Lo que la vuelve interesante es lo que hicieron en el medio.

En julio, el mismo CTO publicó el método que habían encontrado: Agentic Pods. Un pod son dos personas, un ingeniero con manejo de inteligencia artificial más un experto de dominio de alguna función del negocio. No de tecnología: de finanzas, de marketing, de operaciones, de legales, de compras, de soporte. En dos meses corrieron pods sobre 16 funciones distintas: es, en esencia, el mismo enfoque de a quién sentamos al lado de quién que aplicamos en nuestro servicio de implementación de agentes de IA.

Cada pod trabaja en un sprint de diez días con esta secuencia:

Días	Qué se hace
1 y 2	El ingeniero acompaña al experto. Observa cada paso, documenta el flujo de trabajo, pregunta. No escribe una línea de código.
3	Se priorizan oportunidades por escala, repetición, impacto de negocio y disponibilidad de datos.
4 y 5	Se construye un agente que funciona, al lado de la persona que hace el trabajo. No para ella.
6 a 9	Se valida con varias otras personas que hacen la misma tarea, para confirmar que sirve más allá del caso original.
10	Sale a producción.

Los resultados que publicaron:

Proceso	Antes	Después
Asignación de capital en 150 ciudades	15 horas	30 minutos
Reporte de pacing financiero	2 días	10 minutos
Control de calidad de contenido web de marketing	2 semanas	50 minutos

Y una frase del CTO que vale más que las tres filas de la tabla: la unidad de automatización es el flujo de trabajo, no la tarea individual.

Una salvedad necesaria antes de seguir. Todas estas cifras las publica Uber sobre Uber. No las auditó nadie de afuera. Y una empresa que acaba de quedar mal parada por gastar de más tiene un incentivo evidente para mostrar que aprendió. Tomá los números con esa pinza. Lo que sí se sostiene independientemente de las cifras es el cambio de método, porque el método se puede evaluar por su lógica interna.

El sprint de Uber es Personas, Procesos y Tecnología

Acá está lo que hace que este caso valga un artículo y no un comentario.

Mirá otra vez la tabla de los diez días. No está ordenada por conveniencia:

Días 1 y 2: personas. Dos días enteros, el veinte por ciento del sprint, son una persona mirando trabajar a otra. Sin construir nada. El objetivo declarado es entender el flujo y ganar intuición sobre cómo se hace hoy la tarea.

Día 3: procesos. Recién con el flujo entendido se decide qué automatizar, con cuatro criterios explícitos: escala, repetición, impacto de negocio y datos disponibles. Es el momento en que se elige el problema. Es el mismo tipo de criterio que conviene aplicar para decidir qué automatizar primero en cualquier equipo, no solo en un pod de dos personas.

Días 4 y 5: tecnología. Ahora sí se construye. Y se construye al lado de la persona que hace el trabajo, no en un escritorio aparte, lo que significa que las decisiones técnicas se corrigen en el día en lugar de en la demo final.

Días 6 a 9: vuelta a las personas. Se valida con otros que hacen lo mismo. Es el paso que separa una automatización que sirve a un caso de una que sirve a un proceso.

Ese orden es el marco de Personas, Procesos y Tecnología, que no es una preferencia metodológica: es lo que separa el segundo intento de Uber del primero. El primer intento repartió la herramienta a toda la organización y esperó que el valor apareciera solo. Eso es empezar por la tecnología. El segundo empezó por la persona que sufre el proceso: el mismo error de orden, con otro nombre, que hace fracasar la mayoría de las implementaciones de CRM, elegir la herramienta antes de diseñar el proceso.

Y hay un detalle del caso que se pasa por alto, el más copiable de todos: eligieron un reporte de dos días, no un proyecto de seis meses. El primer proyecto de inteligencia artificial no está para demostrar ambición, está para ganarse el derecho a la próxima apuesta.

Qué medir en lugar de tokens

El punto de partida es que medir el uso de inteligencia artificial no está mal. Lo que está mal es rankear personas por el volumen que consumen.

La prueba de que la distinción existe es Shopify, que midió lo mismo que Meta y llegó a otro lado. Le cambió el nombre al tablero, de "leaderboard de tokens" a "tablero de uso", a propósito, para desalentar la competencia entre personas. Y le puso interruptores automáticos que detectan agentes desbocados por picos de gasto diario. Mismo dato, dos usos: uno para entender, el otro para competir.

Tres métricas que aguantan mejor:

🔹 Procesos que salieron a producción. No pilotos, no pruebas de concepto, no demos. Procesos que hoy corren distinto que hace tres meses. Se cuentan con los dedos y no se pueden inflar.

🔹 Tiempo de ciclo del proceso elegido. Cuánto tardaba antes, cuánto tarda ahora. Es la métrica que usó Uber para contar su caso. Es la única de la lista que le importa a alguien fuera del área.

🔹 Cuántas personas dejaron de hacer esa tarea a mano. Es la que mejor resiste el gaming, porque para moverla hay que cambiar el trabajo de alguien de verdad.

Las tres tienen algo en común: miden el resultado del proceso, no la actividad de la persona. Ese es el criterio y sirve para evaluar cualquier métrica que te propongan de acá en adelante.

Cuatro señales de que tu métrica de IA está mal diseñada

1. Se puede subir sin que cambie nada en la operación. Si alguien mejora el número sin que ningún proceso funcione distinto, la métrica mide actividad. Antídoto: que el número se reporte junto al proceso que cambió.

2. Rankea personas. Un ranking convierte una herramienta de diagnóstico en una competencia entre compañeros. El dato puede ser el mismo; el ranking es lo que cambia la conducta. Antídoto: tablero agregado por área, sin nombres.

3. Nadie definió el resultado antes de empezar. Es el hallazgo del estudio de MIT y el más frecuente. Si el proyecto arrancó por la herramienta, la métrica va a ser de uso de la herramienta. Antídoto: no habilitar presupuesto hasta que esté escrito qué proceso mejora y cuánto.

4. No tiene tope ni corte automático. Un agente que se descontrola de noche no es mala fe, es software. Antídoto: los interruptores de Shopify, o un límite de gasto diario con alerta.

Conclusión

El tokenmaxxing no fue un fracaso de la inteligencia artificial. Fue un fracaso de diseño de objetivos, del mismo tipo que producía código inflado en los noventa y cuentas falsas en un banco en 2016. La tecnología cambió, el error es idéntico: se premió una actividad y se obtuvo esa actividad, no el resultado que se buscaba.

Lo que hace valioso el caso de Uber no es que gastó de más. Es que la corrección que encontró después se puede copiar sin tener su presupuesto: dos personas, diez días, un proceso conocido que tarda demasiado. Y los primeros dos días de esos diez son mirar trabajar a alguien.

Lo caro nunca fueron los tokens. Lo caro fue no haber decidido antes dónde valía la pena usarlos.

Si tu proceso ya está mapeado y con reglas claras, la pregunta que sigue es si tu empresa está lista para implementar un agente de IA, o si todavía queda trabajo de proceso antes de eso.

---