En el módulo 7 armamos el árbol de KPI y, entre las métricas guardrail (las que no pueden empeorar mientras persigues la métrica estrella), pusimos una que quedó ahí anotada como un número que hay que vigilar: el costo por tarea. La tratamos como un semáforo. Este módulo la toma en serio como disciplina. Porque un producto de software tradicional tiene un costo marginal casi cero —servir una petición más no te cuesta prácticamente nada—, y por eso durante veinte años el manual de producto digital fue “crece primero, monetiza después”. Un producto de IA rompe esa regla: cada consulta que respondes consume tokens, GPU y a veces un humano que revisa, y todo eso se factura. El costo marginal dejó de ser cero. Eso cambia por completo cómo se piensa el dinero.

La tesis del módulo

Un producto de IA cobra por uso, así que su economía se decide por tarea, no por mes; si el costo de resolver una tarea es mayor al valor que entrega, más usuarios te hunden más rápido — la rentabilidad es un problema de diseño, no de facturación.

La frase incómoda de arriba es literal. En un SaaS clásico, un usuario que usa mucho el producto es tu mejor cliente: te paga lo mismo y casi no te cuesta. En un producto de IA, un usuario que usa mucho el producto puede ser el que te hace perder plata, si tu precio es plano y tu costo es por uso. La rentabilidad no se arregla el día de la facturación con un plan más caro: se arregla en el diseño del sistema —qué modelo usas, cuánto contexto le mandas, cuándo interviene un humano—. FinOps es la disciplina que conecta esas dos cosas.

Qué es FinOps y qué significa aplicado a IA

FinOps (contracción de Finance + DevOps; disciplina y práctica cultural de gestión financiera del gasto en la nube que reúne a finanzas, ingeniería y negocio para que las decisiones de costo se tomen con datos y a tiempo). Nació en el mundo cloud para un problema muy concreto: cuando cualquier ingeniero puede levantar infraestructura con una línea de comando, el gasto deja de vivir en una compra anual que aprueba el CFO y pasa a ocurrir mil veces al día, distribuido. FinOps no es “recortar costos”; su meta declarada es maximizar el valor de negocio de lo que gastas. Recortar es una consecuencia posible, no el objetivo.

Aplicado a IA, FinOps se resume en tres movimientos que vas a ver repetirse en todo el módulo:

Hacer visible el costo. No puedes gestionar lo que no mides. El primer paso siempre es instrumentar: saber cuánto cuesta cada tarea, cada feature, cada usuario.
Asignar el costo a quien lo genera. Un número global mensual no acciona nada. El costo tiene que atribuirse a la feature, al equipo o al segmento de usuario que lo produce, o nadie se hace cargo.
Optimizarlo continuamente. No es un proyecto de “reducción de costos” de una vez al año. Es un bucle: mides, encuentras el gasto gordo, aplicas una palanca, vuelves a medir.

Ojo: FinOps de IA es más volátil que el FinOps de cloud tradicional. En cloud, el precio de una máquina virtual es estable por meses. En IA, un proveedor puede sacar un modelo nuevo que cuesta la décima parte, o subir el precio, o tú puedes cambiar un prompt y duplicar los tokens sin darte cuenta. El gasto se mueve semana a semana. Por eso la instrumentación no es opcional.

La economía unitaria: por qué el costo por tarea es la cifra que importa

Economía unitaria (unit economics: los ingresos y costos asociados a una sola unidad de tu producto —una tarea, una consulta, un usuario activo— en vez del total agregado). Es la lente de este módulo. El total mensual te dice si sobrevives este mes; la economía unitaria te dice si el negocio funciona a escala.

La razón es puramente aritmética. Si cada tarea te cuesta más de lo que te deja, entonces:

  ganancia = (valor_por_tarea − costo_por_tarea) × volumen

Cuando el paréntesis es negativo, subir el volumen no te acerca a la rentabilidad: te aleja más rápido. Es la trampa clásica de “perdemos plata en cada venta, pero lo compensamos con volumen”, que no compensa nada. Por eso el número que un product manager de IA revisa cada semana no es el gasto total —ese sube con el crecimiento y no dice nada por sí solo—, sino el costo por tarea y su relación con el valor que esa tarea entrega.

Ejemplo trabajado: descomponer el costo de una consulta

Tomemos un asistente que responde preguntas sobre documentos internos (un caso de RAG). Las cifras son ilustrativas —precios y volúmenes de ejemplo para mostrar el método, no datos de un producto real. Queremos el costo de una consulta:

# Precios de ejemplo (USD por millón de tokens). Ilustrativos.
PRECIO_ENTRADA = 3.00 / 1_000_000   # tokens de entrada (contexto + pregunta)
PRECIO_SALIDA  = 15.00 / 1_000_000  # tokens de salida (respuesta)

# Perfil de una consulta típica
tokens_entrada = 6_000   # pregunta + 8 chunks recuperados del RAG
tokens_salida  = 700     # la respuesta

# 1. Costo del modelo (inferencia)
costo_modelo = tokens_entrada * PRECIO_ENTRADA + tokens_salida * PRECIO_SALIDA
# = 6000*0.000003 + 700*0.000015 = 0.018 + 0.0105 = 0.0285 USD

# 2. Costo del retrieval (embedding de la query + búsqueda vectorial)
costo_retrieval = 0.0004  # embeddings + query a la base vectorial

# 3. Costo de tools (si la consulta llama a una API externa)
#    Solo el 30% de las consultas usan tools; se prorratea.
costo_tools = 0.30 * 0.002  # = 0.0006

# 4. Costo de la revisión humana
#    El 8% de las respuestas van a un humano que cobra ~0.50 USD por revisión.
costo_humano = 0.08 * 0.50  # = 0.04

costo_por_consulta = (costo_modelo + costo_retrieval
                      + costo_tools + costo_humano)
# ≈ 0.0285 + 0.0004 + 0.0006 + 0.04 = 0.0695 USD por consulta

Fíjate en el resultado, porque contradice la intuición: el modelo cuesta 0.028 y el humano cuesta 0.04. En este ejemplo, la revisión humana es el rubro más caro de la consulta, aunque solo toque al 8% de los casos. Es un patrón habitual: la gente optimiza obsesivamente el precio del token —el número que aparece en la factura del proveedor y por eso es el visible— mientras el costo humano, que está escondido en otra planilla, es el que domina la ecuación. La economía unitaria obliga a poner todos los costos en la misma cuenta.

De dónde sale el gasto: el desglose completo

El costo por token es la punta del iceberg. Estos son todos los rubros de un producto de IA, con proporciones típicas ilustrativas para dar un orden de magnitud (varían enormemente según el producto):

Rubro	Qué es	Peso típico	Nota
Tokens de inferencia	Lo que cobra el proveedor por cada llamada al modelo (API)	25–45%	El más visible; escala directo con el uso
GPU / serving	Arrendar o comprar GPU si auto-hospedas el modelo	0% o 30–60%	Cero si usas API; alto si te auto-hospedas
Infra	Base vectorial, cachés, colas, bases de datos, red	5–15%	Sube con RAG y con historial largo
Datos y etiquetado	Curar, limpiar y anotar datos; construir el corpus	5–20%	Alto al inicio; baja al estabilizar
Evals	Correr la suite de evaluación en cada cambio (también consume tokens)	3–10%	Se olvida siempre; no es gratis
Monitoreo	Trazas, logs, observabilidad, dashboards de costo	2–8%	El costo de ver el costo
Supervisión humana	Revisores, moderadores, human-in-the-loop	10–40%	El escondido; a menudo el mayor

La decisión de mayor impacto en esta tabla es la fila de GPU/serving, y es la misma disyuntiva del módulo 4: build vs buy vs API. Si consumes un modelo por API, tu columna de GPU es cero pero pagas un margen al proveedor en cada token. Si te auto-hospedas, la GPU aparece como un costo fijo grande que no depende del volumen —pagas la GPU esté ociosa o al máximo—. Eso invierte por completo la economía: la API conviene a volumen bajo o variable; el auto-hospedaje conviene a volumen alto y sostenido, donde el costo fijo se reparte entre muchísimas tareas. La aritmética de ese cruce está desarrollada en producción, costos y decisiones de GPU.

Estimar el presupuesto: costo por tarea × volumen, con escenarios

Con el costo por tarea en la mano, el presupuesto es una multiplicación —pero una multiplicación que hay que hacer tres veces, porque el volumen es incierto y, en IA, el éxito es lo que más encarece:

  gasto_mensual ≈ costo_por_tarea × tareas_por_mes

El error de principiante es multiplicar por un solo número de volumen (“el plan”) y presentar eso como el presupuesto. Lo correcto son tres escenarios:

Base — el volumen que esperas de verdad.
Optimista — el volumen si el producto pega. Y aquí está la vuelta de tuerca de IA: el escenario optimista es el que más asusta al CFO, porque más adopción es más costo, no menos. En un SaaS tradicional, el éxito abarata (repartes el costo fijo); en un producto de IA con costo marginal, el éxito encarece en términos absolutos. Hay que decirlo explícito en el presupuesto.
Pesimista — poco volumen. Suele ser el escenario “cómodo” de costo, pero el incómodo de negocio.

Artefacto: tabla de presupuesto por escenario

Cifras ilustrativas, reusando el costo por tarea de ~0.07 USD del ejemplo anterior:

Escenario	Tareas/mes	Costo/tarea	Gasto/mes	Ingreso/mes	Margen
Pesimista	50 000	0.070	3 500	6 000	+2 500
Base	200 000	0.070	14 000	24 000	+10 000
Optimista	800 000	0.070	56 000	96 000	+40 000

Este ejemplo está sano: el margen crece con el volumen porque el valor por tarea (aquí ~0.12) supera al costo por tarea (0.07). El día en que el costo por tarea cruce por encima del valor, esta misma tabla se vuelve roja en la fila optimista primero —y esa es exactamente la señal que FinOps existe para darte antes de que la factura llegue.

Controlar el gasto: presupuestos, alertas y límites

Estimar no es controlar. El control necesita tres mecanismos, y el tercero es el que salva la noche:

Presupuestos y alertas. Defines un techo de gasto (mensual, por feature) y configuras alertas a un porcentaje del camino —al 50%, al 80%, al 100%—, no solo cuando ya te pasaste. La alerta al 80% te da tiempo de reaccionar; la factura a fin de mes solo te informa del cadáver.
Costo como métrica de primera clase. El costo por tarea vive en el mismo dashboard que la latencia y la calidad, se revisa en la misma reunión, y tiene dueño. Si el costo solo aparece en la factura del proveedor una vez al mes, no lo estás gestionando: lo estás sufriendo.
Límites por usuario y por sesión. Un tope de tareas o de tokens por usuario, por sesión o por ventana de tiempo. Esto no es solo economía: es seguridad. Es el control directo contra el unbounded consumption (consumo sin límites: el abuso donde un actor —malicioso o un bug— dispara un volumen enorme de peticiones y te genera una factura ruinosa, a veces llamado Denial of Wallet, denegación de billetera). Sin un límite duro, una sola sesión en bucle puede costar más que todo un mes normal.

Cuidado: el límite por usuario tiene que ser un tope duro en la infraestructura, no una sugerencia en el prompt. “No respondas más de 20 veces por hora” escrito en el system prompt es una recomendación estadística que un atacante rodea. El tope que de verdad protege es el que rechaza la petición número 21 antes de que llegue al modelo. Es el mismo principio de defensa por arquitectura del módulo de red teaming: la garantía vive en el código, no en el prompt.

Palancas para bajar el costo sin romper la calidad

Aquí está el corazón del módulo. Cuando el costo por tarea es demasiado alto, hay palancas —y cada una tiene un trade-off (compensación: lo que ganas en costo lo pagas en otra dimensión). La regla de oro: ninguna palanca es gratis, y aplicarlas a ciegas rompe la calidad que tanto costó medir en el módulo 7.

Palanca	Cómo baja el costo	Qué arriesga	Cuándo usarla
Model routing (enrutar por dificultad a un modelo más chico/barato lo fácil, reservando el caro para lo difícil)	Mueve la mayoría del volumen al modelo barato	Mala clasificación: manda lo difícil al chico y baja la calidad	Casi siempre; es la palanca de mayor retorno
Caché de prompts / respuestas	No paga dos veces por lo mismo (prompt repetido o respuesta idéntica)	Respuestas obsoletas si el dato cambió	Prompts de sistema largos y preguntas repetidas
Prompts más cortos	Menos tokens de entrada en cada llamada	Menos contexto puede bajar la calidad	Cuando el prompt tiene relleno inútil
RAG en vez de contexto gigante	Recupera solo los trozos relevantes en vez de meter todo el documento	Si el retrieval falla, la respuesta empeora	Bases de conocimiento grandes
Batch (procesar en lote lo que no es urgente, a tarifa reducida)	Muchos proveedores cobran menos por trabajo diferido	No sirve para lo interactivo (introduce demora)	Tareas de fondo, no de chat en vivo
Cuantización / self-host a volumen	Modelo más liviano y/o costo fijo repartido entre mucho volumen	Costo fijo alto; ligera baja de calidad al cuantizar	Volumen alto y sostenido

Hay una palanca que quedó fuera de la tabla a propósito, porque es la palanca-trampa: la tentación de usar razonamiento caro (modelos que “piensan” con cadenas largas de tokens intermedios antes de responder) para todo, porque sube la calidad en los benchmarks. Pero ese razonamiento se paga en tokens —muchos—, y en la mayoría de las tareas de un producto real no aporta nada que justifique el costo. La disciplina es reservarlo para las tareas que de verdad lo necesitan y enrutar el resto a algo más barato; el análisis de cuándo el razonamiento en producción vale su precio está en razonamiento en producción.

El diagrama: la cascada de costo de una tarea

Cada tarea acumula costo a medida que atraviesa el sistema. Verlo como cascada muestra dónde muerde cada palanca:

        LA CASCADA DE COSTO DE UNA TAREA

  entrada
    │
    ▼
 ┌──────────────┐   palanca: prompt corto,
 │  contexto +  │◄── caché, RAG (menos
 │   prompt     │    tokens de entrada)
 └──────┬───────┘
        │
        ▼
 ┌──────────────┐   palanca: model routing,
 │    modelo    │◄── cuantización, batch
 │ (inferencia) │    (modelo más barato)
 └──────┬───────┘
        │
        ▼
 ┌──────────────┐   palanca: cachear la
 │ tools /      │◄── llamada, evitar la
 │ retrieval    │    tool si no aporta
 └──────┬───────┘
        │
        ▼
 ┌──────────────┐   palanca: subir la
 │  revisión    │◄── confianza del auto
 │   humana     │    para revisar menos
 └──────┬───────┘
        │
        ▼
  COSTO TOTAL DE LA TAREA

El diagrama deja clara la lección de FinOps: no hay una sola palanca mágica: hay una en cada escalón, y el costo total es la suma de todas. La revisión humana, abajo del todo, suele ser el escalón más caro y el que menos se optimiza —porque no aparece en la factura del proveedor de IA, sino en la nómina.

Errores comunes

Mirar el gasto total mensual y no el costo por tarea. El total sube con el crecimiento y no dice si el negocio funciona. La unidad que decide la rentabilidad es la tarea, no el mes.
Optimizar solo el precio del token. Es el rubro visible, pero rara vez el mayor. La supervisión humana, la infra y el retrieval a menudo pesan más y quedan fuera de la cuenta.
Presupuestar con un solo escenario. El plan optimista es el que más encarece en IA, y es justo el que hay que poner sobre la mesa: el éxito cuesta plata, no la ahorra.
Confiar en la factura de fin de mes como control. Para cuando llega, el daño ya ocurrió. El control son alertas al 50/80% y límites duros por usuario, no un informe post mortem.
Dejar el límite de consumo en el prompt. “No respondas más de N veces” es una sugerencia que se rodea. El tope contra el Denial of Wallet vive en la infraestructura o no existe.
Aplicar palancas a ciegas. Bajar el modelo o recortar el prompt sin medir la calidad convierte un ahorro en una degradación silenciosa. Toda palanca se aplica contra las métricas del módulo 7, no a pesar de ellas.
Olvidar que los evals también cuestan. Correr la suite en cada cambio consume tokens. Es un costo legítimo del producto, no un gasto invisible de ingeniería.

La frase para llevarse

“En un producto de IA la rentabilidad no se decide en la factura, se decide en la arquitectura: el precio lo cobra el proveedor, pero el costo por tarea lo diseñas tú. Un usuario feliz que te cuesta más de lo que te deja no es crecimiento, es una fuga con buena cara.”

Qué viene

Módulo 9: equipo y modelo operativo. Ya sabes cuánto cuesta cada tarea y cómo controlarlo; ahora falta la pregunta de quién hace todo esto. Un producto de IA no lo lleva “un equipo de software” a secas: necesita gente que curе datos, que escriba evals, que revise casos límite, que decida modelos —y ese costo humano que vimos dominar la economía unitaria tiene nombres y roles concretos. Vamos a ver cómo se arma el equipo, qué modelo operativo sostiene un producto de IA en el tiempo, y cómo se reparte la responsabilidad para que el costo por tarea que tanto costó bajar no se dispare de nuevo apenas nadie esté mirando.

Producto de IA — Módulo 8: presupuesto y FinOps de IA