Qué es la calidad de datos y por qué es la base de cualquier proyecto de IA

El dato malo no nació con la IA, pero la IA lo vuelve caro y visible

El primer tropiezo serio de una empresa con la IA no suele ser el modelo, es el momento en que alguien mira el resultado y dice “esto no me cuadra”. Se arma un tablero de ventas y no coincide con lo que cobró finanzas. Se entrena un modelo para priorizar clientes y marca como prioritario a uno que se fue hace un año. Se pide un pronóstico de stock y sale disparatado. La reacción típica es desconfiar de la herramienta, cuando el problema estaba mucho antes: en los datos con los que se la alimentó.

Ese desorden no nació con la IA, convivía en silencio hace años. El negocio funcionaba igual porque una persona con experiencia corregía a ojo lo que el sistema mostraba mal: sabía que ese cliente ya no compra, que ese código es un duplicado, que esa cifra hay que ajustarla. La IA no tiene ese criterio de pasillo. Toma el dato como verdad y lo escala a miles de decisiones por minuto. Por eso la calidad de datos deja de ser un tema del área técnica y se vuelve una decisión de dirección: define si un proyecto de IA se puede sostener o si va a amplificar los errores que hoy alguien tapa a mano.

Qué es la calidad de datos en criterio de negocio, no de sistemas

Calidad de datos no es tener “muchos datos” ni tenerlos en la nube. Es qué tan confiable es la información para decidir sobre ella. Un dato de calidad es el que puedes usar sin tener que preguntarle a nadie si es cierto, si está completo y si sigue vigente. Cuando esa confianza no existe, cada reporte abre una discusión y cada automatización arrastra el riesgo de estar operando sobre algo falso, con la diferencia de que la automatización no se detiene a dudar.

Conviene separar dos cosas que las empresas mezclan. Una es la cantidad y el almacenamiento: dónde viven los datos y cuántos hay. La otra es la calidad: si esos datos sirven para lo que se van a usar. Se puede tener un repositorio enorme y una calidad pésima, y se puede tener una sola planilla impecable que sostiene una decisión crítica. Para el negocio lo que importa no es el volumen, es si puedes confiar en el número cuando toca firmar.

Cómo se mide: las cuatro preguntas que definen si un dato sirve

La calidad no es un “sí o no”, se mide en dimensiones concretas. Estas son las cuatro que reviso primero con un cliente, traducidas a lo que significan en la operación y no en un glosario técnico:

• Correcto (exactitud): el dato refleja la realidad. El precio guardado es el precio real, el saldo es el saldo, la dirección es donde de verdad se entrega. Un dato correcto pero viejo ya dejó de ser correcto.
• Completo: no faltan los campos que la decisión necesita. Un cliente sin sector, sin tamaño y sin fecha de alta sirve para facturarle, pero no para que un modelo entienda a quién se le vende ni por qué se va.
• Actual (vigencia): el dato está al día. Un contrato marcado como activo que venció hace seis meses no es un error de tipeo, es una fuente de decisiones equivocadas que se toman con total confianza.
• Consistente: el mismo dato dice lo mismo en todos los sistemas. Si el cliente es “ACME S.A.” en ventas, “Acme SA” en soporte y “acme sociedad anonima” en facturación, para la máquina son tres clientes distintos, y cualquier análisis por cliente sale partido.

Hay más dimensiones que se suman según el caso (unicidad, o sea sin duplicados, y trazabilidad, saber de dónde salió cada dato), pero estas cuatro explican la mayoría de los desastres que he visto. Casi ningún proyecto falla por una falta exótica: falla por correos duplicados, fechas en formatos mezclados y campos vacíos que nadie llenó a tiempo.

Por qué es el techo de cualquier proyecto de IA

La razón por la que este tema es la base de todo proyecto de IA cabe en una idea: un modelo hereda los errores de sus datos. No inventa criterio, extrae patrones de lo que le das. Si le entregas un histórico donde la mitad de las ventas “perdidas” en realidad se ganaron pero nadie actualizó el registro, va a aprender a predecir con precisión matemática sobre una realidad falsa.

Esto aplica en los dos grandes usos de IA en una empresa. En la IA predictiva (pronósticos, scoring, detección de fuga), la calidad del dato histórico es literalmente el material de aprendizaje: datos sesgados producen modelos sesgados, y el sesgo no se ve en la demo, se ve en las decisiones de tres meses después. En la IA generativa conectada a tus documentos, el sistema responde citando lo que encuentra, así que un manual desactualizado o una política duplicada se convierten en respuestas equivocadas dichas con autoridad.

El agravante frente al pasado es la velocidad y la escala. Antes un dato malo causaba un error puntual que alguien pescaba en el camino. Ahora ese mismo dato malo puede alimentar miles de decisiones automáticas antes de que nadie lo note. La calidad de datos no es entonces un requisito de moda, es el techo real de lo que la IA puede hacer por tu negocio. Ningún modelo, por avanzado que sea, sube por encima de la calidad de la información que le das.

Cómo se ordena en la práctica, sin frenar la operación

El error de arranque es tratar la calidad de datos como un proyecto gigante de “limpiar todo”. Eso no termina nunca y consume presupuesto sin mostrar resultado. El enfoque que funciona es al revés: partir del caso de uso y ordenar solo lo que ese caso necesita. Esto es lo que reviso antes de dar por listo un conjunto de datos para IA:

• Un caso de uso que fije el alcance: la pregunta concreta que responderá la IA define qué datos importan. Ordenar “los datos de clientes” es infinito; ordenar “los datos que necesita el modelo de fuga” es un proyecto con final.
• Una fuente de verdad por dato: cuando el mismo dato vive en tres sistemas, alguien del negocio debe decidir cuál manda. Esa decisión no es técnica, es de dueño de área, y sin ella la limpieza es opinión contra opinión.
• Reglas de validación en la entrada: es más barato impedir que un correo mal escrito entre al sistema que limpiarlo después. La calidad se sostiene en el punto de captura, no en un lavado final.
• Un dueño del dato con nombre y apellido: alguien responsable de que ese conjunto se mantenga vigente. Sin esa figura, cualquier limpieza dura hasta la siguiente semana de operación.
• Un diagnóstico sobre muestra, no sobre la base entera: revisar a mano una muestra representativa dice el estado real más rápido y más barato que auditar millones de filas de golpe.

Ninguno de estos puntos es comprar una herramienta. Son decisiones de orden y de responsabilidad. La tecnología de calidad de datos ayuda a sostener el proceso y a detectar problemas a escala, pero no reemplaza la decisión humana de qué versión es la correcta cuando dos sistemas se contradicen.

Los errores que hacen fracasar el trabajo de calidad de datos

Casi todos son de gestión, no de técnica. Los que más se repiten en las empresas donde el tema se les fue de las manos:

• Limpiar una vez y olvidarlo. Los datos se ensucian solos con cada venta, cada alta y cada cambio. Una limpieza sin proceso de mantenimiento vuelve al punto de partida en pocos meses.
• Confundir cantidad con calidad. Acumular datos “por si sirven” sin criterio genera un depósito grande e inútil. Más datos malos no es más valor, es más ruido que estorba.
• Dejar la decisión de calidad al área técnica. El técnico sabe detectar un duplicado, pero no sabe cuál de dos direcciones es la buena. Eso lo sabe el negocio, y si el negocio no lo decide, no lo decide nadie.
• Perseguir el 100 por ciento. La calidad perfecta no existe y buscarla paraliza. La meta es que el dato sea lo bastante confiable para la decisión que sostiene, ni más ni menos.
• Medir el esfuerzo y no el resultado. Reportar “se limpiaron 40.000 registros” no dice nada. Lo que importa es si la decisión que depende de esos datos mejoró de verdad.

El patrón detrás de todos es el mismo: tratar la calidad como una tarea puntual de sistemas y no como un proceso permanente con responsable. Se parece más a la limpieza de un local, que hay que hacer todos los días, que a una obra que se entrega una vez y se cierra.

Qué NO es la calidad de datos, y qué no resuelve por sí sola

Es un tema que, por importante, se infla hasta que parece la respuesta a todo. Conviene marcar el límite antes de firmar un proyecto:

• No es tener muchos datos. Volumen y calidad son cosas distintas. Se puede tener poco y confiable, o mucho y basura.
• No es una herramienta que se instala. Hay software que ayuda a detectar y corregir, pero la calidad la sostiene un proceso con dueño, no una licencia.
• No garantiza buenas decisiones. Datos limpios habilitan una buena decisión, no la toman. El criterio de negocio sigue siendo humano.
• No arregla un proceso roto. Si la operación genera datos malos porque nadie los carga bien, limpiar el resultado es secar el piso con la llave abierta. El arreglo está en el proceso que produce el dato.
• No es lo mismo que gobierno de datos. La calidad es una parte; el gobierno incluye además permisos, privacidad y quién puede ver qué. Buena calidad con malos permisos sigue siendo un riesgo.

Marcar esto en la propuesta cuesta una reunión incómoda, pero evita el reclamo del mes cuatro, cuando alguien esperaba que “ordenar los datos” también arreglara un proceso que nadie tocó ni presupuestó.

Cuándo invertir en calidad de datos y cuándo el problema es otro

No es una decisión de tamaño de empresa ni de presupuesto. Es una decisión sobre qué depende de esos datos y cuánto cuesta que estén mal. Estas señales ayudan a ubicarse antes de gastar.

Señales de que hay que ordenar antes de seguir

• El mismo indicador da distinto según quién lo saque y de qué sistema lo saque.
• Un proyecto de IA ya entregó resultados que el equipo no se cree, y al revisar aparecen duplicados o registros vencidos.
• Las decisiones importantes se toman con un archivo que alguien “ajusta a mano” antes de cada reunión.
• Nadie puede decir cuál de los sistemas manda cuando un dato aparece distinto en dos lados.

Señales de que el problema no es la calidad de datos

• Los datos están bien, pero no existe la pregunta de negocio que justifique el proyecto: eso es falta de caso de uso, no de calidad.
• El dato que falta no está sucio, simplemente nunca se capturó: primero hay que crear el proceso que lo genere.
• El bloqueo es de permisos o de privacidad, no de exactitud: ese es un tema de gobierno de datos, no de limpieza.

El orden correcto: dolor, proceso, datos y recién la herramienta

La conclusión práctica es incómoda para quien quiere resultados rápidos: en IA, el trabajo aburrido va primero. Antes de elegir un modelo o una plataforma, hay que saber qué decisión se quiere mejorar (el dolor), cómo se produce hoy la información que la sostiene (el proceso) y si esa información es confiable (los datos). La herramienta es lo último, no lo primero, y quien la vende como punto de partida se está saltando justo lo que hace que funcione.

La buena noticia es que este trabajo paga aunque el proyecto de IA se posponga. Una empresa que ordena la calidad de sus datos decide mejor con o sin modelo: sus reportes dejan de discutirse, su operación deja de depender de la persona que corrige a ojo y su conocimiento deja de irse cuando alguien renuncia. La calidad de datos no es un requisito técnico que estorba antes de la parte interesante. Es la parte interesante, porque es la que fija el techo de todo lo demás que quieras construir encima.