La imposibilidad de medir la productividad de la IA

Este es largo, perdona. Ya he escrito antes que suelo escribir cuando intento aclararme. Esta pregunta en concreto lleva tiempo dándome vueltas, y cada vez que creía haberla contestado encontraba otro fallo en la respuesta.

En Flowstate nos preguntan a menudo cómo medir el retorno de la inversión en IA. A veces quieren saber si sus equipos son más productivos. A veces solo necesitan algo creíble que enseñar al consejo cuando pregunta por la factura. Es lógico.

Pero a mí esto me interesa por algo más que por tener una empresa que debe responder a la pregunta. Creo que la IA puede hacer a las personas mucho más capaces, y me gustaría que fuera eso lo que construimos. Que los agentes se coman la mierda repetitiva. Que la gente tenga más tiempo para el trabajo que de verdad quiere hacer, incluidas cosas que antes no podía permitirse intentar.

Buena parte del pensamiento detrás de Flowstate es esa. Pero no puedo dar por hecho que está ocurriendo solo porque me guste la idea.

Estoy leyendo The Humanist Review, y joder, qué buena escritura hay ahí. En serio, ve a echar un vistazo. El ensayo de Daron Acemoglu sobre la IA y el trabajo merece leerse entero, pero esta frase sobre el sector empresarial se me quedó grabada:¹

It will demand more pro-worker tools when it focuses on increasing productivity and innovation, rather than only labor cost-saving.

Es decir, que el sector empresarial pedirá más herramientas a favor de los trabajadores cuando se centre en aumentar la productividad y la innovación, y no solo en ahorrar costes laborales. Creo que tiene razón. Si defiendo la IA solo en términos de los salarios que podría sustituir, no puedo sorprenderme de que la conversación acabe en recortar empleos. Prefiero poder explicar qué puede hacer ahora el equipo que antes no podía. O si quitar un proceso tedioso ha mejorado de verdad el día de trabajo de alguien.

El problema es demostrarlo. Que alguien diga que ahorra una hora al día es interesante, pero sigo queriendo saber qué ha cambiado. ¿Ha hecho más cosas? ¿Por fin ha tenido tiempo de pensar a fondo en algo? Quizá la herramienta le ahorró una hora y a otra persona le dio una hora de revisión.

Así que me puse a buscar una forma de comparar el trabajo que hace una empresa con lo que gasta en hacerlo. A ser posible, algo útil para equipos distintos, tanto si el trabajo lo hacían empleados, autónomos, un proveedor de servicios o agentes. No esperaba que todos los departamentos tuvieran la misma idea del éxito. Sí esperaba que pudiéramos ponernos de acuerdo en parte de la contabilidad.

He acabado con un enfoque que creo que vale la pena probar, más que con una respuesta que le recomendaría a todo el mundo. Bastantes de mis ideas anteriores estaban equivocadas. He dejado los errores útiles, porque explicar por qué fallaron probablemente ayuda más que fingir que llegué a la versión actual con una previsión extraordinaria.

El primer problema es fácil de demostrar: dale a un agente las preguntas de soporte sencillas y las personas que se quedan con las difíciles pueden de pronto parecer peores en su trabajo.

Ayudar al equipo, al parecer, lo empeoró

Imagina un equipo de soporte que atiende 800 casos fáciles y 200 difíciles al mes. Un caso fácil requiere seis minutos de atención humana. Uno difícil, treinta. Todos se resuelven con el mismo nivel de calidad.

Son números inventados.

Antes de la IA, este equipo hipotético necesitaba 180 horas de atención para sus 1000 casos. Son 5,56 casos por hora.

Ahora un agente resuelve 600 de los casos fáciles. A las personas les quedan 200 fáciles y 200 difíciles: 120 horas para 400 casos, o 3,33 por hora.

El panel informa de una caída del 40% en el ritmo del equipo humano. El tiempo medio de atención pasa de 10,8 minutos a 18.

Nadie se ha vuelto más lento. Las personas tienen los casos más duros. Los fáciles antes diluían la media y ahora ya no están.

La empresa sigue teniendo los 1000 casos resueltos y necesita sesenta horas menos de atención humana. Volveré a lo que valen esas horas. Por ahora, pedirle al equipo que recupere su media de antes sería una respuesta bastante estúpida a un cambio que hicimos a propósito.

Pasa los casos fáciles a un agente

i

Fáciles, personasDifíciles, personasFáciles, agente

Casos fáciles que resuelve el agente al mes600 de 800

Casos por hora humana

5,56 → 3,33

Horas de atención humana

180 → 120

Entrega reconocida

$7200 → $7200

Coste asignado a la atención

$7200 → $5280

Gasto real, con la nómina sin cambios

$7200 → $7680

Los casos por hora humana bajan un 40 %. Los mismos 1000 casos se siguen resolviendo, y quedan 60 horas de atención libres para otra cosa.

Esto pasaba ya antes de los chatbots. El Remote Encoding Center del servicio postal de EE. UU. se ocupa de las imágenes de direcciones que sus máquinas no logran descifrar. Un relato de 2022 describe cómo las máquinas se quedaban con las imágenes más fáciles y dejaban a las personas las que tardaban más en interpretarse.² El vídeo de Tom Scott desde el centro sigue siendo uno de mis ejemplos favoritos de un sistema automatizado que cambia un proceso de negocio, años antes de que nadie lo llamara IA. Intercom hace la misma observación sobre la carga de casos que queda en manos humanas tras automatizar el soporte.³

También hay buena investigación que usa justo el ritmo que acabo de criticar. En Generative AI at Work, Erik Brynjolfsson, Danielle Li y Lindsey Raymond informan de un aumento medio del 15% en las incidencias resueltas por hora. Su asistente de IA ayudaba a las personas que atendían a los clientes. No se hacía cargo de una cola aparte de casos fáciles. Además examinaron la calidad y la experiencia del trabajo.⁴

No discrepo de contar casos en ese contexto. Discrepo de dar por hecho que siguen siendo comparables después de cambiar qué casos reciben las personas. “Casos por hora” puede ser útil. Pero necesita una descripción de los casos.

Y hasta en mi ejemplo tan limpio, un día con menos preguntas fáciles puede ser un día más exigente. Nada en la tabla nos dice si el trabajo ha mejorado.

¿Qué estamos preguntando en realidad?

¿Entregamos más? ¿Hizo falta menos? ¿El trabajo consiguió algo útil? ¿Tuvieron mejor día las personas que lo hicieron?

Son preguntas distintas. Yo he sido culpable de tratar la “productividad” como si respondiera a las cuatro.

Los recuentos nos hablan del volumen. Los costes, de lo que invertimos. El plazo de entrega, de cuánto esperó alguien. Los ingresos y el margen importan, pero no nos dirán qué pasó dentro de cada equipo. Tampoco lo hará una encuesta que pregunte a la gente si se siente más rápida.

El experimento de METR con desarrolladores a principios de 2025 deja esto último bastante claro, y de forma dolorosa. Desarrolladores con experiencia, trabajando en repositorios de código abierto que conocían, tardaron un 19% más con las herramientas de IA disponibles. Después, seguían calculando que las herramientas los habían hecho un 20% más rápidos.⁵ Es un resultado de esos desarrolladores y esas herramientas, no un veredicto sobre los agentes de programación en 2026. La actualización de METR de febrero de 2026 dice que las herramientas más nuevas probablemente ayudan más, y explica por qué los sesgos de selección hacen difícil estimar esa mejora.⁶

Hay, inevitablemente, una encuesta de McKinsey. En sus resultados de agosto de 2026, el 80% de los encuestados dijo que la IA mejoraba su propia productividad. Solo el 37% le atribuía algún impacto en los beneficios de la empresa.⁷ Una brecha útil para que la encuentre una consultora. Y también son dos preguntas distintas basadas en lo que cada uno declara, así que no podemos restar un porcentaje del otro y declarar robado el beneficio que falta.

El marco SPACE me ayudó a poner un límite a la pregunta. Nicole Forsgren, Margaret-Anne Storey y sus coautores sostienen que la productividad de los desarrolladores no se puede captar con una sola métrica ni una sola dimensión.⁸ Estoy de acuerdo. Una medida de la eficiencia de entrega sigue pudiendo ser útil. Solo tiene que dejar de pretender que describe todo lo demás.

Llamaré a la propuesta un índice estandarizado de entrega. Trata del trabajo entregado y de los recursos que hay detrás. El resultado de negocio y la experiencia de hacer el trabajo necesitan su propia evidencia.

Probé con los números que ya teníamos

Cada uno parecía razonable hasta que le puse un ejemplo incómodo.

Las tablas no son motivo para tirar todas las medidas existentes. Necesitaba partes de varias. Lo que fallaba una y otra vez era suponer que una sola podía hacer todo el trabajo.

Probé los candidatos con once casos inventados, entre ellos un agente que se lleva el trabajo fácil y un equipo que se divide en dos. Mis notas de trabajo tienen los casos, los datos ficticios y los cálculos. Tómalo como el registro de cómo cambió la idea, no como once pruebas de que la versión final funciona en una empresa.

Trabajo no es un ticket

Mi primera definición era agradablemente limpia: contar el trabajo que alguien pidió y alguien aceptó.

Por desgracia, la empresa que había descrito no existía.

En Flowstate, nuestro propio Linear va casi siempre por detrás del trabajo que se hace de verdad. No necesito un estudio histórico de los gestores de incidencias para reconocer ese problema.

Un ingeniero se da cuenta de algo, lo habla, lo arregla y crea un ticket en algún punto del camino. Un cliente abre una conversación en Intercom. Llega una factura. Un abogado da un consejo en una llamada. El ingeniero de guardia investiga porque mantener el servicio en marcha ya es su responsabilidad.

No hacemos legítimo el trabajo por ponerlo detrás de un botón de aprobación. Y quien crea el registro no es necesariamente quien necesitaba el trabajo.

Lo que intento contar es un entregable o servicio de negocio con un propósito, un alcance y una condición de finalización que podamos explicar. Una petición puede establecer esas cosas. También un objetivo acordado, un problema de un cliente o una responsabilidad permanente. Un ingeniero no debería necesitar que otro departamento encargue el arreglo de una vulnerabilidad para que cuente.

Las definiciones variarán según la función. No veo manera de evitarlo.

Estos no son nombres alternativos para filas de una base de datos. Un cambio fusionado puede estar incompleto. Una factura marcada como pagada puede estar mal. Un cliente callado puede estar satisfecho o hasta las narices.

La evidencia está repartida. Un incidente puede dejar una conversación de soporte, una incidencia de ingeniería, tres pull requests y un correo de seguimiento. Contar seis registros no establece seis resultados. La minería de procesos centrada en objetos sirve aquí porque representa eventos conectados con varios objetos de negocio.⁹ Ayuda a unir los registros. No decide qué debería contar el incidente.

Si las empresas compartirán el contexto relevante, y si la IA puede interpretarlo con fiabilidad, son problemas aparte. Los dejo fuera de este post. Para la contabilidad, supón que podemos establecer una descripción suficientemente buena del trabajo y sus costes, mediante revisión humana, automatización o ambas.

Eso sigue dejando una pregunta difícil: dada la evidencia, ¿qué contamos? Que falte evidencia debería dejar el trabajo sin resolver, no declararlo sin valor. Si no, estoy construyendo una medida de quién escribe las notas de cierre más entusiastas.

Los contables ya han pasado por aquí

El ejemplo de soporte necesita una forma de distinguir seis minutos de trabajo de treinta. Esta parte, al menos, no es nueva.

ACCA describe las horas estándar como una forma de combinar productos distintos en una sola medida de producción. Separa cuánto se produjo, cuánta de la capacidad disponible se usó y con qué eficiencia.¹⁰ La ONS usa índices de actividad ponderados por coste para buena parte de la producción de los servicios públicos.¹¹

Tomo prestada esa estructura: contar los resultados por tipo y usar después pesos de referencia estables para sumarlos. Nos da una escala sin exigir que cada servicio interno tenga un precio de venta.

La ONS también sirve de contraste para mi ambición. Alrededor de un tercio de la producción de servicios públicos que cubre su metodología sigue usando la convención de que los insumos son iguales a los resultados, lo que hace constante la productividad en esa parte.¹¹ Que exista la medición ponderada por coste no significa que alguien ya haya resuelto cómo medir todos los servicios.

Volvamos al soporte. A una tarifa laboral de referencia de $40 la hora, una resolución fácil lleva un peso de $4 y una difícil, de $20. Multiplica cada recuento por su peso y suma:

D = 800 × 4 + 200 × 20 = 7200

(1)

Nos salen $7200 antes del agente y $7200 después. El negocio recibió las mismas 800 resoluciones fáciles y 200 difíciles. Que 600 de ellas salgan más baratas no las hace desaparecer del resultado.

Escrito en general, es esto:

D_t = Σ_k n_k,t s_k,b

(2)

D es el resultado entregado en dólares de coste de referencia. n es el recuento de cada tipo y s es su coste de referencia de extremo a extremo. t identifica el periodo que medimos y b el periodo de referencia. La suma recorre los tipos de trabajo.

Esos dólares no son ingresos ni ahorros. Nos permiten comparar cantidades de trabajo distinto usando un único conjunto declarado de pesos.

Al principio intenté justificar el peso argumentando que el coste histórico era un suelo para el valor. ¿Seguro que una empresa no pagaría cuatro horas por un trabajo que vale menos de cuatro horas?

Una valoración extremadamente generosa de cómo decide una empresa. Las empresas compran cosas que no deberían, y las inversiones sensatas pueden fallar. El coste antiguo nos dice algo sobre la producción. No demuestra lo que valía el resultado.

Para un negocio real, el estándar cubriría la mezcla relevante de personas, herramientas, agentes y servicios comprados. Donde tenemos estimaciones de esfuerzo creíbles por rol, las tarifas de referencia fijas impiden que el mismo trabajo reciba un peso mayor porque lo hizo una persona más cara. Un servicio comprado puede necesitar, en cambio, un precio de referencia comparable.

Los sueldos y las facturas reales van al lado del coste. El mismo entregable con el mismo alcance debería tener el mismo peso de resultado en Londres y en Lisboa. Cambiar de proveedor tampoco debería cambiarlo.

Las horas estándar pueden servir donde tengan sentido. Pero un índice que cubra trabajo automatizado necesita algo más que las horas humanas que quedan, o sus pesos pueden tender a cero cuanto mejor funcione la automatización. Los costes de recursos de referencia nos dan una base más amplia.

Y el periodo de referencia no tiene por qué ser anterior a la IA. Necesita evidencia utilizable. “Antes de que nadie usara ChatGPT” no seguirá siendo una fecha útil para siempre.

¿Esto no son puntos de historia en dólares?

Podría serlo. Primero, una corrección por la que he visto enfadarse, con razón, a muchos ingenieros: los puntos de historia no son horas. Se pensaron para dimensionar el trabajo en relación con otro trabajo, por complejidad e incertidumbre, y por eso tantos equipos usan una escala tipo Fibonacci. Los saltos se agrandan según baja la confianza. Convertir puntos en horas nunca fue la idea.

El riesgo aquí es otro. Coger las estimaciones del equipo, convertirlas en dólares y llamar objetivo al resultado sería la misma conjetura con mejor imagen financiera.

La disculpa de Ron Jeffries por haber inventado posiblemente los puntos de historia tiene gracia, pero no responde a esta objeción.¹² Gergely Orosz describe a un desarrollador que inflaba las estimaciones en cuanto el equipo empezó a tratar sus puntos de sprint como una prueba de éxito.¹³ Un sistema de coste de referencia ofrece la misma tentación. Ponle un peso mayor al trabajo y la puntuación mejora.

Lo que quiero es un estándar para una clase de trabajo entregado, no una estimación continua de lo difícil que parece este intento concreto. Una estimación de planificación puede subir cuando encontramos un problema. El peso del resultado no debería subir solo porque tardamos más. Si el alcance cambió, tenemos que decir qué cambió.

Yo construiría el estándar a partir de ejemplos revisados de trabajo comparable y lo probaría con otros ejemplos. Fijaría los pesos para la comparación. Registraría los cambios para que ni el equipo ni su responsable puedan mejorar un resultado informado agrandándolos después.

Sigue habiendo criterio en eso. ¿Qué trabajos van juntos? ¿El caso caro es otro tipo de trabajo o un intento caro de lo mismo? Un revisor tiene que poder cuestionar tanto la categoría como el peso.

Incluso elegir el promedio importa. La mediana describe un caso típico. Multiplícala por el volumen y, en una carga de trabajo con cola larga, no reproducirá en general el uso total de recursos. Para un peso de coste de recursos esperado, normalmente empezaría con una media de una clase bien definida y mostraría la dispersión. No elegiría el estadístico que hiciera el índice más bonito.

La IA podría ayudar a sugerir pesos. El trabajo de Anthropic para estimar la duración de tareas encontró información útil para ordenarlas, pero Claude sobrestimaba las tareas de software cortas y subestimaba las largas.¹⁴ Ordenar los trabajos más o menos bien no basta cuando sus pesos relativos determinan el resultado.

Un sistema de puntos podría adoptar controles parecidos. No me toca cantar victoria por cambiar el nombre. La prueba es si otro equipo puede aplicar las definiciones y si un desacuerdo razonable cambia la conclusión.

Si eso no se sostiene, entonces sí, he reinventado los puntos de historia en dólares.

¿Lo terminamos o dejamos de hablar de ello?

Fin nos da un ejemplo concreto útil. Intercom cuenta las resoluciones confirmadas y las supuestas, es decir, cuando el cliente se va tras una respuesta sin pedir más ayuda. Su documentación también dice que el cargo se revierte si el cliente vuelve a la misma conversación pidiendo más asistencia.¹⁵

Es una regla de facturación clara. Deja una pregunta sobre los clientes callados, pero es injusto discutirla sin la regla de reversión. Y las conversaciones cerradas por humanos merecen el mismo escrutinio.

Para este índice, especificaría qué cuenta como finalización para cada tipo de trabajo. A veces hay una aceptación explícita. A veces hay una prueba, un registro de pago o evidencia de entrega. A veces solo tenemos señales indirectas y hay que mostrar esa incertidumbre. “Cerrado” no puede resolver todos los casos.

Repetir trabajo tampoco es sencillo. Una conversación reabierta puede ser una respuesta fallida o una pregunta nueva. Revertir código puede arreglar un defecto o reflejar un cambio de decisión de producto. Una disputa posterior no invalida automáticamente el asesoramiento legal que la precedió.

Necesitamos una regla sobre qué correcciones revierten resultados anteriores, cuánto los revierten y cuáles pertenecen a un alcance nuevo. Úsala para personas y agentes por igual. Compara trabajo que ha tenido la misma oportunidad de revelar defectos y revisa el periodo original cuando el crédito anterior ya no se sostiene. Una cola recién cerrada no debería lucir mejor solo porque nadie ha tenido tiempo de quejarse.

Comprobar también consume recursos. Los escenarios de revisar y rehacer de GDPval muestran cuánto puede cambiar la ventaja aparente de coste cuando se incluye la revisión de un experto. Son escenarios modelados, no ahorros observados en empresas, y el artículo señala que no incluye costes equivalentes de revisión y fallo para su referencia humana.¹⁶ Yo querría el flujo de trabajo entero con sus costes en ambos lados.

La planificación dejó al descubierto otro error de mi versión anterior. Sugerí no dar ningún crédito a un ciclo de previsión si los ajustes del planificador lo empeoraban. Eso confundía completar el trabajo con obtener un resultado favorable.

El valor añadido de la previsión sirve para evaluar ajustes sobre observaciones comparables.¹⁷ No es un interruptor universal para saber si la planificación ocurrió. Una previsión sólida puede cumplir su encargo y aun así salir mal. Un buen asesoramiento legal puede frenar un acuerdo. Un experimento puede ser útil precisamente porque nos dice que abandonemos el proyecto.

Si la medida solo reconoce las buenas noticias, se le escapará parte del buen trabajo.

¿Cuarenta borradores de qué?

Ahora dale al índice algo de trabajo de marketing.

Un equipo producía cuatro variantes de anuncio a la semana. Cada una llevaba dos horas, lo que da a cada una un peso de referencia de $80 a nuestra tarifa ilustrativa. El resultado de la semana era $320.

Con IA produce cuarenta. Aplica el peso a cada archivo generado y el resultado pasa a $3200, mientras los resultados de la campaña apenas se mueven.

Al principio lo tomé como prueba de que la medida estaba rota. Puede que lo esté, pero no por el motivo que pensaba. Cuarenta entregables distintos y comparables podrían ser diez veces más producción sin ser diez veces más útiles. Ya había dicho que no estaba midiendo valor, y luego esperaba que el número lo midiera igualmente.

La otra pregunta es si esos cuarenta archivos eran cuarenta entregables. Podrían ser borradores para elegir qué entra en un único experimento.

Para este ejemplo, supón que el servicio es un experimento de campaña para una audiencia concreta, con una pregunta de prueba definida y requisitos de informe. Yo contaría ese experimento. Generar cuatro borradores o cuarenta no cambia la unidad. Su producción y su selección forman parte de su coste.

Si el equipo lanza otro experimento realmente distinto y de alcance comparable, eso sí es más resultado. Llamar diez experimentos a diez variaciones de la misma prueba no lo es. Necesitaríamos la definición antes de ver el resultado, no una explicación ingeniosa después.

En otro flujo de trabajo, producir variantes listas para usar podría ser el servicio en sí. Entonces las variantes individuales pueden ser la unidad correcta. Es otro límite de medición, y no cambiaría de uno a otro según cuál diera el número más grande.

Tom Cunningham y Parker Whitfill, de METR, ayudaron a aclarar por qué la pregunta del valor sigue siendo aparte. Distinguen el efecto de la IA sobre la mezcla de tareas antigua, sobre la mezcla nueva y sobre el valor producido. Abaratar algo cambia lo que la gente decide intentar, además de la rapidez con que termina la carga de trabajo de ayer.¹⁸

Estoy de acuerdo en separar esas preguntas. Un recuento de producción no se convierte en una medida de valor porque el trabajo fuera caro antes. Y la aprobación de un jefe tampoco hace que cuarenta variantes sean cuarenta veces más útiles que una.

¿Qué pasa cuando desaparece un paso?

El software rompe el recuento en sentido contrario.

Supón que una funcionalidad antes necesitaba tres horas de especificación, diez de implementación y dos de revisión. A $40 la hora, el coste de referencia es $600.

Ahora un agente puede construir la misma funcionalidad a partir del contexto que ya hay. El uso cuesta $25. La revisión humana lleva tres horas, que representan $120 de esfuerzo a nuestra tarifa. Los recursos modelados usados suman $145. Supón que la funcionalidad cumple los mismos requisitos y las mismas comprobaciones de calidad.

Si cuento los pasos del proceso antiguo, pierdo la especificación. La implementación y la revisión que sobreviven tienen pesos antiguos que suman $480. Pero el negocio recibió la funcionalidad entera.

Contar pasos pierde el 20% del resultado porque un documento pasó a ser innecesario. Contar la funcionalidad completa mantiene intacta la comparación.

Esto solo funciona si el paso de verdad era innecesario. Quitar una comprobación de seguridad o eliminar un requisito cambiaría lo que se entregó. La misma funcionalidad, con el mismo estándar, es la que hace el trabajo importante en esa frase.

Lo mismo vale para “la funcionalidad completa”. No puede significar lo que se llame petición. Si partes una funcionalidad en tres tickets, no debería recibir tres pesos de funcionalidad. Si juntas tres funcionalidades genuinas en una épica, dos no deberían desaparecer.

Luego están los padres y los hijos. Si la funcionalidad de extremo a extremo ya incluye diseño y revisión, no puedo sumar el peso de la funcionalidad al mismo trabajo contado otra vez por esos equipos. Podemos atribuir contribuciones dentro del total. No podemos crear resultado extra de la empresa moviéndolo entre departamentos.

Prueba a reorganizar el mismo trabajo sin cambiar lo que se entrega. El total de la empresa debería quedarse quieto. Prueba a externalizar una parte. Misma prueba.

Los proyectos largos también necesitan cuidado con el tiempo. Yo usaría comparaciones acumuladas o hitos útiles por sí mismos cuyos pesos sumen el alcance acordado. Si no, meses de coste desembocan en un único pico enorme de finalización, y un panel mensual se pasa la mayor parte del año engañando.

Vale. ¿Qué cuenta como la misma funcionalidad?

Con esa funcionalidad de quince horas he sido bastante generoso conmigo mismo. Una corrección ortográfica y un sistema de facturación pueden llamarse ambos funcionalidad. Meterlos en una misma categoría nos devolvería de golpe al problema del soporte.

Elijamos algo más concreto: una exportación CSV del historial de auditoría de un cliente. Un administrador de cuenta autorizado necesita exportar ocho campos concretos para un rango de fechas elegido. El encargo define los límites de volumen y de tiempo de respuesta, los requisitos de exactitud y los controles de acceso. Tiene que funcionar en el producto en vivo.

Yo contaría una capacidad de exportación entregada de ese alcance. No el botón, el endpoint, las pruebas y la documentación por separado. Tampoco la contaría cada vez que alguien descargara el archivo. Aquí medimos la entrega de un cambio, no el funcionamiento del producto después.

En esta empresa ficticia, supón que encontramos cinco cambios anteriores de exportación de informes con un alcance de datos, un comportamiento de usuario, unos límites de operación y unos requisitos de garantía comparables. Con la misma base de precios de referencia, sus costes de extremo a extremo fueron $480, $560, $600, $640 y $720. La media es $600.

Así podríamos construir el peso. Cinco números convenientes no demuestran que sea bueno. El revisor tiene que comprobar qué hacía comparables a esos trabajos, en lugar de buscar sin más la palabra “export”. Después probaríamos la clase y su peso con otro trabajo.

Ahora tenemos una definición con la que discutir:

Fíjate en que la clase no depende de la implementación elegida, del número de pull requests ni del sueldo del ingeniero. Eso puede afectar al coste sin cambiar lo que recibió el negocio.

El flujo de eventos es distinto. Cambia el comportamiento exigido. Necesitaríamos una clase de referencia adecuada u otro tratamiento explícito para ese alcance, aplicado de forma coherente al trabajo anterior y posterior. No podemos inventarnos una categoría de “exportación muy compleja” después de una construcción cara y concederle más resultado.

¿Y una plataforma de informes nueva sin precedentes creíbles? No la forzaría a entrar en esta clase. Describiría su alcance, sus costes y sus hitos útiles, y la dejaría fuera de esta serie comparable hasta tener una base para incluirla.

Su coste debe seguir siendo visible. El informe tiene que conciliar el servicio medido con el trabajo sin emparejar y el resto del gasto. Si no, estaría escogiendo los éxitos fáciles de clasificar y dejando toda la inversión incómoda en otro sitio.

Esta es la parte más difícil de la propuesta. Otro revisor podría rechazar la clase de exportación o su peso de $600. Al menos podemos localizar el desacuerdo y ver si otra elección razonable cambia la respuesta.

Algo del trabajo de ingeniería puede admitir clases como esta. Algo no. Averiguarlo sería un resultado útil, aunque arruine mi esperanza de un total para toda la empresa.

Las sesenta horas no han salido de la nómina

Volvamos al soporte y al ahorro que me tentaba informar.

Al principio, 180 horas de atención a $40 daban $7200. Después, 120 horas dan $4800. Si sumas un cargo ilustrativo del agente de $0,80 por cada una de sus 600 resoluciones, el coste de atención asignado es $5280.

Son $1920 menos. Salvo que las personas siguen empleadas en las mismas condiciones.

Supón que la nómina en este ejemplo simplificado sigue en $7200. Suma la factura del agente de $480 y la empresa gasta $7680. La necesidad de atención bajó. La factura subió.

Robert Kaplan y Steven Anderson hacen esta distinción en su trabajo sobre el costeo basado en actividades con tiempo como motor: la capacidad sin usar ofrece oportunidades de ahorro o de crecimiento.¹⁹ Estoy de acuerdo, y eso cambia la regla aquí. Las horas liberadas van a una línea de capacidad. Los ahorros necesitan evidencia de gasto reducido o una explicación creíble del gasto evitado.

Las sesenta horas podrían permitir atender a más clientes sin otra contratación. Podrían reducir las horas extra, absorber los picos o hacer el trabajo menos frenético. También podrían quedar sin usar. No quiero que la contabilidad elija un resultado antes de que la empresa haya hecho algo con ese tiempo.

Para el índice principal de eficiencia de costes, usaría el coste de suministrar el servicio medido, incluido el trabajo fallido y la capacidad sin usar. Compara el crecimiento de la entrega con el crecimiento del coste:

E_t = 100 × D_t / D_bC_t / C_b

(3)

D es el total de la entrega. C es el coste dentro del mismo límite de informe. E empieza en 100, de modo que 100 significa que la eficiencia de costes no ha cambiado.

En el ejemplo de soporte, la entrega se queda en $7200 mientras el gasto sube de $7200 a $7680. El índice es 93,8: la eficiencia de costes cayó un 6,25% ese mes.

Con el modelo aparte de atención asignada, la razón es 136,4. Es la mejora en los recursos que necesita el flujo de trabajo, no una ganancia financiera realizada. Ambos números son útiles una vez etiquetados. Poner “ahorro de IA” encima de cualquiera de los dos nos ahorraría muchas explicaciones y crearía un problema mucho mayor.

Para una cuenta de costes real, incluye la nómina y las cargas, los autónomos, los servicios comprados, las licencias, el uso de agentes y la infraestructura. La revisión, el mantenimiento y la medición también consumen recursos. No cuentes dos veces la mano de obra de revisión si ya está en el total de la nómina.

La tarifa de un proveedor va una sola vez en la cuenta, junto a nuestra propia supervisión. No inventamos además su nómina interna ni sus costes de tokens. Externalizar no debería hacer desaparecer el coste de la compra, ni contarlo dos veces.

También necesitamos una base coherente a lo largo del tiempo. Los gastos del periodo no son pagos en efectivo. Una construcción pagada este trimestre puede servir varios años. Elige y declara el tratamiento. No contabilices la construcción como gasto en una comparación y la repartas entre años en otra. El ejemplo de soporte supone que gasto y pago en efectivo coinciden.

Los precios también importan. Unos tokens más baratos mejoran la economía aunque no cambie nada del flujo de trabajo. Una subida de sueldos hace lo contrario. Donde se puedan comparar las cantidades y la calidad de los insumos, una vista a precios constantes ayuda a separar los cambios de precio del uso de recursos. Sin esa evidencia, muestra el resultado de costes nominal y explica sus límites.

Por último, que haya sesenta horas menos de atención no establece que pueda eliminarse un puesto entero. El personal tiene que seguir cubriendo el trabajo cuando llegue. La siguiente pregunta trata de la demanda y de los compromisos de servicio, no de dividir entre un número de horas conveniente.

El error que creí que se cancelaría

Había escrito que un peso equivocado se cancelaría al comparar un equipo consigo mismo. El mismo error aparece en los dos lados, así que seguro que estamos bien.

No. No cuando la mezcla se mueve.

Toma dos tipos de trabajo. Para este ejemplo, establece que sus pesos de referencia correctos son $1 para el trabajo simple y $10 para el complejo. En el primer trimestre, el equipo completa noventa unidades simples y una compleja. En el segundo, diez simples y nueve complejas. El resultado correctamente ponderado es $100 en ambos trimestres. Mantén también sin cambios el total de recursos.

Ahora asigna al trabajo complejo un peso incorrecto de $20.

Informamos de un crecimiento del 72,7% donde no hubo ninguno en la medida bien ponderada. El error se mantuvo fijo. Hicimos más del trabajo que habíamos sobrevalorado.

Un peso erróneo puede fabricar crecimiento

i

Crecimiento real 0,0 %. El índice dice +72,7 %. Mismo trabajo, distinta mezcla.

¿Cuánto se equivoca el peso del trabajo complejo?+100 %

Unidades complejas en el trimestre 29

Equivocarse también en el mismo importe con el peso del trabajo simple

La relación es esta:

ĜG = 1 + ē_t1 + ē_b,ē_t = Σ_k w_k,t e_k

(4)

G es la razón de crecimiento con los pesos correctos del ejemplo. Ĝ usa nuestros pesos estimados. e es el error proporcional de peso de cada tipo y w es su cuota del resultado correctamente ponderado. ē es el error medio tras ponderar por esas cuotas.

Los errores se cancelan cuando ese promedio es el mismo en ambos periodos. Una mezcla de trabajo sin cambios lo lograría. También equivocarse en todos los pesos en la misma proporción. Otras combinaciones también pueden cancelarse. Esas dos no son las únicas posibilidades.

La comprobación práctica es mirar qué ganó cuota. Si la mejora aparente viene de una categoría cuyo peso apenas nos fiamos, prueba alternativas plausibles. ¿Aguanta la ganancia? Los resultados por tipo deberían estar junto al total, sin que haga falta que los pida expresamente quien duda.

Las categorías pueden esconder otro cambio. Si el agente se lleva lo más fácil de los “casos fáciles”, hasta mi modelo de soporte con dos categorías puede ajustar demasiado poco. Tenemos que comprobar también qué cambió dentro de cada categoría.

También podemos mejorar al ver el trabajo

Incluso con pesos perfectos, los registros pueden engañarnos.

Supón que el resultado real crece un 10%. Capturamos el 80% del resultado correctamente ponderado en el primer periodo y el 84% en el segundo. La comparación observada pasa a ser:

D̂_tD̂_b = 1,10 × 0,840,80 = 1,155

(5)

El panel informa de un crecimiento del 15,5%. Cuatro puntos porcentuales de mejor cobertura añadieron 5,5 puntos porcentuales al crecimiento aparente. Sin crecimiento real, ese mismo cambio de cobertura fabricaría un 5%.

Un agente puede dejar un registro exhaustivo de trabajo que una persona habría terminado con una conversación. Mejores registros serían bienvenidos. Por sí solos, no serían más producción.

“Cobertura” en esa ecuación significa la parte del resultado capturada, ponderada sobre la misma base de referencia. No significa el porcentaje de nómina asociado a una integración, los puestos conectados ni el gasto visible.

Saber adónde fue el 80% del dinero no nos dice que hayamos encontrado el 80% del trabajo. Eso solo se sigue con más supuestos sobre el trabajo observado y el que falta. Conserva la cobertura del gasto como una comprobación financiera útil. No la metas en la ecuación del resultado solo porque sea más fácil de obtener.

Por eso conservé el ejemplo de cobertura aunque deje fuera de este post el sistema de recogida de evidencia. Un cambio en lo que podemos ver cambia la medición, sea cual sea la forma en que recojamos los registros.

Más registros no lo arreglarán automáticamente. El volumen puede reducir el ruido aleatorio. Un sesgo consistente puede permanecer. Y cuatro trimestres de datos no reducen automáticamente la incertidumbre a la mitad. Los errores compartidos entre trimestres no se comportan como errores independientes.

Prefiero publicar una serie más estrecha que observemos de forma coherente antes que hacer una afirmación sobre toda la empresa con una cobertura que no podemos defender. Necesita un límite claro, las mismas ventanas de seguimiento y comprobaciones de cambios en el registro. El trabajo fuera de ese límite sigue visible como trabajo sin medir.

Unas simulaciones anteriores me ayudaron a explorar estos errores. No he conservado sus bandas numéricas como evidencia de la precisión que tendría el método. Eso exige publicar la implementación y los supuestos, y comprobarlos después con trabajo real. Los ejemplos de aquí establecen los modos de fallo sin fingir que sabemos con qué frecuencia ocurrirá cada uno.

Al final, hasta la línea base se vuelve un problema

No podemos congelar un único conjunto de pesos para siempre y dar por hecho que el negocio seguirá siendo comparable por cortesía. Los servicios cambian. Algunos desaparecen, y los nuevos no vienen con un precio antiguo.

Una opción es actualizar los pesos periódicamente, comparando cada par de periodos adyacentes con los mismos pesos. Un enlace anual con los pesos del año anterior es:

L_t = Σ_k n_k,t s_k,t−1Σ_k n_k,t−1 s_k,t−1

(6)

El numerador cuenta el resultado de este año con los pesos del año pasado. El denominador cuenta el resultado del año pasado con esos mismos pesos. Multiplica los enlaces para obtener un índice de más largo recorrido.

Eso evita llamar cambio de producción a un cambio de pesos. También tiene un inconveniente: los componentes encadenados por separado en general no suman el total encadenado. El BEA advierte expresamente contra tratar los componentes en dólares encadenados como aditivos.²⁰

Así que construye la serie de la empresa a partir de su propio conjunto de resultados sin solapamientos. No sumes paneles de equipo diseñados de forma independiente con la esperanza de que midan cosas compatibles. Parte del trabajo interno puede ser útil en una vista por función y estar ya incluido en el entregable de extremo a extremo de la empresa.

Una clasificación modificada también necesita un puente: un periodo de solapamiento, una reconstrucción creíble de la serie anterior o una ruptura declarada. Encadenar no reparará una mala definición de servicio ni trabajo omitido que acabamos de descubrir.

Esto puede dejarnos con comparaciones útiles por función y sin un total defendible para toda la empresa. Lo aceptaría. Sería mejor que inventar un total porque el encargo original lo pedía.

A veces el buen trabajo reduce el recuento

Supón que ingeniería arregla el defecto detrás de mil conversaciones de soporte. Nuestro índice de casos de soporte informa de menos casos atendidos.

Debe hacerlo. Hubo menos casos. El error sería decidir que la empresa se ha vuelto menos productiva.

Con un límite más amplio, intentamos ayudar a los clientes a usar el producto con éxito. Mantener o mejorar ese servicio con menos contactos evitables puede ser una ganancia considerable. El recuento estrecho de casos necesita la definición de servicio más amplia o las medidas de resultado a su lado.

La fiabilidad y la prevención tienen el mismo problema. Una semana de guardia tranquila puede ser una buena semana. Una intervención de cumplimiento útil puede evitar que un caso llegue a existir.

Para esas funciones, probaría unidades basadas en el servicio mantenido durante un periodo: qué se mantuvo funcionando, para quién, con qué carga y qué riesgo, y con qué estándar. Una entrada en el calendario de guardias no basta. Tampoco convertiría el resultado de un mes en cero porque se incumplió un umbral. El ajuste de calidad tiene que reflejar el fallo, en lugar de hacer que todo dependa de un interruptor.

Estas unidades son más difíciles de definir. Eso es parte del problema que intento entender, no algo que un recuento de tickets nos permita esquivar.

¿Y el trabajo que antes no podíamos hacer?

Un equipo de auditoría que muestreaba transacciones ahora puede examinarlas todas. Pon el antiguo coste humano hipotético en cada comprobación adicional y la afirmación de resultado se vuelve enorme.

Pero nadie iba necesariamente a comprar ese proceso manual. Y más comprobaciones tampoco significan un aumento proporcional de la garantía.

Si el servicio nuevo es comparable con algo que ya medimos, podemos contabilizar el cambio de alcance o de calidad sobre esa base. Si no lo es, informaría por separado de la capacidad, su coste y lo que esperamos que consiga mientras establecemos una definición útil.

A eso lo llamo un libro de capacidades. No significa que el gasto sea capitalizable. No significa que podamos esconder trabajo caro bajo “innovación” cada vez que la razón de eficiencia decepcione. La cuenta tiene que seguir conciliando con las finanzas.

Cuando el servicio se vuelva repetible y definible, puede unirse al índice de entrega con una regla de incorporación explícita. Que lo haya hecho posible la IA no debería dejarlo fuera para siempre.

Aquí vuelve el argumento de Acemoglu sobre la demanda empresarial. Si las empresas solo premian el ahorro de costes laborales, solo comprarán herramientas que sustituyan personas.¹ Un libro de capacidades es una forma de premiar la otra clase.

Mi aportación aquí es más modesta. Dar a la empresa un lugar donde explicar lo que la inversión hace posible, en lugar de pedir a cada proyecto que se justifique como trabajo antiguo más barato. Un responsable, evidencia y una fecha de revisión serían un buen comienzo. “Es IA” no es un caso de inversión.

Acemoglu también argumenta contra las distorsiones fiscales que favorecen al capital sobre el trabajo, basándose en un trabajo con Andrea Manera y Pascual Restrepo.¹²¹ Estoy de acuerdo en eliminar una preferencia artificial por la sustitución. Para este post, sin embargo, la decisión está dentro del presupuesto: ¿cuánto cuesta ahora el servicio que ya tenemos y qué podemos hacer que antes no podíamos?

El libro no tomará esa decisión por nosotros. Debería hacer más difícil evitarla.

¿Se lo enseñaría a un director financiero?

Sí, pero junto con el resto de la cuenta, no como una nota para la empresa.

Kent Beck y Gergely Orosz defienden con fuerza que no se pongan objetivos de esfuerzo y de resultado, en su respuesta a McKinsey. Al hablar de sus métricas a medida, escriben: “Customers don’t care. Executives don’t care. Investors don’t care.” (a los clientes, a los directivos y a los inversores les da igual).²²

Creo que ese rechazo va demasiado lejos. Un director financiero puede preguntarse razonablemente si podemos prestar el mismo servicio de nóminas, con el mismo estándar, con menos recursos. No deberíamos tener que esperar a que se mueva el beneficio de la empresa para investigar por qué se ha vuelto más caro.

Su argumento es más matizado que esa frase. También reconocen que el esfuerzo y el resultado sirven para diagnosticar problemas, y los peligros de juzgar a las personas solo por los resultados.¹³ En su sección final, Orosz recomienda usar el esfuerzo y el resultado para investigar problemas en lugar de convertirlos en las medidas públicas del éxito.

Ese es el desacuerdo más acotado que vale la pena tener. Creo que una comparación informada con regularidad del resultado y el coste de un servicio definido podría ayudar, junto con los resultados de negocio. Tiene que justificar su coste y su efecto sobre el comportamiento. Un panel precioso que convierte al equipo en mejoradores de panel a jornada completa ha fracasado.

Esto es, más o menos, lo que me gustaría ver:

Las medidas de resultado deberían diferir según la función. Las reservas pertenecen a una conversación de ventas. No son una prueba de aceptación sensata para un asesoramiento legal. Prefiero mostrar esas diferencias antes que esconderlas dentro de un “multiplicador de impacto”.

A nivel de empresa, la cuenta financiera también debe reflejar cómo compramos el trabajo. Los ingresos por empleado pueden subir tras externalizar aunque el coste total de la entrega suba. Suma los servicios comprados y los costes de IA relevantes antes de decidir que el negocio se ha vuelto más eficiente. Los ingresos siguen teniendo otros factores, así que esa razón no atribuirá el cambio a la IA.

No usaría el índice de entrega para clasificar a individuos. Sus pesos describen clases de trabajo, no toda la contribución de una persona. Hacer de mentor, las interrupciones y ayudar a otro a terminar un trabajo no caben en el recuento de resultados de un individuo. Si atas el sueldo al índice, damos a la gente un motivo para defender pesos mayores y más trabajo contable.

Incluso comparar el trabajo asistido por IA con el trabajo solo humano exige el mismo cuidado que el ejemplo inicial. Las asignaciones pueden diferir dentro de una categoría. Saber que hubo un agente de por medio no prueba que causara la mejora.

Y un artefacto terminado no prueba que la persona responsable lo entendiera. Ese es otro problema, sobre todo si decimos que el propósito es hacer a las personas más capaces.

La prueba que aún no he hecho

He mostrado cómo se comportan unos cuantos cálculos con entradas que elegí yo. He tomado prestados métodos contables y he aprendido de las objeciones de otros. Nada de eso me dice si dos equipos pueden usar esta propuesta con trabajo real y llegar a un resultado útil.

Esa es la siguiente prueba.

Empezaría con tres contextos: un flujo repetible de casos o transacciones, un flujo de proyecto y un servicio continuo. Para cada uno, escribe la unidad, el alcance y el límite del informe antes de ver los resultados. Añade la regla de finalización, el tratamiento de la calidad, los pesos de referencia y la base de costes. Di qué pasa con el trabajo sin emparejar y con las correcciones posteriores.

Después dale la misma evidencia a otro equipo competente. ¿Pueden reproducir el cálculo? ¿En qué discrepan sobre lo que debe entrar?

La aritmética debería ser fácil de acordar. El ejemplo de la exportación muestra dónde estará la discusión de verdad. Si dos elecciones razonables de categoría invierten el resultado principal, el informe tiene que mostrarlo en lugar de zanjar el desacuerdo con un decimal.

Elige las clases de referencia y estima sus pesos con un conjunto de trabajo, y pruébalos después con otro. Incluye en la revisión los registros excluidos y el trabajo que queda fuera del sistema de seguimiento principal. No redibujes las categorías hasta que el historial resulte convincente.

Repite las pruebas de ticket partido, ticket fusionado, reorganización y externalización. Comprueba si hay cambios en el registro. El total de la empresa no debería moverse cuando lo único que hemos cambiado es cómo describimos o compramos el mismo trabajo.

Prueba primero esta contabilidad con una descripción del trabajo establecida de forma independiente. Si una máquina puede recuperar esa descripción a partir de los sistemas disponibles es una prueba de implementación posterior. Si personas con evidencia suficiente no se ponen de acuerdo en las unidades, un mejor clasificador no rescatará la definición.

Probar si la IA causó una mejora es otro trabajo. El acceso aleatorizado puede ayudar donde sea viable, igual que un despliegue escalonado bien diseñado con un grupo de comparación creíble. El aprendizaje, los efectos colaterales, la selección de tareas y un seguimiento de calidad equivalente importan todos. Los adoptantes entusiastas y los reacios no son comparables automáticamente por tener el mismo cargo.

¿Con qué exactitud necesita medir la medida? Depende de la decisión. Una señal aproximada para saber dónde investigar tiene una carga distinta a la de la evidencia que se usa para recortar plantilla o informar de ahorros. El error aceptable debería seguir a esa decisión, no un tamaño de muestra de auditoría universal.

Publica las definiciones, el cálculo y la política de revisión junto con el resultado. Mi listón es que otro equipo pueda aplicar el método, cuestionar sus decisiones y ver si la conclusión sobrevive. No bastaría con el reconocimiento de un contable ni con una ecuación de aspecto impresionante.

Ahora tengo una pregunta mejor

Empecé con “¿nos hizo la IA más productivos?”. Ahora quiero saber qué servicio cambió, si estamos contando lo mismo y adónde fue la capacidad liberada. Esas preguntas son menos cómodas en una diapositiva. Son mucho más útiles cuando alguien pregunta qué deberíamos hacer a continuación.

Esto importa para Flowstate porque conectar el trabajo con los recursos que hay detrás es el problema que intentamos resolver. No quiero que el producto dependa de defender una fórmula a la que le cogí cariño escribiendo una entrada de blog. Si el trabajo real rompe el modelo, el modelo tiene que cambiar.

Sigo queriendo que los agentes quiten el trabajo repetitivo de los días de la gente. Quiero que una empresa reconozca el beneficio cuando alguien gana tiempo para pensar, ayuda a un compañero o prueba algo nuevo, en lugar de exigir más tickets para demostrar que la compra del software funcionó.

No estoy seguro de cuánto de eso cabe en un índice. Quizá menos de lo que esperaba. Un resultado útil podría ser un conjunto de comparaciones de las que nos fiemos, con los huecos a la vista.

Cuando el agente se lleva los casos fáciles, las personas que quedan no deberían tener que fabricar actividad para defenderse. Cuando alguien afirme un ahorro, deberíamos poder preguntar adónde fue. Y cuando el número propuesto no responda a la pregunta, deberíamos decirlo antes de que se convierta en el objetivo de alguien.

Fui a buscar una medida. He acabado con un método que probaría y una lista bastante larga de motivos para tener cuidado. Dado de dónde partía, creo que es progreso.

Notas técnicas

Estos son los cálculos detrás de los ejemplos. Los supuestos importan: una identidad puede ser exacta sin decirnos con qué exactitud podemos estimar sus insumos en una empresa. Las razones de abajo suponen pesos de referencia positivos y denominadores distintos de cero.

La identidad del error de peso

Sea s el peso de referencia correcto estipulado para el tipo k, y sea el peso estimado:

ŝ_k = s_k(1 + e_k)

(7)

Para un resultado contado con exactitud, define el total correctamente ponderado y la cuota de cada tipo como:

D_t = Σ_k n_k,t s_k,w_k,t = n_k,t s_kD_t

(8)

Entonces:

D̂_t = Σ_k n_k,t s_k(1 + e_k) = D_t(1 + ē_t)

(9)

Al tomar la razón entre periodos se obtiene la identidad usada arriba. Supone errores de peso proporcionales fijos por tipo, cantidades exactas y una definición común del resultado. No modela el trabajo omitido, las clasificaciones cambiantes ni los límites inciertos de los entregables.

Para errores pequeños, el error relativo de la razón de crecimiento es aproximadamente:

ĜG − 1 ≈ Σ_k (w_k,t − w_k,b) e_k

(10)

Si además los errores de cada tipo son variables aleatorias independientes de media cero y con una desviación típica común, la desviación típica de primer orden de ese error de la razón de crecimiento es:

σ_G ≈ σ_e √Σ_k (w_k,t − w_k,b)²

(11)

Bajo esos supuestos concretos, transferir veinte puntos porcentuales de cuota de resultado entre dos tipos y fijar la desviación típica del error en el 20% da aproximadamente un 5,66% de error relativo en la razón de crecimiento, una desviación típica. No es una banda de error establecida empíricamente, y en general no es el mismo número de puntos porcentuales de crecimiento informado. Los estándares correlacionados o sesgados de forma sistemática requieren otro cálculo.

La cobertura es un concepto de resultado en la identidad

En el ejemplo de solo cobertura, sea c la parte del resultado correctamente ponderado que es visible en los registros, sin falsos positivos ni otros errores. Entonces el resultado observado es c veces el resultado completo, de modo que:

D̂_t / D̂_bD_t / D_b = c_tc_b

(12)

La ecuación es exacta bajo esas definiciones. Estimar c es lo difícil. Una razón de gasto conectado entre gasto total es otro estadístico y no puede sustituirse sin un modelo explícito que vincule la cobertura de recursos con la cobertura de producción.

El límite contable también importa aquí. Observar una parte del resultado mientras se usa toda la base de costes no estima el mismo objeto que medir tanto el resultado como el coste de un servicio deliberadamente restringido y observado de forma coherente. Ninguno de los dos debería rebautizarse como eficiencia de toda la empresa sin justificación.

Por qué la exactitud global del clasificador no basta

Para un problema de reconocimiento binario simple con pesos fijos asignados correctamente, define los totales de verdaderos positivos, falsos positivos y falsos negativos usando esos pesos en lugar de los recuentos de elementos. La precisión ponderada es el peso de verdaderos positivos dividido entre todo el peso reconocido. La exhaustividad ponderada es el peso de verdaderos positivos dividido entre todo el peso elegible. Donde los denominadores no son cero:

peso reconocidopeso elegible = exhaustividad ponderadaprecisión ponderada

(13)

La precisión y la exhaustividad ordinarias basadas en recuentos no dan esa identidad para un índice ponderado por coste. Una clasificación errónea que cambie el peso de un elemento reconocido requiere un tratamiento adicional. También los candidatos que nunca se encontraron y las relaciones inciertas entre registros padre e hijo. Combinar estos errores en una sola ecuación multiplicativa requiere definiciones compatibles. No se justifica solo porque cada término tenga un nombre plausible.

El reconocimiento probabilístico es posible, pero un estimador propuesto debe mantener las clasificaciones mutuamente excluyentes y evitar contar entregables que se solapan. Un conjunto de tickets puntuados de forma independiente no cumple esas condiciones automáticamente. Las probabilidades calibradas abordan la incertidumbre en los candidatos observados, no el trabajo que falta por completo en el conjunto de candidatos.

Qué puede establecer una muestra de auditoría

La conocida estimación de 385 observaciones sale de un cálculo concreto: una muestra aleatoria simple de una proporción binaria independiente, un intervalo del 95% por aproximación normal, una proporción de peor caso de un medio y un margen de cinco puntos porcentuales. El tamaño de muestra sin redondear es:

n ≈ 1,96² × 0,5 × 0,50,05² = 384,16

(14)

No establece que 385 registros vayan a calibrar los costes de referencia, validar todos los tipos de trabajo ni resolver un cambio pequeño entre periodos. La estratificación, los conglomerados, los pesos desiguales, los casos raros de coste alto y el desacuerdo entre revisores cambian el diseño necesario. La planificación de la auditoría debería partir del error que podría cambiar la decisión de negocio, no de un número redondo conocido.

Reproducibilidad e interpretación

Los ejemplos trabajados usan las entradas indicadas. No son estimaciones del rendimiento típico de una empresa. Unas bandas de error numéricas de Monte Carlo también necesitarían que se publicaran la implementación, las distribuciones de los parámetros, los supuestos de dependencia y las semillas aleatorias. Tendríamos que establecer después qué supuestos encajan con el trabajo observado antes de interpretar las bandas como exactitud esperada.

La suma de la entrega tiene unidades de moneda de coste de referencia. Un índice de presentación puede normalizar esa suma a 100 en el periodo base. El índice de eficiencia de costes ya usa esa normalización. Ninguno mide el valor económico, el impacto causal de la IA ni lo que vale un empleado.

Will Hackett es cofundador y CTO de Flowstate.

Footnotes

1. Daron Acemoglu, Will AI Replace Workers? Not If We Build It Right., The Humanist Review of AI, 15 de julio de 2026. Defiende herramientas que complementen a los trabajadores y una demanda empresarial centrada en la productividad y la innovación, no solo en el ahorro de costes laborales. La conexión con el diseño de informes de aquí es una inferencia mía, no un método propuesto en ese ensayo. Fuente. ↩ ↩² ↩³

2. National Association of Letter Carriers, The Remote Encoding Center: Where bad addresses go to get better, The Postal Record, julio de 2022, pp. 34 y 35. El relato describe cómo las máquinas se quedan con las imágenes de direcciones más fáciles y dejan las más difíciles para los codificadores humanos. Fuente. ↩

3. Intercom, How Fin AI Agent and Copilot Cut Handle Time and Boost Agent Productivity. El comentario sobre la carga de casos que queda en manos humanas es opinión del proveedor que apoya el mecanismo de la mezcla de trabajo, no evidencia independiente del tamaño de una ganancia de productividad. Fuente. ↩

4. Erik Brynjolfsson, Danielle Li y Lindsey Raymond, Generative AI at Work, The Quarterly Journal of Economics 140(2), 2025, pp. 889 a 942. El estudio publicado informa de un aumento medio del 15% en las incidencias resueltas por hora en su contexto de soporte al cliente, con efectos distintos en velocidad y calidad según los trabajadores. Artículo publicado. Resumen de los autores. ↩

5. Joel Becker, Nate Rush, Beth Barnes y David Rein, Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity, METR, 10 de julio de 2025. El resultado se refiere a los desarrolladores con experiencia que participaron, sus repositorios y las herramientas disponibles en ese experimento. Fuente. ↩

6. Joel Becker y colegas, We are Changing our Developer Productivity Experiment Design, METR, 24 de febrero de 2026. El seguimiento trata la selección de participantes, la selección de tareas y las dificultades para medir el tiempo con agentes concurrentes. Fuente. ↩

7. McKinsey, The state of AI in 2026: On the road to ROI, 25 de agosto de 2026. Las respuestas de la encuesta se recogieron entre 1719 participantes del 4 de mayo al 8 de junio de 2026. Las cifras informadas del 80% de productividad individual y del 37% de impacto en el EBIT responden a preguntas distintas. Fuente. ↩

8. Nicole Forsgren, Margaret-Anne Storey, Chandra Maddila, Thomas Zimmermann, Brian Houck y Jenna Butler, The SPACE of Developer Productivity: There’s more to it than you think, ACM Queue 19(1), 2021. Sostiene que la productividad de los desarrolladores no se puede captar con una sola métrica ni una sola dimensión. El índice de entrega acotado que se propone aquí no se presenta como sustituto de ese marco. Fuente. ↩

9. Alessandro Berti y colegas, OCEL (Object-Centric Event Log) 2.0 Specification, arXiv:2403.01975, enviado el 4 de marzo de 2024. La especificación admite eventos y relaciones que afectan a varios objetos de negocio. Es un estándar de representación, no una métrica de productividad. Fuente. ↩

10. ACCA, The standard hour in performance measurement. Las horas estándar dan una medida de actividad común para productos heterogéneos y permiten razones separadas de volumen, utilización y eficiencia. Fuente. ↩

11. Office for National Statistics, Public service productivity estimates: sources and methods, revisado el 1 de mayo de 2026, en especial la sección 1 sobre producción, insumos y números índice. La metodología usa medidas de actividad ponderadas por coste para buena parte, aunque no toda, de la producción de los servicios públicos. Fuente. ↩ ↩²

12. Ron Jeffries, Story Points Revisited, 23 de mayo de 2019. Su disculpa matizada por haber inventado posiblemente los puntos de historia es la referencia aquí, no una evidencia contra toda forma de estimación relativa. Fuente. ↩

13. Gergely Orosz y Kent Beck, Measuring developer productivity? A response to McKinsey, Part 2, The Pragmatic Engineer, 31 de agosto de 2023. Su discusión conjunta trata los incentivos basados solo en resultados. La sección de cierre, identificada aparte, es de Orosz e incluye el ejemplo de inflado de estimaciones y la recomendación de usar el esfuerzo y el resultado para diagnosticar problemas en lugar de como medidas públicas de éxito. Fuente. ↩ ↩²

14. Alex Tamkin y Peter McCrory, Estimating AI productivity gains from Claude conversations, Anthropic, 25 de noviembre de 2025. La comprobación con tareas de software informa de correlaciones de Spearman de 0,44 para Claude y 0,50 para los desarrolladores, junto con estimaciones comprimidas del modelo. Un buen rendimiento al ordenar no establece una calibración en horas. Fuente. ↩

15. Intercom, Fin AI Agent outcomes, documentación consultada el 7 de octubre de 2026. Véanse “Resolution definition” y la explicación de que las peticiones posteriores de más asistencia en la misma conversación revierten el cargo por resolución. Los ejemplos trabajados de este post no usan los precios reales de Fin. Fuente. ↩

16. Tejal Patwardhan y colegas, GDPval: Evaluating AI Model Performance on Real-World Economically Valuable Tasks, 2025, apéndice A.2.1 y tabla 2. Los escenarios de revisar y rehacer usan supuestos concretos y omiten un tratamiento comparable de revisión y fallo para la referencia humana. No deben leerse como estimaciones generales de ahorro en el trabajo. Fuente. ↩

17. Ralf Seifert, Richard Markoff y Matthew Spooner, How a new approach to demand planning can redefine success, I by IMD, 5 de agosto de 2024. Trata el valor añadido de la previsión y la posibilidad de que una mejor línea base reduzca la contribución incremental de los ajustes humanos. Fuente. ↩

18. Tom Cunningham y Parker Whitfill, Task Substitution and Uplift, METR, 8 de mayo de 2026. Distingue el aumento de productividad en tareas antiguas, en tareas nuevas y en valor, con relaciones derivadas bajo supuestos explícitos. Fuente. ↩

19. Robert S. Kaplan y Steven R. Anderson, Rethinking Activity-Based Costing, Harvard Business School Working Knowledge, 24 de enero de 2005. Distingue la capacidad suministrada de la capacidad consumida y trata las oportunidades que surgen de la capacidad sin usar. Fuente. ↩

20. US Bureau of Economic Analysis, Chained-dollar estimates. Señala la no aditividad fuera del año de referencia y advierte contra usar los componentes como si fueran dólares aditivos corrientes. Fuente. ↩

21. Daron Acemoglu, Andrea Manera y Pascual Restrepo, Does the U.S. Tax Code Favor Automation?, Brookings Papers on Economic Activity, primavera de 2020. Analiza un tratamiento fiscal que favorece la inversión en equipos y software frente al trabajo. Las estimaciones históricas de ese artículo no son un cálculo del tratamiento fiscal actual de ninguna empresa concreta. Fuente. ↩

22. Gergely Orosz y Kent Beck, Measuring developer productivity? A response to McKinsey, The Pragmatic Engineer, 29 de agosto de 2023, en especial la sección 4. El rechazo citado se refiere a las métricas a medida de esfuerzo y resultado de McKinsey, no a toda forma posible de medición operativa. Fuente. ↩