El módulo 4 cerró con el costo de operar el caso A: $0,10 por correo. Pero operar es solo una parte de tener. Falta construirlo, integrarlo, evaluarlo, mantenerlo cuando el proveedor cambie el modelo, y — la parte que este módulo aporta al catálogo — la porción de plataforma compartida que alguien tiene que pagar. El TCO (Total Cost of Ownership, costo total de propiedad) es la suma honesta de todo eso a lo largo de la vida del sistema.

Para armarlo bien no hace falta inventar nada: la industria cloud lleva dos décadas puliendo la disciplina de comparar “quedarse como estás” contra “moverse a lo nuevo” sin hacer trampa en ninguno de los dos platillos. AWS la codificó en dos herramientas — el Cloud Value Framework y el Migration Evaluator —, ambas pensadas para migraciones cloud. Llevarlas a casos de uso de IA es una adaptación metodológica de este curso, no un método oficial de AWS para aprobar casos de IA; pero sus dos lecciones centrales se trasladan bien. Este módulo las importa.

La tesis del módulo

Un TCO honesto exige la misma disciplina en los dos platillos de la balanza: el mundo nuevo con todos sus costos ocultos (evals, mantenimiento, plataforma) y el statu quo con todos los suyos (crecimiento del volumen, errores, oportunidades perdidas). La trampa habitual es comparar un futuro idealizado contra un presente congelado. El método cloud lo corrige con dos movimientos: medir el statu quo completo antes de proponer, y valorar más allá del ahorro puro.

El TCO de un caso de IA: la tabla completa

El módulo 2 de Producto presenta el desglose base (desarrollo, inferencia, datos, evals, monitoreo, mantenimiento, supervisión). Lo que la metodología agrega aquí son las dos filas que ese desglose no separa y que deciden casos:

Componente	Una vez / recurrente	El caso A (ilustrativo)
Desarrollo e integración	Una vez	$18.000
Evals (suite inicial + por cambio)	Una vez + goteo	$4.000 + $2.000/año (desde año 2)
Operación (módulo 4: 3 capas)	Recurrente	$14.280/año
Mantenimiento y deriva	Recurrente	$3.000/año
Cuota de landing zone	Una vez (compartible)	$12.000
Apagar el proceso viejo	Una vez	$3.000
TCO año 1		$54.280
TCO año 2+		$19.280/año

La cuota de landing zone. El caso A necesita gateway, control de gasto, enmascaramiento de datos y guardrails — piezas que no son de este caso sino de todos los casos. El módulo 6 las detalla; aquí importa la decisión contable, que veremos al final.
Apagar el proceso viejo. Exclusiva del arquetipo A y sistemáticamente olvidada: migrar, capacitar, redefinir roles, correr en paralelo unas semanas. El ahorro solo existe cuando el proceso viejo de verdad se achica, y achicarlo cuesta. Un arquetipo A que no presupuesta el apagado termina pagando dos procesos — el nuevo y el viejo “por si acaso”.

Lección 1 del método AWS: mide el statu quo completo (Migration Evaluator)

El Migration Evaluator es la herramienta con la que AWS arma casos de negocio de migración, y su rasgo distintivo no es cómo calcula el costo de la nube — es cuánto insiste en calcular bien el costo de quedarse: no solo los servidores, sino los ciclos de renovación de hardware, los contratos de mantenimiento, las licencias. Porque el error clásico del comprador es comparar el precio de lo nuevo contra una foto incompleta de lo viejo.

Trasladado a IA, el statu quo del caso A no es solo los $10.608/mes del módulo 3. Quedarse también cuesta:

Crecimiento. Si el volumen de correos crece 15% anual, el statu quo de año 3 no cuesta $127K/año — cuesta $168K, más la contratación y capacitación que ese crecimiento exige. Y la simetría corre para los dos lados: con 15% más de correos, el sistema de IA también crece — más revisión humana del 20% dudoso (la fila que domina su costo), más inferencia, más colas y más soporte. La comparación justa proyecta ambos platillos con el mismo crecimiento; en este caso el de IA crece mucho menos en dinero, porque solo una fracción del volumen toca a un humano, y en horizontes de varios años esa diferencia puede ser el argumento más fuerte del caso.
El costo del error actual. El 7% de correos mal derivados del baseline no es gratis: son clientes esperando y reprocesos. Ya lo medimos — ahora entra al platillo del statu quo.
La rigidez. El proceso humano tiene horario, vacaciones y rotación (con su curva de aprendizaje). No siempre se monetiza, pero se declara.

Ojo: esto no es licencia para inflar el platillo viejo hasta que lo nuevo gane. Cada costo del statu quo entra con la misma exigencia que el baseline del módulo 3: medido o anclado en un dato, con supuesto explícito. La disciplina es simétrica o no es disciplina.

Lección 2: el valor tiene cinco pilares (Cloud Value Framework)

La segunda lección corrige el sesgo opuesto: evaluar solo por ahorro. El Cloud Value Framework de AWS estructura el valor de una adopción tecnológica en cinco pilares, porque en muchas migraciones el ahorro directo no resultó ser el valor más grande:

Pilar CVF	En cloud significaba	En un caso de IA significa
Ahorro de costos	Menos data center	El ahorro contra baseline (caso A)
Productividad del equipo	Menos ops manual	Horas liberadas hacia trabajo de más valor
Resiliencia operativa	Menos caídas	Menos errores, cobertura 24/7, sin colas
Agilidad de negocio	Lanzar más rápido	Capacidades nuevas: el arquetipo B entero
Sostenibilidad	Menos huella	Eficiencia de recursos (aún incipiente en IA)

La utilidad práctica es doble. Primero, como checklist de valor no contado: el caso A se justifica por el pilar 1, pero los pilares 2 y 3 (el equipo liberado atiende mejor lo complejo; el error baja del 7%) existen y se anotan como upside. Segundo — y más importante — como lente de arquetipos: el arquetipo A vive en los pilares 1-3 y el arquetipo B vive en el pilar 4. Un comité que solo mira el pilar 1 aprobará automatizaciones y matará toda capacidad nueva; uno que solo mira el 4 acumulará apuestas sin retorno. El portafolio sano puntúa en los dos.

Build vs buy vs API, decidido por arquetipo

El TCO cambia radicalmente según qué se construye y qué se compra. La decisión completa es el módulo 4 de Producto; la metodología aporta el atajo por arquetipo:

Opción	Cuándo gana	Sesgo por arquetipo
Comprar SaaS con IA	El caso es genérico (triaje, resúmenes)	A genéricos: casi siempre evalúa comprar 1º
API + desarrollo propio	El caso usa TU contexto y datos	B con frecuencia; A con procesos propios
Fine-tuning (ajustar un modelo existente)	Tarea estrecha y estable donde el prompt no alcanza	Excepción, no punto de partida
Entrenar o alojar modelo propio	Escala enorme o requisito duro de control	Excepción aún mayor

La razón del sesgo: los arquetipos A genéricos son mercados — si tu proceso es como el de mil empresas, alguien ya vende la solución con el TCO amortizado entre mil clientes. Los arquetipos B suelen ser capacidades que te distinguen, y comprarlas genéricas las vuelve genéricas — pero no siempre: un flujo nuevo para tu empresa puede ser estándar en el mercado, y entonces un SaaS configurable es la opción sensata. Fine-tuning tampoco equivale a tener modelo propio: se ajusta un modelo existente, a menudo por API, sin entrenarlo ni alojarlo.

El impuesto de plataforma: ¿quién paga la landing zone?

Queda la decisión contable de la fila nueva. La landing zone cuesta (ilustrativamente) $12.000 y el caso A es el primero en necesitarla. Tres formas de contabilizarla:

¿QUIÉN PAGA LA LANDING ZONE?

     ┌───────────────────────────────┐
     │     landing zone: $12.000     │
     └───┬───────────┬───────────┬───┘
         │ opción 1  │ opción 2  │ opción 3
         ▼           ▼           ▼
   el caso 1     inversión    se difiere
   la paga       de cartera   "para después"
   entera        (separada)   sin decidirlo

Opción 1 — el caso 1 la paga entera. Honesta pero injusta: castiga al pionero por costos que los casos 2..N usarán gratis, y sesga el portafolio hacia no empezar nunca.
Opción 2 — inversión de plataforma separada. La landing zone se aprueba como proyecto propio, justificado por la cartera de casos del embudo (los 3 candidatos del módulo 2, no solo el primero). Es la opción correcta cuando el embudo tiene más de un caso serio — que es exactamente lo que la metodología garantiza.
Opción 3 — diferirla. Salir a producción sin gateway, sin control de gasto, sin guardrails, “mientras validamos”. Es la opción que no se elige: se cae en ella. El módulo 6 muestra su precio real.

La regla práctica del curso (una heurística, no una norma contable): si el embudo tiene ≥2 candidatos serios que la necesitan, conviene tratar la landing zone como inversión de cartera (opción 2) y que cada caso cargue solo su operación. Dos candidatos no garantizan que la plataforma se reutilice, así que la opción 2 tiene dos condiciones: el ROI de la cartera sí incluye la plataforma — su construcción y su operación (equipo, soporte, actualizaciones), que no se vuelven a contar en la infraestructura de cada caso —, y la cartera se revisa si los casos hermanos no llegan. Si de verdad hay un solo caso a la vista, el caso la paga (opción 1) — y que el ROI aguante, porque no habrá hermanos con quien repartir.

Errores comunes

Comparar el futuro ideal contra el presente congelado. El statu quo también crece, también falla y también cuesta. Migration Evaluator en una frase: mide lo viejo con el mismo rigor que presupuestas lo nuevo.
Evaluar todo por el pilar 1. Un comité que solo entiende ahorro mata sistemáticamente el arquetipo B. El CVF existe para nombrar el valor de agilidad y capacidad nueva sin dejar de exigirle números (módulo 3: contrafactual).
Olvidar el costo de apagar lo viejo. Sin presupuesto de apagado, el arquetipo A termina con dos procesos vivos y el ahorro en cero. Es una fila del TCO, no una nota al pie.
Construir lo genérico y comprar lo diferencial. Es el sesgo exactamente invertido: pagar desarrollo propio para un triaje que venden diez SaaS, y comprar genérico el cotizador que era tu ventaja.
Cargar toda la plataforma al primer caso. El pionero muere de impuesto y la organización concluye que “la IA no da ROI”. Con embudo de ≥2 casos serios, la landing zone se evalúa como inversión de cartera — y se cobra en el ROI de la cartera.
Diferir la plataforma sin decidirlo. La opción 3 nunca aparece en un acta: aparece en el postmortem. Si se difiere, que sea una decisión escrita con fecha de revisión, no una omisión.

La frase para llevarse

“El método cloud cabe en dos frases: mide el costo completo de quedarte antes de vender el cambio, y valora el cambio en cinco pilares antes de reducirlo a ahorro. Y cuando llegue la cuenta de la plataforma, repártela en la cartera — o el primer caso pagará el peaje de todos los que vienen detrás.”

Qué viene

Módulo 6: la landing zone de IA. Le debemos el detalle a esa fila de $12.000: qué contiene exactamente la plataforma mínima que los casos comparten — el LLM gateway, el FinOps de plataforma, la persistencia, los reintentos y fallbacks, la ofuscación de datos, los guardrails y el manejo de datos críticos. Componente por componente: qué es, qué pasa si falta, y cuál es el mínimo viable según el riesgo del caso — porque tampoco se trata de construir seis meses de plataforma antes del primer piloto.

Casos de uso de IA — Módulo 5: TCO y el método AWS