Métricas de DS: modelos desplegados, impacto en el negocio, degradación del modelo

Pasó seis semanas llevando el AUC de 0.84 a 0.89. Su VP mira la diapositiva, asiente y pregunta: "Bien, ¿qué ganamos con eso?" Usted no tiene un número. La sala queda en silencio por las razones equivocadas.

Esta es la brecha en la que cae la mayoría de los Data Scientists. Nosotros medimos la precisión del modelo. El CFO mide dólares. Cuando esas dos columnas no se reconcilian en una diapositiva de QBR, las revisiones de headcount no preguntan "¿cuál era tu F1?". Preguntan "¿qué entregó el equipo de DS?". Si no puede traducir el trabajo del modelo a lenguaje de negocio, lo recortan antes que al ingeniero que entregó un botón.

Así que arreglemos las métricas. Cinco de ellas. Cada una es defendible en una sala con un socio de finanzas que nunca ha abierto un notebook de Jupyter y no planea hacerlo.

Por qué esto importa ahora

Todos los equipos de DS que he visto sobrevivir un ciclo de presupuesto tenían el mismo rasgo: su líder podía nombrar números en dólares. No "mejoramos la precisión en 3 puntos". No "entregamos 12 experimentos". Dólares. Horas. Tickets desviados. Margen recuperado.

Los equipos que fueron recortados hablaban de la calidad del modelo de forma aislada. Tenían hermosas matrices de confusión y cero evidencia de que alguna decisión en la empresa cambió gracias a un modelo.

Las conversaciones sobre headcount en 2026 son más directas que hace tres años. La era del dinero barato enseñó a los equipos de DS a medir inputs (artículos, experimentos, AUC). La era actual solo cuenta outputs que aparecen en un estado de resultados. Si se formó bajo las reglas antiguas, tiene que reentrenarse, rápido. Las métricas a continuación son la manera de hacerlo.

Las 5 métricas que realmente importan

1. Modelos desplegados en producción

El conteo de modelos que sirven tráfico real de producción, vinculados a una decisión real, con un responsable real de guardia.

No notebooks. No "desplegado en staging". No "ejecuté un backfill una vez y envié los resultados a operaciones por correo electrónico". Un modelo que está atendiendo solicitudes, tiene un runbook y rompe algo visible si se cae.

Objetivo: 2-4 modelos desplegados por IC por año.

Ese número parece bajo. No lo es. Un modelo desplegado significa: pipeline de datos en producción, pipeline de entrenamiento en producción, stack de servicio en producción, monitoreo en producción, consumidor downstream conectado. La mayoría de los DS sobrestima cuántos ha hecho realmente porque cuentan notebooks. Cuente lo que está de guardia. El número se vuelve honesto rápidamente.

Si entregó cero el año pasado, esa es la conversación. ¿Por qué? ¿Fue la plataforma? ¿Fue el alcance? ¿Fue una parte interesada que nunca integró su resultado? Cada respuesta apunta a una corrección diferente y ninguna de ellas es "necesito un mejor modelo".

2. Impacto en el negocio en dólares

A cada modelo desplegado se le adjunta un número en dólares. Ingresos aumentados, costo ahorrado, horas devueltas (multiplicadas por la tarifa horaria cargada), abandono prevenido, fraude detectado.

Objetivo: cada modelo desplegado >= $250K de impacto anualizado, o elimínelo.

El piso de $250K es aproximado. Ajuste según el tamaño de la empresa. Una startup de 30 personas puede defender modelos de $50K si son baratos de ejecutar; una empresa pública no debería molestarse con menos de $500K. El principio se mantiene: cada modelo tiene un número, y si el número es pequeño, el modelo desaparece o el headcount que consume lo hace.

Cómo calcularlo realmente (no teóricamente, en una diapositiva):

• Modelo de ingresos: incremento en la tasa de conversión x tráfico base x valor promedio del pedido x anualizado. Haga que finanzas apruebe el baseline antes de desplegar. El acuerdo previo es todo; las afirmaciones de lift a posteriori siempre se cuestionan.
• Modelo de costo: tickets desviados x costo por ticket. Horas ahorradas x tarifa cargada. Pérdidas de inventario evitadas. Obtenga un número de finanzas para el costo por ticket, no lo adivine.
• Modelo de riesgo: fraude detectado x pérdida promedio por caso. Deuda incobrable evitada x tasa de cancelación.

Cualquier cosa que calcule, ponga la metodología en una nota al pie de la diapositiva. "Lift medido contra el baseline previo al lanzamiento aprobado por FP&A el 14-02-2026." Esa oración vale más que el número en sí, porque significa que el número no se re-debatirá el trimestre siguiente.

3. Tasa de degradación del modelo

El porcentaje de caída en su métrica de producción respecto a su métrica en el momento del entrenamiento, medido mensualmente.

La mayoría de los modelos pierde del 5% al 20% de su métrica principal en los primeros 90 días de producción. Deriva en las distribuciones de entrada, fuga de etiquetas que no apareció en la evaluación offline, estacionalidad que los datos de entrenamiento no cubrían. Cosas normales. El peligro no es la degradación. Es la degradación silenciosa.

Objetivo: cualquier modelo con degradación superior al 15% por trimestre sin un plan de reentrenamiento es un pasivo. O lo corrige o lo elimina.

Un ejemplo trabajado. Suponga que su modelo de fraude entrenó con AUC 0.91. Después del despliegue:

• Mes 1: AUC 0.89 en producción. Caída = (0.91 - 0.89) / 0.91 = 2.2%. Dentro del ruido.
• Mes 2: 0.86. Caída = 5.5%. Obsérvelo.
• Mes 3: 0.81. Caída = 11.0%. Tiene un problema; investigue.
• Mes 4: 0.76. Caída = 16.5% respecto al entrenamiento. Pasivo.

Si no tiene un pipeline de reentrenamiento que pueda detectar esto en el mes 2, construya uno antes de construir cualquier modelo nuevo. Un modelo que se degrada silenciosamente es peor que ningún modelo. Le da al negocio una falsa confianza.

El dashboard de una línea que su VP quiere sobre esto: "X de N modelos en producción tienen alertas de deriva conectadas y un SLA de reentrenamiento. Y de N no lo tienen." Esa proporción les dice cuánta superficie está realmente bajo control.

4. Tiempo de experimento a producción

Días entre "el notebook funciona" (la evaluación offline supera el nivel) y "el tráfico de producción está llegando al modelo".

Objetivo: menos de 45 días. 60 días es aceptable para un modelo difícil. Por encima de 90 días significa que la plataforma está rota, no usted.

Esta es la métrica que la mayoría de los Data Scientists no pondrá en una diapositiva porque los hace parecer lentos. Póngala de todas formas. Si su número es 120 días, esa es una conversación de plataforma, no una conversación de rendimiento. La solución son los almacenes de características, los pipelines de entrenamiento, los registros de modelos y la automatización del despliegue, no "el Data Scientist necesita trabajar más duro".

Cuando un VP vea este número y sea malo, debería tener una conversación de diseño organizacional: ¿necesitamos un ingeniero de plataforma de ML? ¿Necesitamos consolidar la cadena de herramientas de despliegue? ¿Necesitamos dejar de permitir que cada equipo desplegue su propio stack de servicio a medida?

La primera vez que entré a un QBR y puse el tiempo de ciclo en la diapositiva, la primera reacción de mi VP fue defensiva. Al final de la reunión, había escrito "plataforma de ML, prioridad Q2" en la pizarra. Ese número desbloqueó una contratación.

5. NPS de los socios del negocio

Una encuesta trimestral de dos preguntas a los PMs, líderes de operaciones y analistas que consumen sus modelos.

1. En una escala del 0 al 10, ¿con qué probabilidad recomendaría trabajar con nuestro equipo de DS a un par en otra empresa?
2. ¿Por qué?

Por debajo de 30 (NPS) significa que está resolviendo los problemas equivocados, su comunicación es deficiente, su entrega es poco confiable, o alguna combinación. La respuesta de texto libre le dice cuál.

Objetivo: NPS >= 50, con un piso duro de 30. Por debajo de 30 es una señal de repriorización, no una señal de "hágalo mejor el próximo trimestre".

¿Por qué incluir esto con las métricas duras? Porque las cuatro métricas anteriores son todas rezagadas. Para cuando la degradación o el conteo de modelos le cuenten la historia, habrán pasado dos trimestres. El NPS de socios adelanta. Cuando el PM que apoya deja de pedirle que delimite nuevo trabajo, tiene seis meses antes de que el número en dólares se aplane. El NPS lo detecta antes de eso.

Ejecútelo. Envíe un formulario, no un correo electrónico. Anonimice las respuestas. Lea el texto libre. Ajuste.

El diagnóstico "alta precisión, sin impacto"

Aquí está el momento en que se encontrará: un modelo con excelentes métricas offline, desplegado durante dos trimestres, en el que nadie del lado del negocio puede señalar que haya cambiado algo. Ejecute esta lista de verificación antes de que su VP lo haga en usted.

Diagnóstico de 4 preguntas (cópielo en su documento de preparación para QBR):

[ ] 1. ¿El resultado del modelo estaba vinculado a una decisión específica?
      (No "informó la estrategia". Una decisión específica: descuento sí/no,
       prioridad del ticket alta/baja, enrutamiento del lead al representante A o B.)

[ ] 2. ¿Esa decisión cambió realmente gracias al modelo?
      (¿Alguien se comportó diferente? Extraiga los datos antes/después.
       Si la tasa de decisión es idéntica antes y después del lanzamiento,
       el modelo es decoración.)

[ ] 3. ¿La decisión cambiada valió dinero?
      (Las decisiones pueden cambiar sin valor. Si los representantes empezaron a
       enrutar leads de forma diferente pero la conversión no se movió, eso son $0.)

[ ] 4. ¿Finanzas acordó la metodología?
      (Obtenga esto por escrito ANTES del QBR. "FP&A aprobó el baseline
       el AAAA-MM-DD" es la oración mágica.)

Si responde "no" a cualquiera de las cuatro, no tiene una métrica de impacto en el negocio. Tiene una historia. Las historias no sobreviven a un CFO. Corrija la brecha subyacente o elimine el modelo y libere el headcount.

La trampa en la que cae la mayoría de los equipos es la pregunta 1: despliegan un propensity score y consideran el trabajo terminado. Un score no es una decisión. El score sentado en una base de datos no vale nada. La regla de decisión que consume el score y cambia el comportamiento es de donde vienen los dólares. Si esa regla no existe, el modelo es un pasatiempo.

La diapositiva de QBR

Una diapositiva. Cinco filas. Último trimestre, este trimestre, delta. Una historia del modelo con un número en dólares debajo.

Así es la mía (los números son ilustrativos, el formato es real):

Destacado Q2: Lead-scoring v2 (desplegado el 14 de abril) Enruta los leads inbound a representantes según la propensión de conversión. Reemplazó el round-robin. Medido contra el baseline previo al lanzamiento (aprobado por FP&A el 22-03-2026): tasa de conversión 4.1% a 5.6%. Impacto anualizado: $1.1M en nuevos ingresos. Alertas de deriva conectadas; SLA de reentrenamiento de 30 días.

Esa es la diapositiva completa. Cinco números. Una historia del modelo. Una nota al pie citando el baseline de FP&A. Ningún AUC en ninguna parte de la página.

¿Podría haber puesto AUC? Por supuesto. El modelo está en 0.87, frente a 0.81 en v1. A nadie en esa sala le importa. Si les importara, preguntarían, y yo respondería. No preguntarán. Preguntarán si $1.1M es real, quién aprobó el baseline y cuál es la rotación de guardia cuando falla.

Eso es la conversación que se supone que debe iniciar una métrica. AUC no inicia esa conversación. Los dólares sí.

Trampas de las métricas de vanidad

Cinco métricas que veo a los líderes de DS optimizar accidentalmente, que parecen productivas y no lo son.

Conteo de publicaciones. Los artículos son excelentes para contratar DS senior en organizaciones de investigación. No son lo que su VP defiende en una revisión de estado de resultados. Si está en un equipo aplicado y su métrica principal son las publicaciones, está jugando el juego equivocado. El CFO no lee NeurIPS.

Posición en Kaggle. Útil para la marca personal. Inútil para el impacto en la empresa. Un DS senior sin perfil de Kaggle y cuatro modelos de ingresos desplegados supera a un Kaggle Grandmaster con dos notebooks en la pregunta que importa: ¿el negocio mejoró?

AUC del modelo solo. AUC es una métrica de calidad del modelo. La calidad del modelo es un medio; el resultado del negocio es el fin. AUC en una diapositiva sin dólares al lado hace que la sala piense que está ocultando algo. A menudo lo está, incluso de usted mismo.

Conteo de notebooks. He visto currículos de DS que enumeran "ejecuté 47 experimentos". Cuarenta y siete experimentos y cero modelos desplegados es una peor señal que cuatro experimentos y cuatro modelos desplegados. La proporción de despliegues respecto a experimentos es el número real.

"Modelos construidos." Tenga cuidado con esta redacción. "Construido" no es "desplegado". "Construido y demostrado al equipo" no es "desplegado". "Construido e integrado en un dashboard que los PMs miran a veces" no es "desplegado". Si un modelo no está atendiendo tráfico de producción en una decisión real, está en un cajón. El número que va en la diapositiva es el número que está realmente en producción.

El patrón en los cinco: miden trabajo realizado, no valor entregado. Los CFOs miden valor entregado. Usted también debería.

Póngalo en su calendario

Si se lleva una sola cosa de esto:

1. Para el viernes: cuente sus modelos desplegados (definición real) y escriba el número en dólares para cada uno.
2. Para el próximo QBR: haga que FP&A apruebe un baseline para cualquier modelo que no tenga uno. Por escrito.
3. Cada mes, registre la métrica de producción vs. entrenamiento para cada modelo. Si la degradación supera el 15%, escale.
4. Cada trimestre: envíe la encuesta de NPS de 2 preguntas. Lea el texto libre.
5. Cada QBR: traiga la diapositiva de 5 filas. Lidere con dólares, no con AUC.

El trabajo no es la calidad del modelo. El trabajo es el impacto desplegado. AUC es un medio; los dólares son el fin. Si no puede nombrar el número en dólares para cada modelo que ha desplegado, no tiene una métrica. Tiene un pasatiempo.

Más información

• Descripción de puesto de Data Scientist
• Sus primeros 30/60/90 días como nuevo Data Scientist
• Trabajar con su VP de IA / Director de DS
• Eliminar un modelo que no funciona