marybernalj Cuando los datos dejan de informar y empiezan a entrenar
Serie · Data Architecture Stories
De los datos al conocimiento: cómo diseñar infraestructuras con propósito
En los primeros posts de esta serie hablamos de estructura, de cimientos invisibles y de cómo los entornos de datos han evolucionado desde esquemas rígidos hacia plataformas más flexibles y vivas. Todo ese recorrido tenía un objetivo claro: llegar al punto en el que los datos dejan de servir únicamente al análisis y comienzan a sostener sistemas que aprenden. Porque, cuando se habla de inteligencia artificial, el mayor desafío rara vez está en el modelo; casi siempre está en los datos y en cómo han sido organizados.
Hoy muchas organizaciones buscan incorporar IA sin revisar primero cómo fluye, se transforma y se gobierna su información. No es casual que distintos estudios reporten que entre el 70% y el 85% de los proyectos de inteligencia artificial no logran generar valor sostenido o fracasan al pasar a producción. Informes de MIT (2025) y Gartner (2025) coinciden en que las principales causas no son algorítmicas, sino problemas de calidad, disponibilidad, integración y gobernanza de datos. En otras palabras, se intenta construir inteligencia sobre bases que no fueron pensadas para aprender.
En entornos analíticos tradicionales, los sistemas responden preguntas retrospectivas: qué ocurrió, cuánto se vendió o cómo cambió un indicador. En IA, las preguntas son más exigentes: ¿con qué datos aprende el sistema?, ¿qué historia temporal contienen?, ¿cómo se detectan y corrigen errores?, ¿podemos explicar por qué una predicción fue distinta para dos personas similares? En este contexto, los datos dejan de ser un insumo para reportes y se convierten en el material de entrenamiento del sistema. Aquí aparece de forma natural la necesidad de prácticas como el Data Stewardship: roles y responsabilidades claras para garantizar que los datos tengan dueño, contexto y reglas explícitas a lo largo de su ciclo de vida.
Esto explica por qué, según IBM y O’Reilly, entre el 60% y el 80% del esfuerzo de un proyecto de machine learning se dedica a preparar datos: limpiar, integrar, versionar, documentar y contextualizar. Cuando ese trabajo no está respaldado por un diseño sólido de flujos, almacenamiento y control, los modelos se vuelven frágiles, difíciles de explicar y aún más difíciles de mantener en el tiempo.
Aquí es donde todo lo discutido en los posts anteriores cobra sentido. La estructura de los datos, de la que hablamos al inicio de la serie, es la que permite conservar contexto e historia. Los cimientos invisibles, ingesta, almacenamiento, procesamiento y consumo, son los que garantizan trazabilidad y coherencia. La transición del data warehouse al data lake y luego a esquemas híbridos habilita combinar estabilidad con flexibilidad. Y el enfoque orientado a decidir, no solo a reportar, es el que permite que los sistemas empiecen a mirar hacia adelante.
En la práctica, un entorno preparado para IA necesita algo más que grandes volúmenes de información. Requiere datos históricos bien organizados, no solo valores actuales. Necesita separar claramente datos crudos, datos procesados y datos listos para entrenamiento. Exige versionar no solo modelos, sino también los conjuntos de datos que los alimentan. Demanda reglas de calidad integradas al flujo, porque la IA no corrige errores: los amplifica. Y, sobre todo, debe estar diseñado para iterar y retroalimentarse, no para pipelines estáticos pensados solo para reportes. Es precisamente en este punto donde disciplinas como MLOps comienzan a cobrar relevancia, conectando datos, modelos y operación continua.
Un escenario frecuente es el de organizaciones que desarrollan modelos con buen desempeño en pruebas, pero que fallan al pasar a producción. Al analizar el problema, no se encuentra un error en el algoritmo, sino datos incompletos, cambios silenciosos en las fuentes o la imposibilidad de reconstruir con qué información se entrenó una predicción pasada. La solución rara vez es cambiar el modelo; casi siempre implica rediseñar cómo se gestionan los datos a lo largo de su ciclo de vida.
Este desafío no es solo técnico, también es cultural. Los entornos que logran escalar la IA son aquellos que dejan de ver los datos como un subproducto operativo y comienzan a tratarlos como un activo estratégico. Aprender implica aceptar errores, medirlos y corregirlos. Implica que la calidad de la información no es responsabilidad de un solo equipo, sino un acuerdo organizacional. Las empresas que avanzan en IA no son necesariamente las que usan los modelos más complejos, sino las que construyen sistemas capaces de aprender de forma continua y responsable.
Si hoy estás pensando en incorporar inteligencia artificial, antes de hablar de algoritmos conviene hacerse algunas preguntas clave: ¿sé de dónde provienen los datos que entrenan mis modelos?, ¿puedo reproducir una predicción hecha hace seis meses?, ¿tengo mecanismos para detectar sesgos o degradación en los datos?, ¿mis sistemas están pensados para aprender o solo para reportar? Si alguna de estas respuestas es negativa, el principal obstáculo no es la IA, sino la forma en que se gestionan los datos.
Esta serie comenzó hablando de estructura y termina hablando de aprendizaje. Porque, al final, la inteligencia artificial no empieza en el modelo, sino en la manera en que organizamos el conocimiento. Los datos son el lenguaje con el que aprenden los sistemas. Y la forma en que los diseñamos define hasta dónde pueden llegar.
