Medir el impacto de la IA en una empresa consiste en comprobar si cambia un resultado de negocio que ya importa, no solo si aumenta el uso de herramientas o la cantidad de contenido generado. Colleen Aubrey, vicepresidenta sénior de Applied AI Solutions en Amazon Web Services (AWS), defendió ese enfoque en una entrevista publicada el 6 de noviembre de 2026. Para evaluar mejor la contribución de la IA, conviene fijar una referencia y comparar tareas equivalentes con y sin ella cuando sea posible.
La diferencia importa porque contar consultas, tokens o líneas de código describe actividad, pero no indica por sí solo si la empresa obtuvo un mejor resultado. Una métrica de negocio, en cambio, sigue algo que la organización ya considera relevante, como el inventario.
Elige primero el resultado que quieres mejorar; después decide cómo comparar el trabajo con y sin IA.
Mide resultados de negocio, no actividad de IA
Aubrey recomienda partir de una métrica empresarial existente y observar si cambia al trabajar de otra manera. El uso de una herramienta puede ayudar a entender su adopción, pero no sustituye la medida del resultado que motivó el proyecto.
Define esa métrica y su valor de referencia antes de evaluar el cambio. Así podrás comparar el resultado posterior con una base concreta, en vez de tomar un aumento de uso o de producción como señal suficiente de valor.
Compara tareas equivalentes para evaluar la contribución de la IA
IBM describe un método de comparación en el que grupos de usuarios con características similares realizan el mismo proyecto: uno utiliza IA y el otro trabaja con métodos tradicionales. IBM compara velocidad, calidad, coste y precisión. La idea es mirar varias dimensiones del resultado, no solo cuánto tarda la primera versión.
También recomienda tener en cuenta la experiencia de cada persona en la tarea concreta, su adaptación a la herramienta y cómo esta se integra con el resto del trabajo. Si los grupos o las tareas difieren demasiado, sus resultados serán más difíciles de interpretar. El método descrito por IBM es una orientación para diseñar una evaluación; no es el procedimiento atribuido a los ejemplos de AWS.
Qué muestran los ejemplos reportados de AWS
En la entrevista, Aubrey atribuyó a un caso de Wells Vehicle Electronics una reducción del 7 % del inventario durante tres meses, mientras el número de referencias monitorizadas aumentó de 20 a 2.000. El dato conecta una métrica operativa con la escala de seguimiento, pero no describe por sí solo el diseño de medición.
Aubrey también dijo que la velocidad de despliegues a producción de su grupo se duplicó después de mejoras en la cobertura de pruebas y el estado de los pipelines. El resultado se refiere al grupo y a ese trabajo de ingeniería; no atribuye la mejora únicamente a un asistente de programación. Los dos casos son resultados comunicados en la entrevista, con sus ámbitos y periodos descritos allí.
En desarrollo de software, mide todo el ciclo
Para los equipos de software, GitLab aconseja evaluar el ciclo de vida del desarrollo de software (SDLC, por sus siglas en inglés), desde la planificación hasta la entrega y el mantenimiento. La velocidad de generación de código no recoge por sí sola el tiempo que puede hacer falta después para revisar, probar o mantener ese código, ni el trabajo relacionado con la seguridad.
| Ámbito | Medidas o dimensiones | Alcance |
| Tareas empresariales comparables | Velocidad, calidad, coste y precisión | Dimensiones que IBM describe para comparar grupos que realizan el mismo proyecto con y sin IA. |
| Entrega de software | Frecuencia de despliegue, tiempo de entrega de cambios, tiempo medio de recuperación, tasa de fallos de cambios y fiabilidad | Métricas DORA que GitLab cita para equipos de software; no son indicadores universales para cualquier proyecto de IA. |
Las métricas DORA describen aspectos de la entrega de software. Para valorar el efecto de la IA, GitLab también recomienda considerar la calidad, la seguridad y el esfuerzo posterior de revisión, pruebas y mantenimiento. Son dimensiones que pueden desplazar trabajo dentro del ciclo de desarrollo, aunque el primer borrador llegue antes.
IBM describe una comparación de asistentes de programación en la que algunos equipos produjeron menos líneas de código para obtener el mismo resultado. Por eso, contar líneas no basta para saber si un equipo produjo más valor: el resultado y el trabajo necesario para mantenerlo también cuentan.