Tres errors que frenen el ROI en projectes d'IA (i com evitar-los)

Un proyecto de IA puede parecer rentable y no haber demostrado todavía retorno económico. Ocurre cuando convertimos horas teóricamente ahorradas en euros que la empresa nunca llega a capturar, dejamos fuera costes necesarios para operar la solución o atribuimos a la IA una mejora que también depende de otros cambios en proceso, personas o demanda.

El problema no es menor. Una automatización puede reducir de forma evidente el tiempo dedicado a una tarea y, aun así, ofrecer un retorno bastante inferior al esperado cuando añadimos integración, supervisión, consumo, mantenimiento y el trabajo necesario para que la nueva capacidad siga funcionando.

Por eso, para dirección, la pregunta útil no es simplemente “¿cuánto ahorro produce la IA?”. Es otra: “¿qué valor adicional podemos atribuir realmente al proyecto después de contabilizar todo lo que cuesta crearlo, operarlo y controlarlo?”.

En R&R llamaremos ROI defendible a un cálculo que puede explicarse ante dirección sin depender de supuestos ocultos: parte de una situación anterior conocida, diferencia beneficio potencial de beneficio realmente capturable, incorpora el coste total del proyecto y hace explícitas las hipótesis que todavía no se han podido observar.

No significa que el ROI tenga que conocerse con precisión absoluta antes de empezar. En un piloto siempre existirá incertidumbre. Significa que debemos saber qué parte estamos midiendo, qué parte estamos estimando y qué tendría que cumplirse para que la inversión compense.

1. Qué significa realmente ROI en un proyecto de IA

Buena parte de la confusión sobre el retorno de la inteligencia artificial aparece porque utilizamos la palabra ROI para describir cosas distintas. Una herramienta puede utilizarse mucho, producir más rápido, mejorar una tarea o incluso reducir un coste operativo sin que todas esas mejoras constituyan por sí mismas un retorno financiero atribuible al proyecto.

El ROI es una relación económica: compara el beneficio neto generado por una inversión con el coste necesario para obtenerlo. Por tanto, antes de calcularlo necesitamos saber qué resultado ha cambiado, qué valor económico tiene ese cambio y qué parte puede atribuirse razonablemente a la nueva capacidad.

1.1. Actividad, output, resultado e impacto económico no son lo mismo

Un proyecto puede mostrar señales positivas mucho antes de haber demostrado retorno. De hecho, conviene que las muestre: adopción, velocidad o calidad son indicadores útiles para saber si la solución está funcionando. El error empieza cuando utilizamos esas señales como sustituto de la consecuencia económica final.

Un proyecto puede tener mucha adopción y poco ROI. También puede tener poco volumen y generar un retorno excelente si actúa sobre una tarea pequeña pero económicamente importante.

1.2. El problema de medir demasiado pronto

Durante un piloto es normal trabajar con indicadores intermedios. No tendría sentido esperar doce meses para saber si una automatización está reduciendo el tiempo de una tarea o si un asistente comercial mejora la preparación de determinadas interacciones. Esas métricas sirven para decidir si merece la pena continuar.

Lo que debemos evitar es convertir una señal temprana en una conclusión económica definitiva. Una reducción de tiempo observada durante dos semanas puede degradarse cuando aumenta el volumen, aparecen excepciones, cambian los usuarios o incorporamos todos los controles necesarios para operar en producción.

El IBM Institute for Business Value encontró una señal parecida en su estudio de 2025 con 2.000 CEOs de 33 países: los encuestados indicaron que solo el 25 % de las iniciativas de IA había entregado el ROI esperado y solo el 16 % se había escalado a toda la empresa. De nuevo, la cifra no debe trasladarse mecánicamente a una pyme concreta, pero sí refuerza una conclusión útil: experimentar, escalar y obtener el retorno previsto son etapas diferentes.

Fuente: IBM Institute for Business Value · 2025 CEO Study

1.3. Qué significa que un ROI sea “defendible”

En R&R utilizamos la expresión ROI defendible para distinguir una estimación comercial o exploratoria de una evaluación que puede sostener una decisión de inversión.

Un ROI defendible no exige conocer el futuro. Exige que dirección pueda reconstruir el razonamiento: de dónde sale la baseline, qué mejora se ha observado, cómo se convierte esa mejora en valor, qué parte podemos atribuir al proyecto, qué costes estamos incorporando y qué hipótesis siguen abiertas.

1.4. El ROI no debe utilizarse para justificar una decisión ya tomada

Existe otra distorsión frecuente: construir el business case después de haber decidido qué herramienta queremos implantar. En ese momento el cálculo deja de funcionar como criterio y empieza a convertirse en una justificación.

El orden debería ser el contrario. Primero identificamos qué resultado empresarial merece mejorar, después estimamos qué valor tendría hacerlo, calculamos qué coste podemos asumir y finalmente comprobamos si la IA ofrece una forma suficientemente buena de intervenir.

Con esta base ya podemos entrar en los tres errores que más deforman la lectura económica. El primero es especialmente común porque parece intuitivo: convertir toda mejora operativa, y especialmente todo tiempo aparentemente ahorrado, en beneficio económico.

2. Error 1: convertir actividad o ahorro aparente en beneficio económico

El primer error aparece antes incluso de introducir costes en la ecuación: dar por hecho que toda mejora operativa tiene el mismo valor económico que la mejora que somos capaces de medir.

Es especialmente frecuente con el tiempo. Si una tarea que antes requería diez horas pasa a necesitar seis, parece razonable afirmar que hemos “ahorrado cuatro horas”. Como medida operativa puede ser correcto. Como beneficio financiero, todavía no sabemos suficiente.

Esas cuatro horas pueden convertirse en coste evitado, en capacidad para absorber más trabajo, en tiempo dedicado a una actividad de mayor valor o simplemente en una holgura que la organización no utiliza de forma distinta. El mismo ahorro de tiempo puede producir consecuencias económicas completamente diferentes.

2.1. Tiempo liberado no es lo mismo que coste eliminado

Supongamos que cinco personas liberan dos horas semanales gracias a una nueva automatización. Podemos valorar ese tiempo utilizando su coste laboral y obtener rápidamente una cifra anual. Ese cálculo puede ser útil como valor de capacidad liberada, pero sería incorrecto presentarlo automáticamente como reducción de costes.

La nómina seguirá siendo la misma salvo que la empresa pueda capturar esa mejora mediante algún mecanismo concreto. Por ejemplo:

2.2. De ahorro potencial a ahorro capturable

Esta distinción permite introducir una variable que suele faltar en los business cases de IA: la capturabilidad.

En este artículo utilizaremos ese término para describir qué parte de una mejora operativa puede convertirse realmente en una consecuencia económica útil para la empresa. No es una tasa universal ni un porcentaje estándar. Debe estimarse para cada caso.

Si una automatización libera 1.000 horas al año, no deberíamos valorar automáticamente las 1.000 horas al coste laboral correspondiente. Primero necesitamos entender su distribución.

Liberar 20 minutos diarios repartidos entre 80 personas puede tener un valor muy distinto a liberar 1.000 horas concentradas en un cuello de botella operativo que obliga regularmente a contratar apoyo externo.

2.3. La mejora de productividad tampoco garantiza por sí sola ROI

Productividad y retorno están relacionados, pero tampoco son equivalentes. Una persona puede producir el mismo trabajo en menos tiempo o producir más en la misma jornada. Ambas cosas son valiosas. Sin embargo, para incorporarlas al ROI debemos identificar qué consecuencia económica produce esa nueva capacidad.

Los datos de la OCDE sobre uso de IA generativa en pymes muestran bien por qué conviene mantener esta separación. En su encuesta de 2024 a 5.232 pymes de hasta 249 empleados de siete países —Austria, Canadá, Alemania, Irlanda, Japón, Corea y Reino Unido; España no estaba incluida—, entre las empresas usuarias de IA generativa un 32,7 % declaró una reducción de la carga de trabajo, un 11,8 % un aumento i un 54,8 % ningún cambio. La propia OCDE advierte que estos resultados no permiten convertir la variación de carga directamente en ahorro financiero ni establecer por sí solos causalidad.

Font: OECD · Generative AI and the SME Workforce

Es una distinción especialmente relevante para una pyme. Reducir carga puede permitir trabajar mejor, reducir saturación o recuperar capacidad de dirección sin que exista una partida presupuestaria que desaparezca al día siguiente. Ese valor puede ser real; simplemente no debemos llamarlo ahorro de costes si no estamos eliminando o evitando un coste.

A On la IA sí que estalvia temps (i on no) desarrollamos específicamente cómo medir el temps fins a sortida vàlida y cuándo una reducción de tiempo sobrevive a preparación, revisión, corrección y retrabajo. Aquí damos el paso siguiente: convertir esa mejora operativa en una variable económica defendible.

2.4. Ingresos adicionales: el problema de la atribución

El mismo cuidado es necesario cuando el beneficio esperado no procede de costes, sino de ingresos. Es fácil construir un business case en el que una nueva capacidad de IA “genera” más oportunidades, mejora conversión o incrementa ventas. Lo difícil es demostrar qué parte de esa variación procede realmente del proyecto.

Imaginemos que un equipo comercial incorpora IA para preparar reuniones, priorizar cuentas y personalizar seguimientos. Tres meses después, la tasa de conversión mejora. Esa variación puede estar relacionada con el proyecto, pero también con:

• cambios en precios o propuesta de valor;
• una cartera de oportunidades distinta;
• mejoras simultáneas en proceso comercial;
• mayor experiencia del equipo;
• estacionalidad o condiciones de mercado;
• otras acciones de marketing o ventas.

No necesitamos un ensayo científico para tomar una decisión empresarial. Sí necesitamos evitar el extremo contrario: atribuir a la IA todo lo bueno que ocurre después de implantarla.

2.5. Una forma práctica de trabajar con atribución

En una pyme no siempre será posible aislar perfectamente el efecto causal de una iniciativa. Podemos, sin embargo, aumentar mucho la calidad de la evaluación si establecemos antes del piloto:

• una baseline temporal suficientemente representativa;
• la variable concreta que esperamos mover;
• qué otras iniciativas pueden modificarla durante el mismo período;
• un grupo, proceso o período de comparación cuando sea viable;
• y un rango de atribución prudente si no podemos aislar completamente el efecto.

Por ejemplo, si una mejora de margen representa 40.000 € pero existen varios cambios simultáneos, puede ser más defendible trabajar con escenarios en los que atribuimos al proyecto de IA una parte del resultado que adjudicarle los 40.000 € completos.

2.6. Reducción de errores y retrabajo también puede crear valor

No todo el beneficio tiene que proceder de horas o ingresos. Un proyecto también puede generar retorno reduciendo errores, repeticiones, devoluciones, incidencias o fallos de proceso.

En estos casos la valoración debe partir, de nuevo, de una baseline. Si sabemos cuántos errores se producen, cuánto cuesta resolverlos y qué reducción se observa después del cambio, podemos estimar el coste evitado.

Conviene incluir también el efecto contrario. Si la nueva solución introduce errores distintos o exige más revisión humana para detectarlos, esa carga debe descontarse. Un proyecto no crea valor porque elimine una hora de trabajo manual si añade otra hora de validación o corrección.

2.7. Las tres preguntas que cierran el primer error

Cuando estas tres respuestas son explícitas, el numerador del ROI empieza a ser defendible. Pero todavía falta la otra mitad de la ecuación.

Y es aquí donde aparece el segundo error: comparar todo ese beneficio con el precio de la herramienta en lugar de con el coste real de construir y mantener la capacidad.

3. Error 2: calcular el retorno sin incorporar el coste total del proyecto

El segundo error suele hacer que el denominador sea demasiado pequeño. Comparamos el beneficio esperado con la licencia, el coste de una API o la factura inicial del proveedor y llamamos a esa relación ROI.

Pero una herramienta no es lo mismo que una capacidad operativa. Para que una solución de IA funcione dentro de una empresa puede ser necesario preparar datos, integrarla con otros sistemas, diseñar controles, formar usuarios, revisar resultados, mantener flujos y actualizarla cuando cambian procesos, modelos o proveedores.

Algunos proyectos serán muy simples y tendrán pocos costes adicionales. Otros no. El criterio no consiste en inflar artificialmente el presupuesto, sino en hacer visible qué recursos necesita realmente la solución durante el horizonte que estamos evaluando.

3.1. Precio de herramienta y coste del proyecto son magnitudes diferentes

Una suscripción de 30 € al mes puede habilitar un caso de uso muy rentable. También puede suceder que una licencia aparentemente barata requiera decenas de horas de configuración, revisión periódica, acceso a datos y mantenimiento.

Por eso, para evaluar el retorno, necesitamos trabajar con una visión de coste total de propiedad o TCO durante un período definido.

3.2. Siete capas de coste que conviene revisar

3.3. Los costes iniciales y los recurrentes deben separarse

No todos estos costes se comportan igual. Algunos aparecen principalmente al principio: diagnóstico, configuración, integración inicial o formación. Otros continúan durante la vida del sistema: licencias, consumo, supervisión, mantenimiento o actualización.

Esta distinción importa porque el resultado del ROI depende del horizonte temporal. Un proyecto con una inversión inicial importante puede ofrecer un ROI mediocre durante tres meses y muy bueno durante dos años si los beneficios son recurrentes y el coste operativo permanece controlado.

También puede ocurrir lo contrario: un piloto barato parece extraordinariamente rentable, pero su coste crece al llevarlo a producción porque aparecen integraciones, controles y mantenimiento que el experimento inicial no necesitaba.

3.4. La supervisión humana no es un detalle gratuito

En determinados casos, revisar la salida forma parte del diseño correcto del sistema. No es necesariamente una ineficiencia: puede ser el control que permite utilizar IA en un proceso donde el coste de un error es significativo.

Pero económicamente esa supervisión existe. Si una persona debe revisar diez minutos cada resultado generado, ese tiempo forma parte del coste de operación y debe compararse con el tiempo que habría requerido realizar la tarea de otra forma.

El marco AI RMF de NIST insiste precisamente en tratar evaluación, monitorización, roles de responsabilidad y revisión como elementos del ciclo de vida del sistema, no como una actividad que termina cuando se despliega la tecnología. En su perfil específico para IA generativa, NIST contempla además monitorización en producción e intervención humana ante determinadas desviaciones.

Fuente: NIST · AI Risk Management Framework: Generative Artificial Intelligence Profile

Esto no significa que todas las pymes necesiten construir una estructura compleja de gobierno. Significa que el nivel de control debe ser proporcional al caso de uso y que el coste de ese control forma parte de su economía.

3.5. Datos e integración pueden cambiar completamente el business case

Algunos casos funcionan con información que el usuario ya tiene disponible y apenas necesitan integración. Otros requieren acceder a CRM, ERP, documentación, expedientes, catálogos, históricos o sistemas internos.

En esos proyectos, el coste no está únicamente en “conectar una API”. Puede haber información duplicada, campos sin mantener, permisos inconsistentes, documentos incompatibles o reglas de negocio que nunca se habían formalizado porque hasta entonces residían en la experiencia de determinadas personas.

La IA no crea ese problema, pero puede hacerlo visible. Y si necesitamos resolverlo para que el proyecto funcione, debemos decidir con criterio qué parte del coste pertenece realmente al caso de IA y qué parte corresponde a una deuda operativa o tecnológica que la empresa necesitaba resolver de todas formas.

3.6. El coste puede cambiar cuando aumenta el volumen

Uno de los motivos por los que el ROI de un piloto no siempre sobrevive al escalado es que varias variables cambian simultáneamente.

Puede crecer:

• el consumo de modelos o infraestructura;
• el número de integraciones;
• la cantidad de excepciones;
• la necesidad de soporte;
• el volumen de revisión;
• las exigencias de seguridad y trazabilidad;
• y el coste de mantener conocimiento, instrucciones o datos actualizados.

A la vez, también pueden aparecer economías de escala: una integración inicial puede utilizarse para miles de operaciones, una base de conocimiento puede servir a varios equipos y un coste de implantación puede diluirse conforme aumenta el volumen.

Por eso no es suficiente afirmar que “si funciona para 100 casos funcionará diez veces mejor para 1.000”. El modelo económico debe identificar qué costes son fijos, cuáles crecen con el uso y cuáles aparecen únicamente cuando elevamos el nivel de exigencia del sistema.

3.7. Qué no debería entrar automáticamente en el TCO

El objetivo tampoco es convertir cada proyecto en un ejercicio contable imposible. Hay costes que pueden existir alrededor de una iniciativa pero no ser materiales o incrementales.

Por ejemplo, si una persona dedica quince minutos en una reunión mensual ya existente a revisar un indicador del proyecto, puede que cuantificar esa fracción de salario añada una precisión ficticia.

En cambio, si dos personas deben dedicar seis horas semanales a validar resultados, ese coste difícilmente puede ignorarse.

3.8. La prueba del denominador

Después de los dos primeros errores, ya tenemos las dos piezas básicas del cálculo: un beneficio que intentamos hacer atribuible y capturable y un coste que intenta representar el TCO real.

Todavía queda una distorsión importante: convertir esas estimaciones iniciales en una certeza y escalar antes de haber comprobado si el modelo económico sobrevive al funcionamiento real.

4. Error 3: escalar un ROI que todavía no está demostrado

El tercer error aparece cuando un piloto ofrece buenas señales y convertimos esas señales en una conclusión demasiado pronto. La automatización funciona, los usuarios responden bien, el tiempo de una tarea disminuye y el business case empieza a parecer evidente.

Ese es precisamente el momento en que más conviene separar potencial, evidencia y decisión. Un piloto puede demostrar que una hipótesis merece continuar sin haber demostrado todavía cuál será el ROI cuando el sistema funcione con más usuarios, más volumen, más excepciones y controles propios de producción.

La evidencia empresarial reciente muestra precisamente esa distancia entre prueba y escala. En la encuesta global de McKinsey publicada en 2025, casi dos tercios de las organizaciones consultadas todavía no habían empezado a escalar IA en toda la empresa, y solo un 39 % declaraba impacto de IA sobre EBIT a nivel empresarial. Son organizaciones de tamaños y sectores diversos, no una estimación específica para pymes, pero la señal es útil: experimentar, escalar y capturar impacto económico son etapas distintas.

Fuente: McKinsey · The state of AI in 2025: Agents, innovation, and transformation

4.1. ROI estimado, observado y demostrado no son lo mismo

Una de las mejoras más sencillas que puede introducir dirección es dejar de presentar todas las cifras de retorno con el mismo grado de certeza.

No tiene el mismo significado afirmar que “esperamos ahorrar 400 horas al año” que decir “durante ocho semanas hemos observado una reducción media de 35 minutos por caso sobre 180 operaciones reales”.

Ambas cifras pueden ser útiles. Lo que cambia es el tipo de evidencia que contienen.

Esta clasificación evita una práctica habitual: presentar el ROI estimado del business case como si ya fuese una consecuencia económica obtenida.

El problema no es utilizar estimaciones. Toda decisión de inversión contiene supuestos sobre el futuro. El problema aparece cuando dejamos de distinguir qué sabemos y qué necesitamos que ocurra.

4.2. El piloto tiene una economía distinta a la operación real

Un piloto está diseñado precisamente para reducir complejidad. Puede trabajar con pocos usuarios, una parte del proceso, un conjunto limitado de documentos o un número reducido de excepciones.

Esa reducción es útil porque permite aprender más rápido. Pero también significa que los costes y beneficios observados durante el piloto no deben extrapolarse automáticamente.

Al pasar a producción pueden aparecer costes que el experimento no necesitaba:

• nuevos perfiles de usuario con comportamientos menos homogéneos;
• más casos excepcionales;
• mayores requisitos de seguridad, acceso y trazabilidad;
• integraciones adicionales;
• soporte y gestión de incidencias;
• necesidad de documentar y mantener procedimientos;
• más supervisión o controles de calidad;
• costes variables ligados al volumen de uso.

También puede suceder lo contrario. Una inversión inicial elevada puede diluirse cuando el mismo sistema procesa más operaciones o sirve a varios equipos.

Por eso la pregunta correcta antes de escalar no es:

“¿Funcionó el piloto?”

sino:

“¿Qué parte de la economía observada durante el piloto seguirá siendo cierta cuando cambiemos volumen, usuarios y condiciones de operación?”

4.3. El error de extrapolar linealmente

Supongamos que una prueba con 100 operaciones permite ahorrar 20 horas. Multiplicar automáticamente ese resultado por diez para estimar 200 horas en 1.000 operaciones puede ser razonable como primera hipótesis, pero no como conclusión.

La relación puede dejar de ser lineal porque:

• las operaciones adicionales son más complejas;
• aumenta la proporción de excepciones;
• la revisión humana no escala al mismo ritmo que la generación;
• la calidad cambia con nuevos tipos de entrada;
• el coste tecnológico depende del consumo;
• o la organización no consigue capturar toda la capacidad adicional.

También podemos encontrar economías favorables: procesos más estandarizados, reutilización de infraestructura, aprendizaje de usuarios o reducción del coste unitario.

Lo importante es que el escalado no se base en una regla de tres invisible.

4.4. El ROI puede empeorar incluso cuando la tecnología mejora

Parece contradictorio, pero una solución técnicamente mejor no garantiza un retorno mayor.

Una versión posterior puede producir respuestas más completas y, al mismo tiempo, utilizar más recursos, aumentar latencia, requerir mayor infraestructura o provocar que los usuarios deleguen tareas que antes resolvían de forma muy rápida.

También puede suceder que, al comprobar que una tecnología funciona, la empresa amplíe el alcance: más departamentos, más integraciones, más datos, más procesos.

El proyecto genera más capacidad, pero el objeto económico ya no es el mismo que el del piloto inicial.

4.5. Qué debería demostrar un piloto antes de escalar

No todos los casos necesitan el mismo nivel de evidencia. Una automatización reversible, barata y de bajo riesgo puede escalar con menos comprobaciones que un sistema integrado en un proceso crítico.

Como criterio general, antes de incrementar de forma material la inversión conviene haber reducido incertidumbre sobre cinco cuestiones:

4.6. Escalar no debería ser la única salida posible

Otra señal de un mal business case es que el piloto parece tener una única conclusión aceptable: escalar.

Una prueba bien gobernada debería poder terminar al menos en cuatro decisiones:

Escalar, ajustar, mantener limitado o parar son cuatro resultados legítimos. Volveremos a ellos al final del artículo, cuando podamos combinar evidencia, economía, operabilidad y riesgo sin duplicar aquí esa decisión.

Esta lógica conecta directamente con la implantación: en Implantar IA en empresas: por qué falla y qué revisar desarrollamos los problemas de proceso, gobernanza, datos y operación que pueden impedir que una solución llegue de piloto a producción.

En esta página nos quedamos deliberadamente en la frontera económica: cuándo la evidencia disponible permite comprometer más inversión.

4.7. La regla que cierra el tercer error

5. Cómo calcular un ROI defendible en un proyecto de IA

Después de corregir los tres errores, podemos construir el cálculo. La fórmula matemática es sencilla. Lo difícil es decidir qué cifras merecen entrar en ella.

Para este artículo utilizaremos:

La fórmula no es distinta de la lógica básica de cualquier ROI. Lo que cambia es el rigor con el que construimos numerador y denominador.

5.1. Paso 1 · Fijar la baseline

No podemos demostrar mejora si no sabemos razonablemente qué ocurría antes.

La baseline no tiene que ser perfecta. Debe ser suficientemente representativa para comparar el resultado posterior.

Según el caso puede incluir:

• tiempo medio por operación;
• volumen procesado;
• coste unitario;
• errores o incidencias;
• retrabajo;
• tasa de conversión;
• necesidad de soporte externo;
• backlog;
• capacidad máxima antes de ampliar estructura.

Si el proceso es muy variable, una semana aislada puede ser una mala referencia. Conviene utilizar un período que capture variación normal, estacionalidad y excepciones relevantes.

5.2. Paso 2 · Elegir la unidad económica que queremos mover

El proyecto necesita una conexión explícita entre mejora operativa y negocio.

No todos los casos deberían medirse exclusivamente en horas. Dependiendo del proceso, la unidad relevante puede ser:

• coste por operación;
• coste por expediente;
• margen por transacción;
• coste de una incidencia;
• horas de capacidad crítica;
• volumen adicional absorbible;
• contratación evitada;
• ingresos incrementales;
• o una combinación de varias fuentes.

Cuanto más directamente conectada esté la métrica con una decisión económica, menos transformaciones necesitaremos para llegar al ROI.

5.3. Paso 3 · Medir el delta operativo

Una vez definida la baseline, medimos la diferencia entre el proceso anterior y el nuevo proceso completo.

La palabra completo es importante. Si una IA genera una salida en treinta segundos pero después requiere ocho minutos de revisión y corrección, no deberíamos comparar treinta segundos contra el tiempo anterior.

Debemos comparar:

Esa lógica es la misma que desarrollamos con mayor profundidad en On la IA sí que estalvia temps (i on no) .

5.4. Paso 4 · Aplicar capturabilidad

El delta operativo nos indica qué ha mejorado. Todavía necesitamos determinar qué parte de esa mejora genera valor económico.

Aquí conviene evitar un único “porcentaje estándar”. La capturabilidad depende de cómo se utiliza la capacidad liberada.

5.5. Paso 5 · Ajustar la atribución

Una vez sabemos qué valor podría capturarse, debemos evitar atribuir al proyecto una mejora que tiene múltiples causas.

En algunos procesos la conexión será muy directa. Por ejemplo, una automatización elimina una operación externa que costaba una cantidad conocida.

En otros, como ventas, productividad directiva o mejora de decisiones, la atribución será necesariamente menos precisa.

Podemos trabajar entonces con:

• comparación antes/después;
• períodos equivalentes;
• grupos comparables;
• cohortes de usuarios;
• análisis de cambios simultáneos;
• o rangos prudentes de atribución.

La precisión absoluta no siempre será posible. La transparencia sobre el supuesto sí.

5.6. Paso 6 · Construir el TCO

Ahora incorporamos el denominador trabajado en el segundo error.

Para el horizonte seleccionado, sumamos los costes materiales:

No todas las partidas existirán en todos los proyectos. El objetivo es representar la economía real del caso, no completar una plantilla por obligación.

5.7. Paso 7 · Elegir horizonte y escenarios

Un ROI sin período de referencia puede ser engañoso.

Una inversión inicial de 20.000 € puede parecer muy distinta si la evaluamos sobre tres meses, doce meses o tres años.

El horizonte debería corresponder con una duración razonable de la decisión: suficientemente largo para capturar beneficios recurrentes, pero no tanto como para fingir que conocemos variables que pueden cambiar materialmente.

En IA esta precaución es especialmente importante porque modelos, precios, proveedores y capacidades tecnológicas pueden evolucionar con rapidez.

Cuando existe incertidumbre relevante, es preferible construir varios escenarios que esconderla dentro de una única cifra. Más adelante veremos cómo utilizar un escenario conservador, uno base y uno favorable, y cómo localizar el punto de ruptura que puede cambiar la decisión.

5.8. La fórmula final

Cuando ya disponemos de las variables anteriores, podemos realizar el cálculo:

Supongamos, por ejemplo, que durante un año estimamos 30.000 € de valor económico atribuible y capturable y un TCO de 12.000 €.

El beneficio neto sería:

Y el ROI:

Esa cifra solo es tan buena como las variables que la sostienen. Si los 30.000 € proceden de una estimación excesivamente optimista, el cálculo matemático seguirá siendo correcto y la decisión empresarial será mala.

La fórmula rara vez es el problema. El problema son los supuestos que escondemos dentro de ella.

5.9. Una hoja de ROI debería mostrar algo más que el porcentaje final

Para dirección, una hoja que solo devuelve “ROI = 150 %” contiene poca información.

Como mínimo debería permitir reconstruir:

• baseline utilizada;
• mejora operativa observada o estimada;
• valor económico bruto;
• porcentaje o criterio de capturabilidad;
• criterio de atribución;
• costes iniciales;
• costes recurrentes;
• horizonte;
• volumen esperado;
• escenario;
• ROI resultante;
• y las principales hipótesis pendientes.

Así el business case deja de ser una cifra aislada y se convierte en un modelo que podemos revisar conforme obtenemos nueva evidencia.

5.10. La calculadora es útil si entendemos qué estamos introduciendo

R&R dispone de una calculadora bàsica de ROI que permite realizar una primera estimación de retorno y punto de equilibrio.

Es útil como aproximación inicial, especialmente en casos sencillos. Pero ninguna calculadora puede decidir por nosotros si una hora liberada es realmente capturable, qué parte de una mejora debemos atribuir a la IA o qué costes incrementales son materiales.

Esas decisiones pertenecen al análisis del caso, no a la aritmética.

5.11. La prueba final del ROI defendible

Hasta aquí hemos construido el método. El siguiente paso es aplicarlo a un caso concreto para comprobar cuánto puede cambiar el resultado cuando pasamos del ROI aparente al ROI defendible.

6. Del ROI aparente al ROI defendible: un ejemplo completo

Hasta aquí hemos separado las piezas del cálculo. Veamos ahora qué ocurre cuando las aplicamos al mismo proyecto.

El ejemplo es completamente ilustrativo. No representa un benchmark de mercado, un caso de cliente ni una expectativa de retorno. Su función es mostrar cómo puede cambiar una decisión cuando dejamos de utilizar únicamente horas teóricamente ahorradas y precio de herramienta.

6.1. El caso de partida

Imaginemos una pyme que automatiza parte de un proceso recurrente de reporting. Antes del proyecto, preparar, revisar y cerrar esos informes consume unas 90 horas mensuales distribuidas entre varias personas.

Tras implantar la nueva solución, el proceso completo —incluyendo preparación, uso de IA, revisión, excepciones y corrección— requiere 38 horas mensuales.

La mejora operativa observada sería:

Para hacer visible la lógica económica, supongamos además un coste interno de 32 €/hora.

6.2. El cálculo rápido: un ROI del 824 %

El cálculo más tentador sería:

Supongamos que la licencia y el consumo tecnológico cuestan 180 € al mes:

Si utilizáramos exclusivamente esas dos cifras:

La aritmética es correcta. El modelo económico no.

Hemos supuesto simultáneamente que todas las horas liberadas tienen valor económico íntegro para la empresa y que el único coste necesario para producir ese beneficio es la tecnología.

Ninguna de esas dos premisas ha sido demostrada todavía.

6.3. Primer ajuste: no todas las horas son capturables

Analizando cómo se distribuyen las 52 horas mensuales, la empresa concluye —para este ejemplo— que puede aprovechar económicamente alrededor del 65 %.

El resto corresponde a pequeñas fracciones dispersas, holguras difíciles de reasignar o tiempo que mejora la comodidad operativa pero no modifica de forma material la capacidad o el coste.

Obsérvese que no estamos afirmando que el 65 % sea una regla recomendable. Es un supuesto específico del ejemplo. En otro proyecto podría ser 20 %, 90 % o no tener sentido expresarlo como porcentaje.

6.4. Segundo ajuste: tampoco atribuimos el 100 % de la mejora a la IA

Durante el mismo período, el equipo también ha simplificado algunos pasos del proceso. Por tanto, sería difícil defender que toda la mejora procede exclusivamente de la nueva solución.

Para el escenario base del ejemplo, asignamos un 90 % de atribución al proyecto.

Ya hemos pasado de 19.968 € de ahorro aparente a 11.681,28 € de valor que estamos dispuestos a incorporar al business case.

6.5. Tercer ajuste: construir el TCO

Ahora incorporamos los costes materiales del primer año.

La revisión ordinaria de cada informe ya está incluida en las 38 horas mensuales del nuevo proceso. La partida de 2.400 € representa únicamente mantenimiento, seguimiento y control adicionales que quedan fuera de ese ciclo operativo, para evitar contabilizar dos veces el mismo esfuerzo.

6.6. El ROI defendible cambia radicalmente

Ahora sí podemos aplicar el modelo construido en el bloque anterior:

Hemos pasado de un supuesto 824 % de ROI a un 5,6 % durante el primer año.

La tecnología no ha empeorado. El ahorro operativo tampoco ha desaparecido. Lo único que hemos hecho es cambiar la calidad del modelo económico.

6.7. ¿Significa eso que el proyecto ya no merece la pena?

No necesariamente. Ese sería otro error.

El 5,6 % corresponde al primer año, que soporta varios costes iniciales que no tienen por qué repetirse con la misma intensidad.

En nuestro ejemplo, diseño, integración inicial y formación representan:

Mientras que los costes recurrentes que hemos supuesto son:

Si el beneficio observado se mantuviera en un segundo año y no aparecieran nuevos costes materiales, la economía sería distinta.

Eso no significa que debamos proyectar indefinidamente el mismo beneficio. Significa que ROI del primer año, economía recurrente y retorno acumulado son perspectivas distintas.

6.8. El ejemplo también muestra por qué una cifra aislada dice poco

Imaginemos dos presentaciones ante un comité de dirección.

La segunda cifra es mucho menos espectacular. También es muchísimo más útil para decidir.

6.9. Qué aprenderíamos del piloto

El ejemplo tampoco debería cerrarse con un simple “sí” o “no”. Ahora sabemos exactamente qué variables gobiernan el resultado.

• La solución libera 52 horas mensuales.
• La decisión depende mucho de cuánto de ese tiempo consigue capturar realmente la organización.
• Los costes iniciales pesan de forma importante durante el primer año.
• Si el beneficio persiste, la economía recurrente puede mejorar de forma material.
• Antes de escalar, merece la pena validar si capturabilidad, volumen y coste de supervisión se mantienen.

Hemos convertido así el cálculo de ROI en algo más útil: un mapa de las variables que podrían cambiar la decisión.

7. ROI no basta: payback, escenarios y sensibilidad

El ROI responde a una pregunta importante: cuánto valor obtenemos en relación con lo que invertimos.

Pero dirección suele necesitar al menos otras dos respuestas:

• ¿cuánto tardaremos en recuperar la inversión inicial?
• ¿qué variables pueden hacer que el proyecto deje de compensar?

Ahí entran el payback i el análisis de sensibilidad.

7.1. ROI y payback miden cosas diferentes

Dos proyectos pueden tener un ROI parecido y exigir tiempos de recuperación completamente distintos.

Para una pyme, esa diferencia puede ser decisiva. Un proyecto muy rentable a tres años puede no ser prioritario si inmoviliza recursos durante demasiado tiempo o si existe mucha incertidumbre tecnológica.

El payback simple responde a:

En nuestro ejemplo debemos separar primero inversión inicial y coste recurrente.

Por tanto:

Esa información complementa al ROI del 5,6 % del primer año.

El proyecto apenas genera beneficio neto acumulado durante esos primeros doce meses, pero recupera aproximadamente la inversión inicial cerca del final del período.

7.2. El payback tampoco debería utilizarse solo

Recuperar rápido una inversión no significa necesariamente que sea la mejor inversión disponible.

Un proyecto puede tener un payback muy corto y después generar poco beneficio. Otro puede necesitar más tiempo para recuperar el desembolso inicial y producir mucho más valor acumulado.

Además, el payback simple tiene limitaciones:

• no describe qué ocurre después de recuperar la inversión;
• no incorpora por sí mismo el valor temporal del dinero;
• puede ocultar diferencias importantes de riesgo;
• y depende de que el beneficio periódico sea suficientemente estable.

Para inversiones grandes, horizontes largos o flujos de caja complejos, pueden ser necesarias métricas financieras adicionales. Para muchos proyectos operativos de IA en una pyme, sin embargo, ROI + payback + sensibilidad proporciona una lectura directiva bastante más útil que un único porcentaje.

7.3. La sensibilidad muestra dónde está realmente el riesgo

Volvamos al ejemplo. Una de las variables que más condiciona el resultado es la capturabilidad.

Mantenemos constantes:

• las 624 horas anuales liberadas;
• el coste de 32 €/hora;
• una atribución del 90 %;
• y el TCO anual de 11.060 €.

Cambiamos únicamente qué porcentaje del valor puede capturar la empresa.

El proyecto tecnológico es exactamente el mismo. Lo que cambia es la capacidad de la organización para convertir la mejora en valor útil.

En el escenario conservador, el proyecto pierde dinero durante el primer año. En el favorable, el ROI llega aproximadamente al 30 % y la inversión inicial se recupera en unos ocho meses.

Esta diferencia es mucho más informativa que añadir un decimal al cálculo del escenario base.

7.4. No todas las variables merecen tres escenarios

Podemos construir hojas con decenas de supuestos y terminar haciendo el modelo menos útil.

El criterio debería ser concentrarnos en variables que sean:

• suficientemente inciertas;
• económicamente materiales;
• y capaces de cambiar la decisión de inversión.

Dependiendo del proyecto, podrían ser:

7.5. El punto de equilibrio es otra pregunta útil

Además de calcular un escenario conservador y favorable, podemos invertir la lógica:

¿Qué tendría que ocurrir para que el proyecto dejara de perder dinero?

Esta pregunta convierte el business case en una condición operativa.

Podemos buscar, por ejemplo:

• cuántas operaciones mensuales necesitamos procesar;
• cuántas horas deben liberarse;
• qué capturabilidad mínima necesitamos alcanzar;
• cuánto puede crecer el coste recurrente;
• o qué reducción de errores hace rentable el proyecto.

De esta forma, en lugar de decir “esperamos un ROI del 20 %”, podemos formular una condición mucho más gobernable:

Esa formulación nos dice qué debemos observar después del despliegue.

7.6. El mejor escenario no debería ser el único que justifica el proyecto

Un business case es frágil cuando solo resulta atractivo si prácticamente todas las hipótesis salen bien.

Si necesitamos simultáneamente:

• adopción casi total;
• ahorro máximo;
• costes sin desviaciones;
• alta atribución;
• y ninguna degradación al escalar,

probablemente no estamos ante una inversión robusta, aunque el escenario favorable arroje un ROI espectacular.

Por el contrario, un proyecto cuyo escenario conservador sigue siendo razonable puede merecer prioridad aunque su máximo retorno potencial sea menor.

7.7. ROI, payback y sensibilidad responden a tres preguntas distintas

8. Qué hemos observado en R&R al medir valor con IA

Los marcos anteriores sirven para ordenar el cálculo. Pero trabajar con IA en procesos reales deja además una serie de aprendizajes que no aparecen cuando analizamos únicamente herramientas, licencias o demostraciones controladas.

Las observaciones de este bloque proceden de experiencia interna de R&R trabajando con automatización, reporting, análisis, desarrollo de herramientas y sistemas apoyados por IA. No son un estudio estadístico, no representan una media de mercado y no deberían interpretarse como una promesa de resultados para otras empresas.

8.1. Ahorrar tiempo y ahorrar dinero son dos resultados distintos

En determinadas rutinas de reporting hemos observado internamente reducciones de tiempo de hasta el 45 %. Es una mejora operativa material, pero no equivale por sí sola a una reducción de costes: el efecto económico depende de si esa capacidad permite absorber más trabajo, evitar apoyo externo, reducir acumulación o devolver tiempo útil a dirección.

8.2. Los casos pequeños pueden tener una economía excelente

Existe una tendencia natural a asociar retorno importante con proyectos grandes. En IA no tiene por qué ser así.

Un proceso muy acotado puede ofrecer una combinación especialmente favorable:

• frecuencia elevada;
• entradas bien definidas;
• resultado fácil de verificar;
• integración sencilla;
• bajo coste de error;
• y poco mantenimiento.

Aunque el beneficio absoluto no sea extraordinario, puede presentar un TCO bajo, un payback corto y una probabilidad elevada de mantener el resultado.

Al contrario, un proyecto ambicioso que promete transformar un proceso completo puede acumular suficientes dependencias, excepciones y costes de coordinación como para ofrecer peor economía.

El tamaño estratégico de una idea y la calidad económica de su primer caso de uso no son la misma cosa.

8.3. El ROI de una tarea no es el ROI de un sistema

Este aprendizaje es especialmente visible cuando pasamos de utilizar IA como asistencia individual a integrarla dentro de una herramienta o proceso empresarial.

Una determinada función puede ser extraordinariamente rápida: clasificar información, resumir documentos, proponer una respuesta o generar una primera versión.

Pero el sistema completo puede necesitar además:

• resolver identidad y permisos;
• conservar trazabilidad;
• gestionar estados;
• controlar versiones;
• validar resultados;
• integrar datos;
• resolver fallos;
• y mantener compatibilidad cuando cambian proveedores o procesos.

En desarrollo de herramientas propias lo hemos comprobado de forma recurrente: la IA puede acelerar mucho una pieza sin reducir en la misma proporción el tiempo necesario para conseguir un sistema completo, estable y gobernable.

No contradice el valor de la IA. Explica por qué medir solo la velocidad de una microtarea puede sobreestimar el ROI del producto o proceso completo.

8.4. La validación puede decidir la rentabilidad

Dos tareas aparentemente similares pueden tener economías muy distintas según cuánto cueste comprobar la salida. Si un profesional valida con rapidez, el ahorro puede sobrevivir; si debe volver a fuentes, reconstruir razonamiento o rehacer buena parte del trabajo, la ventaja puede desaparecer.

Esto conecta directamente con el concepto de temps fins a sortida vàlida desarrollado en On la IA sí que estalvia temps (i on no) .

Desde el punto de vista económico, la consecuencia es sencilla: el coste de validación forma parte de la unidad de producción.

8.5. La capacidad liberada puede tener valor aunque no reduzca plantilla

En una pyme, buena parte del valor no aparece en forma de una persona menos en nómina.

Puede aparecer como:

El error sería elegir una cifra monetaria arbitraria para cualquiera de esos beneficios solo porque necesitamos completar una hoja de ROI.

Cuando la monetización no es suficientemente defendible, es mejor mantener parte del resultado como métrica operativa complementaria que inventar una precisión financiera. Esta distinción entre herramienta y capacidad empresarial la desarrollamos también en Cómo ganar capacidad empresarial con IA sin aumentar estructura, coste ni dependencia .

8.6. Una buena arquitectura puede mejorar la economía con el tiempo

No todos los costes iniciales deberían interpretarse como una penalización.

Una integración, una estructura de datos, un sistema de permisos o una capacidad de monitorización pueden utilizarse después en otros casos.

Cuando esto ocurre, la empresa deja de financiar únicamente una automatización y empieza a construir capacidad reutilizable.

Pero conviene mantener el mismo rigor que hemos utilizado durante todo el artículo: no debemos atribuir al primer caso todos los beneficios hipotéticos que quizás genere esa infraestructura en el futuro.

Podemos reconocer su valor estratégico y, al mismo tiempo, calcular separadamente el ROI del proyecto concreto.

8.7. El ROI puede cambiar después de que el proyecto sea rentable

Un proyecto no queda económicamente “certificado para siempre” porque haya funcionado durante su primer año.

Pueden cambiar:

• precios de modelos y proveedores;
• volumen de uso;
• calidad de la salida;
• requisitos regulatorios;
• costes de supervisión;
• estructura del proceso;
• o incluso la alternativa contra la que estamos comparando.

Una solución que antes evitaba mucho trabajo puede perder parte de su ventaja si el proceso convencional también mejora.

Y una solución inicialmente marginal puede volverse muy atractiva si disminuyen costes, mejora el modelo o aumenta suficientemente el volumen.

8.8. La principal conclusión no es tecnológica

Todos estos aprendizajes apuntan hacia la misma dirección: la tecnología influye en el ROI, pero la organización determina cuánto de ese potencial consigue convertirse en valor.

Definición de tarea, calidad de datos, capacidad de integración, criterios de validación, disciplina para medir, adopción y capacidad para reasignar recursos pueden ser tan importantes como la elección del modelo.

9. Cuándo escalar, ajustar o parar

El objetivo final de medir ROI no es producir un porcentaje. Es mejorar una decisión.

Una vez conocemos beneficio, TCO, payback, sensibilidad y grado de evidencia, la pregunta deja de ser si “la IA funciona” y pasa a ser mucho más concreta:

¿Merece este proyecto el siguiente euro, la siguiente hora y el siguiente nivel de complejidad?

9.1. Cuatro dimensiones antes de decidir

No utilizaría un umbral universal del tipo “todo proyecto con ROI superior al 20 % debe escalarse”.

La decisión debería combinar al menos cuatro dimensiones.

9.2. Escalar

Escalar tiene sentido cuando el proyecto ha reducido las incertidumbres materiales y la economía se mantiene razonablemente atractiva incluso sin utilizar el escenario más optimista.

Escalar tampoco significa desplegar inmediatamente en toda la empresa. Puede consistir en ampliar un departamento, un conjunto de procesos o un volumen controlado.

9.3. Ajustar

Algunos pilotos confirman que existe valor, pero muestran que la solución actual no es todavía la mejor forma de capturarlo.

Puede ser necesario modificar:

• alcance;
• modelo o proveedor;
• instrucciones;
• proceso previo;
• integración;
• controles;
• experiencia de usuario;
• o incluso la métrica utilizada para evaluar el caso.

Ajustar es una buena decisión cuando la hipótesis económica sigue siendo atractiva pero hemos localizado una restricción concreta que impide capturarla.

9.4. Mantener limitado

No todo caso rentable necesita convertirse en una plataforma empresarial.

Algunas soluciones funcionan precisamente porque:

• tienen pocos usuarios;
• trabajan con inputs homogéneos;
• el proceso está bien delimitado;
• las excepciones son escasas;
• y la validación permanece barata.

Extenderlas a otros contextos puede destruir parte de esa economía.

9.5. Parar

Parar un proyecto no significa necesariamente que la tecnología haya fallado.

Puede funcionar perfectamente y seguir sin merecer más recursos.

Esto último es importante. El ROI no debería evaluarse solo contra cero.

Una empresa tiene recursos limitados. Un proyecto con retorno positivo puede seguir siendo una mala prioridad si existe otra forma de utilizar capital, atención directiva o capacidad técnica con mejor resultado esperado.

9.6. La comparación correcta incluye el coste de oportunidad

Dos proyectos pueden presentar ROI positivo y no merecer la misma prioridad.

Dirección debería considerar:

9.7. Una matriz simple para tomar la decisión

Sin convertir el análisis en un scoring mecánico, podemos resumir la lectura en cuatro situaciones.

9.8. El objetivo no es aprobar proyectos de IA: es asignar mejor los recursos

Este cambio de perspectiva es probablemente el más importante de todo el artículo.

Si una empresa empieza preguntando “¿cómo conseguimos que este proyecto de IA tenga ROI?”, existe el riesgo de que el cálculo termine convertido en una justificación.

La pregunta más útil es:

Algunas veces la respuesta será IA. Otras veces será simplificar un proceso, mejorar datos, integrar dos sistemas, cambiar una responsabilidad o eliminar trabajo que nunca debería haberse realizado.

A IA pràctica amb ROI: quan té sentit i quan no desarrollamos precisamente cómo pasar del problema al caso de uso, pilotarlo y decidir si merece escalar.

El papel de esta página es más concreto: evitar que una cifra de ROI mal construida convierta una buena tecnología en una mala decisión empresarial.

10. Preguntas frecuentes sobre ROI en proyectos de IA