En las últimas piezas hablamos de FinOps de IA y costo por transacción exitosa y de cómo el ruteo de modelos por complejidad baja ese costo sin perder calidad. Son métricas que el equipo técnico entiende bien. El problema aparece cuando hay que pedir presupuesto para escalar: el comité de dirección y, sobre todo, el CFO no aprueban tokens ni latencia. Aprueban un business case que muestre cuánto cuesta, cuánto regresa, en qué plazo y qué tan sensible es ese resultado a los supuestos.
Este artículo explica cómo construir ese business case a partir de los datos operativos que ya tienes, cómo presentarlo con escenarios y análisis de sensibilidad, y qué errores hacen que finanzas lo rechace o, peor, lo apruebe con números que luego no se cumplen.
Por qué el costo por transacción no basta para el CFO
El costo por transacción exitosa es la unidad correcta para operar un servicio de IA, pero es solo una pieza del cálculo financiero. Al CFO le interesan tres preguntas distintas:
- ¿Cuál es el costo total de propiedad? No solo inferencia, también integración, datos, personas, monitoreo, cumplimiento y mantenimiento.
- ¿Cuál es el beneficio neto y cuándo llega? Ahorros, ingresos incrementales o riesgo evitado, con su curva de adopción real.
- ¿Qué tan seguro es el número? Qué supuestos lo sostienen y qué pasa si alguno falla.
Un business case sólido traduce la operación del servicio en esas tres respuestas. Si el equipo ya tiene piloto, bitácora de evidencia y tablero de FinOps, la mayor parte de los insumos existe; solo hay que ordenarlos en el lenguaje de finanzas.
Paso 1: define la línea base con datos, no con estimaciones
Todo business case empieza por el costo del proceso actual. Para el caso de uso que quieres escalar, documenta el volumen mensual, el tiempo promedio por caso, el costo cargado de la hora de las personas que lo atienden, la tasa de error o retrabajo y su costo, y cualquier costo externo (outsourcing, multas, penalizaciones por nivel de servicio).
La clave es que esta línea base salga de registros, no de entrevistas. Si en el piloto mediste el antes y el después, usa esas cifras. Si no, toma una muestra de dos a cuatro semanas del sistema de tickets, del ERP o del CRM. Un CFO desconfía con razón de una línea base que el propio equipo del proyecto calculó “a ojo”.
Paso 2: arma el costo total de propiedad en cuatro capas
El error más común es presentar solo el costo de los modelos. Para un horizonte de 12 a 36 meses, separa el costo en cuatro capas:
- Costo variable de operación. Tu costo por transacción exitosa multiplicado por el volumen proyectado, incluyendo reintentos, escalamientos a humanos y el efecto del ruteo.
- Costo fijo de plataforma. Infraestructura, licencias, herramientas de observabilidad y evaluación continua, almacenamiento y seguridad.
- Costo de implementación. Integraciones con ERP, CRM u otros sistemas, preparación de datos, pruebas, gestión del cambio y capacitación. Normalmente se concentra en los primeros meses.
- Costo de sostenimiento. Horas del dueño del servicio, on-call, revisión de la cola de excepciones, auditorías de calidad, actualizaciones de modelo y control de cambios.
La capa de sostenimiento es la que más se subestima. Si el servicio tiene SLOs, golden sets y postmortems, alguien dedica horas cada semana a mantenerlos. Ese tiempo es costo real y conviene ponerlo por escrito desde el inicio.
Paso 3: cuantifica beneficios en categorías separadas
Mezclar tipos de beneficio es la forma más rápida de perder credibilidad. Clasifícalos así:
- Ahorro duro. Costos que efectivamente desaparecen del estado de resultados: horas de outsourcing que se cancelan, contrataciones que no se hacen, penalizaciones que dejan de pagarse.
- Capacidad liberada. Horas que el equipo recupera pero que no se traducen en menor gasto a menos que se reasignen. Es valiosa, pero hay que decir explícitamente en qué se va a usar.
- Ingreso incremental. Mayor conversión, menos abandono o ventas que antes no se cerraban. Requiere un mecanismo de atribución acordado con el área comercial.
- Riesgo evitado. Fraude detectado, errores de cumplimiento prevenidos o multas evitadas. Se presenta como valor esperado: probabilidad por impacto.
Una buena práctica es que el caso sea rentable solo con el ahorro duro, y que el resto se presente como potencial adicional. Si el proyecto depende por completo de la capacidad liberada o del ingreso incremental, dilo con claridad y explica cómo lo vas a medir.
Paso 4: modela la curva de adopción, no el estado ideal
Ningún servicio de IA llega al 100% de su volumen objetivo el primer mes. La adopción suele seguir fases: modo sombra, despliegue parcial por segmento, expansión y estabilización. Proyecta el beneficio mes a mes con esa curva, y no como si el servicio estuviera completo desde el día uno.
Incluye también la tasa de automatización realista. Si en el piloto el 70% de los casos se resolvió sin intervención y el resto pasó a la cola de excepciones, ese es tu punto de partida, no el 95% que muestra la demo del proveedor.
Paso 5: presenta tres escenarios y un análisis de sensibilidad
En lugar de un solo número, presenta tres escenarios con supuestos explícitos:
- Conservador. Adopción lenta, tasa de automatización igual o menor a la del piloto, costo por transacción sin mejoras de ruteo.
- Base. Adopción y automatización según la evidencia del piloto, con las optimizaciones de FinOps que ya están validadas.
- Optimista. Mejoras adicionales que todavía no están probadas, claramente marcadas como tales.
Después, identifica las tres o cuatro variables que más mueven el resultado, normalmente volumen, tasa de automatización, costo por transacción y costo de sostenimiento, y muestra cómo cambia el ROI y el periodo de recuperación si cada una se mueve un 20% en contra. Este análisis responde la pregunta que el CFO va a hacer de todas formas: “¿qué tiene que salir mal para que esto no valga la pena?”.
Ejemplo hipotético: conciliación de pagos en una distribuidora en México
Imagina una distribuidora con varias sucursales que concilia manualmente miles de pagos de clientes cada mes contra facturas en su ERP. El equipo de cobranza dedica buena parte de su semana a casos donde la referencia bancaria no coincide con la factura. Un piloto de IA que propone el emparejamiento y manda a revisión humana solo los casos de baja confianza mostró una reducción importante del tiempo por caso.
Con esa evidencia, el equipo arma el business case así: línea base con el tiempo real registrado en el piloto; costo total con las cuatro capas, incluyendo la integración con el ERP y las horas del dueño del servicio; beneficio separado entre horas de outsourcing que se cancelan (ahorro duro) y días de cartera que se reducen (beneficio financiero por flujo de efectivo); y una curva de adopción por sucursal. El escenario conservador ya recupera la inversión dentro del horizonte acordado, y la sensibilidad muestra que la variable crítica es la tasa de automatización. Con eso, el comité aprueba la expansión con un compromiso claro: revisar la tasa de automatización cada mes en el scorecard.
Errores que hacen fracasar el business case
- Presentar solo el costo de inferencia y omitir integración, datos y sostenimiento.
- Contar la capacidad liberada como ahorro duro sin un plan de reasignación.
- Usar la tasa de automatización de la demo y no la del piloto.
- Proyectar el beneficio completo desde el mes uno, sin curva de adopción.
- Entregar un solo escenario sin decir qué supuestos lo sostienen.
- No definir quién mide el beneficio después de la aprobación, ni con qué frecuencia.
Checklist del business case de IA
- Línea base del proceso actual tomada de registros, no de estimaciones.
- Costo total de propiedad en cuatro capas para un horizonte de 12 a 36 meses.
- Beneficios separados en ahorro duro, capacidad liberada, ingreso incremental y riesgo evitado.
- Curva de adopción mensual basada en la evidencia del piloto.
- Tres escenarios con supuestos explícitos y análisis de sensibilidad de las variables clave.
- Indicadores de seguimiento en el scorecard y un dueño responsable de reportarlos.
Cierre
El business case conecta el trabajo operativo de FinOps, SLOs y evaluación continua con la decisión que realmente importa para la empresa: invertir o no en escalar. Cuando se construye con datos del piloto, costos completos y escenarios honestos, deja de ser un documento para conseguir presupuesto y se vuelve el contrato de seguimiento entre tecnología y finanzas.
Si tu equipo necesita convertir un piloto de IA en un business case que tu CFO pueda aprobar y después auditar, en Next Wave te ayudamos a construirlo con tus propios datos. Escríbenos a contacto@nextWaveAI.AI o llámanos al +52 (33) 3126 6969.
Add comment