Al final del primer trimestre, la dirección pregunta: «¿Qué nos ha aportado la IA?» Y el ingeniero que lideró el piloto empieza a hojear sus apuntes. El contenido se generó más rápido. Los agentes gestionaban algunos correos. Los informes llegan antes. Pero la cifra concreta — cuántas horas, cuántos euros, cuál es la diferencia respecto a antes — no está. No porque el proyecto haya fracasado. Sino porque nadie midió cómo estaban las cosas antes de empezar.
Esta situación es más habitual en la práctica de lo que debería. La mayoría de las fuentes indican que entre el 75 % y el 95 % de los proyectos de IA no alcanzan el valor de negocio planificado. Una de las razones clave no es la mala calidad de la tecnología, sino la ausencia de un marco medible: no hay baseline, no hay métricas acordadas de antemano, y cuando llega el momento de evaluar, comparamos algo con nada. Este artículo describe cómo hacerlo bien — desde la definición del baseline, pasando por las partidas de coste reales, hasta la decisión de cuándo un proyecto tiene verdadero sentido.
Por qué el baseline es el paso más importante
Antes de cualquier despliegue de IA existe un estado que se quiere mejorar. Ese estado — el baseline — es el valor de referencia frente al cual se medirá cualquier mejora. Sin él no hay ROI. Solo hay un relato.
El baseline debería capturar:
- Tiempo — cuántas horas semanales dedica un equipo concreto a esa tarea (no estimado, sino realmente medido o documentado en un tracker)
- Tasa de errores — cuál es el nivel actual de errores, trabajo repetido o escalaciones
- Costes — costes salariales de esa actividad, y en su caso honorarios externos (outsourcing, licencias)
- Latencia — cuánto tarda el procesamiento de una solicitud desde la entrada hasta la salida
El problema es que las empresas normalmente no tienen esos datos preparados. El tiempo en correos no se registra. La tasa de errores en el procesamiento de documentos nunca se ha calculado. Por eso es perfectamente válido recopilar el baseline específicamente antes del proyecto — incluso de forma retrospectiva para los últimos tres meses. Lo fundamental es que debe existir antes de arrancar el piloto.
Para proyectos donde la medición es difícil (por ejemplo, un asistente de IA para procesos de toma de decisiones), existen métricas proxy indirectas: tiempo desde la entrada de la consulta hasta la decisión final, número de iteraciones necesarias para aprobar un documento, porcentaje de casos en los que el output era directamente utilizable sin edición.
Qué incluye el coste total
Aquí es donde la mayoría de los business cases internos distorsionan la realidad. En la presentación aparece el precio de los tokens de API y quizás una licencia de software. Lo demás se silencia o se aplaza. El coste real de un proyecto de IA incluye varias capas:
Desarrollo e integración
- Tiempo interno de ingenieros o proveedor externo para el desarrollo, la integración en sistemas existentes y las pruebas
- Prototipado y experimentos que no llegaron a producción (son un coste real del proyecto)
- Preparación de datos — limpieza, anotación, estructuración de los datos de entrada
Operación — tokens e infraestructura
Para modelos en cloud API son los costes de tokens — en un copiloto sencillo pueden ser marginales, pero en soluciones agentic con decenas de llamadas diarias crecen rápidamente. Para despliegues locales es el hardware (servidor GPU), la electricidad y el mantenimiento. Este cálculo se aborda con más detalle en el artículo sobre los costes de un agente de IA en producción.
Personas y procesos
- Change management — tiempo de formación, adaptación del equipo, cambio de flujos de trabajo
- Revisión y supervisión — cuando los outputs van a producción (contratos, informes, correos), alguien tiene que revisar. Este tiempo se infravalora sistemáticamente en los cálculos de ROI.
- Ajuste de system prompts, monitorización de calidad, resolución de incidencias y regresiones
Mantenimiento y actualizaciones
Los modelos cambian, las APIs se actualizan, los procesos empresariales evolucionan. Un sistema de IA desplegado no es un producto terminado — es un componente vivo que necesita ajustes regulares. Una estimación realista es el 15–30 % anual de los costes operativos respecto al coste original de desarrollo.
La buena noticia es que precisamente este desglose obliga a pensar con más precisión. Hemos visto proyectos donde, al descomponer todas las partidas, resultó que un copiloto para un solo operador era más eficiente que un extenso sistema multi-agente — porque el coste total era varias veces menor con un beneficio medible similar.
Cómo calcular los beneficios — cuantitativos y cualitativos
Cuando ya se tiene el baseline y los costes, viene la otra parte de la ecuación: los beneficios medibles.
Ahorros directos
La categoría más fácil de calcular:
- Tiempo ahorrado × tarifa horaria = ahorro salarial. Si un agente reemplaza 4 horas de trabajo manual diario a 25 €/hora, el ahorro anual es ~26 000 €.
- Reducción de la tasa de errores — si el control de documentos por IA redujo el porcentaje de errores del 8 % al 2 %, calcule el coste de corrección de cada error y multiplíquelo por la diferencia.
- Velocidad de procesamiento — reducir el tiempo desde la consulta del cliente hasta la respuesta se puede traducir en menos escalaciones o en operaciones comerciales rescatadas.
Beneficios indirectos
Son reales, pero más difíciles de medir. Incluyen el aumento de la capacidad del equipo (las personas hacen trabajo de mayor valor en lugar de tareas rutinarias), mayor satisfacción del cliente, toma de decisiones más rápida. Inclúyalos en el business case, pero no los exprese como una cifra exacta — cuantifíquelos de forma conservadora o nómbrelos como cualitativos.
Valor estratégico
Algunos proyectos no son rentables en términos puramente financieros, pero tienen valor estratégico: reducción de la dependencia de un proveedor concreto, cumplimiento normativo (EU AI Act, GDPR), mejora de la infraestructura de datos que tiene valor también para otros proyectos. Estos beneficios son una parte legítima del business case — simplemente identifíquelos claramente como estratégicos, no financieros.
Payback y ROI — cómo interpretarlos de forma realista
Cuando se tienen los números, el cálculo es directo:
- ROI (%) = (Beneficios totales − Costes totales) / Costes totales × 100
- Período de payback = Costes totales / Beneficios mensuales
Donde la mayoría de los business cases falla es en el horizonte temporal. El 84 % de los CEOs asume de forma realista que el retorno positivo tarda más de 6 meses. Para casos de uso complejos (no solo un copiloto, sino workflows agentic, RAG sobre documentación corporativa, integración con ERP) el horizonte realista es 12–24 meses. Los pilotos con un payback «en tres meses» solo son ciertos en automatizaciones muy sencillas con costes de implementación bajos.
Algunos consejos prácticos al trabajar con los números:
- 1.Use estimaciones conservadoras de beneficios y estimaciones realistas (no optimistas) de costes
- 2.Presente escenarios: mejor caso, caso base, peor caso — con diferentes supuestos de adopción
- 3.Separe los costes únicos (desarrollo, integración) de los recurrentes (tokens, mantenimiento, personas)
- 4.No olvide el ramp-up — los primeros meses de despliegue son típicamente menos eficientes mientras el equipo se adapta
El resumen relacionado sobre por qué fracasan los pilotos de IA muestra que la ausencia de objetivos medibles antes del inicio es uno de los motivos de fracaso más frecuentes.
Cuándo un proyecto no tiene business case
Una parte honesta de cualquier marco de ROI es también la decisión de cuándo un despliegue de IA no tiene sentido. Hemos visto proyectos donde esta decisión no se tomó a tiempo — y el resultado fue medio año de tiempo invertido con cero output.
Señales de que un proyecto no tiene suficiente business case:
- Escala demasiado pequeña — si la actividad ocupa al equipo menos de 5 horas semanales, los costes de despliegue y mantenimiento raramente alcanzan el payback en un horizonte razonable
- No hay datos — un sistema de IA sin datos de entrada de calidad no produce outputs utilizables. Si no hay datos, invierta primero en infraestructura de datos
- El proceso no está definido — la IA automatiza un proceso, no el caos. Si las personas no saben describir los pasos de cómo resuelven la tarea manualmente, la IA no lo resolverá por ellas
- Supervisión demasiado elevada — si cada output de IA debe pasar por una revisión igual de detallada que antes del despliegue, el beneficio efectivo es cercano a cero
Rechazar un proyecto basándose en el análisis de ROI no es un fracaso — es tiempo y dinero ahorrados que pueden dirigirse donde existe un caso real.
Beneficios blandos — cómo presentarlos en el business case
La categoría de «beneficios blandos» se usa en las presentaciones para enmascarar un argumento cuantitativo débil. Eso no significa que no existan — existen, pero hay que nombrarlos de otra manera.
En lugar de «mayor satisfacción del cliente», diga: «según la encuesta previa al despliegue, el 62 % de los clientes valoraba el tiempo de respuesta como demasiado lento; tras el despliegue del copiloto, el tiempo de respuesta medio bajó de 4,2 horas a 47 minutos.» Eso es medible — aunque sea una métrica proxy y no una cifra financiera directa.
En lugar de «mayor eficiencia del equipo», diga: «antes del despliegue el equipo dedicaba un promedio de 12 horas semanales a preparar informes de estado; después, 2,5 horas.» Si no puede convertirlo a euros, preséntelo como ahorro factual de capacidad — no como beneficio financiero.
Los beneficios que son realmente solo una sensación (mejor moral del equipo, imagen más moderna de la empresa) inclúyalos en la sección estratégica y no les asigne valor numérico.
Seguimiento del ROI tras el despliegue — por qué es diferente del business case
El business case se elabora antes del proyecto. El seguimiento del ROI tras el despliegue es una disciplina distinta — y la mayoría de las empresas la ejecuta solo de forma superficial.
Un sistema de IA en producción debería tener métricas de monitorización en vivo que se evalúen regularmente:
- Volumen de tareas procesadas (y tendencia)
- Tasa de aceptación del output sin edición humana (acceptance rate)
- Porcentaje de errores o escalaciones
- Tiempo real dedicado a la supervisión (frente al supuesto original)
Estos datos sirven para dos cosas: en primer lugar, confirman o refutan los supuestos del business case; en segundo lugar, muestran dónde el sistema se degrada — el modelo queda obsoleto, cambian los inputs, crece el drifting respecto al caso de uso original. La observabilidad de los sistemas de IA es un tema en sí mismo; la base la forma el registro de cada entrada, salida y decisión del agente.
Para empresas que contemplan varios proyectos de IA en paralelo, el seguimiento del ROI a nivel de cartera es clave: no solo qué proyecto tiene el ROI más alto, sino también qué proyectos consumen capacidad del equipo sin beneficio medible.
Preguntas frecuentes
¿Cómo definir el baseline cuando no se tienen datos históricos?
Recoja datos antes de lanzar el piloto — incluso 4–6 semanas son suficientes para obtener una muestra adecuada para la mayoría de los procesos. Si no es posible, use entrevistas estructuradas con los miembros del equipo: «¿Cuántas horas semanales dedica a esta tarea? ¿Cuántos casos gestiona al mes?» Combínelo con logs de sistemas existentes (sistema de tickets, metadatos de correo, registros ERP). Una estimación con incertidumbre explícitamente nombrada es mejor que ningún baseline.
¿Cuál es el horizonte de payback realista para un proyecto de IA en una empresa industrial?
Para un copiloto sencillo (asistente para documentación, correos, reporting): 6–12 meses. Para RAG sobre documentación corporativa o analítica predictiva: 12–18 meses. Para un sistema agentic complejo integrado con ERP/SCADA: 18–36 meses. El atajo de «menos de 6 meses» solo se cumple con costes de implementación bajos y gran escala — por ejemplo, cuando un agente reemplaza cientos de operaciones manuales diarias.
¿Cómo incluir en el ROI los costes de fine-tuning o de infraestructura RAG?
Sí, y deberían presentarse por separado de los costes operativos. El fine-tuning es un coste único (preparación del dataset, tiempo de entrenamiento, evaluación), pero el modelo hay que actualizarlo periódicamente — planifique una repetición anual. La infraestructura RAG (base de datos vectorial, pipeline de embedding, ajuste del retrieval) es un coste fijo con un componente variable bajo. Ambos son inversiones en fundamentos que pueden servir a múltiples casos de uso — distribúyalos entre los proyectos que los utilizan.
¿Qué hacer si el piloto mostró beneficio, pero el despliegue en producción no lo replica?
Este es un escenario habitual — la mayoría de los pilotos corren sobre inputs curados y condiciones controladas. Primera pregunta: ¿cuál es la acceptance rate de los outputs reales (sin edición)? Si ha caído significativamente respecto al piloto, el problema es un distribution shift de los datos de entrada, o bien el scope del piloto no representaba la variabilidad real de producción. Solución: análisis de los casos de fallo, ampliación de la muestra de entrenamiento o reducción del scope al subconjunto de casos en los que el sistema funciona de forma fiable.
¿Cuándo tiene sentido hacer un análisis build vs. buy antes de calcular el ROI?
Siempre. El ROI depende de si el sistema se construye internamente, se compra como solución ya hecha, o se combina ambas opciones. Cada variante tiene un perfil de costes distinto y un payback diferente. El análisis build vs. buy se trata con más detalle en el artículo dedicado a esta elección — lo recomendamos como paso previo antes de finalizar cualquier business case.
*Si está elaborando el business case para un proyecto de IA y necesita ayuda para definir las métricas, el baseline o el modelo de costes — precisamente con esto ayudamos a clientes de la industria antes de que empiecen el desarrollo. Contáctenos para una consulta gratuita.*