Pular para o conteúdo principal
Volver al blog
Arquitectura y datos
4 min de lectura

No hay IA sin preparación de datos

El problema de datos es poco visible al inicio y compuesto al final. Corregir en el origen parece desperdicio y es lo único que evita el retrabajo grande.

Cuando un proyecto de IA no entrega lo que prometió, la conversación suele girar en torno al modelo. En la mayoría de los casos que veo, el modelo era adecuado. Lo que faltaba era dato en condiciones de ser usado, y eso casi nunca aparece en la propuesta inicial.

El problema empieza antes del primer experimento

La preparación de datos no es sinónimo de volumen. Una empresa con diez años de historial puede estar menos preparada que una con dos, si en esos diez años el significado de los campos cambió tres veces sin registro.

Un estudio de caso de Microsoft sobre ingeniería de software para aprendizaje automático describe la gestión de datos como una etapa que atraviesa todo el ciclo, no como un paso inicial que se concluye. Recolección, limpieza, etiquetado y versionado vuelven en cada iteración, y los equipos que lo tratan como tarea de preparación subestiman el esfuerzo de forma sistemática.

Cascadas de datos

La investigación sobre cascadas de datos, publicada por Google, describe un patrón incómodo: los problemas de calidad de datos son poco visibles al inicio y producen efectos compuestos y negativos que solo aparecen mucho después, a menudo ya en producción.

Lo que vuelve peligrosa a la cascada es la asimetría. El costo de corregir en el origen es bajo y el beneficio es invisible, así que nadie lo prioriza. El costo de corregir con el modelo ya en producción es alto, y el problema llega disfrazado de "el modelo se está equivocando".

La implicación práctica es directa: el trabajo de datos hecho temprano parece desperdicio y es lo único que evita el retrabajo grande.

Cuatro preguntas que revelan la preparación real

Antes de cualquier proyecto de IA, cuatro preguntas separan la expectativa de la realidad.

¿El dato existe de forma accesible? Existir en un sistema heredado sin API, o dentro de PDFs escaneados, es muy distinto de existir en una tabla consultable.

¿El significado es estable? Si el campo "estado" tuvo tres conjuntos de valores en cinco años, el historial solo sirve con una traducción explícita.

¿La calidad es conocida? No perfecta, conocida. Saber que el 12% de los registros tiene la dirección vacía es utilizable. No saberlo no lo es.

¿El uso está permitido? La base de origen, el consentimiento y la finalidad tienen que soportar el uso previsto, sobre todo cuando hay datos personales.

Si alguna respuesta es "no sé", esa investigación es el primer entregable del proyecto, no una nota al pie.

La validación de datos es una prueba, no un reporte

El trabajo sobre validación de datos para aprendizaje automático, presentado por investigadores de Google, defiende un punto que vale para cualquier aplicación de IA: el error de datos debe detectarse automáticamente, en la entrada del pipeline, contra un esquema esperado.

En la práctica eso significa declarar expectativas y fallar cuando se rompen: tipo, rango de valores, obligatoriedad, cardinalidad, distribución aproximada. Es el equivalente de una prueba unitaria, solo que para el insumo en vez del código.

La ganancia no es académica. Sin validación, un sistema de origen que cambia de formato en silencio degrada el resultado durante semanas antes de que alguien lo note. Con validación, el pipeline se detiene en el primer lote extraño y alguien es avisado el mismo día.

Gobernanza sin volverse burocracia

El cuerpo de conocimiento de gestión de datos de DAMA organiza el tema en dominios como calidad, arquitectura, metadatos y gobernanza. Es extenso, y leer la guía entera antes de empezar es la manera más confiable de nunca empezar.

El recorte mínimo que funciona para un proyecto de IA son tres cosas:

  • Dueño definido por conjunto de datos, una persona con nombre, no un área.
  • Diccionario vivo que diga qué significa cada campo y cuándo cambió el significado.
  • Linaje registrado, es decir, de dónde vino, qué transformaciones sufrió y adónde fue.

Con esos tres, la mayoría de las preguntas de auditoría y de investigación ya tiene respuesta.

La base de conocimiento tiene exigencias propias

Cuando el proyecto es de recuperación aumentada, la preparación cambia de naturaleza. Lo que importa pasa a ser si el documento está actualizado, si hay versiones en conflicto circulando, si el texto sobrevive a la extracción y si el permiso del documento puede respetarse en la búsqueda.

Dos versiones de la misma política, una revocada y otra vigente, indexadas juntas, producen un sistema que responde con confianza usando la regla equivocada. Ningún ajuste de modelo corrige eso.

Qué significa esto para tu equipo

Antes de aprobar el próximo proyecto de IA, haz una evaluación de preparación de dos semanas sobre los conjuntos que va a usar. Acceso, estabilidad de significado, calidad medida y permiso de uso, con hallazgos escritos.

Si la evaluación señala un problema serio, ese es el proyecto real, y entrega valor incluso sin IA: reportes confiables, integración posible, auditoría más barata.

Y pon validación automática en la entrada del pipeline desde el primer día. Es la pieza más barata de construir al inicio y la más cara de agregar cuando el sistema ya está en producción.

Referencias

Las fuentes usadas en este texto, para que las verifiques y profundices.

  1. 1"Everyone wants to do the model work, not the data work": Data Cascades in High-Stakes AISambasivan et al. (Google Research, CHI), 2021
  2. 2Data Validation for Machine LearningBreck et al. (SysML), 2019
  3. 3Software Engineering for Machine Learning: A Case StudyAmershi et al. (Microsoft Research, ICSE), 2019
  4. 4DAMA-DMBOK: Data Management Body of KnowledgeDAMA International