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 llegar rápidamente a la misma conclusión: hemos aumentado la productividad. Puede que sí. Pero todavía no lo sabemos. 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

El primer problema es que utilizamos la palabra productividad para describir cosas diferentes. A veces queremos decir velocidad. Otras veces hablamos de volumen. En ocasiones hablamos de ahorro. Y otras de capacidad. No son exactamente lo mismo. Si una persona pasa de preparar cinco documentos semanales a preparar diez, ha aumentado su producción. Si tarda la mitad en preparar cada uno, ha reducido el tiempo de ejecución. Si podemos realizar el mismo trabajo con menos recursos, hemos mejorado la eficiencia. Si gracias a la IA podemos abordar una actividad que antes no era viable económicamente, hemos aumentado nuestra capacidad. Y si todo eso termina produciendo mejores resultados para la organización, empezamos a hablar de valor.

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 desarrollo de software muestra muy bien el problema

En ingeniería de software esta diferencia resulta especialmente visible. Podemos medir el código generado, las sugerencias aceptadas, las solicitudes de integración completadas y el tiempo de implementación. Todas esas métricas pueden mostrar una mejora y, al mismo tiempo, ocultar un deterioro del sistema. Pueden crecer el tamaño de los cambios, el tiempo de revisión, el retrabajo y los defectos posteriores. También puede aumentar algo mucho más difícil de observar de inmediato: la deuda técnica. Este último punto me parece especialmente importante. La IA puede reducir espectacularmente el coste de producir código.

Pero no reduce necesariamente en la misma proporción el coste de comprenderlo, revisarlo, mantenerlo y evolucionarlo. De hecho, podemos llegar a una situación paradójica: producimos software más rápido de lo que somos capaces de comprenderlo. Durante un tiempo, las métricas pueden parecer excelentes: más funcionalidades, más entregas y más velocidad. Meses después aparecen las consecuencias. El sistema resulta más difícil de modificar, las regresiones aumentan, las revisiones se vuelven más complejas y los desarrolladores necesitan más tiempo para comprender código que técnicamente funciona. La productividad inicial se ha financiado parcialmente con un coste futuro. Si únicamente medimos velocidad de entrega, nunca veremos 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. 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.

Porque ahora sabemos qué esperamos que cambie y qué efectos secundarios debemos vigilar. Después medimos. Y aceptamos también la posibilidad de descubrir que nuestra hipótesis era incorrecta.

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? Si la respuesta es sí, estaremos hablando de productividad real. Si todavía no podemos responderla, quizá lo único que sepamos con certeza es que ahora somos capaces de producir más deprisa. Y no son la misma cosa. La evaluación debe mostrar si la organización mide productividad y resultados o se limita a observar adopción, uso y tiempo aparentemente ahorrado.