Cómo saber si la IA está aumentando realmente la productividad

Una persona prepara en veinte minutos un documento que antes necesitaba dos horas. Un desarrollador implementa en una mañana una funcionalidad que habría requerido varios días. Un equipo utiliza inteligencia artificial para analizar cientos de documentos en minutos. Un departamento automatiza una tarea que hasta entonces realizaban manualmente varias personas. En todos esos casos resulta tentador concluir que ha aumentado la productividad, aunque todavía falte comprobar la calidad y el trabajo posterior. La velocidad es una de las mejoras más visibles que introduce la inteligencia artificial y, precisamente por eso, también puede convertirse en una de las más engañosas.

Una tarea puede ejecutarse mucho más rápido sin que mejore el sistema del que forma parte. Un aumento de la producción puede traer más retrabajo; el tiempo que ahorra una persona puede convertirse en trabajo adicional para otra, y un coste inmediato menor puede elevar el coste futuro. Incluso multiplicar la producción no garantiza un resultado mejor. Por eso, después de desplegar herramientas y empezar a transformar procesos, aparece una pregunta inevitable: ¿cómo sabemos si la IA está aumentando realmente nuestra productividad?

Este artículo expone mi criterio profesional para evaluar ese cambio. No presenta una relación causal demostrada para cualquier organización ni sustituye una línea base y una medición propias.

Primero hay que definir qué entendemos por productividad

Para una tarea repetible, mediría la productividad como trabajo aceptado por unidad de recurso, manteniendo el criterio de calidad. Si se trata de una capacidad nueva, definiría primero qué resultado útil cuenta.

Antes de medir acordaría qué cambio buscamos. Pasar de cinco documentos semanales a diez aumenta la producción; tardar la mitad en cada uno reduce el tiempo de ejecución. Hacer el mismo trabajo con menos recursos mejora la eficiencia. Abordar una actividad antes inviable amplía la capacidad. Ninguno de esos cambios demuestra por sí solo que el resultado tenga más valor para la organización.

Conviene distinguirlos. El uso, la velocidad, la producción, la eficiencia, la productividad y el valor están relacionados, pero no son magnitudes intercambiables. Una organización puede mejorar enormemente una métrica y no mejorar las demás.

Las métricas de adopción no son métricas de productividad

Cuando desplegamos herramientas de IA aparecen indicadores fáciles de obtener:

• licencias asignadas y usuarios activos;
• frecuencia de uso, conversaciones y tokens consumidos;
• código, documentos y otros artefactos generados;
• agentes ejecutados.

Estas métricas permiten saber si la herramienta se utiliza, pero miden sobre todo adopción. Un usuario que realiza cincuenta interacciones diarias no es necesariamente más productivo que otro que realiza cinco; un equipo que genera el 40 % de su código con IA tampoco tiene por qué estar desarrollando software mejor o más rápido. El uso puede ser necesario para obtener beneficios, pero no los demuestra.

Las horas ahorradas solo miden una parte

Otra métrica habitual consiste en preguntar cuánto tiempo cree una persona que ha ahorrado utilizando IA. Es comprensible. Además, permite construir rápidamente cifras muy atractivas. Si cien empleados aseguran ahorrar treinta minutos diarios, podemos convertirlo en horas anuales y posteriormente en euros. El cálculo parece sencillo, pero contiene varios supuestos. Hay que comprobar si ese tiempo se ha ahorrado, qué ha ocurrido con él y qué resultado produjo su reutilización. Supongamos que una herramienta permite ahorrar una hora semanal a mil empleados. Eso no significa automáticamente que la organización haya ganado mil horas de capacidad productiva.

Quizá ese tiempo se haya utilizado para realizar más trabajo. Quizá haya permitido reducir un cuello de botella. Quizá haya mejorado la calidad. Quizá simplemente haya reducido presión sobre las personas. Eso también puede ser valioso. Pero es un resultado diferente. Traducir automáticamente «horas ahorradas» a «euros ahorrados» puede producir una precisión económica que en realidad no existe.

Necesitamos una línea base

Para demostrar una mejora necesitamos una referencia que describa el proceso anterior: tiempo de ciclo y coste, errores y retrabajo, personas implicadas, calidad obtenida y plazo de entrega. No hace falta instrumentar durante meses cada actividad, pero sí conocer lo suficiente para explicar qué cambió. La línea base tampoco debe limitarse a la ejecución: incluye, cuando sea relevante, lo que ocurre antes y después, porque ahí puede esconderse buena parte de los costes.

La medición debe abarcar el ciclo completo

Imaginemos que una persona necesitaba tres horas para preparar un informe. Con IA tarda treinta minutos. Aparentemente hemos reducido el tiempo en más de un 80 %. Pero descubrimos que ahora otra persona dedica cuarenta minutos adicionales a comprobar datos, corregir afirmaciones y revisar fuentes. El ahorro sigue pudiendo ser considerable. Pero ya no es el que habíamos observado inicialmente. En otro caso, quizá la revisión adicional sea mínima, pero aumenten los errores que llegan posteriormente a producción. O quizá el volumen generado aumente tanto que el equipo responsable de validar los resultados se convierta en el nuevo cuello de botella.

Por eso, la medición debe abarcar la entrada, la ejecución, la revisión, la corrección, la entrega y las consecuencias posteriores.

Optimizar una tarea no significa optimizar el sistema: la productividad solo puede evaluarse al observar el ciclo completo.

Ver a tamaño originalCerrar

La unidad de análisis no debería ser únicamente la interacción con la IA. Debería ser el flujo de trabajo afectado por ella. Optimizar una etapa no garantiza haber optimizado el sistema.

Producción y resultado no son lo mismo

Esta distinción es especialmente importante porque la IA reduce el coste marginal de producir texto, código, imágenes, análisis, documentación, propuestas, casos de prueba y variantes. Sin embargo, una empresa no existe para maximizar artefactos: un equipo de software no maximiza líneas de código; el de marketing, publicaciones; el de producto, especificaciones; ni el de formación, cursos. Lo importante es el resultado que esos artefactos permiten conseguir.

La IA puede ayudarnos a producir diez veces más sin que el resultado final cambie apenas. Incluso puede empeorar. Por eso, cuanto más barato resulte producir, más importante será medir aquello que ocurre después de generarlo. El caso del workslop aborda el trabajo de comprobación y corrección que puede recaer sobre quien recibe el resultado.

El desarrollo de software muestra muy bien el problema

En desarrollo podemos medir el código generado, las sugerencias aceptadas, las solicitudes de integración completadas y el tiempo de implementación. Esas métricas pueden mejorar mientras crecen el tamaño de los cambios, la revisión, el retrabajo y los defectos. La deuda técnica tarda más en hacerse visible: producir código cuesta menos, pero el equipo sigue teniendo que comprenderlo y mantenerlo.

Ese desfase puede permitirnos integrar cambios más deprisa de lo que sabemos revisarlos. Si después cuesta más modificar el sistema, aumentan las regresiones o necesitamos más tiempo para entenderlo, parte del ahorro inicial se ha trasladado al mantenimiento. Medir solo la entrega dejaría fuera esa transferencia.

En desarrollo lo llamamos deuda técnica porque disponemos de un vocabulario asentado para describirla. Pero el fenómeno no es exclusivo del software.

La deuda también forma parte del coste

Esto no ocurre solamente con código. Podemos generar deuda documental, de datos, operativa, de conocimiento y de procesos. La deuda técnica es, en realidad, una manifestación particular de un fenómeno más amplio: la IA también puede generar deuda operativa. En un departamento jurídico, generar análisis, cláusulas o borradores mucho más rápido puede aumentar el volumen que necesita revisión y hacer más difícil distinguir qué decisiones han sido realmente validadas. En un equipo de contenidos o formación, multiplicar la producción puede significar también multiplicar versiones, inconsistencias, materiales que mantener y contenidos cuya vigencia habrá que revisar posteriormente.

En recursos humanos, producir evaluaciones, descripciones o documentación a gran escala puede crear dependencia de criterios que nadie ha formalizado suficientemente y que después resultan difíciles de auditar o corregir. En operaciones, automatizar rápidamente decisiones parciales puede terminar creando una colección de flujos, agentes e integraciones con propietarios difusos y costes de mantenimiento que aparecen meses después. La cuestión no es que estos usos sean incorrectos. Es que el coste de producir un activo puede disminuir mucho más rápido que el coste de gobernarlo durante todo su ciclo de vida. Una automatización rápida puede introducir una dependencia difícil de mantener. Un conjunto de agentes creados independientemente puede terminar duplicando lógica.

Cada departamento puede construir su propia base de conocimiento. Podemos acumular instrucciones, capacidades reutilizables, herramientas y flujos sin un responsable claro. También puede aumentar la cantidad de sistemas que necesitan supervisión. Es decir, la IA puede crear activos cuyo coste de mantenimiento aparece después. Por eso evaluaría no solamente cuánto cuesta construir una capacidad, sino también cuánto cuesta operarla, entenderla, mantenerla, evaluarla y cambiarla. La productividad sostenible necesita incorporar ese coste.

Calidad y velocidad deben medirse juntas

Si una tarea se realiza dos veces más rápido pero produce resultados peores, necesitamos saberlo. La calidad no siempre tiene una métrica sencilla: según el proceso, puede expresarse mediante exactitud, completitud, defectos, reclamaciones, rechazos, regresiones, reaperturas, incidencias, cumplimiento, satisfacción, conversión o resultados pedagógicos. Si esperamos aumentar la velocidad, debemos observar simultáneamente alguna dimensión de calidad; de otro modo diseñaremos una evaluación predispuesta a demostrar éxito.

El retrabajo es una métrica especialmente valiosa

Una variable merece particular atención: el retrabajo, medido por el tiempo de corrección, los resultados que vuelven a abrirse y los cambios posteriores. La IA puede producir una primera versión mucho antes de entregar un resultado aceptable; para la organización importa más el tiempo transcurrido hasta obtener ese resultado.

El cuello de botella cambia de lugar

Cuando aceleramos una parte de un sistema, algo interesante suele ocurrir: el cuello de botella se mueve. Si los desarrolladores producen más deprisa, quizá la revisión o el control de calidad se conviertan en el límite. Si generamos contenidos más rápido, quizá la aprobación editorial pase a ser el problema. Si analizamos documentación automáticamente, quizá ahora podamos identificar muchas más incidencias de las que somos capaces de resolver. Si automatizamos la generación de propuestas, quizá el cuello de botella pase a operaciones. Eso no significa que la mejora haya sido inútil, sino que el sistema ha cambiado y tenemos que volver a observarlo. Una iniciativa de IA puede ser muy exitosa precisamente porque revela el siguiente problema que debemos resolver.

Lo peligroso sería declarar victoria midiendo únicamente la etapa que hemos acelerado.

La capacidad nueva también debe medirse

Existe además otro tipo de beneficio que las métricas tradicionales pueden infravalorar. La IA no solamente permite hacer lo mismo más barato. También puede permitir hacer cosas que antes no hacíamos: analizar todos los documentos en lugar de una muestra, personalizar materiales que antes tenían que ser genéricos, revisar sistemáticamente elementos que antes solo comprobábamos de forma puntual, explorar muchas más alternativas antes de tomar una decisión, proporcionar asistencia fuera del horario en el que una persona podría hacerlo y procesar volúmenes que antes no eran viables económicamente. Ese valor no aparece necesariamente como «horas ahorradas». Es capacidad nueva y, en algunos casos, puede ser mucho más importante que la eficiencia. Por eso preguntaría también:

¿Qué podemos hacer ahora que antes no podíamos hacer razonablemente?

No todo beneficio tiene que convertirse en reducción de plantilla

También sería prudente con otra equivalencia frecuente. Productividad no significa necesariamente reducción de personas. Una mejora puede utilizarse para reducir costes, absorber crecimiento sin aumentar proporcionalmente el equipo, reducir los tiempos de espera, mejorar la calidad, aumentar la cobertura, liberar trabajo de poco valor, dedicar más tiempo a problemas complejos u ofrecer capacidades que antes no existían. Son decisiones de negocio diferentes. Si únicamente consideramos exitosas las iniciativas que permiten reducir plantilla, estaremos ignorando una parte considerable del valor potencial de la tecnología. Y probablemente incentivaremos además comportamientos poco saludables a la hora de medir resultados.

El coste de la IA tampoco es solamente la licencia

Para calcular productividad o retorno necesitamos mirar también el denominador. La licencia es la parte más visible. Pero una capacidad empresarial basada en IA incorpora el consumo de modelos y la infraestructura, el desarrollo y las integraciones, los controles y la revisión humana, y el mantenimiento durante su vida útil. Una automatización puede ahorrar cientos de horas y seguir sin ser económicamente interesante si necesita una infraestructura y una supervisión desproporcionadas. Otra puede parecer cara por consumo de modelos y, sin embargo, producir un retorno extraordinario porque elimina un cuello de botella de mucho mayor valor. Por eso, los costes tecnológicos deben analizarse junto al proceso que se transforma.

Lo relevante es el coste total por resultado útil.

No existe una única métrica corporativa de productividad con IA

Un único KPI corporativo de «productividad aumentada por IA» sería cómodo y engañoso: cada tipo de trabajo necesita indicadores ligados al resultado que intenta mejorar. Un marco común puede observar estas dimensiones:

• Tiempo: ciclo completo.
• Calidad: resultado igual o mejor.
• Retrabajo: trabajo adicional y reaperturas.
• Coste: coste total por resultado útil.
• Capacidad: actividades que antes no eran viables.
• Riesgo: fallos y dependencias nuevos.
• Resultado: mejora que justificaba la intervención.

No es necesario optimizarlas todas a la vez, pero sí hacer visibles los intercambios.

Comparar, experimentar y revisar

Siempre que sea posible, las evaluaciones no deben basarse exclusivamente en percepciones. Pueden comparar periodos, equipos, tareas, flujos con y sin asistencia o versiones de una solución mediante pilotos, muestras o evaluaciones controladas. La comparación debe conservar una mezcla de tareas comparable y registrar los cambios de demanda, equipo o proceso. Si en el segundo periodo llegan incidencias más sencillas, una reducción de tiempo no puede atribuirse solo a la IA. No todo admite un experimento perfecto; sí debe existir una hipótesis previa. Por ejemplo:

Creemos que esta solución reducirá el tiempo completo de resolución de incidencias sin aumentar reaperturas ni derivaciones.

Eso es mucho más útil que:

Vamos a introducir IA en soporte.

La hipótesis concreta qué debe cambiar y qué efectos secundarios hay que vigilar. La medición puede mostrar también que la intervención no ha mejorado el proceso.

Una iniciativa que no mejora también produce conocimiento

Esto último me parece importante. No todas las iniciativas de IA van a funcionar, y eso no debería convertirse automáticamente en un fracaso. Quizá descubramos que el coste de revisión elimina el ahorro, que la calidad no es suficiente, que una automatización tradicional funciona mejor, que el proceso no estaba suficientemente estandarizado, que los datos necesarios no existen, que las personas no confían en el resultado o que el problema real estaba en otra parte. Todo eso es información valiosa si el experimento estaba diseñado para aprender. El problema no es probar una iniciativa y descubrir que no produce valor. El problema es no tener mecanismos para descubrirlo.

Productividad sostenible, no productividad aparente

La IA permite producir determinados tipos de trabajo a una velocidad que hace pocos años habría parecido difícil de imaginar. Eso es real. Pero precisamente porque la capacidad de producción aumenta tan rápido, necesitamos ser más rigurosos al evaluar qué significa esa producción. No basta con preguntar cuánto más hacemos. Hay que observar la calidad, la revisión, el retrabajo y el coste total. También la deuda que se introduce, el desplazamiento del cuello de botella y el resultado final que mejora. La métrica más importante probablemente no será cuántas horas nos ha ahorrado la IA. Será más difícil de expresar en un cuadro de mando:

¿Estamos consiguiendo mejores resultados con los recursos disponibles sin trasladar un coste oculto al futuro o a otra parte del sistema? Para responder necesito comparar el resultado útil con la línea base e incluir el trabajo de quienes lo revisan, lo reciben y lo mantienen. Si todavía falta esa comprobación, producir más deprisa sigue siendo una señal parcial.