Seis de cada diez proyectos de inteligencia artificial no llegan a producción o no generan valor medible, según cifras atribuidas a Gartner. El denominador común no es la calidad del modelo ni el presupuesto: es la gestión de los datos que lo alimentan. Para los equipos de gobierno de datos en América Latina, ese dato no es una advertencia genérica — es un diagnóstico operativo.
La estadística circula con fuerza en el debate técnico de 2025 y 2026: la mayoría de las iniciativas de inteligencia artificial corporativa colapsan en la fase de datos, no en la de algoritmos. Los data scientists pasan entre el 60% y el 80% de su tiempo limpiando, reconciliando y buscando datos — tiempo que no se invierte en modelado ni en generación de valor. Detrás de ese cuello de botella hay déficits concretos de gobernanza: ausencia de data lineage documentado, ownership sin asignar, catálogos incompletos o inexistentes, y clasificación de datos que nunca se actualizó desde que se implementó el data lake.
El dato sin dueño: el origen más frecuente del fracaso
El DAMA-DMBOK identifica el data ownership como una de las capacidades fundacionales de cualquier programa de gobierno de datos. En la práctica, muchas organizaciones latinoamericanas tienen datos distribuidos entre sistemas legados, plataformas cloud y hojas de cálculo departamentales sin que ningún data steward sea formalmente responsable de su calidad o actualización. Cuando un proyecto de IA intenta consumir esos datos, el equipo técnico descubre inconsistencias que nadie puede resolver porque nadie tiene autoridad para hacerlo. El modelo termina entrenándose con datos incorrectos o el proyecto se paraliza esperando validación.
El EDM Council, en su marco DCAM (Data Capability Assessment Model), ubica el data ownership y la definición de roles de stewardship entre las capacidades de nivel 2 — las que deben estar consolidadas antes de avanzar a casos de uso analíticos avanzados. Sin embargo, según se informa en relevamientos del sector, una proporción significativa de empresas medianas y grandes de la región inicia proyectos de IA sin haber alcanzado ese nivel de madurez.
Data lineage y catálogos: la infraestructura invisible que los proyectos IA exigen
Un modelo de machine learning no puede ser auditado si no se puede rastrear el origen de cada feature que lo alimenta. El data lineage — la trazabilidad documentada de cómo un dato se transforma desde su fuente hasta el output del modelo — es un requisito operativo, no un nice-to-have. Sin él, cuando el modelo arroja un resultado sesgado o erróneo, el equipo no puede determinar si el problema está en la extracción, en la transformación, en el etiquetado o en el modelo mismo. El debugging se vuelve arqueología.
Los catálogos de datos cumplen una función complementaria: hacen que los datos correctos sean encontrables. En organizaciones donde el catálogo no existe o está desactualizado, los equipos de datos duplican esfuerzos, consumen versiones distintas del mismo dataset o directamente trabajan con datos cuya definición de negocio nadie conoce. Herramientas como Collibra, Alation o soluciones open source como OpenMetadata resuelven el problema técnico, pero solo si hay un proceso de gobernanza que las alimente con metadata real y actualizada.
En Brasil, Argentina y México: regulación que agrega presión al problema de datos
El contexto regulatorio latinoamericano amplifica el riesgo. En Brasil, la LGPD (Lei Geral de Proteção de Dados) exige que las organizaciones puedan demostrar el propósito del tratamiento de datos personales — incluyendo los usados para entrenar modelos de IA. Si no hay catálogo ni lineage, esa demostración es imposible, y la Autoridade Nacional de Proteção de Dados (ANPD) puede considerar el tratamiento como no conforme. En Argentina, la Ley 25.326 y las disposiciones de la AAIP imponen obligaciones similares de accountability. En México, el INAI ha comenzado a preguntar, en el marco de auditorías, qué datos se usan en sistemas automatizados de toma de decisiones. Un proyecto de IA sin gobernanza de datos no solo fracasa técnicamente: puede generar exposición regulatoria.
Cuándo aplica este diagnóstico — y cuándo no
Este problema es especialmente agudo en proyectos de IA que consumen datos operacionales de múltiples sistemas (ERP, CRM, fuentes externas), en modelos que toman decisiones con impacto en clientes o empleados, y en organizaciones que no tienen un Chief Data Officer o un equivalente funcional con autoridad real sobre datos. No aplica de la misma manera a proyectos de IA que trabajan sobre datos sintéticos, datasets cerrados y bien documentados, o experimentos acotados en entornos sandbox sin dependencia de datos productivos.
Un CDO que quiera evaluar la exposición de su organización puede partir de tres preguntas concretas: ¿Cada dataset crítico para proyectos de IA tiene un data steward nombrado y operativo? ¿Existe lineage documentado desde la fuente hasta el modelo para al menos los tres proyectos de mayor impacto? ¿El catálogo de datos fue actualizado en los últimos seis meses? Si alguna respuesta es negativa, el riesgo de fracaso no es teórico — es inminente. El punto de partida práctico puede ser una evaluación de madurez contra el CDMC (Certified Data Management Professional) del EDM Council o contra los dominios del DAMA-DMBOK, priorizando ownership, calidad y arquitectura de datos antes de aprobar nuevos presupuestos de IA.
Para profundizar en los marcos de referencia, el DAMA-DMBOK está disponible en dama.org y el DCAM del EDM Council en edmcouncil.org — ambos con versiones de evaluación de madurez descargables que permiten un diagnóstico inicial sin costo.
