El módulo 3 nos dejó la vara: 0,88 por correo en el caso A, un rango de ingreso incremental en el B. El paso 5 de la metodología pregunta cuánto costaría el sistema que compite contra esa vara — y la respuesta exige entender algo que descoloca a cualquiera que venga del software tradicional: en IA, cada uso cuesta plata. El software clásico también tiene costos variables (cómputo, almacenamiento, soporte), pero servir al usuario un millón y uno suele costar casi lo mismo que servir al millón. Un sistema sobre una API de LLM típicamente paga por cada token, en cada llamada, mientras exista (hay otras modalidades — capacidad reservada, modelos alojados —, pero el costo por uso sigue ahí). La economía se parece menos a “software” y más a una fábrica con costo variable por unidad.

Este módulo calcula ese costo variable de verdad, con precios reales. La teoría general ya está en el catálogo — presupuesto y FinOps enseña la economía unitaria, el desglose completo del gasto y el catálogo de palancas — así que aquí no la repetimos: la aplicamos al embudo. Lo propio de este módulo es llegar al costo por tarea del caso A línea por línea, compararlo contra el baseline del módulo 3, y ver cómo la elección de gama de modelo interactúa con la revisión humana — la decisión que un caso de uso debe traer resuelta al comité.

La tesis del módulo

El costo por tarea de un sistema de IA tiene tres capas — tokens, infraestructura y humanos — y crecen en ese orden de magnitud: la inferencia suele ser centavos, la infraestructura céntimos más, y el humano en el circuito domina la cuenta en cuanto aparece. Quien costea solo los tokens no está siendo optimista: está costeando otro sistema, uno sin supervisión, que probablemente no es el que va a construir.

Los precios: cómo leerlos sin marearse

Los modelos se cobran por millón de tokens (MTok), con precio distinto para entrada (lo que el modelo lee) y salida (lo que genera). Cuántos tokens ocupa un texto depende del tokenizer de cada modelo y del idioma: en inglés un token rinde ~¾ de palabra; en español suele rendir menos (más tokens por palabra), así que mide con el tokenizer real en vez de estimar. Los órdenes de magnitud de precios de lista vigentes al escribir esto (septiembre de 2026, tomando como referencia las gamas de Anthropic; cada proveedor, modelo y modalidad cobra distinto y los precios cambian rápido — verifica siempre la página del proveedor):

Gama	Ejemplo de precio (USD/MTok)	Cuándo usarla
Económica	~$1 entrada / ~$5 salida	Clasificar, extraer, tareas simples de volumen
Media	~$3 entrada / ~$15 salida	Redactar, razonar sobre contexto, la mayoría
Alta	~$5-10 entrada / ~$25-50 salida	Razonamiento complejo, agentes de largo aliento

Dos observaciones que ordenan cualquier estimación:

En estas tarifas, la salida cuesta ~5× la entrada (el ratio varía por proveedor). Un sistema que lee mucho y escribe poco (clasificar 2.000 tokens y responder “facturación”) es estructuralmente barato; uno que escribe mucho (redactar informes largos) es estructuralmente caro. Mirar el ratio lectura/escritura del caso te dice su naturaleza económica antes de cualquier cálculo.
Entre gamas hay 3-10× de diferencia. Elegir gama no es un detalle técnico: es la decisión económica más grande del diseño, y por eso pertenece al caso de uso, no solo al equipo de ingeniería.

Para seguir con los números del curso, tratamos la moneda ilustrativa de los módulos anteriores como dólares — los precios de modelos se publican en USD.

El costo por tarea, capa por capa

COSTO DE UNA TAREA — LAS TRES CAPAS

START ──► ┌──────────┐     ┌──────────┐     ┌──────────┐
          │  tokens  │ ──► │  infra   │ ──► │  humano  │
          │ entrada+ │     │ logs, BD │     │ revisa el│
          │  salida  │     │ y colas  │     │ % dudoso │
          └──────────┘     └──────────┘     └────┬─────┘
            centavos       céntimos más          │
                                                 ▼
                             la capa que domina la cuenta

Capa 1: tokens — el caso A, calculado

Triaje de un correo con un modelo de gama media ($3 / $15 por MTok). Entrada: el correo (~500 tokens) + instrucciones y categorías (~1.200 tokens) + ejemplos (~300) ≈ 2.000 tokens. Salida: categoría, prioridad y borrador de respuesta corta ≈ 300 tokens.

COSTO DE TOKENS POR CORREO (gama media)

  entrada: 2.000 tok × $3/MTok    = $0,0060
  salida:    300 tok × $15/MTok   = $0,0045
  ──────────────────────────────────────────
  por correo                      = $0,0105
  × 12.000 correos/mes            = $126/mes

$126 al mes contra un baseline de $10.608. La primera lección del módulo: la inferencia casi nunca es el problema. La segunda: ese número es frágil, porque tres factores lo multiplican:

Los reintentos y la variabilidad. Si el 8% de las salidas falla la validación y se reintenta, el costo sube 8%. Trivial aquí; no tan trivial cuando cada tarea cuesta dólares.
Los agentes. Si en vez de una llamada el sistema es un agente que consulta el CRM, busca el historial y decide en 6-10 pasos, cada tarea son 6-10 llamadas y el contexto se re-lee en cada una: el costo no suma, multiplica. En este ejemplo, un agente de 8 pasos sobre el mismo correo podría costar del orden de 15-30× la llamada única (el múltiplo real depende de cuánto contexto se re-lee y del caché). La regla de diseño económico: usa el flujo simple que resuelva el caso, no el agente que impresiona en la demo.
El contexto gordo. Meter “por si acaso” 20.000 tokens de manual en cada llamada multiplica la entrada ×10. El contexto se diseña, no se acumula.

Y dos palancas lo dividen:

El caché de prompt. La parte repetida de la entrada (instrucciones, categorías, ejemplos — los 1.500 tokens que van en todas las llamadas) puede cachearse: las lecturas de caché cuestan ~0,1× el precio normal. En el caso A, 500 tokens a precio pleno + 1.500 a 0,1× = 650 tokens efectivos de 2.000: la entrada baja ~67%, y los tokens del mes quedan en ~$77 (los $80 de abajo). Con condiciones: escribir en el caché cuesta más que una lectura normal (~1,25× en las tarifas de referencia), el caché expira si no se usa y cada miss se paga completo — el ahorro real depende del tráfico.
El batch. Lo que no necesita respuesta inmediata (análisis nocturno, resúmenes diarios) suele tener ~50% de descuento procesándolo por lotes, a cambio de aceptar latencia de horas. El triaje es interactivo y no aplica; el análisis de llamadas del arquetipo B, sí.

Capa 2: infraestructura

Todo lo que rodea al modelo: base de datos (historial, vectores si hay búsqueda), colas, logs y observabilidad, el servicio que integra con el correo. Para un caso como el A, decenas a pocos cientos de dólares al mes — digamos $150/mes ilustrativos. Rara vez decide el caso, pero omitirla es el clásico “costeo de demo”. El detalle de operar esto en serio es el curso de Deploy.

Capa 3: el humano en el circuito

Aquí se decide la economía real. El sistema clasifica con confianza el 80% de los correos; el 20% dudoso (2.400/mes) lo revisa una persona a 2 minutos por correo:

COSTO DEL HUMANO EN EL CIRCUITO

  2.400 correos × 2 min           = 80 horas/mes
  80 h × $12/h                    = $960/mes

$960 contra $126 de tokens: la revisión humana cuesta 7,6× la inferencia. Es el mismo patrón que prod-08 documenta a nivel de producto (el costo humano escondido en otra planilla domina la ecuación) — y verlo repetirse en el caso A no es casualidad: es un patrón frecuente en cuanto hay revisión humana. Esta fila tiene además una propiedad que las demás no: escala con el volumen y con la desconfianza. Si la calidad del modelo cae (deriva, cambio de proveedor, casos nuevos), el porcentaje revisado sube y la fila se traga el ahorro. Por eso el costo por tarea honesto del caso A no es $0,0105 — es:

COSTO POR TAREA COMPLETO — CASO A (mensual)

  tokens (con caché)              ≈ $   80
  infraestructura                 ≈ $  150
  humano en el circuito           ≈ $  960
  ──────────────────────────────────────────
  total operación                 ≈ $1.190/mes
  costo por correo                ≈ $0,10

  baseline (módulo 3)             = $0,88/correo
  ahorro bruto operativo          ≈ 89%

El caso sigue siendo excelente — pero nota que el número defendible ($0,10 por correo) es ~10× el número de la demo ($0,0105). El múltiplo exacto es de este caso, no una ley: depende de cuánta revisión humana e infraestructura haya. La lección que sí generaliza: cuando alguien te presente un caso costeado solo en tokens, trata ese número como un piso, no como una estimación, y pide las otras dos capas.

La curva costo-calidad

La última pieza: gama de modelo y porcentaje revisado no son independientes. Un modelo de gama económica clasifica peor → más correos dudosos → más revisión humana. Uno de gama alta clasifica mejor → menos revisión → pero cada llamada cuesta más. El óptimo no se adivina: puede estar en un extremo o en una cascada, donde el modelo barato resuelve lo fácil y escala lo difícil al modelo caro (el model routing de la tabla de palancas de prod-08, aquí con los números del caso puestos).

Diseño	Tokens/mes	Revisión/mes	Total/mes
Todo gama económica	~$30	30% dudoso → $1.440	~$1.620
Todo gama media	~$80	20% dudoso → $960	~$1.190
Cascada (85% eco + 15% media)	~$45	22% dudoso → $1.056	~$1.250
Todo gama alta	~$200	12% dudoso → $576	~$925

La tabla es ilustrativa — los porcentajes de dudosos son supuestos, no mediciones — y en este escenario gana un extremo: el modelo más caro puede ser el diseño más barato, porque la fila que domina es la humana. En otro caso ganará la cascada o el económico. La única forma de saberlo es llenar esta tabla con evals reales sobre los datos del caso — que es exactamente el tipo de análisis que un caso de uso serio trae al comité y una demo no.

Errores comunes

Costear la demo, no el sistema. El costo de tokens de la llamada feliz omite reintentos, contexto real, agentes y — sobre todo — la revisión humana. Trata los tokens como piso y calcula las tres capas.
Elegir gama de modelo por reflejo (“el barato para ahorrar”). La gama se elige con la tabla costo-calidad completa, incluyendo lo que la calidad le hace a la fila humana. El barato puede ser el más caro.
Diseñar agente donde bastaba una llamada. Un agente de 6-10 pasos re-lee el contexto en cada uno y multiplica el costo (en el ejemplo, del orden de 15-30×). El agente se justifica cuando la tarea lo exige, no porque es 2026.
Ignorar caché y batch. Son 50-90% de descuento sobre partes del gasto, con poco esfuerzo (y con sus condiciones: escrituras de caché, expiración, latencia del batch). No usarlas en un caso de volumen es dejar plata en la mesa desde el diseño.
Asumir que el % revisado es fijo. Es la variable más viva del sistema: sube con la deriva, con casos nuevos, con pérdida de confianza del equipo. El módulo 7 la mete al análisis de sensibilidad por esta razón.
Presentar el costo como punto y no como estructura. “$1.190/mes” informa menos que “$0,10/correo, dominado por revisión humana al 20%”. La estructura dice qué palancas existen; el punto, no.

La frase para llevarse

“El software clásico cuesta construirlo; la IA cuesta cada vez que la usas. Costea las tres capas — tokens, infraestructura, humanos — y recuerda que el costo de tokens de la demo es un piso, no una estimación: en cuanto hay revisión, la fila que manda suele respirar.”

Qué viene

Módulo 5: el TCO y el método AWS. El costo por tarea es la operación; falta todo lo demás — construir, integrar, evaluar, mantener, y la parte que casi nadie suma: la plataforma compartida que el primer caso de uso paga. Vamos a armar el costo total de propiedad con la disciplina de los frameworks de negocio de cloud (Cloud Value Framework, Migration Evaluator) — que llevan veinte años resolviendo exactamente este problema: comparar honestamente el statu quo contra el mundo nuevo, sin esconder costos en ninguno de los dos lados.

Casos de uso de IA — Módulo 4: la economía de la IA