Inteligencia artificial · Valor y medición
Entre usar inteligencia artificial y capturar valor hay una cadena: tarea → flujo → resultado → caja. La aritmética es fácil. Demostrar que cada eslabón aguanta es lo difícil, y es lo único que separa un retorno de una historia bien contada.
En este artículo
El tablero que aplaude y el tablero que decide
Tengo una aplicación de gimnasio que me felicita. Me dice cuántos días entré, cuántos minutos estuve adentro y cuántas series levanté. Es un tablero honesto y completamente insuficiente: mide que fui, no que estoy mejor. Y aunque estuviera mejor, faltaría la pregunta incómoda: ¿eso cambió algo en mi vida?
La misma confusión aparece cuando una empresa se sienta a decidir si el proyecto de IA sigue. Rara vez he visto un comité dedicado a eso: la conversación ocurre donde alcanza —un punto de la reunión de dirección, o el informe que prepara el área de tecnología para justificar la renovación de las licencias—. Y ahí compiten dos tableros.
Uno informa activación, consultas y consumo de tokens. El otro informa tiempo de resolución, reapertura de casos, costo por caso y —esta es la casilla incómoda— qué pasó con las horas liberadas.
Aplaude
Permite decidir
Los dos tableros describen el mismo trimestre de la misma empresa.
El retorno sobre la inversión (ROI, por sus siglas en inglés) compara los beneficios atribuibles con la inversión completa. La fórmula la hace cualquiera en una servilleta. Demostrar qué beneficio fue causado por la intervención y capturado por la empresa, no.
Esa es la tensión detrás de «How to measure returns on AI», la columna de The Economist que motivó este análisis: deja de maximizar tokens, mide resultados, vigila la calidad, espera una caída inicial de productividad y decide qué vas a hacer con el tiempo que liberes. Es una corrección necesaria para una conversación que confundió acceso con adopción, y adopción con valor.
Pero cambiar un contador de tokens por un contador de horas no resuelve el problema económico. Lo empieza.
Lo que The Economist acierta
Dos de sus cuatro ideas son las que sostienen todo lo que sigue.
Una métrica de entrada no demuestra un resultado. Tokens, usuarios activos, prompts o agentes desplegados son telemetría: sirven para saber si el sistema existe y si alguien lo usa. No dicen si el trabajo mejoró.
Velocidad sin calidad destruye valor. En un experimento aleatorizado con 758 consultores de Boston Consulting Group (BCG), quienes usaron GPT‑4 completaron 12,2 % más tareas dentro de la frontera de capacidad del modelo y las terminaron 25,1 % más rápido, con una calidad significativamente mejor. En una tarea puesta a propósito fuera de esa frontera, en cambio, los usuarios de IA fueron 19 % menos propensos a llegar a la respuesta correcta. Equivocarse antes no es productividad.
Las otras dos —que los beneficios pueden llegar después de una caída inicial, y que el tiempo liberado necesita un destino— merecen sección propia y las retomo más adelante.
Mi diferencia con la columna es de arquitectura, no de fondo: «mide resultados» sigue siendo una consigna. Para volverla un sistema de gestión hay que reconstruir la cadena causal completa.
Por qué las cifras parecen pelearse
¿La IA sube 15 % la productividad o hace a los programadores 19 % más lentos? ¿Ahorra 40 % del tiempo o no mueve la productividad de 89 % de las empresas? Los números parecen contradecirse porque responden preguntas distintas.
| Hallazgo | Qué se observó y cómo | Qué permite afirmar | Qué no permite afirmar |
|---|---|---|---|
| 40 % menos tiempo y 18 % más calidad en escritura profesional | Una tarea acotada; experimento aleatorizado | Efecto causal en esas tareas | Impacto en un proceso o en el estado de resultados |
| 15 % más casos resueltos por hora en soporte | Un agente en un flujo real; despliegue escalonado, 5.172 agentes | Efecto operativo en una empresa | Que aplique a toda ocupación, o retorno financiero |
| Gana dentro de la frontera, pierde fuera | Tarea de conocimiento; experimento prerregistrado, 758 consultores | Que el efecto cambia de signo según la tarea | Que toda consultoría mejore igual |
| 19 % más tiempo con IA | Código abierto real; experimento aleatorizado, 16 desarrolladores | Efecto en repositorios maduros con herramientas de 2025 | Que la IA ralentice el desarrollo en general |
| 2,2 % de las horas laborales «ahorradas» | Un trabajador; encuesta representativa, autorreporte | Percepción agregada de tiempo liberado | Causalidad, calidad o captura financiera |
| 89 % no reporta impacto en productividad | Una empresa; documento de trabajo, ~6.000 ejecutivos | La brecha entre uso y efecto percibido | Que la IA no funcione: es autorreporte sin revisión por pares |
Hay al menos cuatro niveles observados —tarea, persona, flujo y empresa— y una ganancia puede ser verdadera en el primero y evaporarse antes del cuarto. Un redactor termina un informe 40 % antes, pero el documento espera tres días la firma del comité. Un agente contesta más rápido, pero suben las reaperturas. Un desarrollador genera más código y traslada trabajo a revisión y mantenimiento. Una empresa activa licencias, pero la demanda no crece y la nómina tampoco.
Es la fila del banco: puedes poner al cajero más rápido del mundo, que si el gerente que firma sigue siendo uno solo, la fila no desaparece. Se muda de escritorio.
Esa fuga no invalida la mejora local. Invalida el salto automático de mejor tarea = mejor empresa.
Y hay un detalle del experimento de METR —Model Evaluation and Threat Research, un instituto independiente que evalúa modelos de IA— que deberías recordar cada vez que alguien te muestre una encuesta de productividad: esos 16 desarrolladores tardaron 19 % más con IA, y aun así creyeron que habían sido unos 20 % más rápidos. La percepción se equivocó de signo. Cuando el 2,2 % de horas ahorradas que reporta la Reserva Federal —arriba desde 1,6 % en el tercer trimestre de 2024— sale de autorreportes, esa brecha es parte del dato.
Un ROI puede ser aritméticamente correcto y económicamente falso si una sola de sus premisas —que el tiempo sea reasignable, que exista demanda, que la calidad sea observable, que nadie ajuste su conducta a la métrica, que el efecto persista— no se cumple.
La cadena de evidencia del valor de IA
En los cinco niveles de la analítica sostuve que describir, diagnosticar, predecir y prescribir son inferencias distintas, y que confundirlas es la forma más común de engañarse con datos. La cadena que propongo es esa misma idea aplicada al dinero: cinco eslabones, cinco tipos de afirmación, y la regla de que la fuerza del caso no la da su cifra más vistosa sino su conexión más débil.
Toca un eslabón para ver qué mide, qué hay que probar y por dónde se fuga el valor.
0 · Actividad ¿se usa?
- Métricas
- Usuarios activos, frecuencia, tipos de tarea, aceptación de sugerencias, consumo.
- Prueba mínima
- Ninguna: es diagnóstico. Sirve para ver adopción y detectar fallas de acceso.
- Se fuga si
- Alguien la presenta como retorno. No prueba productividad ni caja.
1 · Capacidad de tarea ¿el trabajo sale mejor?
- Métricas
- Tiempo por tarea, exactitud, calidad, variabilidad, desempeño por nivel de experiencia.
- Prueba mínima
- Comparación contra una línea base —la versión mínima y bien hecha sin la intervención— y, cuando se pueda, asignación aleatoria.
- Se fuga si
- El promedio esconde que la IA ayuda a los nuevos y estorba a los expertos.
2 · Flujo ¿cambió el sistema real?
- Métricas
- Tiempo de ciclo de punta a punta, colas, retrabajo, escalaciones, carga de revisión, excepciones.
- Prueba mínima
- Mirar el proceso completo, no la etapa que mejoró.
- Se fuga si
- Una etapa gana diez minutos y la siguiente pierde doce.
3 · Resultado de negocio ¿se movió algo que importa?
- Métricas
- Conversión, retención, resolución en primer contacto, incidentes, tiempo de lanzamiento, errores materiales.
- Prueba mínima
- Mostrar que el resultado cambió por la intervención y no por temporada, mezcla de casos, incentivos o demanda.
- Se fuga si
- El cambio coincide con una campaña, un pico estacional o una mezcla distinta de clientes.
4 · Captura económica ¿quién lo convirtió en valor?
- Métricas
- Margen incremental, gasto realmente evitado, capacidad absorbida por demanda, pérdida esperada reducida, caja.
- Prueba mínima
- Un dueño de negocio y Finanzas acuerdan el mecanismo de captura antes de desplegar.
- Se fuga si
- Nadie firmó qué haría la empresa si la métrica mejoraba. «Más rápido» no se convierte solo en caja.
El riesgo y el aprendizaje corren en paralelo a toda la cadena: un sistema puede generar valor hoy y aumentar deuda técnica o fragilidad mañana; y puede no producir un peso todavía y estar construyendo una capacidad reutilizable que sí valdrá.
La pregunta no es: «¿cuál es el ROI de nuestra IA?».
La pregunta es: «¿en qué eslabón tenemos evidencia, dónde se rompe la causalidad y cómo vamos a capturar el efecto?».
Esto extiende otra idea del blog: AI‑Native no es tener más IA, es aprender a rediseñar el trabajo. El retorno no vive dentro del modelo. Vive en el sistema que lo rodea: personas, reglas, datos, plataforma y decisiones.
Una hora ahorrada no es una hora monetizada
«Ahorramos 20.000 horas» suena financiero porque las horas tienen un salario pegado. Pero multiplicar horas por costo laboral produce un valor teórico de capacidad, no un beneficio realizado.
| Destino de la hora liberada | Clasificación prudente |
|---|---|
| Se dispersó en reuniones, esperas o más holgura | Beneficio de experiencia; valor financiero no demostrado |
| Redujo horas extra o contratación externa | Ahorro realizado: salió menos caja |
| Permitió atender más demanda con el mismo equipo | Valor de capacidad; se monetiza solo si hay demanda |
| Evitó una contratación que estaba en el plan | Costo evitado: cambió una decisión presupuestaria verificable |
| Se reasignó a ventas, análisis o innovación | Atribuible solo si mides esa salida adicional |
| Mejoró el descanso y bajó el desgaste | Beneficio real —menos rotación y errores—, pero necesita su propia cadena |
Dos trampas se repiten. La primera es contar disponibilidad como ahorro: si nadie reduce gasto ni produce más, el costo laboral sigue ahí completo. La segunda es contar dos veces la misma hora, valorándola como tiempo liberado y sumando además la contratación evitada o el ingreso que esa capacidad generó. El beneficio de fondo es uno solo; sus manifestaciones contables no se apilan.
Un ejemplo para hacer la cuenta
Supón —esto es didáctico, no un caso real— que una empresa colombiana reporta 20.000 horas liberadas y les asigna un costo cargado de COP 80.000 la hora. COP es el código del peso colombiano. El «beneficio» de presentación sería COP 1.600 millones.
Al seguir la cadena descubre que solo 25 % de esa capacidad se reasignó a trabajo con salida medible: COP 400 millones. Canceló además COP 300 millones de contratación externa. Y el costo total de propiedad fue COP 550 millones.
El beneficio realizado son COP 700 millones; el neto, COP 150 millones; y el ROI simple, 27 %. No 191 %, que es lo que sale de tratar todas las horas como caja. Y si las horas reasignadas y la contratación cancelada corresponden al mismo trabajo, incluso ese 27 % está inflado por doble conteo.
Calculadora del espejismo
Cambia los supuestos y mira cuánto se mueve la cifra. Los valores iniciales son los del ejemplo. Nada sale de tu navegador.
Los deslizadores necesitan JavaScript. Esta vista muestra el ejemplo del artículo con sus cifras correctas, pero no reacciona: falta el snippet B.
Actívalo si no puedes demostrar que son beneficios distintos: entonces solo cuenta el mayor de los dos.
Ejemplo didáctico. No corresponde a un caso observado.
La aritmética nunca fue lo difícil. Lo difícil es demostrar el mecanismo de captura.
El libro mayor: caja, capacidad, riesgo y aprendizaje
Una sola cifra de ROI mezcla efectos con distinta liquidez, incertidumbre y horizonte. Es como sumar en la misma línea el efectivo de la caja, el inventario que no has vendido y la reputación del negocio: los tres valen, pero no se cobran igual. Por eso propongo un libro mayor del valor de IA con cuatro cuentas separadas.
1 · Caja. Ingreso incremental, margen de contribución, gasto eliminado, contratación externa reducida. Es la cuenta más fácil de auditar y la única que tu director financiero defiende sin pestañear.
2 · Capacidad. Horas liberadas, volumen adicional posible, colas más cortas, contratación evitada. Es valor potencial hasta que la demanda o una decisión de presupuesto lo capture.
3 · Calidad y riesgo. Errores, retrabajo, incidentes, pérdida esperada, cumplimiento, privacidad, confianza del cliente. Puede ser activo o pasivo. El Instituto Nacional de Estándares y Tecnología de Estados Unidos (NIST) recomienda, en su perfil de IA generativa del marco de gestión de riesgos, medir riesgos e impactos durante todo el ciclo de vida y no solo antes de desplegar.
4 · Aprendizaje y opción. Datos de evaluación reutilizables, componentes compartidos, capacidades internas y conocimiento sobre dónde falla la IA. Tiene valor estratégico, pero no se infla como si fuera caja segura.
Esta separación es la que le da instrumentos a PULSE: si la organización va a sentir sus propias señales antes de decidir, necesita que la señal no mienta. Cuatro cuentas mienten menos que un número.
El costo que casi nadie pone en el denominador
Pregúntate qué trabajo nuevo creó la IA: revisar, verificar, documentar, corregir, escalar excepciones, mantener integraciones. La producción generativa crece más rápido que la capacidad experta de revisarla, y a esa brecha la llamé deuda de revisión.
Es la línea más subestimada de cualquier caso de negocio de IA, por una razón estructural: la revisión humana no es un paso del proceso, es un presupuesto de atención experta, y ese presupuesto es inelástico. Puedes duplicar la producción de borradores en una semana; no puedes duplicar en una semana la cantidad de gente con criterio para aprobarlos.
Tampoco toda salida necesita el mismo control. La matriz de proporcionalidad del mismo artículo cruza la consecuencia del error —reversible o irreversible— con el volumen de casos: verificación ligera, muestreo con alertas, revisión completa, o rediseñar antes de escalar. Poner todo en revisión completa mata el ROI. No poner nada lo hipoteca.
Riesgo de primer y de segundo orden
El de primer orden ocurre dentro del caso de uso: una respuesta errónea, fuga de datos, sesgo, incumplimiento, costo de inferencia por encima de lo previsto. Casi siempre tiene métrica operativa y dueño identificable.
El de segundo orden aparece porque el sistema cambia el comportamiento de la organización: dependencia del proveedor, pérdida gradual de criterio experto, homogeneización de ideas, o el cuello de botella que se muda hacia un equipo que nadie está mirando. Tarda más, no cabe en el tablero del proyecto y sí altera el retorno de la cartera. Un proyecto puede superar su meta de productividad y fracasar por un riesgo de segundo orden que nadie se asignó, así que lleva un registro aparte de exposición, dueño, horizonte e indicador adelantado.
El denominador también necesita disciplina: el costo total de propiedad incluye integración, datos, pruebas, evaluación humana, seguridad, cumplimiento, formación, gestión del cambio, monitoreo y deuda técnica. Y en una inversión de escala conviene descontar los flujos —traer el dinero futuro a hoy con una tasa que refleje tiempo y riesgo—, algo que en una prueba temprana solo produce una precisión falsa.
Cómo medir sin engañarte
Medir bien no es convertir cada piloto en un ensayo académico. Es usar el mejor diseño posible para el riesgo de la decisión que tienes enfrente.
1 · Define la unidad de valor. No «la licencia». El caso, la decisión, el cliente, el expediente, el ticket o el proceso que recibe la intervención.
2 · Registra una línea base segmentada. Un promedio global esconde cosas grandes: en el estudio de soporte con 5.172 agentes, el quintil de menor desempeño mejoró alrededor de 36 % en casos por hora, mientras los agentes más expertos casi no ganaron velocidad y perdieron algo de calidad. El mismo despliegue, dos historias opuestas.
3 · Construye la comparación. Necesitas saber qué habría pasado sin IA —los economistas lo llaman contrafactual, pero la pregunta es tan simple como suena—. De mayor a menor fuerza: asignación aleatoria por casos o equipos; despliegue escalonado, donde grupos comparables reciben la herramienta en momentos distintos; grupo emparejado; serie temporal interrumpida; y comparación antes/después solo si no hay nada mejor.
4 · Mide velocidad y calidad juntas. Toda métrica de productividad necesita una barrera: exactitud, reapertura, satisfacción, error material o carga de revisión. Si el sistema optimiza la cifra visible, el costo se muda a donde nadie mira.
5 · Suma todo el costo incremental, incluida la deuda de revisión.
6 · Declara el mecanismo de captura. Antes de la prueba, completa esta frase: «si la métrica X mejora Y, la empresa hará Z». Z puede ser reducir contratación externa, absorber una cola, rediseñar roles o bajar una provisión de riesgo. Si no puedes completarla, no tienes un caso de negocio: tienes una intención.
7 · Fija una regla de decisión. No basta una meta; define también un límite. Escalar si el efecto supera el umbral con calidad estable. Rediseñar si mejora la tarea pero no el flujo. Detener si el costo de revisión o el riesgo se comen el beneficio.
Esos siete pasos caben en un trimestre: quincena inicial para el contrato de valor —flujo, dueño operativo, dueño financiero, línea base y mecanismo de captura—, seis semanas de prueba con comparación, y el último mes para conciliar con Finanzas, separar las cuatro cuentas y decidir.
Ficha ejecutiva · nueve preguntas
Tu ficha está lista cuando puedes responder las nueve. Márcalas mientras las revisas; nada se guarda.
La curva J y los dos presupuestos
El mejor contraargumento a una disciplina estricta de ROI hay que decirlo en voz alta: si le exiges caja positiva a todo experimento temprano, matas el aprendizaje que iba a construir tu ventaja.
La curva J refuerza la objeción. Una tecnología nueva puede bajar el desempeño un tiempo porque aprender, limpiar datos y rediseñar procesos consume recursos antes de liberar valor, y castigar esa fase como fracaso confunde inversión complementaria con ineficiencia permanente.
La salida no es dejar de medir: es separar dos contratos de inversión.
| Presupuesto de descubrimiento | Presupuesto de escala |
|---|---|
| Compra aprendizaje y opción | Compra un resultado económico repetible |
| Hipótesis y gasto acotados | Línea base, comparación válida y costo total |
| Hitos de conocimiento | Umbrales de resultado y de riesgo |
| Puede aceptar VPN negativo | Exige mecanismo de captura creíble |
| Termina cuando aprende o invalida | Se renueva cuando el efecto se sostiene |
El descubrimiento no debe fingir un ROI que no existe: debe mostrar qué incertidumbre redujo —capacidad real, calidad, adopción, costo, riesgo o posibilidad de reutilizar—. Y la escala no debe esconderse detrás del aprendizaje indefinido: debe demostrar repetibilidad y captura.
Y hay una forma de sobrevivir a la parte baja de la curva sin pedirle fe a nadie: buscar victorias tempranas a propósito. No un caso grande que lo demuestre todo, sino uno pequeño, acotado y medible que produzca valor real mientras el resto todavía aprende. Sirve para dos cosas a la vez: da evidencia concreta de que el mecanismo funciona, y compra el tiempo que la curva J necesita.
Eso cambia cómo priorizas. En esta fase, un caso pequeño con captura clara y rápida vale más que uno grande con captura difusa a dieciocho meses. No porque sea más importante, sino porque es el único que puede demostrar algo mientras los demás maduran. Búscalo con intención: de tus candidatos, cuál tiene el resultado más medible, el dueño más claro y el ciclo más corto. Ese va primero, aunque no sea el más ambicioso.
Así evitas dos errores simétricos: optimizar tan temprano que desaparece la exploración, o llamar «estratégico» a todo proyecto que no logra explicar su valor.
Tu organización es parte del sistema
En una encuesta de McKinsey de 2026, los líderes de organizaciones que rediseñaron flujos fueron 5,3 veces más propensos a reportar captura de valor que quienes dejaron el trabajo intacto: 32 % frente a 6 %. Antes de usar ese dato conviene decir qué es: una asociación autorreportada sobre 750 empleados de habla inglesa, encuestados entre febrero y abril de 2026. No demuestra que el rediseño cause el retorno; podría ser al revés, que las empresas que ya capturan valor sean las que se animan a rediseñar. Sí es coherente con la teoría y con la curva J: la herramienta aislada rara vez cambia el sistema.
Un documento de trabajo del National Bureau of Economic Research (NBER) encuestó a casi 6.000 ejecutivos en Estados Unidos, Reino Unido, Alemania y Australia: aunque 69 % de las empresas usaba IA, 89 % no reportó ningún impacto en productividad laboral en los tres años anteriores, y aun así esperaban un aumento promedio de 1,4 % en los tres siguientes. No es causal ni pasó revisión por pares, pero retrata la brecha entre lo que ya ocurrió y lo que se sigue esperando.
Esa brecha casi siempre esconde tres decisiones sin resolver: quién es dueño del resultado —Tecnología, el área operativa o Finanzas—, quién revisa las excepciones y con qué capacidad real, y qué vas a hacer con el tiempo liberado, decidido antes de liberarlo.
Y hay una versión de este mismo error un nivel más arriba. En empresas grandes, el indicador que llega al reporte trimestral suele ser cuántos casos de uso hay en producción. Cuarenta y siete suena mejor que nueve. Pero cuarenta y siete casos sin priorizar son, casi siempre, cuarenta y siete integraciones que mantener, cuarenta y siete colas de revisión y ningún flujo cambiado de verdad. El número de casos es la métrica de vanidad de la cartera, igual que los tokens lo son del proyecto.
Lo que escasea no son los casos: es el trabajo de mirarlos juntos. Cuáles comparten datos, permisos o evaluación. Cuáles se estorban entre sí. Cuáles tocan el mismo flujo desde dos áreas que no se hablan. De ese cruce salen tres decisiones que un conteo nunca da: qué casos combinar en uno solo, cuáles matar temprano, y cuál merece que le construyas la plataforma compartida. Una cartera de IA se gestiona como una cartera, no como una lista.
La IA predice, el humano juzga, la plataforma habilita, el flujo cambia y la organización aprende. Si el flujo no cambia o la organización no aprende, la secuencia se detiene antes del valor.
Una lectura para América Latina
Mi inferencia para la región —no una estimación causal— es que la cadena suele ser más frágil por tres razones: menos escala para amortizar plataformas, costo de capital más alto y capacidades digitales más desiguales. El fAIr Tech Radar del Banco Interamericano de Desarrollo (BID) reporta una madurez regional de 2,9 sobre 5, con un diagnóstico preciso: avances técnicos reales y rezago en gobernanza e inclusión, con startups que innovan rápido sin estructuras responsables y corporaciones frenadas por rigidez institucional. Ese dato no mide ROI, pero explica por qué copiar un caso de uso global falla localmente aunque la herramienta sea idéntica.
Para muchas empresas de la región, la mejor alternativa no es desplegar cien pilotos. Es construir una base compartida de datos, permisos, evaluación y monitoreo; escoger dos o tres flujos con volumen suficiente; y reutilizar lo aprendido. El activo no es solo el caso que funcionó: es la reducción del costo marginal del siguiente.
También cambia el significado del ahorro. Si tu demanda crece y contratar talento especializado es difícil, la capacidad liberada puede valer más que recortar plantilla. Si tu mercado es pequeño y la demanda no está, esa misma hora no tiene comprador. La economía de tu contexto pesa tanto como la capacidad del modelo.
Dónde la evidencia es floja
La conversación sobre retorno mezcla estudios sólidos con afirmaciones que no soportan el mismo peso. Esta es la contabilidad honesta de lo que acabas de leer.
| Afirmación | Evidencia disponible | Precaución |
|---|---|---|
| La IA mejora tareas de escritura y de soporte | Experimentos y despliegues con comparación | Alta validez interna; transferencia limitada por tarea y organización |
| La IA puede empeorar el trabajo fuera de su frontera | Experimento prerregistrado; ensayo aleatorizado en código abierto | Una sola tarea externa; METR tuvo 16 desarrolladores y herramientas de 2025 |
| Las empresas todavía no capturan productividad amplia | Encuestas a trabajadores y a ejecutivos | Autorreporte sin causalidad; y METR muestra que la percepción puede equivocarse de signo |
| Rediseñar flujos aumenta la probabilidad de capturar valor | Encuesta de consultora, 750 respuestas | Correlación, selección de muestra y posible causalidad inversa |
| La curva J explica el retraso de los beneficios | Teoría económica e historia de tecnologías de propósito general | No demuestra que un proyecto concreto vaya a mejorar después |
| La cadena y el libro mayor mejoran las decisiones | Síntesis e inferencia mía | Marco no validado comparativamente en una cartera empresarial |
Y hay un punto que vale la pena aislar, porque afecta cómo vas a citar la evidencia. El experimento de BCG es la fuente más usada de este debate y también la más maltratada. La versión publicada en Organization Science dice que los usuarios de IA fueron «19 % menos propensos» a acertar fuera de la frontera; buena parte de la divulgación lo convirtió en «19 puntos porcentuales», que es una afirmación bastante más fuerte. Y la mejora de calidad dentro de la frontera aparece como «significativamente mejor», sin porcentaje, aunque circule mucho una cifra de 40 % que viene del documento de trabajo previo. Si lo vas a llevar a un comité, cita la versión publicada.
El mejor ataque contra este marco
Si yo tuviera que desarmar este artículo, no discutiría los estudios. Iría contra la cadena, y por dos frentes.
El primero: una cadena así explica cualquier cosa después de que pasó. ¿Funcionó? Los eslabones aguantaron. ¿No funcionó? Alguno se rompió. Un marco que nunca puede estar equivocado no es un marco: es un relato. Mi defensa es que cada eslabón trae una prueba mínima que se declara antes de desplegar, y que el mecanismo de captura se firma antes de ver el resultado. Eso convierte la cadena en una apuesta y no en una explicación. Pero la concesión es real: casi nadie escribe esas pruebas por adelantado, y una cadena que solo se aplica en la autopsia sí es un relato.
El segundo: exigir evidencia cuesta tiempo, y el tiempo también es dinero. En una tecnología que se mueve rápido, la empresa que pide pruebas antes de escalar puede perder contra la que escala por convicción. Para eso está el presupuesto de descubrimiento: la cadena no se le aplica a la exploración. Pero no sé decirte dónde queda exactamente la frontera entre prudencia y parálisis, y ponerla demasiado alta es una manera perfectamente eficaz de quedarse atrás.
Hay una tercera debilidad, más aburrida y también cierta: cinco eslabones no agotan las fuentes de valor. Reputación, aprendizaje estratégico y velocidad de respuesta competitiva no se monetizan sin algo de arbitrariedad. Separarlas en otra cuenta reduce la inflación; no elimina el juicio.
¿Qué me haría cambiar de opinión? No hace falta esperar el estudio ideal. Bastaría con ver, en una cartera real y auditada, que las empresas que capturaron valor lo hicieron sin haber declarado antes ningún mecanismo de captura. Si eso apareciera de forma repetida, mi cadena estaría pidiendo un trámite y no una prueba. Hoy lo que veo apunta al revés. Y lo escribo sabiendo que «lo que veo» es exactamente el tipo de evidencia que este artículo te pide no aceptar.
Conclusión
The Economist tiene razón: contar tokens es una forma sofisticada de no responder la pregunta económica. Contar horas tampoco basta.
El ROI de la IA no es una propiedad del modelo ni una cifra que emerge del tablero. Es una afirmación causal sobre tu organización: esta intervención cambió este trabajo; ese trabajo movió este resultado; la empresa capturó este efecto; y lo hizo después de pagar sus costos y asumir sus riesgos.
Una cadena débil no pide más entusiasmo. Pide encontrar el eslabón roto.
Y tal vez ahí esté la medida más madura de una empresa frente a la IA: no cuántas respuestas puede producir, sino cuánta evidencia necesita para decidir qué merece escalar, qué debe rediseñar y qué conviene dejar ir.
Preguntas frecuentes
¿Qué es el ROI de la IA?
Es la relación entre los beneficios realizados que se pueden atribuir a una iniciativa de inteligencia artificial y su costo total. Para que signifique algo debe separar caja, capacidad, riesgo y aprendizaje, incluir los costos de integración y revisión, y apoyarse en una comparación creíble contra lo que habría pasado sin la intervención.
¿Los tokens o los usuarios activos sirven para medir valor?
Sirven para medir actividad y diagnosticar adopción. No demuestran productividad, resultado de negocio ni retorno financiero. Son el punto de partida de la cadena, no su final.
¿Cómo se convierte el tiempo ahorrado en dinero?
Cuando cambia un flujo económico verificable: reduce horas extra o contratación externa, evita una contratación prevista, permite atender más demanda, o se reasigna a una salida cuyo valor sí se mide. Multiplicar horas por salario sin comprobar esa captura infla el beneficio, a veces por un factor de siete.
¿Cómo mido el ROI si la IA apenas está en piloto?
Con un presupuesto de descubrimiento: acota el gasto y mide la incertidumbre que redujiste sobre capacidad, calidad, adopción, costo y reutilización. No presentes aprendizaje como caja, y exige el caso financiero completo al pasar a escala.
¿Cuál es el mejor diseño para evaluar una iniciativa?
La asignación aleatoria por casos o equipos da la inferencia más fuerte. Si no es viable, un despliegue escalonado, un grupo comparable o una serie temporal interrumpida. Cualquiera necesita línea base y barreras de calidad y riesgo.
¿Cuándo debería detenerse un proyecto de IA?
Cuando la mejora no persiste, no alcanza el flujo completo, traslada más costo a revisión, no tiene mecanismo de captura, o el aprendizaje que queda no justifica el siguiente tramo de inversión.
Fuentes y lecturas
En Philia Sophia
- La IA solo amplifica lo que tu empresa ya es
- Analítica de datos en 5 niveles
- AI‑Native: rediseñar el trabajo
- El prompt no es el problema: 2 mapas
- PULSE: decidir mejor con datos
Artículo de partida
Evidencia científica y económica
- Generative AI at Work — Quarterly Journal of Economics
- Navigating the Jagged Technological Frontier — Organization Science
- Productivity Effects of Generative AI — Science
- The Productivity J‑Curve — NBER
- Firm Data on AI — documento de trabajo NBER
- METR — IA de 2025 y productividad de desarrolladores
Medición, gestión y contexto regional
- FRED Blog — Does generative AI save time at work?
- NIST — AI Risk Management Framework
- McKinsey — From adoption to impact
- BID — fAIr Tech Radar
Nota de transparencia. Este artículo fue investigado y escrito por Javier Forero Ruiz con asistencia de inteligencia artificial para búsqueda, contraste de fuentes, edición bilingüe y verificación técnica. Las tesis, inferencias, selección de evidencia y responsabilidad editorial son mías. La columna de The Economist no fue reproducida: su argumento se trianguló con el enlace original y una síntesis independiente. No se usó IA para inventar testimonios, datos ni resultados.
Artificial intelligence · Value and measurement
AI ROI is not calculated. It is demonstrated
A chain runs between using artificial intelligence and capturing value: task → workflow → outcome → cash. The arithmetic is easy. Proving that every link holds is the hard part, and it is the only thing separating a return from a well-told story.
In this article
The dashboard that applauds and the dashboard that decides
I have a gym app that congratulates me. It tells me how many days I showed up, how many minutes I spent inside, how many sets I did. It is an honest and completely insufficient dashboard: it measures that I went, not that I am better. And even if I were better, the uncomfortable question would remain: did that change anything in my life?
The same confusion shows up when a company sits down to decide whether to continue the AI project. I have rarely seen a committee dedicated to that: the conversation happens wherever it fits—an item in the leadership meeting, or the report the technology team prepares to justify renewing the licenses. And there, two dashboards compete.
One reports activation, queries and token consumption. The other reports resolution time, case reopening, cost per case and—this is the uncomfortable one—what happened to the released hours.
It applauds
It supports a decision
Both dashboards describe the same quarter at the same company.
Return on investment (ROI) compares attributable benefits with the full investment. Anyone can do that arithmetic on a napkin. Proving which benefit was caused by the intervention and captured by the company is another matter.
That is the tension behind «How to measure returns on AI», the Economist column that prompted this analysis: stop maximizing tokens, measure outcomes, watch quality, expect an initial productivity dip, and decide what you will do with the time you release. It is a necessary correction to a conversation that confused access with adoption, and adoption with value.
But swapping a token counter for an hour counter does not solve the economic problem. It starts it.
What The Economist gets right
Two of its four points carry everything that follows.
An input metric does not demonstrate an outcome. Tokens, active users, prompts and deployed agents are telemetry: they tell you whether the system exists and whether anyone uses it. They do not tell you whether the work improved.
Speed without quality destroys value. In a randomized experiment with 758 Boston Consulting Group (BCG) consultants, those using GPT‑4 completed 12.2% more tasks inside the model’s capability frontier and finished them 25.1% faster, with significantly better quality. On a task deliberately placed outside that frontier, however, AI users were 19% less likely to reach the correct answer. Being wrong sooner is not productivity.
The other two—that benefits may follow an initial dip, and that released time needs a destination—deserve sections of their own, and I return to them below.
Where I part ways with the column is architectural, not substantive: «measure outcomes» is still a slogan. Turning it into a management system requires rebuilding the whole causal chain.
Why the numbers seem to fight each other
Does AI raise productivity by 15%, or make developers 19% slower? Does it cut task time by 40%, or leave productivity unchanged at 89% of firms? The figures appear to contradict each other because they answer different questions.
| Finding | What was observed, and how | What it supports | What it does not support |
|---|---|---|---|
| 40% less time and 18% higher quality in professional writing | A bounded task; randomized experiment | Causal effect on those tasks | Impact on a process or on the income statement |
| 15% more cases resolved per hour in support | An agent in a live workflow; staggered rollout, 5,172 agents | Operational effect in one company | That it applies to every occupation, or financial return |
| Gains inside the frontier, losses outside it | Knowledge task; preregistered experiment, 758 consultants | That the effect changes sign depending on the task | That all consulting improves equally |
| 19% more time with AI | Real open-source work; randomized experiment, 16 developers | Effect in mature repositories with 2025 tools | That AI slows software development in general |
| 2.2% of work hours «saved» | One worker; representative survey, self-report | Aggregate perception of released time | Causality, quality or financial capture |
| 89% report no productivity impact | One firm; working paper, ~6,000 executives | The gap between usage and perceived effect | That AI does not work: it is self-report, not peer reviewed |
There are at least four observed levels—task, person, workflow and firm—and a gain can be real at the first and evaporate before the fourth. A writer finishes a report 40% sooner, but the document waits three days for the committee’s signature. An agent answers faster, but reopened cases rise. A developer generates more code and shifts work into review and maintenance. A company activates seats, but demand does not grow and neither does headcount.
It is the line at the bank: you can hire the fastest teller in the world, but if there is still only one manager to sign, the line does not disappear. It moves to another desk.
That leak does not invalidate the local improvement. It invalidates the automatic jump from better task = better firm.
And there is a detail from the METR experiment that you should remember every time someone shows you a productivity survey. METR—Model Evaluation and Threat Research—is an independent institute that evaluates AI models. Those 16 developers took 19% longer with AI, and still believed they had been about 20% faster. Perception got the sign wrong. When the 2.2% of hours saved reported by the Federal Reserve—up from 1.6% in the third quarter of 2024—comes from self-reports, that gap is part of the data.
An ROI can be arithmetically correct and economically false if a single one of its premises fails: that time can be reallocated, that demand exists, that quality is observable, that nobody adjusts behavior to the metric, that the effect persists.
The AI value evidence chain
In the five levels of analytics (in Spanish) I argued that describing, diagnosing, predicting and prescribing are different inferences, and that confusing them is the most common way to fool yourself with data. The chain I propose is that same idea applied to money: five links, five kinds of claim, and the rule that the strength of the case comes not from its flashiest number but from its weakest connection.
Tap a link to see what it measures, what has to be proven, and where the value leaks.
0 · Activity is it used?
- Metrics
- Active users, frequency, task types, suggestion acceptance, consumption.
- Minimum proof
- None: it is a diagnostic. Useful for adoption and for detecting access failures.
- It leaks when
- Someone presents it as return. It proves neither productivity nor cash.
1 · Task capability does the work come out better?
- Metrics
- Task time, accuracy, quality, variability, performance by experience level.
- Minimum proof
- Comparison against a baseline —the minimal, well-executed version without the intervention— and, where possible, random assignment.
- It leaks when
- The average hides that AI helps newcomers and hinders experts.
2 · Workflow did the real system change?
- Metrics
- End-to-end cycle time, queues, rework, escalations, review load, exceptions.
- Minimum proof
- Look at the whole process, not the stage that improved.
- It leaks when
- One stage gains ten minutes and the next loses twelve.
3 · Business outcome did something that matters move?
- Metrics
- Conversion, retention, first-contact resolution, incidents, launch time, material errors.
- Minimum proof
- Show that the outcome changed because of the intervention and not because of seasonality, case mix, incentives or demand.
- It leaks when
- The change coincides with a campaign, a seasonal peak or a different customer mix.
4 · Economic capture who turned it into value?
- Metrics
- Incremental margin, spend actually avoided, capacity absorbed by demand, expected loss reduced, cash.
- Minimum proof
- A business owner and Finance agree on the capture mechanism before deployment.
- It leaks when
- Nobody signed off on what the company would do if the metric improved. “Faster” does not turn itself into cash.
Risk and learning run alongside the entire chain: a system can create value today and add technical debt or fragility tomorrow, and it can produce no cash yet while building a reusable capability that will pay off later.
The question is not: «what is the ROI of our AI?»
The question is: «at which link do we have evidence, where does causality break, and how are we going to capture the effect?»
This extends another idea from the blog: AI-native is not having more AI, it is learning to redesign work (in Spanish). Return does not live inside the model. It lives in the system around it: people, rules, data, platform and decisions.
An hour saved is not an hour monetized
«We saved 20,000 hours» sounds financial because hours have a salary attached. But multiplying hours by labor cost produces a theoretical capacity value, not a realized benefit.
| Destination of the released hour | Prudent classification |
|---|---|
| It dissolved into meetings, waiting or extra slack | Experience benefit; financial value unproven |
| It reduced overtime or external contracting | Realized savings: less cash left the business |
| It let the same team serve more demand | Capacity value; monetized only if demand exists |
| It avoided a hire already in the plan | Avoided cost: a verifiable budget decision changed |
| It moved into sales, analysis or innovation | Attributable only if you measure that additional output |
| It improved rest and reduced strain | Real benefit—less attrition and error—but it needs its own chain |
Two traps recur. The first is counting availability as savings: if nobody reduces spend or produces more, the labor cost is still there in full. The second is counting the same hour twice, valuing it as released time and also adding the avoided hire or the revenue that capacity generated. There is one underlying benefit; the ways it shows up in the accounts do not stack.
An example to run the numbers
Assume—this is illustrative, not a real case—that a company reports 20,000 released hours and assigns them a loaded cost of $75 per hour. The headline «benefit» would be $1.5 million.
Following the chain, it discovers that only 25% of that capacity moved into work with measurable output: $375,000. It also canceled $275,000 in external contracting. And total cost of ownership was $500,000.
Realized benefit is $650,000; net benefit, $150,000; simple ROI, 30%. Not 200%, which is what you get from treating every hour as cash. And if the reassigned hours and the canceled contracting refer to the same work, even that 30% is inflated by double counting.
Mirage calculator
Change the assumptions and watch how far the number moves. The starting values are the ones from the example. Nothing leaves your browser.
The sliders need JavaScript. This view shows the article’s example with its correct figures, but it does not react: snippet B is missing.
Turn this on if you cannot prove they are separate benefits: only the larger of the two then counts.
Illustrative example in US dollars. Not an observed business case.
The arithmetic was never the hard part. Demonstrating the capture mechanism is.
The ledger: cash, capacity, risk and learning
A single ROI figure mixes effects with different liquidity, uncertainty and horizon. It is like adding, on one line, the cash in the register, the inventory you have not sold, and the goodwill of the business: all three are worth something, but you do not collect them the same way. So I propose an AI value ledger with four separate accounts.
1 · Cash. Incremental revenue, contribution margin, eliminated spend, reduced external contracting. It is the easiest account to audit and the only one your CFO will defend without blinking.
2 · Capacity. Released hours, additional volume made possible, shorter queues, avoided hiring. It is potential value until demand or a budget decision captures it.
3 · Quality and risk. Errors, rework, incidents, expected loss, compliance, privacy, customer trust. It can be an asset or a liability. In its generative AI profile of the risk management framework, the US National Institute of Standards and Technology (NIST) recommends measuring risks and impacts across the whole lifecycle and not only before deployment.
4 · Learning and option value. Reusable evaluation data, shared components, internal capabilities and knowledge about where AI fails. It has strategic value, but do not inflate it as if it were safe cash.
This separation is what gives PULSE (in Spanish) its instruments: if the organization is going to sense its own signals before deciding, it needs the signal not to lie. Four accounts lie less than one number.
The cost almost nobody puts in the denominator
Ask what new work AI created: reviewing, verifying, documenting, correcting, escalating exceptions, maintaining integrations. Generative output grows faster than the expert capacity to review it, and I called that gap review debt (in Spanish).
It is the most underestimated line in any AI business case, for a structural reason: human review is not a step in the process; it is a budget of expert attention, and that budget is inelastic. You can double draft output in a week; you cannot double the number of people with the judgment to approve it.
Nor does every output need the same control. The proportionality matrix in that same article sets the consequence of error—reversible or irreversible—against case volume: light verification, sampling with alerts, full review, or redesign before scaling. Putting everything under full review kills ROI. Putting nothing there mortgages it.
First-order and second-order risk
First-order risk occurs inside the use case: a wrong answer, data leakage, bias, non-compliance, inference cost above plan. It almost always has an operational metric and an identifiable owner.
Second-order risk appears because the system changes organizational behavior: vendor dependence, gradual loss of expert judgment, homogenization of ideas, or the bottleneck moving to a team nobody is watching. It takes longer, it does not fit on the project dashboard, and it does change portfolio return. A project can beat its productivity target and fail on a second-order risk nobody owned, so keep a separate register of exposure, owner, horizon and leading indicator.
The denominator also demands discipline: total cost of ownership includes integration, data preparation, testing, human evaluation, security, compliance, training, change management, monitoring, maintenance and technical debt. And for a scale investment it is worth discounting the flows: NPV = − initial investment + discounted sum of (incremental margin + avoided cost + expected loss avoided − operating cost − residual expected loss), where net present value (NPV) brings future money into today’s terms at a rate reflecting time and risk. In an early test that precision is false; in a large investment, omitting it is false too.
How to measure without fooling yourself
Measuring well does not mean turning every pilot into an academic trial. It means using the best feasible design for the risk of the decision in front of you.
1 · Define the unit of value. Not «the seat.» The case, the decision, the customer, the file, the ticket or the process receiving the intervention.
2 · Record a segmented baseline. A global average can hide a lot: in the support study with 5,172 agents, the lowest-performing quintile improved cases per hour by roughly 36%, while the most experienced agents barely gained speed and lost some quality. Same rollout, two opposite stories.
3 · Build the comparison. You need to know what would have happened without AI—economists call it a counterfactual, but the question is as simple as it sounds. From stronger to weaker: random assignment by case or team; staggered rollout, where comparable groups receive the tool at different times; matched comparison group; interrupted time series; and simple before/after only when there is nothing better.
4 · Measure speed and quality together. Every productivity metric needs a guardrail: accuracy, reopening, satisfaction, material error, incident or review load. If the system optimizes the visible number, the cost moves to where nobody is looking.
5 · Add every incremental cost, including review debt.
6 · State the capture mechanism. Before the test, complete this sentence: «if metric X improves by Y, the company will do Z.» Z can be reducing external contracting, absorbing a queue, redesigning roles or lowering a risk provision. If you cannot complete it, you do not have a business case: you have an intention.
7 · Set a decision rule. A target is not enough; set a boundary too. Scale if the effect clears the threshold with stable quality. Redesign if the task improves but the workflow does not. Stop if review cost or risk eats the benefit.
Those seven steps fit in a quarter: an opening two weeks for the value contract—workflow, operating owner, financial owner, baseline and capture mechanism—then six weeks of comparative testing, and a final month to reconcile with Finance, separate the four accounts and decide.
Executive brief · nine questions
Your brief is ready when you can answer all nine. Tick them as you review; nothing is saved.
The J-curve and two budgets
The best counterargument to strict ROI discipline is serious and has to be said out loud: if you demand positive cash from every early experiment, you kill the learning that was going to build your advantage.
The J-curve reinforces that objection. A new technology can lower performance for a while because learning, cleaning data and redesigning processes consume resources before releasing value. Punishing that phase as failure confuses complementary investment with permanent inefficiency.
The answer is not to stop measuring. It is to separate two investment contracts.
| Discovery budget | Scale budget |
|---|---|
| Buys learning and option value | Buys a repeatable economic outcome |
| Bounded hypothesis and spend | Baseline, valid comparison and total cost |
| Knowledge milestones | Outcome and risk thresholds |
| May accept negative NPV | Requires a credible capture mechanism |
| Ends when it learns or invalidates | Renews when the effect persists |
Discovery should not fake an ROI that does not exist: it should show which uncertainty it reduced—real capability, quality, adoption, cost, risk or reuse. And scale should not hide behind indefinite learning: it has to demonstrate repeatability and capture.
And there is a way to survive the bottom of the curve without asking anyone to take it on faith: deliberately look for early wins. Not one big case that proves everything, but a small, bounded, measurable one that produces real value while the rest is still learning. It does two things at once: it gives concrete evidence that the mechanism works, and it buys the time the J-curve needs.
That changes how you prioritize. At this stage, a small case with clear, fast capture is worth more than a big one with diffuse capture eighteen months out. Not because it matters more, but because it is the only one that can demonstrate anything while the others mature. Look for it on purpose: among your candidates, which has the most measurable outcome, the clearest owner and the shortest cycle? That one goes first, even if it is not the most ambitious.
That is how you avoid two symmetrical errors: optimizing so early that exploration disappears, or calling «strategic» every project that cannot explain its value.
Your organization is part of the system
In a 2026 McKinsey survey, leaders at organizations that redesigned workflows were 5.3 times more likely to report value capture than those that left the work untouched: 32% versus 6%. Before using that figure it is worth saying what it is: a self-reported association across 750 English-speaking employees surveyed between February and April 2026. It does not prove that redesign causes the return; it could run the other way, with companies already capturing value being the ones willing to redesign. It is consistent with theory and with the J-curve: an isolated tool rarely changes the system.
A National Bureau of Economic Research (NBER) working paper surveyed nearly 6,000 executives in the United States, the United Kingdom, Germany and Australia. Although 69% of firms used AI, 89% reported no labor-productivity impact over the previous three years. And they still expected an average 1.4% increase over the next three. It is neither causal nor peer reviewed, but it captures the gap between what has already happened and what is still expected.
That gap almost always hides three unresolved decisions: who owns the outcome—Technology, Operations or Finance; who reviews exceptions, and with what real capacity; and what you will do with the released time, decided before releasing it.
And there is a version of this same error one level up. At large companies, the number that reaches the quarterly report is usually how many use cases are in production. Forty-seven sounds better than nine. But forty-seven unprioritized cases are, almost always, forty-seven integrations to maintain, forty-seven review queues and no workflow actually changed. The count of use cases is the portfolio’s vanity metric, exactly as tokens are the project’s.
Cases are not what is scarce: the work of looking at them together is. Which ones share data, permissions or evaluation. Which ones get in each other’s way. Which ones touch the same workflow from two areas that do not talk to each other. That comparison yields three decisions a count never gives you: which cases to merge into one, which to kill early, and which one deserves the shared platform. An AI portfolio is managed as a portfolio, not as a list.
AI predicts, the human judges, the platform enables, the workflow changes and the organization learns. If the workflow does not change or the organization does not learn, the sequence stops before value.
A Latin American reading
My inference for the region—not a causal estimate—is that the chain tends to be more fragile for three reasons: less scale over which to amortize platforms, higher cost of capital, and more uneven digital capabilities. The Inter-American Development Bank (IDB) fAIr Tech Radar reports average regional maturity of 2.9 out of 5, and its diagnosis is precise: real technical progress, and lag in governance and inclusion. Startups innovate fast without responsible structures, small and medium firms seek balance, and corporations are constrained by institutional rigidity. That figure does not measure ROI, but it helps explain why copying a global use case fails locally even when the tool is identical.
For many firms in the region, the better alternative is not deploying a hundred pilots. It is building a shared foundation of data, permissions, evaluation and monitoring; choosing two or three workflows with enough volume; and reusing what was learned. The asset is not only the use case that worked: it is the lower marginal cost of the next one.
The meaning of savings changes too. If your demand is growing and hiring specialized talent is hard, released capacity may be worth more than cutting headcount. If your market is small and demand is absent, that same hour has no buyer. The economics of your context weigh as much as the model’s capability.
Where the evidence is weak
The return conversation mixes solid studies with claims that cannot carry the same weight. This is the honest accounting of what you just read.
| Claim | Available evidence | Caution |
|---|---|---|
| AI improves writing and support tasks | Experiments and deployments with comparison | High internal validity; limited transfer across task and organization |
| AI can degrade work outside its frontier | Preregistered experiment; open-source randomized trial | A single outside task; METR had 16 developers and 2025 tools |
| Firms have not captured broad productivity yet | Worker and executive surveys | Self-report without causality; and METR shows perception can get the sign wrong |
| Redesigning workflows raises the odds of capturing value | Consulting survey, 750 responses | Correlation, sample selection and possible reverse causality |
| The J-curve explains delayed benefits | Economic theory and the history of general-purpose technologies | It does not prove that a specific project will improve later |
| The chain and the ledger improve decisions | My own synthesis and inference | Framework not comparatively validated across an enterprise portfolio |
And one point is worth singling out, because it affects how you cite the evidence. The BCG experiment is the most cited source in this debate and also the most mishandled. The version published in Organization Science says AI users were «19% less likely» to be correct outside the frontier; much of the popular coverage turned that into «19 percentage points,» which is a considerably stronger claim. And the quality improvement inside the frontier appears as «significantly improved,» with no percentage, even though a 40% figure from the earlier working paper circulates widely. If you are taking it to a committee, cite the published version.
The best attack on this framework
If I had to take this article apart, I would not argue with the studies. I would go after the chain, on two fronts.
First: a chain like this explains anything after the fact. Did it work? The links held. Did it fail? One of them broke. A framework that can never be wrong is not a framework; it is a story. My defense is that every link comes with a minimum proof declared before deployment, and that the capture mechanism is signed off before anyone sees the result. That turns the chain into a bet rather than an explanation. But the concession is real: almost nobody writes those proofs down in advance, and a chain applied only at the autopsy is indeed a story.
Second: demanding evidence costs time, and time is also money. In a fast-moving technology, the company that asks for proof before scaling can lose to the one that scales on conviction. That is what the discovery budget is for: the chain does not apply to exploration. But I cannot tell you exactly where the border runs between prudence and paralysis, and setting it too high is a perfectly effective way to fall behind.
There is a third weakness, duller and also true: five links do not exhaust the sources of value. Reputation, strategic learning and competitive response speed cannot be monetized without some arbitrariness. Keeping them in a separate account reduces inflation; it does not remove judgment.
What would change my mind? No ideal study is needed. It would be enough to see, in a real audited portfolio, that the companies capturing value did so without ever declaring a capture mechanism in advance. If that showed up repeatedly, my chain would be demanding paperwork, not proof. What I see today points the other way. And I write that knowing that «what I see» is exactly the kind of evidence this article tells you not to accept.
Conclusion
The Economist is right: counting tokens is a sophisticated way of not answering the economic question. Counting hours is not enough either.
AI ROI is not a property of the model or a number that emerges from a dashboard. It is a causal claim about your organization: this intervention changed this work; that work moved this outcome; the company captured this effect; and it did so after paying its costs and carrying its risks.
A weak chain does not need more enthusiasm. It needs the broken link found.
And perhaps that is the most mature measure of a company facing AI: not how many answers it can produce, but how much evidence it requires to decide what deserves scaling, what must be redesigned, and what should be allowed to end.
Frequently asked questions
What is AI ROI?
It is the ratio between the realized benefits attributable to an artificial intelligence initiative and its total cost. To mean anything it must separate cash, capacity, risk and learning, include integration and review costs, and rest on a credible comparison against what would have happened without the intervention.
Do tokens or active users measure value?
They measure activity and help diagnose adoption. They do not demonstrate productivity, business outcomes or financial return. They are the start of the chain, not its end.
How does saved time become money?
When it changes a verifiable economic flow: it reduces overtime or external contracting, avoids a planned hire, lets you serve more demand, or is reassigned to an output whose value is actually measured. If you multiply hours by salary without proving that capture, you inflate the benefit—sometimes by a factor of seven.
How do I measure ROI while AI is still a pilot?
With a discovery budget: bound the spend and measure the uncertainty you reduced about capability, quality, adoption, cost and reuse. Do not present learning as cash, and require the full business case when moving to scale.
What is the best design to evaluate an initiative?
Random assignment by case or team gives the strongest inference. If that is not feasible, a staggered rollout, a comparable group or an interrupted time series. Any of them needs a baseline plus quality and risk guardrails.
When should an AI project stop?
When the improvement does not persist, does not reach the full workflow, shifts more cost into review, has no capture mechanism, or the remaining learning does not justify the next tranche of investment.
Sources and further reading
From Philia Sophia
- AI only amplifies what your company already is (in Spanish)
- Data analytics in 5 levels (in Spanish)
- AI-native: redesigning work (in Spanish)
- The prompt is not the problem: 2 maps (in Spanish)
- PULSE: deciding better with data (in Spanish)
Starting article
Scientific and economic evidence
- Generative AI at Work — Quarterly Journal of Economics
- Navigating the Jagged Technological Frontier — Organization Science
- Productivity Effects of Generative AI — Science
- The Productivity J-Curve — NBER
- Firm Data on AI — NBER working paper
- METR — 2025 AI and developer productivity
Measurement, management and regional context
- FRED Blog — Does generative AI save time at work?
- NIST — AI Risk Management Framework
- McKinsey — From adoption to impact
- IDB — fAIr Tech Radar
Transparency note. This article was researched and written by Javier Forero Ruiz with AI assistance for source discovery, evidence checking, bilingual editing and technical verification. The theses, inferences, evidence selection and editorial responsibility are mine. The Economist column was not reproduced: its argument was triangulated from the original link and an independent summary. AI was not used to invent testimonials, data or results. This English version is a localization of the Spanish original.
Deja una respuesta