Producto de IA — Módulo 2: del caso de uso al business case

En el módulo 1 aprendimos a enmarcar el problema: a distinguir cuándo una idea es de verdad un problema que la IA resuelve mejor que una regla, un formulario o un proceso más simple. Salimos de ahí con algo valioso — un problema bien definido, con su usuario, su fricción y su señal de éxito. Pero un problema bien enmarcado todavía no justifica gastar el tiempo de un equipo en él. Falta la pregunta que separa un proyecto que se aprueba de uno que muere en una reunión: ¿vale la pena resolverlo? Este módulo es sobre cómo responder esa pregunta con números que se sostienen, y cómo escribirla en una página que consiga el sí.

El business case (caso de negocio: el argumento cuantificado de por qué construir algo produce más valor del que cuesta) es el documento que todo el mundo dice tener y casi nadie tiene bien hecho. La versión mala vende la tecnología (“usaremos IA generativa de última generación”). La versión buena vende el resultado, en dinero o en tiempo, y demuestra que la solución captura una fracción de ese resultado mayor a lo que cuesta operarla.

La tesis del módulo

Un business case de IA honesto no vende la tecnología: cuantifica el problema en dinero o en tiempo y demuestra que la solución captura una fracción de eso mayor a su costo total. El ROI se calcula con el costo completo — desarrollo, datos, evals, monitoreo, mantenimiento y las horas humanas de supervisión — nunca con el precio del token. La mayoría de los casos de negocio de IA que fracasan no fracasaron en el mercado: fracasaron en la hoja de cálculo, porque inflaron el numerador y escondieron el denominador.

Cuantificar el valor: dónde vive el dinero

Antes de calcular retorno alguno hay que ponerle un número al problema. El valor de un producto de IA casi siempre cae en una de tres canastas, y conviene saber en cuál estás porque cada una se mide distinto.

1. Reducción de costo. Es la más fácil de defender porque el dinero ya se está gastando hoy. Horas de trabajo que se ahorran, tickets (casos de soporte) que se resuelven solos sin llegar a un agente humano, revisiones manuales que se automatizan. Se mide multiplicando volumen por costo unitario: (casos al mes) × (minutos por caso) × (costo del minuto de esa persona).
2. Aumento de ingreso. Más difícil de atribuir, porque el ingreso depende de muchas cosas además de tu producto. Conversión (fracción de visitantes que compran), retención (fracción de clientes que se quedan), ticket promedio más alto. Aquí el número honesto siempre viene con un supuesto grande: “si mejoramos la conversión en 1 punto”.
3. Reducción de riesgo. La más incómoda de cuantificar y la que más se ignora. Errores evitados, multas que no ocurren, fraude detectado, clientes que no se van por un mal servicio. Se mide como (probabilidad del evento malo) × (costo del evento) × (reducción que aporta tu producto).

El error clásico es esperar a tener el número perfecto. No lo vas a tener: estás estimando el futuro. Lo que se pide no es certeza, es honestidad sobre la incertidumbre. Eso se logra con dos hábitos:

• Rangos, no puntos. No digas “ahorraremos 40.000 al año”. Di “entre 25.000 y 55.000, con 40.000 como caso central”. Un rango comunica que sabes que es una estimación, y protege el caso cuando la realidad cae en el borde bajo.
• Supuestos explícitos. Cada número descansa sobre supuestos. Escríbelos al lado: “supone 2.000 tickets/mes, 8 min/ticket, 40% desviables por el agente”. Quien revise el caso puede discutir el supuesto en vez de discutir tu número, que es una conversación mucho más productiva.

Ojo: un valor que no puedes cuantificar ni siquiera en un rango amplio es una señal de alarma, no un permiso para saltarte el paso. “Es que este proyecto es estratégico y su valor no se puede medir” suele significar una de dos cosas: o el valor es real pero nadie hizo el trabajo de estimarlo, o no hay valor y “estratégico” es la palabra que lo tapa. Insiste en un rango. Incluso “entre 0 y mucho” es información: te dice que el caso todavía no existe.

El ROI y sus dos trampas

El ROI (Return on Investment, retorno sobre la inversión) es la relación entre lo que ganas y lo que gastas. La fórmula es simple:

ROI = (valor − costo) / costo

Un ROI de 0 significa que empatas: recuperas exactamente lo que pusiste. Un ROI de 1 (o 100%) significa que por cada peso invertido recuperas ese peso y ganas otro. La fórmula no engaña; lo que engaña es cómo se rellenan sus dos partes. Casi todos los business cases de IA que se aprueban y luego decepcionan cometen los mismos dos pecados a la vez:

• Inflan el numerador. Se cuenta el mejor caso como si fuera el caso esperado. “El agente desvía el 40% de los tickets” se convierte silenciosamente en “ahorramos el 40% del costo de soporte”, olvidando que un ticket desviado no cuesta cero (cuesta la inferencia y la supervisión), que la adopción no es del 100% desde el día uno, y que parte de lo “desviado” vuelve escalado y más caro.
• Subestiman el denominador. Se calcula el costo como el precio de la API (la interfaz por la que se paga el uso del modelo, normalmente por token). Y la API es la punta del iceberg: debajo están los datos, las evals, el monitoreo, el mantenimiento y las personas que supervisan. Un denominador que solo tiene tokens produce un ROI de fantasía.

Un ROI trabajado, con cifras ilustrativas

Los números que siguen son ilustrativos — sirven para mostrar la mecánica, no para copiarlos a tu caso. La lección no está en las cifras sino en las dos columnas.

Un asistente que desvía tickets de soporte. Volumen: 2.000 tickets/mes. Supuesto de desvío efectivo: 35% (no el 45% de la demo). Costo de un ticket atendido por una persona: 6 (moneda ilustrativa). Horizonte: 12 meses.

Concepto	Optimista (el que se presenta)	Honesto (el que ocurre)
Tickets desviados/mes	900 (45%)	700 (35%)
Ahorro bruto/mes	5.400	4.200
Menos costo de inferencia/mes	— (se olvida)	−450
Menos supervisión humana/mes	— (se olvida)	−900
Valor neto/mes	5.400	2.850
Valor neto/año	64.800	34.200
Desarrollo (una vez)	20.000	20.000
Datos, evals, monitoreo/año	— (se olvida)	18.000
Costo total año 1	20.000	38.000
ROI año 1	(64.800−20.000)/20.000 = 224%	(34.200−38.000)/38.000 = −10%

Los dos cálculos usan el mismo proyecto. La columna optimista aprueba el proyecto con un ROI espectacular; la honesta muestra que en el año 1 el proyecto pierde plata y solo se vuelve positivo en el año 2, cuando el desarrollo ya está pagado y el valor neto anual (34.200) supera al costo recurrente (18.000). Esa no es razón para no hacerlo — muchos productos buenos son negativos el primer año — pero es una decisión completamente distinta a “224% de retorno inmediato”. El business case honesto te deja decidir con los ojos abiertos.

Ojo con dónde pones los costos recurrentes. La tabla resta la inferencia y la supervisión del valor (arriba) y suma datos, evals y monitoreo al costo (abajo). Si llevas todo lo recurrente al denominador, el ROI del año 1 da −7% en vez de −10%: la cifra cambia según la convención, el signo no. Elige una convención, dila, y úsala igual en todos los casos que compares. Lo imperdonable no es la convención: es que un costo falte de las dos partes.

El costo total de propiedad (TCO)

El TCO (Total Cost of Ownership, costo total de propiedad: todo lo que cuesta tener y operar algo durante su vida, no solo comprarlo) es el denominador bien hecho. Para un producto de IA tiene componentes que el precio del token ni siquiera roza. Este es el desglose que todo business case debería tener:

Componente	Qué incluye	Una vez / recurrente
Desarrollo	Diseño, integración, prompts, primeras evals	Una vez (con repagos)
Inferencia / tokens	El pago por uso del modelo	Recurrente, escala con volumen
Infraestructura	Servidores, base vectorial, colas, logs	Recurrente
Datos y etiquetado	Recolectar, limpiar, anotar los datos	Una vez + goteo continuo
Evals	Construir y correr la suite de calidad	Una vez + por cada cambio
Monitoreo	Observabilidad, alertas, tableros	Recurrente
Mantenimiento del modelo	Reajustes cuando el proveedor cambia el modelo o llega drift (deriva: los datos del mundo cambian y el modelo empeora sin que nadie lo toque)	Recurrente, impredecible
Supervisión humana	El humano en el loop (persona que revisa o aprueba salidas del modelo antes de que tengan efecto)	Recurrente, el más olvidado

Dos filas merecen una advertencia porque son las que hunden los casos:

Cuidado con la fila de supervisión humana. Casi ningún producto de IA en producción opera sin una persona revisando algo — casos límite, salidas de baja confianza, reclamos. Ese costo es recurrente y crece con el volumen, exactamente al revés de lo que promete la demo (“se opera solo”). Si tu caso asume cero supervisión, no tienes un business case optimista: tienes uno equivocado.

Cuidado con el mantenimiento del modelo. El proveedor actualiza el modelo por debajo y tu comportamiento cambia sin que hayas tocado una línea; los datos del mundo derivan y la calidad cae sola. Presupuestar 0 para mantenimiento equivale a asumir que el sistema nunca envejece. Envejece. Reserva una fracción recurrente para ello aunque no sepas todavía en qué se gastará. La economía de los modelos desarrolla por qué el costo por token es la parte pequeña y volátil de esta tabla.

El costo de oportunidad: lo que no haces por hacer esto

Hay un costo que no aparece en ninguna tabla de TCO porque no se paga con dinero: el costo de oportunidad (el valor de la mejor alternativa que dejas de hacer al elegir esta). Tu equipo tiene capacidad finita. Cada proyecto que aprueban es un proyecto distinto que no harán este trimestre. Un ROI de 30% suena bien en aislamiento, pero si el proyecto de al lado tenía un ROI de 120% y el mismo costo, aprobar el primero te costó la diferencia.

Por eso el business case no se evalúa contra cero (“¿gana más de lo que cuesta?”) sino contra la alternativa (“¿es esto lo más valioso que podemos construir ahora con este equipo?”). Un caso que solo se compara con no hacer nada está haciendo trampa: casi cualquier cosa gana contra no hacer nada. La comparación honesta es contra el mejor uso alternativo del mismo equipo. Ese salto — de evaluar un proyecto solo a compararlo con la cartera entera — es exactamente el trabajo de la priorización, el módulo 6, y es la razón por la que un buen business case termina con una frase incómoda: “y esto es mejor que lo siguiente en la lista porque…”.

Métricas de éxito y el umbral de “no-go”

Un business case que no dice cómo se sabrá si funcionó es una apuesta sin condiciones de pago. Antes de construir hay que fijar dos cosas (el detalle de cómo se diseñan estas métricas es el módulo 7, métricas y KPI; aquí basta con anticiparlo):

• La métrica de éxito: el número que, medido en producción a los N meses, dice que el caso se cumplió. En el ejemplo del asistente: “35% de desvío efectivo sostenido a los 3 meses, sin caída de satisfacción”.
• El umbral de “no-go”: el nivel por debajo del cual el proyecto se detiene, escrito de antemano. “Si a los 2 meses el desvío efectivo está bajo 20%, se corta.” Escribirlo antes de empezar es lo que impide el pecado más caro de los productos de IA: seguir invirtiendo en algo que no funciona porque ya se invirtió mucho (la falacia del costo hundido — el dinero ya gastado que no se recupera y que, por tanto, no debería influir en la decisión de seguir).

Artefacto: el one-pager de business case

Todo lo anterior cabe en una página. Si no cabe, todavía no lo entiendes lo suficiente. Esta es la plantilla, en markdown, lista para copiar y rellenar. Una página fuerza las decisiones que un documento de veinte esconde.

# Business case — [Nombre del producto]

**Autor:** [nombre]  ·  **Fecha:** [fecha]  ·  **Decisión pedida:** [ver abajo]

## 1. Problema
[Una frase: quién sufre qué fricción, con qué frecuencia.
Enlaza al problema enmarcado en el módulo 1.]

## 2. Valor cuantificado
- Canasta: [reducción de costo / aumento de ingreso / reducción de riesgo]
- Estimación: [rango] — caso central [número]
- Supuestos: [volumen, costo unitario, tasa de adopción]

## 3. Solución propuesta
[Dos o tres frases. Qué construimos, no con qué tecnología lo
construimos. La tecnología va en un anexo, no aquí.]

## 4. Costo estimado (TCO año 1)
| Componente        | Una vez | Recurrente/año |
|-------------------|---------|----------------|
| Desarrollo        |         |                |
| Inferencia        |         |                |
| Datos + evals     |         |                |
| Monitoreo + mant. |         |                |
| Supervisión human.|         |                |
| **Total**         |         |                |

## 5. ROI
- Valor neto/año: [número honesto, no el optimista]
- ROI año 1: [(valor − costo) / costo]
- Punto de equilibrio: [en qué mes el acumulado cruza cero]

## 6. Riesgos
- [Riesgo 1 y su mitigación]  ·  [Riesgo 2 y su mitigación]

## 7. Métrica de éxito y umbral de no-go
- Éxito: [métrica, valor objetivo, plazo]
- No-go: [umbral por debajo del cual se corta, plazo]

## 8. Decisión pedida
[Exactamente qué se pide: aprobar presupuesto de X para un piloto
de N semanas, con la revisión de continuidad en la fecha F.]

El campo que más gente olvida es el 8. Un business case que no pide una decisión concreta no es un caso: es un informe. Pide algo medible y acotado — casi siempre un piloto con presupuesto y fecha de revisión, no el producto entero de una vez.

La ecuación de valor y el umbral de decisión

El diagrama resume la lógica entera del módulo: el valor cuantificado se enfrenta al costo total, y solo la fracción capturada por encima del costo es lo que de verdad justifica el proyecto.

        LA ECUACIÓN DE VALOR DE UN BUSINESS CASE

  valor del problema (en dinero o tiempo)
  ┌─────────────────────────────────────────┐
  │█████████████████████████████████████████│
  └─────────────────────────────────────────┘
        │                          │
        │ fracción que la          │ fracción que
        │ solución captura         │ NO capturas
        ▼                          ▼
  ┌───────────────┐          ┌──────────────┐
  │    valor      │          │  queda sin   │
  │  capturado    │          │  resolver    │
  └───────┬───────┘          └──────────────┘
          │
          │  se le resta el COSTO TOTAL (TCO)
          ▼
  ┌─────────────────────────────────────────┐
  │   ¿valor capturado  >  costo total?     │
  └────────────────────┬────────────────────┘
                       │
          ┌────────────┴────────────┐
       sí │                         │ no
          ▼                         ▼
   ┌──────────────┐         ┌────────────────┐
   │   GO: caso   │         │ NO-GO: el caso │
   │  se aprueba  │         │ no se sostiene │
   └──────────────┘         └────────────────┘

La lección visual: el proyecto no se justifica porque el problema sea grande (barra de arriba grande). Se justifica porque la fracción que capturas menos el costo total sigue siendo positiva. Un problema enorme con una solución que captura poco y cuesta mucho es un mal business case, por muy impresionante que suene el problema.

Errores comunes

• Vender la tecnología en vez del resultado. “Usaremos IA generativa de vanguardia” no es un caso de negocio; es un titular. El caso es “reducimos el costo de soporte en un rango de X a Y”. Nadie aprueba presupuesto por la tecnología, lo aprueban por el resultado.
• Calcular el costo como el precio del token. La API es la punta del iceberg. Datos, evals, monitoreo, mantenimiento y supervisión humana suelen sumar más que la inferencia. Un denominador solo-tokens produce un ROI de fantasía.
• Contar el mejor caso como el caso esperado. El 45% de la demo se vuelve el 35% de producción, y la adopción no es del 100% el día uno. Usa el número honesto en el ROI y guarda el optimista para el anexo.
• Números de punto, sin rango ni supuestos. “Ahorraremos 40.000” es una afirmación que no se puede discutir sin discutirte a ti. “Entre 25.000 y 55.000, suponiendo X” invita a discutir el supuesto, que es la conversación correcta.
• Evaluar el caso contra no hacer nada. Casi todo gana contra no hacer nada. El caso se compara con el mejor uso alternativo del mismo equipo — su costo de oportunidad.
• Olvidar la métrica de éxito y el umbral de no-go. Sin ellos no hay forma de saber si funcionó ni cuándo cortar, y el proyecto sobrevive por inercia y costo hundido.
• Un caso que no pide una decisión. Si al final no hay una petición concreta y acotada (aprobar X para un piloto de N semanas), no escribiste un business case: escribiste un informe que nadie va a accionar.

La frase para llevarse

“Un problema grande no es un buen negocio. Un buen negocio es capturar una fracción de ese problema por menos de lo que cuesta capturarla — y el costo incluye todo lo que la demo no te mostró.”

Qué viene

Módulo 3: viabilidad, datos y factibilidad. El business case dice que vale la pena; el siguiente paso es si de verdad se puede. Un caso de negocio precioso se estrella cuando no existen los datos para entrenar o evaluar, cuando la calidad alcanzable no llega al umbral que el negocio necesita, o cuando la integración con los sistemas existentes es más cara que todo lo demás junto. Vamos a separar tres preguntas que suelen confundirse — ¿tenemos los datos?, ¿el modelo puede llegar a la calidad requerida?, ¿podemos integrarlo? — y a construir la evaluación de factibilidad que evita aprobar un caso que la realidad técnica no puede cumplir. Un business case sin prueba de viabilidad es una promesa que aún no sabes si puedes mantener.

Material relacionado

• Módulo 1: ¿es esto un problema de IA?
• Módulo 3: viabilidad, datos y factibilidad
• Módulo 6: priorización
• Módulo 8: presupuesto y FinOps
• Fundamentos: modelos de IA y sus costos
• Glosario de Producto de IA