En el módulo 6 aprendimos a ordenar el trabajo por impacto: RICE, ICE, la disciplina de no hacerlo todo a la vez. Pero toda priorización descansa sobre una palabra tramposa — impacto — y ese módulo la dejó como una promesa. Priorizamos la iniciativa que “mueve más la aguja”; este módulo pregunta cuál aguja, y cómo se sabe si de verdad se movió. Es el puente natural con el mundo de los evals (evaluations, la disciplina de medir sistemáticamente si un sistema de IA hace bien su trabajo) que ya vive en este sitio: cuando en el Curso de Evals definíamos “el éxito” de un modelo, definíamos una métrica. Aquí subimos un piso: del acierto del modelo al valor del producto.

Porque hay una trampa que hunde a productos de IA técnicamente impecables, y este módulo entero existe para desactivarla: creer que un modelo que acierta es un producto que funciona.

La tesis del módulo

Un producto de IA se mide en dos idiomas a la vez — el del modelo (acierto, latencia) y el del negocio (retención, ingreso, costo) — y confundirlos es fatal: un modelo con 95% de acierto que nadie usa es un fracaso de producto con métricas de modelo preciosas. El trabajo del dueño de producto no es maximizar una de las dos, es tender el cable que las conecta, para que ninguna mejora técnica se celebre hasta que mueva un número que al negocio le importa.

Dos idiomas: métricas de modelo y métricas de negocio

Todo producto de IA convive con dos familias de métricas que hablan idiomas distintos y viven en cabezas distintas.

Las métricas de modelo describen qué tan bien hace su trabajo el sistema de IA, aisladamente. Son el terreno de los evals: accuracy (exactitud, fracción de predicciones correctas), precision y recall (precisión y cobertura: de lo que marqué, cuánto acerté; de lo que debía marcar, cuánto encontré), latencia (tiempo que tarda en responder), tasa de alucinación (fracción de respuestas inventadas o falsas). Las vigila el equipo técnico. Se pueden medir sin un solo usuario real, en un banco de pruebas.

Las métricas de producto/negocio describen si el producto genera valor para alguien: adopción (cuántos lo empiezan a usar), retención (cuántos vuelven), tareas completadas (cuántos lograron lo que venían a hacer), CSAT (Customer Satisfaction, satisfacción declarada del usuario, típicamente en una encuesta de 1 a 5), ingreso que genera o protege, y costo por tarea (cuánto cuesta cada uso, tema del módulo 8). Las vigila el negocio. Solo existen cuando hay usuarios reales.

El error clásico es optimizar la primera familia creyendo que la segunda seguirá sola. No sigue. La relación entre ambas no es automática: es una hipótesis que hay que hacer explícita y verificar.

Ojo: una mejora de modelo solo importa si mueve una métrica de negocio. Subir el recall de 0.88 a 0.91 no es un logro de producto por sí mismo; es un logro si ese recall extra reduce las tareas fallidas que hacían abandonar al usuario. Si no puedes trazar la flecha desde la métrica de modelo hasta una de negocio, no sabes si mejoraste el producto o solo el banco de pruebas.

Esa flecha — de modelo a negocio — es la columna vertebral del módulo, y el árbol de KPI que viene más abajo es la herramienta para dibujarla sin engañarse.

La North Star Metric

Con dos familias de métricas y decenas de números disponibles, un equipo se dispersa: cada área optimiza el suyo y nadie mira el todo. La North Star Metric (métrica estrella del norte, la única métrica que captura el valor central que el producto entrega al usuario) es el antídoto. Es el número que, si sube de forma sana, significa que el producto está cumpliendo su promesa.

Una buena north star tiene tres propiedades, y le fallan las tres a la mayoría de los candidatos que la gente propone:

Refleja valor entregado al usuario, no actividad interna. “Resúmenes que el usuario aceptó sin editar” refleja valor; “resúmenes generados” solo refleja que el servidor estuvo encendido.
Es accionable: el equipo puede moverla con su trabajo. Una métrica que sube y baja por factores que no controlas (la temporada, el precio del dólar) no sirve de brújula.
Predice el éxito de negocio: cuando sube sostenidamente, el ingreso o la retención suben detrás. Si puedes subirla sin que el negocio mejore, elegiste una métrica de vanidad disfrazada.

Ejemplos ilustrativos (no cifras reales, solo la forma de una buena north star):

Un asistente de soporte con IA: tickets resueltos sin escalar a un humano. Captura el valor (el usuario se fue con su problema resuelto) y predice el negocio (menos costo de soporte, más satisfacción).
Un buscador semántico interno: búsquedas que terminan en el documento correcto abierto. No “búsquedas hechas”: búsquedas exitosas.
Un generador de borradores: borradores usados en un envío real, no borradores generados.

Fíjate en el patrón: en los tres casos, la north star cuenta éxitos del usuario, no acciones del sistema. Esa es la línea que separa una métrica estrella de una métrica de vanidad.

El árbol de KPI

Una north star es necesaria pero insuficiente: es un número de resultado, y los resultados no se tocan directamente. No puedes ir a una reunión y decir “suban la retención”. La retención es consecuencia de cosas más pequeñas y accionables. El árbol de KPI (KPI tree o driver tree, árbol de indicadores; KPI = Key Performance Indicator, indicador clave de desempeño) descompone la north star en las palancas que sí se tocan, hasta llegar a métricas de modelo concretas.

Se lee de arriba hacia abajo: la north star se abre en drivers (palancas de negocio que la mueven), y cada driver se apoya, cuando es un producto de IA, en una o más métricas de modelo. Así la flecha “modelo → negocio” queda dibujada y auditable.

      ÁRBOL DE KPI DE UN ASISTENTE DE SOPORTE

           ┌─────────────────────────┐
           │   NORTH STAR: tickets   │
           │   resueltos sin humano  │
           └────────────┬────────────┘
                        │
        ┌───────────────┼───────────────┐
        ▼               ▼               ▼
  ┌───────────┐   ┌───────────┐   ┌───────────┐
  │  driver:  │   │  driver:  │   │  driver:  │
  │ cobertura │   │ respuesta │   │ confianza │
  │ del tema  │   │ correcta  │   │  usuario  │
  └─────┬─────┘   └─────┬─────┘   └─────┬─────┘
        ▼               ▼               ▼
  ┌───────────┐   ┌───────────┐   ┌───────────┐
  │ modelo:   │   │ modelo:   │   │ modelo:   │
  │ recall de │   │ tasa de   │   │ latencia  │
  │ retrieval │   │ alucinac. │   │    p95    │
  └───────────┘   └───────────┘   └───────────┘

El árbol paga dos veces. Primero, ordena el trabajo: cada equipo sabe qué métrica de modelo mueve qué driver, y qué driver mueve la north star — es el mapa que faltaba bajo la palabra “impacto” del módulo de priorización. Segundo, hace visible una mejora inútil: si bajas la tasa de alucinación pero el driver “respuesta correcta” no se mueve, aprendiste que la alucinación no era el cuello de botella. El árbol convierte cada optimización en una hipótesis falsable.

Métricas guardrail: lo que no debe empeorar

Optimizar un número casi siempre presiona otro hacia abajo. Subes la cobertura del retrieval trayendo más documentos, y la latencia sube. Bajas la latencia recortando el contexto, y la tasa de alucinación sube. Sin un contrapeso explícito, un equipo puede “ganar” en su métrica mientras rompe el producto por otro lado.

Las métricas guardrail (guardrail metrics, métricas de guardia o barrera de contención) son las que no deben empeorar mientras optimizas otra cosa. No las intentas maximizar; les pones un umbral que no puede cruzarse, y si una mejora lo cruza, la mejora no se lanza aunque suba la north star. Es exactamente la lógica que el Curso de Evals aplica a la seguridad: toda optimización necesita su guardrail, o terminas mejorando un número a costa de un incidente.

Guardrails típicos de un producto de IA:

Costo por tarea ≤ un techo (subir la calidad no puede triplicar la factura; ver FinOps).
Latencia p95 (percentil 95: el tiempo que no supera el 95% de las respuestas) ≤ un máximo tolerable.
Tasa de alucinación ≤ un piso de confianza.
CSAT o satisfacción ≥ el nivel actual (una mejora que enoja a la gente no es mejora).

Cuidado: una north star sin guardrails es una invitación a hacer trampa. Si solo te miden por “tickets resueltos sin humano”, el atajo obvio es que el bot nunca escale — y responda cualquier cosa con tal de cerrar. El guardrail de CSAT y el de alucinación son los que impiden que la north star se cumpla destruyendo el producto. Una métrica de resultado sin guardrails premia el atajo que la infla.

Métricas de vanidad vs. métricas accionables

Una métrica de vanidad (vanity metric) es un número que sube fácil, se ve bien en una lámina y no informa ninguna decisión. Su firma es que solo puede crecer y que crece por razones que no controlas: “número de consultas”, “usuarios que probaron el producto”, “mensajes procesados”. Suben porque hiciste marketing, porque es lunes, porque hubo una campaña — y no te dicen nada sobre si el producto sirve.

El test es brutal y simple: ¿qué decisión cambia si este número sube o baja? Si la respuesta es “ninguna, solo se ve mejor en el reporte”, es vanidad. La contra-métrica accionable siempre existe, y casi siempre es una tasa o una fracción, no un total:

Métrica de vanidad	Por qué engaña	Contra-métrica accionable
Número de consultas	Sube con tráfico, no con valor	Tasa de consultas resueltas con éxito
Usuarios que probaron	Un pico de curiosos que no vuelven	Retención a 7 días de los que probaron
Mensajes procesados	Mide carga, no resultado	Tareas completadas por sesión
Precisión del modelo (sola)	Preciosa aunque nadie lo use	Precisión ponderada por uso real

La regla general: los totales acumulados casi siempre son vanidad; las tasas y las razones casi siempre son accionables. Un total solo puede subir; una tasa puede empeorar, y por eso te obliga a actuar.

El ciclo offline ↔ online

Las métricas de modelo y las de producto no viven en el mismo momento del tiempo, y confundirlos es otra trampa. Hay dos regímenes de medición, conectados por dos flechas.

Las métricas offline se miden antes de lanzar, en un banco de pruebas con casos conocidos: los evals del módulo de definir el éxito. Son baratas, rápidas y repetibles, pero miden un mundo de laboratorio. Las métricas online se miden en producción, con usuarios y tráfico real: adopción, retención, la north star. Son las que de verdad importan, pero son lentas, ruidosas y caras de equivocar.

La flecha de ida es obvia: nada pasa a producción sin superar los evals offline. La flecha de vuelta es la que casi nadie cierra, y es la más valiosa: cada fallo en producción se convierte en un caso nuevo del banco de evals offline. El usuario reportó una respuesta mala, el modelo escaló un ticket que no debía: ese caso concreto se captura y se agrega al banco, para que la próxima versión no pueda repetirlo sin que el eval lo atrape. Es el mismo principio que en red teaming: cada ataque que funcionó una vez se vuelve un caso permanente de la suite.

      CICLO OFFLINE - ONLINE (ida y vuelta)

  ┌────────────────┐  promueve   ┌──────────────┐
  │  EVALS OFFLINE │ ──────────► │  PRODUCCIÓN  │
  │ banco de casos │  si pasa    │   (online)   │
  ├────────────────┘             └──────┬───────┘
  ▲                                     │ falla
  │ el fallo se vuelve                  ▼
  │ un caso nuevo               ┌──────────────┐
  └─────────────────────────────┤  fallo real  │
                                │  capturado   │
                                └──────────────┘

Un producto de IA con este ciclo cerrado mejora con cada error; uno con la flecha de vuelta rota tropieza dos veces con la misma piedra, porque el banco de evals nunca aprendió del incidente.

Artefacto: la ficha de KPI

Una métrica sin dueño y sin umbral es decoración: un número lindo en un panel que nadie mira porque nadie es responsable de él y nada pasa cuando cambia. Para que una métrica gobierne una decisión necesita una ficha de KPI con estos campos, y si falta alguno, el KPI no está listo:

KPI: Tasa de tickets resueltos sin escalar a humano
─────────────────────────────────────────────────
Qué mide:   % de conversaciones cerradas por el bot
            con el problema del usuario resuelto.
Cómo se
calcula:    (tickets cerrados por el bot con CSAT ≥ 4)
            / (total de tickets recibidos), semanal.
Dueño:      Líder de producto de Soporte IA.
Objetivo:   ≥ 55% al cierre del trimestre.
Guardrail:  CSAT global ≥ 4.2  Y  alucinación ≤ 1%.
Se revisa:  cada lunes, comité de producto.
Fuente:     tabla de tickets + encuesta post-cierre.

Los siete campos hacen el trabajo. Cómo se calcula evita la pelea eterna sobre qué significa el número. Dueño es la palabra que más se olvida y la más importante: sin una persona responsable, el KPI se ignora en silencio. Objetivo y guardrail convierten el número en una decisión: si el objetivo se cumple pero el guardrail se rompe, no lanzas. Se revisa le da un latido: un KPI que no se mira en una cadencia fija está muerto aunque exista.

La tabla que sigue muestra cómo conviven los tres tipos de métrica alrededor de un mismo producto, cada una con su vigilante y su gatillo de decisión:

Métrica	Tipo	Quién la vigila	Qué decisión dispara
Recall de retrieval	Modelo	Equipo de IA	Reindexar / cambiar embeddings si cae
Tickets resueltos sin humano	Negocio (north star)	Líder de producto	Priorizar el driver más flojo del árbol
Latencia p95	Guardrail	Plataforma / SRE	Bloquear el release si cruza el umbral
CSAT post-cierre	Guardrail	Producto	Revertir el cambio si baja del piso
Costo por ticket	Guardrail	Producto + Finanzas	Frenar el escalado si supera el techo

Los guardrails no disparan “mejorar”; disparan frenar. Esa es su función: ser el freno que impide que la persecución de la north star rompa lo que no debía romperse.

Errores comunes

Medir solo el modelo. Un panel lleno de accuracy y recall sin una sola métrica de retención o de tarea completada describe un banco de pruebas, no un producto. El 95% de acierto que nadie usa es el fracaso más caro y mejor documentado.
Reportar totales acumulados. “Un millón de consultas procesadas” es vanidad pura: solo puede subir y no informa ninguna decisión. La versión útil es siempre una tasa.
North star sin guardrails. Una métrica de resultado sin barreras premia el atajo que la infla — el bot que nunca escala, el resumen que se acepta porque nadie lo revisa. Sin guardrail, optimizar la north star degrada el producto.
KPI sin dueño. Una métrica que no es responsabilidad de nadie no se mira, no se defiende y no dispara nada. Sin dueño, sin objetivo y sin cadencia de revisión, un KPI es adorno.
Optimizar métricas de modelo sin trazar la flecha al negocio. Subir el recall que no mueve ningún driver del árbol es esfuerzo quemado. Toda mejora técnica debe poder señalar qué métrica de negocio esperaba mover — y verificar si la movió.
Romper la flecha de vuelta offline↔online. Si los fallos de producción no se vuelven casos nuevos del banco de evals, tu producto tropieza dos veces con la misma piedra y tus evals se quedan viejos.
Confundir vigilar con optimizar en los guardrails. Un guardrail no se maximiza, se mantiene sobre un umbral. Tratar la latencia como algo que “siempre hay que bajar más” desvía esfuerzo de la north star, que es lo que de verdad se optimiza.

La frase para llevarse

“Un modelo mide su acierto; un producto mide el valor que ese acierto le entrega a alguien. Entre los dos hay una flecha, y el trabajo del dueño de producto es no dejar que nadie la borre. Una métrica sin dueño y sin umbral no es una métrica: es decoración.”

Qué viene

Módulo 8: presupuesto y FinOps. Ya sabemos medir si el producto funciona; falta el número que aparece en todas las fichas de KPI de este módulo como guardrail y que todavía no abrimos: el costo. Vamos a desglosar de dónde sale el gasto de un producto de IA — tokens, cómputo, almacenamiento, personas —, cómo se arma un presupuesto que no explote en el primer mes de tracción, y qué es FinOps (la disciplina de gobernar el costo de la nube y de la IA como una métrica de producto más, no como una sorpresa de fin de mes). Porque un producto que funciona pero cuesta más de lo que rinde no es un éxito: es un problema con métricas preciosas.

Producto de IA — Módulo 7: métricas y KPI