Por qué confiar en una métrica requiere mucho más que verificar que el número esté bien calculado.
Hay una pregunta aparentemente sencilla que puede generar una discusión sorprendentemente larga:
¿Cuántas tarjetas activas tenemos?
Parece que deberíamos poder ir a una base de datos, ejecutar una consulta y volver con un número.
El problema empieza cuando preguntamos:
¿A qué llamamos una tarjeta activa?
¿Una tarjeta que no fue dada de baja?
¿Una que está habilitada para operar?
¿Una que tuvo al menos un consumo durante los últimos 30 días?
¿Durante los últimos 90?
¿Una tarjeta emitida pero nunca utilizada cuenta como activa?
Dependiendo de la definición, podemos obtener números completamente diferentes.
Y lo más interesante es que todos pueden estar correctamente calculados.
El problema no está necesariamente en el dato.
Está en lo que creemos que significa.
Dos números distintos no siempre implican que uno esté mal. A veces significan que nunca acordamos qué estábamos midiendo.
En la práctica, parte de este problema se resuelve haciendo explícita la definición.
Documentarla ayuda. Versionarla también, porque las métricas cambian y la forma en que una organización entiende su negocio también puede cambiar.
No elimina todas las discusiones.
Pero hace que discutamos sobre la definición y no sobre cuál de dos queries es "la correcta".
Un dato puede estar bien calculado y aun así estar equivocado para la decisión
Cuando hablamos de calidad de datos solemos pensar rápidamente en errores.
Una fuente que dejó de actualizarse.
Un estado que no cambió cuando debería haberlo hecho.
Registros duplicados.
Datos faltantes.
Una transformación incorrecta.
Todos son problemas reales. Me encontré con varios a lo largo de los años.
Pero existe otra categoría bastante más silenciosa.
El pipeline funciona.
La consulta está bien.
El dashboard se actualizó.
El número es matemáticamente correcto.
Y aun así dos personas lo interpretan de manera diferente.
Antes de confiar en una métrica, entonces, no alcanza con preguntar:
¿El número está bien?
También tenemos que preguntar:
¿Qué significa exactamente este número?
Hace décadas que la investigación sobre calidad de datos plantea que evaluar la calidad solamente por su exactitud es insuficiente. Un dato también tiene que ser apropiado para el contexto en el que va a utilizarse y comprensible para quien lo consume.
Eso sigue siendo sorprendentemente actual.
Porque una métrica técnicamente perfecta con una definición ambigua puede llevarnos a una decisión perfectamente equivocada.
La definición forma parte de la métrica
Me pasó más de una vez llegar a una reunión en la que dos áreas mostraban números diferentes para la misma métrica.
En una de esas situaciones, ambos equipos estaban convencidos de que su número era el correcto.
La primera reacción fue buscar el error: revisar queries, fuentes y transformaciones.
Y sí, a veces encontramos errores.
Pero otras veces encontramos algo más interesante.
Las fuentes no eran las mismas.
Los filtros eran diferentes.
Una incluía determinados estados y la otra no.
Una tomaba la fecha de creación y otra la fecha de aprobación.
Una consideraba un período calendario y la otra los últimos 30 días.
El error no estaba necesariamente en el cálculo.
Estábamos usando el mismo nombre para describir cosas diferentes.
Volvamos a "tarjetas activas".
Si Finanzas entiende una tarjeta activa como una tarjeta habilitada y Producto entiende una tarjeta activa como una tarjeta que realizó una transacción durante los últimos 30 días, probablemente obtengan dos números diferentes.
Y ambos pueden tener razón.
El wording de una métrica, entonces, no es un detalle de documentación.
Es parte de la métrica.
Una buena definición debería permitir entender qué estamos midiendo, qué estamos dejando afuera, qué fuente utilizamos, cómo lo calculamos y sobre qué período temporal aplica.
Sin eso, un dashboard puede generar una ilusión de precisión.
Tenemos un número con dos decimales.
Lo que quizás no tenemos es un significado compartido.
El tiempo cambia el significado del dato
En el artículo anterior hablaba de la importancia de conservar la temporalidad de nuestros sistemas.
Acá aparece nuevamente, pero desde otro lugar.
El eje temporal también forma parte de la definición.
Supongamos que alguien pregunta:
¿Cuántos clientes tenemos?
Podemos responder cuántos existen hoy.
Cuántos estaban activos al cierre del mes.
Cuántos compraron durante los últimos 30 días.
Cuántos tuvieron actividad durante el último año.
Cuántos alguna vez fueron clientes.
Son preguntas diferentes escondidas detrás de una frase aparentemente sencilla.
Esto se vuelve todavía más importante cuando comparamos períodos.
Si modificamos la definición de una métrica, cambiamos una fuente o incorporamos información que antes no estaba disponible, podemos romper la comparabilidad histórica sin darnos cuenta.
El gráfico sigue teniendo una línea.
Pero quizás una parte de esa línea significa algo diferente de la otra.
Una métrica sin una definición temporal clara puede ser correcta hoy e incomparable con ella misma mañana.
Cuando reviso un número intento entender no solamente cómo fue calculado.
También cuándo.
Los promedios también cuentan historias incompletas
Hay otro lugar donde intento ser particularmente cuidadoso: medias, promedios y agregaciones.
Supongamos que alguien dice:
"El cliente tarda en promedio 48 horas en completar el proceso."
El número puede ser completamente correcto.
Pero todavía sabemos muy poco.
¿La mayoría tarda aproximadamente 48 horas?
¿O la mitad termina en diez minutos y un pequeño grupo tarda varias semanas?
¿Cambió la composición de los clientes?
¿Existen segmentos con comportamientos completamente diferentes?
¿Estamos comparando poblaciones equivalentes?
Un promedio resume.
Y justamente por resumir, aplana la realidad.
Puede ocultar si los casos están relativamente concentrados alrededor de ese valor o si tenemos una distribución muy asimétrica, donde una pequeña cantidad de casos extremos —una cola larga— empuja el promedio hacia arriba.
Eso no lo convierte en una mala métrica. Lo convierte en una métrica que necesita contexto.
A veces mirar la mediana, algunos percentiles o simplemente la distribución completa cuenta una historia bastante diferente.
Una vez alguien me dijo algo que me quedó:
Con los mismos números se pueden construir interpretaciones diferentes.
Creo que es cierto.
Los datos restringen las historias que podemos contar, pero rara vez eliminan por completo la necesidad de interpretar.
Frente a una conclusión construida sobre un promedio o una agregación, me interesa conocer la fuente, la distribución, la población, el período y cómo se construyó la métrica.
No porque desconfíe del dato.
Sino porque quiero entender qué conclusión permite realmente sostener.
Un dato faltante y un dato incorrecto no tienen el mismo riesgo
Si tuviera que elegir entre no tener un dato y tener un dato incorrecto, prefiero saber que no lo tengo.
Cuando falta información, la incertidumbre es visible.
Podemos decir:
"No sabemos."
Podemos buscar otra fuente, construir una aproximación, postergar una decisión o tomarla sabiendo explícitamente qué información nos falta.
Un dato incorrecto tiene otra característica.
Puede ocultar la incertidumbre.
Nos permite entrar a una reunión con un dashboard, observar un número y tomar una decisión convencidos de que tenemos evidencia.
Ahí está su peligro.
Cuando falta un dato, sabemos que no sabemos. Cuando el dato está mal, podemos estar convencidos de que sabemos algo que nunca fue cierto.
Y un dato ambiguo puede producir un efecto parecido.
Quizás el número sea correcto.
Pero si distintas personas entienden cosas diferentes cuando lo leen, la organización tampoco está tomando decisiones sobre una realidad compartida.
Antes de confiar en una métrica
Con el tiempo fui desarrollando algunas preguntas bastante sencillas cuando aparece un número importante. No forman un framework sofisticado ni pretenden reemplazar un proceso formal de gobierno de datos. Son, simplemente, una forma de entender qué estoy mirando antes de construir una conclusión sobre eso.
- ¿Qué estamos midiendo exactamente?
- ¿Cómo se calcula?
- ¿Cuál es la fuente?
- ¿Qué población incluye y cuál excluye?
- ¿Cuál es el eje temporal?
- ¿Estamos comparando cosas comparables?
- ¿Qué hay debajo de ese número?
Esta última se vuelve especialmente importante cuando estamos mirando medias, promedios o variaciones importantes.
No siempre necesitamos responder todas con el mismo nivel de profundidad. Una métrica operativa que miramos diariamente puede necesitar un nivel de control diferente al número que vamos a utilizar para decidir una inversión importante.
La confianza que necesitamos debería ser proporcional al costo de equivocarnos.
Cuando dos áreas tienen números distintos, el problema no siempre es Data
Cuando dos equipos llegan con números diferentes, es tentador mandar el problema al equipo de Data para que determine cuál es "el correcto".
A veces corresponde.
Pero si el problema es que la organización nunca definió qué significa "cliente activo", Data no puede resolverlo técnicamente.
Puede mostrar las diferencias.
Puede cuantificarlas.
Puede documentarlas.
Puede construir una única métrica cuando exista una definición acordada.
Pero alguien tiene que tomar una decisión de negocio:
¿Qué queremos decir cuando usamos este término?
Ahí aparece algo que para mí es fundamental.
La gobernanza de datos no consiste solamente en permisos, catálogos y herramientas.
También consiste en construir lenguaje compartido.
Que cuando dos personas digan "conversión", "cliente activo", "venta", "mora" o "rentabilidad", sepan si realmente están hablando de la misma cosa.
Con IA, el problema cambia de escala
Hasta hace relativamente poco, muchas de estas discusiones terminaban en un dashboard.
Una persona veía un número.
Lo interpretaba.
Quizás hacía una pregunta.
Quizás detectaba que algo no cerraba.
Ahora estamos empezando a construir otra cosa.
Agentes que consultan información.
Sistemas que interpretan resultados.
Modelos que recomiendan acciones.
Automatizaciones que directamente las ejecutan.
Y eso cambia el nivel de exigencia.
Supongamos que le pedimos a un agente:
"Contactá a todos los clientes inactivos."
Parece una instrucción perfectamente clara.
Hasta que hacemos la misma pregunta del principio:
¿Qué significa inactivo?
O imaginemos otra:
"Priorizá los clientes de alto riesgo."
¿Alto riesgo según qué modelo?
¿Con qué versión?
¿Con datos de qué momento?
¿Sobre qué población fue construido?
¿Existe información más reciente?
¿Y qué significa exactamente "priorizar"?
Un analista frente a una ambigüedad puede levantar la mano y preguntar.
No deberíamos asumir que un agente va a hacerlo.
Puede tomar una definición incompleta, inferir lo que falta y continuar. Y cuando ese sistema tiene además capacidad para actuar, la ambigüedad deja de ser solamente un problema analítico.
Se convierte en un problema operativo.
Un dashboard con un dato ambiguo puede generar una discusión. Un agente con un dato ambiguo puede ejecutar una decisión.
Esto también cambia cómo pienso la gobernanza de IA.
No alcanza con saber qué modelos estamos utilizando, cuánto se usan o qué información pueden consultar. Si queremos delegar progresivamente tareas y decisiones, también necesitamos entender sobre qué datos están razonando, qué definiciones reciben y qué acciones están autorizados a ejecutar.
La observabilidad de un agente no debería terminar en tokens, latencia o cantidad de ejecuciones.
También deberíamos poder reconstruir todo el camino que llevó a una acción. Algo parecido al linaje que hace años buscamos construir sobre nuestros datos, pero aplicado ahora a las decisiones:
Un linaje de decisiones.
- Qué información recibió el sistema.
- Cómo la interpretó a partir de las definiciones disponibles.
- Qué conclusión o inferencia realizó.
- Qué acción ejecutó concretamente sobre el negocio.
Si queremos delegar decisiones, también necesitamos poder reconstruir cómo se tomaron.
No es solamente una preocupación teórica. Los marcos actuales de gestión de riesgo de IA ponen justamente el foco en la confiabilidad, la transparencia, la medición y el gobierno durante todo el ciclo de vida de estos sistemas.
La IA no elimina nuestros problemas de datos.
Puede convertirlos en acciones.
Quizás necesitamos empezar por el lenguaje
Durante mucho tiempo pensamos que mejorar nuestra capacidad de trabajar con datos significaba construir mejores pipelines, warehouses, modelos y dashboards.
Todo eso sigue siendo necesario.
Pero cada vez estoy más convencido de que una parte importante del problema es mucho menos tecnológica.
Necesitamos ponernos de acuerdo sobre qué significan las cosas.
Qué es una venta.
Qué es un cliente.
Qué significa activo.
Cuándo comienza y termina una conversión.
Qué fecha utilizamos.
Qué representa exactamente cada número que ponemos delante de alguien que tiene que decidir.
En el artículo anterior planteaba que la infraestructura de datos empieza mucho antes del data warehouse.
Creo que acá aparece una idea complementaria:
La calidad del dato también empieza antes del dato. Empieza en la definición.
Podemos tener la arquitectura perfecta.
Podemos tener pipelines sin errores.
Podemos actualizar información en tiempo real.
Podemos tener modelos extraordinariamente sofisticados.
Pero si dos personas miran el mismo término y entienden cosas diferentes, todavía tenemos un problema.
Y a medida que deleguemos más decisiones a agentes y sistemas automáticos, esa precisión va a dejar de ser solamente una buena práctica analítica.
Va a convertirse en una condición para poder automatizar con confianza.
Porque al final no alcanza con que un número sea correcto.
También necesitamos saber exactamente qué significa.
Algunas lecturas que acompañan estas ideas
Beyond Accuracy: What Data Quality Means to Data Consumers — Richard Wang y Diane Strong. Un trabajo clásico sobre por qué la calidad de los datos va mucho más allá de que un número sea simplemente correcto.
NIST AI Risk Management Framework. Un marco para pensar la confiabilidad y los riesgos a medida que incorporamos sistemas de inteligencia artificial en procesos y decisiones.
NIST Generative AI Profile. Una extensión del framework anterior enfocada específicamente en los riesgos y desafíos de los sistemas de IA generativa.