Sin KPI, no hay éxito.

La mayoría de los cursos, carreras o magísteres de Machine Learning o Inteligencia Artificial enseñen métricas para evaluar modelos durante la etapa de entrenamiento (accuracy, recall, F1-score, etc.). Estas métricas son bastante buenas para medir el desempeño de los modelos en dicha etapa, pero no son suficientes para abarcar todo el ciclo de vida de un proyecto. Debido a esto, creo que es relevante agregar otras dimensiones a las métricas técnicas, las cuales deberia ser:

• KPIs de Negocio: Estas métricas están directamente asociadas al problema que se busca resolver. Todo proyecto de datos debe vincularse a uno o más KPIs de negocio; de lo contrario, la iniciativa está destinada a fracasar. No existe una fórmula única: la elección de los KPIs dependerá del contexto y del tipo de proyecto. Sin embargo, hoy en día es fundamental que, desde el inicio, los equipos definan los KPIs que definirán el exito del proyecto.
• KPIs de Producción: Métricas utilizadas para evaluar el rendimiento del modelo en producción. Estas métricas pueden estar asociadas tanto a los datos —como data drift y label drift— como a los servicios desplegados por el modelo, por ejemplo APIs, considerando indicadores como latency, throughput, entre otros.

En general, no se habla mucho de estos temas, pero tenía ganas de recopilar aprendizajes desde mi experiencia para que otros no cometan los mismos errores. Además, hace algunos meses se publicó un reportaje del MIT sobre proyectos de Inteligencia Artificial, el cual demuestra que alrededor del 95 % de las iniciativas de AI en las empresas fracasan y solo un 5 % logra sobrevivir. ( https://fortune.com/2025/08/18/mit-report-95-percent-generative-ai-pilots-at-companies-failing-cfo/ )

¿Dónde está el problema?

En mi opinión, la gran mayoría de los proyectos de datos fracasan por tres principales razones: inventar un problema que no existe, no contar con un KPI de negocio claro y medible para la iniciativa, o no diseñar adecuadamente su implementación en producción.

En general, si el problema no está directamente asociado a un KPI del negocio, es muy probable que el proyecto o iniciativa muera por sí sola, ya que no existe un interés real detrás de él.

En lo personal, me ha tocado vivir tanto buenas como malas experiencias: liderando o siento parte de equipos cuyos proyectos impactaban directamente al negocio —donde todo era urgente y prioritario— y otros que no lo hacían, lo que terminaba afectando tanto al proyecto como a las personas involucradas.

En este blog me enfocaré en contar historias sobre este tipo de casos, basadas en experiencias personales que me ha tocado vivir . No profundizaré demasiado en KPIs de producción; sin embargo, es importante aprenderlos, ya que conocer el end-to-end de los proyectos de datos es clave en la actualidad.

Consejo: Oblígate a pensar, construir y discutir realmente cuáles son los KPIs de los proyectos de datos en los que estás involucrado. No todo lo que haces en tu trabajo tiene que estar asociado a un KPI de negocio, pero al menos el proyecto más relevante en el que participas sí debería estarlo. De lo contrario, tu trabajo no mueve la aguja en el lugar donde estas.

Caso 1: Modelo de Fraude de Siniestros (buen escenario)

La primera vez que trabajé modelando un problema de datos fue en Vida Cámara (compañía de seguros), desarrollando un modelo de detección de fraude en reembolsos médicos. Una de las grandes ventajas de los modelos de fraude es que permiten una evaluación monetaria casi inmediata del problema. Si ocurre un fraude en un reembolso, es posible cuantificar rápidamente el monto involucrado, lo que facilita que el modelo tenga mayor visibilidad y un impacto directo en los resultados de la compañía.

Imaginemos que el modelo es capaz de detectar fraudes y detenerlos de forma temprana. En ese escenario, se pueden generar ahorros directos en el estado de resultados, específicamente en la cuenta de claim expenses, ya que el valor de dicha cuenta disminuiría, generando un impacto positivo en el P&L. (estado de resultado)

En mi caso, trabajamos en conjunto con el equipo de operaciones de la compañía y definimos tres métricas de negocio a monitorear mensualmente:

• Cantidad de transacciones fraudulentas detectadas por mes.
• Monto total de las transacciones fraudulentas detectadas por mes.
• Porcentaje de transacciones fraudulentas sobre el total de transacciones del mes.

Estas métricas resultaron clave, ya que nos permitieron traducir el problema de negocio a datos cuantificables y comprensibles, involucrando activamente a los distintos equipos y alineando el trabajo del modelo con objetivos concretos del negocio.

En términos de métricas del modelo, los modelos de fraude suelen calibrarse principalmente utilizando dos métricas técnicas: precision y recall. Las razones son las siguientes:

1. Accuracy no es un buen indicador para este tipo de problemas. En general, la gran mayoría de las transacciones (98 % o 99 %) son correctas. Si evaluáramos el modelo únicamente usando accuracy obtendriamos un valor alto sin que el modelo realmente esté resolviendo el problema, ya que se trata de un caso fuertemente desbalanceado.
2. Recall permite conocer cuántos fraudes están siendo efectivamente detectados por el modelo. La idea es mantener un recall elevado, ya que un valor bajo implica dejar pasar fraudes y, por lo tanto, perder dinero.
3. Precision indica qué proporción de los reembolsos marcados como fraude realmente lo son. Esta métrica cobra especial relevancia cuando existe revisión humana en el proceso, ya que una baja precisión genera muchas falsas alertas, afectando la confianza del equipo y la eficiencia operativa.

En general, estas métricas se comportan de manera inversamente proporcional en función del threshold del modelo (umbral de probabilidad). Al aumentar una, normalmente se afecta negativamente la otra.

Caso 2: Modelo de Pronóstico de Demanda (buen escenario)

Tuve la oportunidad de trabajar en Unimarc, en un equipo realmente bacán, donde debíamos resolver el problema de pronosticar la demanda. Me tocó liderar el equipo de forecasting y construimos un modelo de predicción de demanda que estimaba la demanda diaria por local. En este contexto, trabajábamos con dos tipos de metricas:

• Métricas de negocio: Costo mensual de operadores logísticos

La métrica principal de negocio era el monto mensual facturado por los operadores logísticos. Cada mes recibíamos la facturación asociada a los shoppers solicitados para la operación de la última milla. Como equipo, vinculamos directamente el modelo de predicción de demanda con la solicitud y planificación de shoppers, mediante un análisis de productividad. Cuando el modelo sobreestimaba la demanda, se solicitaban más shoppers de los necesarios, lo que incrementaba la facturación del operador logístico. Este sobrecosto impactaba directamente en los costos operacionales y, por ende, de forma negativa en el estado de resultados de la compañía.

• Métricas de evaluación Técnica: RMSE

Las métricas que utilizábamos para entrenar el modelo eran principalmente la Raíz del Error Cuadrático Medio (RMSE). Además, analizábamos la desviación diaria y semanal entre las órdenes predichas y las órdenes reales, ya que estas diferencias eran las que finalmente impactaban al negocio.

Creo que vincular el modelo de forecasting con la operación de shoppers (por ende con los costos logísticos) de la compañia fue clave, porque le entrego a visibilidad, medición y sentido de urgencia tanto al modelo como al equipo.

 Caso 3: Chatbot coorporativo (oportunidad de mejora).

Antes de irme de Chile, trabajaba en el Grupo Security, donde estábamos desarrollando un chatbot corporativo, una especie de símil de ChatGPT, pero enfocado en clientes internos del banco. Creo que uno de los principales problemas que enfrentamos —y que es bastante común en muchos proyectos de IA— fue la falta de alineación con el negocio. En lugar de resolver problemas que impactaran directamente en los resultados, el foco estaba puesto en otros desafíos que no necesariamente generaban valor tangible. Dedicamos bastante tiempo a mejorar la solución, pero finalmente el proyecto no logró salir completamente a producción, principalmente por temas relacionados con la fusión (BICE - Grupo Security) y otros factores organizacionales.

El proyecto consistía en un sistema RAG (Retrieval-Augmented Generation), para el cual definimos dos tipos de métricas:

• Métricas de negocio: cantidad de usuarios, número de interacciones y sesiones diarias y semanales.
• Métricas de performance: métricas de RAGAS y evaluación del ranking del modelo de retrieval de los chunks.

¿La lección?

El principal lección de este tipo de proyectos es que su impacto suele ser difícil de cuantificar. En general, buscan mejorar la productividad de las personas, pero ese beneficio termina siendo marginal en comparación con otras iniciativas más directamente alineadas con los resultados del negocio. Esto hace que, al momento de priorizar recursos, estos proyectos queden en desventaja frente a soluciones con retornos más evidentes.

En ese sentido, hoy en día es obligatorio repensar los proyectos con AI, eligiendo muy bien las batallas para saber cuales debemos pelear, y cuales deberiamos dejarlas para el futuro, priorizando siempre las que tengan un retorno cuantificable y medible.

Conclusión

Siento que es un buen ejercicio preguntarse si lo que hacemos impacta realmente a la empresa, a las personas y a sus procesos. Si bien no todo puede medirse estrictamente en términos económicos, es importante que el trabajo que realizamos en el día a día genere un impacto claro, ya sea a nivel humano, operativo o financiero. La alineación entre tecnología, personas y el negocio es clave para que los proyectos de datos puedan sostenerse y escalar en el tiempo en cualquier organización o start-up.