“Ahorrará un 30% del tiempo” es una cifra sospechosamente frecuente en presentaciones de IA. A menudo procede de multiplicar minutos estimados por salarios y asumir que cada minuto liberado se convierte en dinero. En la práctica, el trabajo llega por lotes, la revisión continúa y la capacidad liberada puede no reducir ningún coste.
Un business case útil no necesita una cifra espectacular. Necesita explicar qué cambia, cómo se medirá y qué tendría que ocurrir para que la inversión merezca la pena.
Empezar por la unidad de trabajo
“Mejorar el departamento jurídico” no se puede medir. “Preparar la primera revisión de contratos de compra estándar” sí. Tiene inicio, salida, volumen y una barra de calidad.
La unidad puede ser una incidencia resuelta, una factura conciliada, una propuesta enviada o una inspección cerrada. Sobre ella se construyen el resto de números:
Valor anual esperado = volumen × mejora por caso × tasa de adopción × tasa de éxito
La fórmula obliga a introducir dos factores que suelen desaparecer de las diapositivas. Una solución no genera valor si no se usa, y el intento que necesita rehacerse no equivale a trabajo terminado.
La línea base no sale de una encuesta rápida
Preguntar “¿cuánto tardas?” produce una orientación, no una medida. Conviene combinar registros, una muestra cronometrada y observación del proceso. Separar tiempo activo de espera evita atribuir a la IA retrasos que dependen de aprobaciones o colas.
| Variable | Qué medir | Error frecuente |
|---|---|---|
| Volumen | casos por periodo y estacionalidad | usar un mes excepcional |
| Tiempo activo | minutos de trabajo por rol | confundirlo con plazo total |
| Calidad | aceptados, corregidos y rechazados | asumir que el proceso humano es perfecto |
| Coste | personas, sistemas, terceros y reproceso | usar solo salario bruto |
| Riesgo | frecuencia e impacto de incidencias | convertir todo riesgo en euros sin evidencia |
| Experiencia | esfuerzo de cliente y empleado | tratar satisfacción como ahorro contable |
La referencia humana también varía. Si los analistas expertos resuelven en 20 minutos y los nuevos en 50, la media oculta dos casos de valor: aumentar capacidad y acelerar aprendizaje.
Cinco tipos de beneficio que no son intercambiables
Ahorro realizable
Un gasto desaparece o se reduce de forma verificable: horas externas, licencias, penalizaciones o contratación prevista.
Capacidad liberada
El equipo atiende más volumen o dedica tiempo a otra tarea. Tiene valor, pero no es ahorro hasta que se utiliza.
Ingreso incremental
Más oportunidades, conversión o velocidad generan ventas atribuibles. Requiere controlar otros factores.
Calidad y riesgo
Menos errores, reclamaciones o exposición. Puede medirse con frecuencias y costes históricos.
Existe un quinto beneficio: hacer algo que antes no era viable. Por ejemplo, revisar el 100% de expedientes en lugar de una muestra. No encaja bien en una cuenta de horas, pero puede proteger ingresos o mejorar decisiones. Debe explicarse como una nueva capacidad y vincularse a una consecuencia observable.
Contar todos los costes, también después del piloto
El presupuesto inicial suele incluir licencias y desarrollo. Faltan integración, preparación de datos, seguridad, evaluación, formación, soporte, observabilidad, revisiones humanas, incidencias y adaptación a cambios de modelo.
También hay costes variables: inferencia, búsquedas, almacenamiento y herramientas. Un agente puede realizar varios intentos para completar un único caso. Por eso el coste real no son solo los tokens y debe calcularse por resultado aceptado.
Trabajar con escenarios, no con decimales falsos
Un modelo sencillo con tres escenarios suele ser más honesto que una proyección muy precisa:
- Conservador: adopción lenta, más revisión y mejora modesta.
- Base: comportamiento observado en el piloto, descontando aprendizaje inicial.
- Favorable: adopción alta y uso efectivo de la capacidad liberada.
Cada escenario debe mostrar las variables que lo explican. Si el resultado depende de que el 90% de usuarios cambie de hábito en un mes, el riesgo principal es adopción, no rendimiento del modelo.
El análisis de sensibilidad identifica qué supuesto mueve realmente el caso. A veces reducir diez segundos de inferencia apenas importa y conseguir acceso a una fuente fiable cambia por completo la tasa de éxito.
Ejemplo: primera revisión de contratos
Una empresa procesa 6.000 contratos estándar al año. La línea base muestra 38 minutos de revisión activa, un 8% de devoluciones y apoyo externo en los picos.
El piloto no promete reemplazar la revisión jurídica. Prepara una matriz de cláusulas con citas. En una muestra representativa, el 72% llega listo para revisión, el 21% necesita correcciones menores y el 7% se descarta. El tiempo medio baja 14 minutos, no los 25 observados en las mejores pruebas.
El caso base valora las horas externas evitadas y la capacidad para absorber crecimiento. No contabiliza toda la capacidad interna como ahorro. Incluye licencias, integración, revisión, mantenimiento y un margen para cambios. Si la tasa “lista para revisar” cae por debajo del 60%, el proyecto vuelve a validación.
La prueba debe poder matar el proyecto
Un piloto que solo puede confirmar la inversión es una demostración comercial. Antes de empezar, hay que acordar umbrales: calidad mínima, coste máximo por caso, adopción, plazo y fallos que obligan a detenerse.
La financiación puede avanzar por etapas. Exploración comprueba que la tecnología puede abordar la tarea; validación mide casos representativos; producción financia integración, controles y cambio organizativo. Esta separación coincide con la recomendación reciente de vincular la inversión a la madurez y demanda demostrada (OpenAI).
Lo que debe caber en una página
- Problema y unidad de trabajo claramente delimitados.
- Línea base con fuente, periodo, muestra y responsable.
- Beneficios separados entre ahorro, capacidad, ingreso, calidad y riesgo.
- Coste total de implantación y operación durante el horizonte elegido.
- Escenarios con adopción, éxito e incertidumbre explícitos.
- Umbrales para escalar, corregir o detener el proyecto.
- Propietario del resultado de negocio, no solo de la tecnología.
Preguntas frecuentes
¿Qué horizonte temporal conviene usar?
El que refleje inversión y maduración del proceso, normalmente con detalle mensual durante el piloto y anual para operación. Proyecciones largas requieren más escenarios, no más confianza.
¿Cómo se valora el tiempo liberado?
Primero como capacidad. Solo se convierte en ahorro si reduce gasto o contratación; en ingreso, si permite atender demanda con evidencia; o en calidad, si se reasigna a trabajo concreto.
¿Debe incluirse el valor del riesgo evitado?
Sí, cuando existen frecuencias, impactos y controles comparables. Si no, puede presentarse como beneficio cualitativo con su evidencia y sin inventar una cifra.
¿Qué pasa si no hay datos históricos?
Se crea una línea base con una muestra antes del piloto. Empezar unas semanas más tarde es mejor que comparar contra una estimación imposible de defender.
¿Quién debe aprobar el business case?
El responsable del proceso, Finanzas y las funciones que asumen riesgo o costes. Tecnología valida viabilidad, pero no debería ser propietaria en solitario del beneficio.
Un buen caso permite decir que no
La función del business case no es conseguir aprobación. Es evitar una inversión cuando el valor depende de supuestos frágiles y mostrar qué evidencia podría cambiar esa decisión.
Una cifra más modesta, trazable y revisable suele proteger mejor el proyecto que un ROI enorme que nadie sabrá medir después.
Fuentes consultadas
- A scorecard for the AI age — OpenAI
- How to manage AI investments in the agentic era — OpenAI
- Gather appropriate evidence of value — OpenAI Academy
- Industrial Artificial Intelligence Management and Metrology — NIST
- AI ROI: the paradox of rising investment and elusive returns — Deloitte
Fuentes y vigencia revisadas el 18 de agosto de 2026.