Cómo calcular el ROI de un proyecto de IA: método paso a paso

El problema: nadie calcula el ROI, lo inventa

En la mayoría de proyectos de IA que he visto, el ROI aparece dos veces: una vez en la presentación inicial (una cifra optimista, sin método, para justificar el presupuesto) y otra vez nunca más. Nadie vuelve a medir. Cuando dirección pregunta “¿esto funcionó?”, la respuesta es una anécdota (“el equipo dice que ahorra tiempo”), no un número.

El resultado: proyectos que siguen vivos por inercia porque nadie puede probar que fallaron, y proyectos que se cortan porque nadie puede probar que funcionaron. Ambos casos son el mismo error de origen: no se definió cómo se iba a medir el ROI antes de empezar.

Esta guía asume que ya elegiste el caso de uso y ya decidiste que vale la pena intentarlo. Aquí no se discute el criterio de por qué automatizar, eso es otro problema. Aquí se resuelve algo más aburrido y más útil: el método concreto para poner un número honesto encima de un proyecto de IA, antes, durante y después de implementarlo.

Qué es calcular el ROI de un proyecto de IA (y qué no es)

Eso significa que “ahorramos horas” no es ROI: es un insumo. El ROI aparece cuando esas horas se multiplican por el costo real de esas horas (salario cargado, no solo el sueldo bruto) y se le resta el costo del proyecto completo, no solo la licencia mensual del software.

Tampoco es lo mismo que “adopción”: un sistema que usa el 90% del equipo y no cambia ningún resultado de negocio tiene 90% de adopción y 0% de ROI. Son métricas distintas, para preguntas distintas. Esta guía es sobre la segunda.

Paso 1: mide la línea base antes de tocar nada

El error más caro de esta lista es el más simple de evitar: implementar el sistema antes de medir cómo funcionaba el proceso sin él. Sin línea base no hay ROI, hay una opinión con decimales.

• Elige un proceso, no una intención. Nombra la tarea exacta que el sistema va a tocar (“responder cotizaciones”, no “atención al cliente”).
• Mide el proceso actual durante 2 a 4 semanas antes de construir nada: tiempo real por unidad de trabajo, volumen mensual, tasa de error, y quién lo hace hoy.
• Registra el costo actual de esas horas: salario cargado (sueldo más beneficios más overhead), no el sueldo nominal.
• Guarda esos números en un documento fechado, antes del kickoff. Si los mides después de ver los resultados, ya están contaminados por lo que quieres demostrar.

Si el proyecto ya arrancó y no hay línea base, no está perdido: se reconstruye con datos históricos del sistema anterior (tickets, CRM, planillas) o, en el peor caso, con una estimación conservadora del equipo, documentada como estimación y no como medición.

Paso 2: suma los costos reales, no solo la licencia

El costo que se presenta en el comité casi siempre es la licencia mensual de la herramienta. Ese número subestima el costo real varias veces. Un ROI calculado sobre el costo incompleto no es optimista, es falso.

• Implementación inicial: horas de consultoría o desarrollo, integración con los sistemas existentes, migración de datos.
• Licencias y consumo: el software base más el consumo variable (llamadas a API, tokens, minutos de cómputo) que crece con el uso real.
• Mantenimiento: horas mensuales de alguien (interno o externo) que ajusta prompts, revisa errores, actualiza reglas cuando el proceso de negocio cambia.
• Horas del equipo interno: tiempo de los empleados en capacitación, en pruebas, en soporte al proyecto. Es costo real aunque no salga una factura por eso.
• Costo de gobierno y riesgo: revisión de seguridad, cumplimiento, y el tiempo de dirección en supervisar el proyecto.

Súmalos todos en una sola cifra de costo total anualizado. Ese es el denominador de la fórmula. Si el proveedor solo te dio el primer punto, pídele el resto antes de firmar.

Paso 3: traduce el beneficio a dinero y aplica la fórmula

De horas a dinero

Todo beneficio operativo se traduce a una de estas cuatro categorías: horas liberadas (multiplicadas por su costo real), errores evitados (multiplicados por lo que cuesta corregir cada uno), ventas o ingreso adicional atribuible, y tiempo de respuesta más rápido cuando ese tiempo tiene un valor de negocio medible (por ejemplo, tasa de cierre que sube porque se cotiza en minutos y no en días).

La fórmula

ROI = (beneficio - costo) / costo. El resultado se lee como porcentaje: un ROI de 1.0 significa que el proyecto devolvió lo que costó, además de recuperar la inversión.

Ejemplo ilustrativo, con números redondos solo para mostrar el método (no son cifras de ningún cliente real): un proceso que antes tomaba 200 horas al mes a $20 la hora cargada ($4,000 al mes) baja a 60 horas al mes con el sistema de IA. El ahorro es de 140 horas, es decir $2,800 al mes, o $33,600 al año. El costo total anualizado del proyecto (implementación, licencias, mantenimiento y horas internas) es de $18,000. El ROI queda en 0.87, es decir 87% de retorno sobre lo invertido en el primer año.

Elige la ventana de tiempo correcta

Medir a las dos semanas es el segundo error más común. En las primeras semanas el equipo todavía está aprendiendo la herramienta, ajustando prompts y corrigiendo casos raros: el ROI de esa ventana casi siempre es negativo o cercano a cero, y no significa nada. La ventana mínima honesta es de un trimestre completo después de la fecha de adopción estable, no la fecha de lanzamiento. Para procesos estacionales, la ventana debe cubrir al menos un ciclo completo del negocio.

Errores comunes al calcular el ROI

• Medir el beneficio sin línea base: comparar contra una percepción (“antes era más lento”) en vez de contra un número documentado.
• Usar el sueldo nominal en vez del costo cargado, lo que infla artificialmente el ahorro por hora.
• Contar solo la licencia como costo y omitir mantenimiento, horas internas y consumo variable.
• Medir demasiado pronto y declarar éxito o fracaso con datos de las primeras semanas.
• Confundir adopción con ROI: reportar que “el 80% del equipo lo usa” como si fuera el resultado de negocio.

Cómo se ve en la práctica

Una empresa de servicios profesionales (consultoría de mediano tamaño) automatizó la primera respuesta a solicitudes de cotización. Antes de tocar nada, midieron 3 semanas de línea base: 180 solicitudes al mes, 45 minutos de trabajo humano por solicitud, costo cargado de $15 la hora. Documentaron el costo total del proyecto a 12 meses: implementación, integración con su CRM, consumo de API y 5 horas mensuales de mantenimiento de un analista interno.

A los tres meses de adopción estable, remidieron el mismo proceso: el tiempo humano por solicitud bajó a 12 minutos (el sistema arma el borrador, la persona revisa y ajusta). Aplicaron la fórmula con el beneficio en horas liberadas más una mejora medible en la tasa de cierre, porque las cotizaciones salían el mismo día en vez de en dos o tres. El número de ROI que llevaron a dirección tenía línea base, costo completo y ventana de tres meses: pudieron defenderlo pregunta por pregunta.

Mi criterio

Cómo saber si esta metodología quedó bien aplicada

• Existe un documento fechado con la línea base, escrito antes del kickoff del proyecto.
• El costo total incluye implementación, licencias, consumo, mantenimiento y horas internas, no solo la licencia.
• El beneficio está expresado en dinero, no solo en horas o en porcentaje de adopción.
• La medición del resultado se hizo después de al menos un trimestre de adopción estable, no en las primeras semanas.
• El número de ROI se puede recalcular por otra persona con los mismos datos: si solo lo puede explicar quien lo hizo, no es un método, es una historia.

Si los cinco puntos están cubiertos, el número que llevas al comité aguanta preguntas. Si falta alguno, no es que el proyecto haya fallado: es que todavía no sabes si funcionó.