El equipo ya usa AI. ¿Eso cuenta como retorno?

El uso de AI (tokens, logins, prompts) no es retorno: mide actividad, no si el trabajo mejoró, costó menos o llegó al estado de resultados. El retorno exige baseline escrito antes, métricas de resultado y, cuando aplica, costo por unidad procesada en vez de horas «ahorradas».

La pregunta que me hacen cambió: de «¿el equipo ya está usando AI?» a «¿y eso dónde se ve?». La primera se contesta con un tablero; la segunda, con una línea del P&L acordada antes de empezar.

Y sin embargo, durante un tiempo, eso fue exactamente lo que se midió. Aparecieron tableros de adopción, competencias internas de quién consume más, y hasta un nombre para el deporte de maximizar el uso. El uso, en efecto, subió. Después volvieron los presupuestos. Y con ellos, la pregunta difícil.

El tablero de uso mide el combustible, no el viaje

Un token es una unidad de texto que el modelo procesa. Un login es alguien que abrió la herramienta. Ninguna de las dos cosas te dice si el trabajo salió mejor, más barato o más rápido, ni si eso llegó al número.

Se puede pasar el día produciendo reportes, código y respuestas y no haber movido una sola línea del estado de resultados. Otra persona puede usar la misma herramienta veinte minutos, sacar un cuello de botella, y sí. El tablero los trata al revés: premia al que más consume.

Hay un problema más incómodo. Aunque la AI esté produciendo un beneficio real, una parte se esparce en individuos: media hora acá, cuarenta minutos allá. Si ese tiempo no se reasigna (a más ciclo, a más clientes, a no contratar el asiento que se iba a abrir) la empresa no capturó nada. Alguien se benefició. No fue el P&L.

Por eso «horas ahorradas» no es una métrica de retorno. Es una métrica de actividad con disfraz de plata.

El volumen también miente, si no hay calidad

Cuando se cambia el foco del uso al resultado, hay que diseñar el resultado para que capture lo bueno y lo malo.

Un ejemplo que no es de una empresa, y por eso se ve tan claro: investigadores de la University of Surrey revisaron papers que sacaban asociaciones de un mismo dataset de salud pública de Estados Unidos. Entre 2014 y 2021, el ritmo era de unos cuatro al año. En 2024, hasta el 9 de octubre, iban ciento noventa, muchos de un solo factor, sin el diseño que el problema pedía (Suchak y otros, PLOS Biology). Más papers. No necesariamente mejor ciencia.

La trampa es la misma adentro de una empresa: más tickets «cerrados», más código mergeado, más mails mandados. Si no se mide calidad (errores, retrabajo, lo que el cliente tuvo que corregir), el volumen se parece a productividad y no lo es.

En ingeniería, Google Cloud lleva años midiendo tres cosas a la vez: velocidad, facilidad y calidad. Las dos primeras sin la tercera son una forma cara de shippear peor, más rápido.

Qué sí contaría como retorno

Tres capas. No un KPI.

La de uso sigue sirviendo mientras hay que empujar adopción. Un área en cero es señal. Un ranking de quién gasta más tokens no lo es.

La de resultado es la que contesta al directorio: tiempo de ciclo, costo por unidad procesada, errores, retrabajo, precios que de verdad cambiaron, capital de trabajo que se liberó. Cada una contra un baseline escrito antes de encender la herramienta. Y con un chequeo de calidad, no sólo de cantidad.

La de organización es la que se olvida cuando hay ansiedad por reportar ROI el mes uno: si la gente puede trabajar con esto, si se está construyendo criterio interno en lo que la AI no va a automatizar, si el cambio se está gobernando. No reemplaza al número. Evita que el número se pida antes de que el trabajo exista.

Hay una honestidad más. A veces el número baja un tiempo, porque hay que aprender, porque el cuello de botella se corre de lugar, porque las prácticas con las que se medía el performance anterior ya no alcanzan. Eso no es un argumento para no medir. Es un argumento para medir con una ventana, y para no vender el mes uno como si fuera el caso.

Y hay una trampa en la que no hay que caer, aunque sea la más fácil de poner en un Excel: tomar el tiempo «ahorrado» como excusa para recortar gente. En algunos oficios, en algunas circunstancias, el trabajo cambia de tamaño. Pero la gente que ya no está no se puede redeployar a algo que rinda más, y el dueño no compra «vengo a echar gente». El retorno que sí se puede defender es otro: lo que no se gastó en contratar más, el costo de cada vuelta, los días que dejó de tardar el ciclo.

Nada de eso lo cuenta un tablero de adopción. Lo cuenta un sistema que observa el outcome, el mismo que tiene que estar instalado si alguien va a cobrar contra resultado.

Las tres cosas que pediría antes de creer un «retorno de AI»

1. Un baseline escrito antes de empezar. Qué métrica, contra qué período, quién la valida. Si el número se inventa después, no es retorno: es relato.
2. Un outcome que el sistema pueda ver, con calidad. No «usamos más». No «ahorramos horas». Costo por unidad, tiempo de ciclo, precios cambiados, errores que bajaron. Y la cuenta de lo que hubo que corregir a mano.
3. Una ventana, no una foto del mes uno. Aprender cuesta. Pedir el P&L antes de haber rediseñado el trabajo es pedir un milagro y llamar a la decepción «fracaso de la AI».

La pregunta del artículo anterior sigue siendo la que importa: si mañana te sentás con tu CFO, ¿podrían ponerse de acuerdo en qué línea del estado de resultados aparece lo que ya invertiste?

A esa le agrego una, que es la misma dicha al revés: si el uso se duplicó y el número no se movió, ¿qué compraste exactamente?