Los Proyectos de AI Empresarial Fallan en la Etapa de Datos — No en la Etapa del Modelo

El sesenta y cinco por ciento de los despliegues de AI empresarial se estan estancando. Ese numero se ha mantenido aproximadamente constante durante tres anos, lo que significa que el problema es estructural, no circunstancial. Una nueva generacion de modelos fundacionales no lo ha arreglado. Tampoco mejores herramientas de MLOps, mas personal de ingenieria ML ni mayor respaldo ejecutivo.

El diagnostico convencional culpa a la etapa equivocada. Cuando un proyecto de AI empresarial falla en entregar, la autopsia usualmente se enfoca en la seleccion del modelo ("deberiamos haber usado una arquitectura diferente"), la infraestructura ("nuestra configuracion de nube no era la correcta") o la preparacion organizacional ("necesitabamos mas alfabetizacion en AI"). Estas no siempre estan equivocadas. Pero casi siempre son incompletas — y frecuentemente estan buscando un culpable equivocado.

La razon real por la que los proyectos de AI empresarial se estancan es casi siempre la misma: los datos no estaban listos, y nadie asigno el tiempo ni las herramientas para prepararlos.

Los Numeros No Son Ambiguos

La investigacion es consistente y lo ha sido durante anos.

El consenso de la industria — entre MIT, McKinsey, Gartner y profesionales a escala — ubica el 60 al 80% del tiempo de proyectos ML en preparacion de datos, no en entrenamiento de modelos. No en despliegue, no en evaluacion, no en configuracion de infraestructura. Preparacion de datos.

Forrester, en una encuesta de 2024 a 500 lideres de datos empresariales realizada con Capital One, encontro que el 73% identifico la calidad y preparacion de datos como la barrera numero uno para el exito de AI. No la calidad del modelo. No los costos de computo. No la gobernanza. Calidad y preparacion de datos.

La investigacion de IBM y MIT encuentra consistentemente que el 80 al 90% de los datos empresariales son no estructurados — documentos, emails, imagenes, PDFs, registros manuscritos, exportaciones de bases de datos heredadas. Estos son los datos de los que la mayoria de los sistemas de AI empresarial necesitan aprender, y tambien son los datos que requieren mas preparacion antes de que cualquier sistema de entrenamiento o recuperacion pueda usarlos.

Solo el 30% de las organizaciones usan AI para preparacion automatizada de datos. El otro 70% lo maneja manualmente, con scripts personalizados o no lo maneja en absoluto.

Estos numeros suman una imagen clara. La mayoria de las organizaciones empresariales tienen la mayor parte de sus datos en formatos que la AI no puede consumir directamente. La mayoria pasa la mayor parte del tiempo de sus proyectos ML tratando de arreglar esto. Y la mayoria sigue fallando en entregar sistemas de AI funcionales a tiempo.

La Historia Que los Equipos Se Cuentan

Hay un patron predecible en como los equipos de AI empresarial explican proyectos fallidos o estancados. La historia pasa por varias etapas.

Etapa 1: Optimismo. Se aprueba un piloto. El caso de uso esta claro. Se identifican las fuentes de datos. El equipo selecciona un modelo, configura la infraestructura y comienza.

Etapa 2: Friccion. Los datos estan mas desordenados de lo esperado. Los archivos estan en formatos que el pipeline no puede parsear. Las etiquetas son inconsistentes. Los expertos de dominio no pueden operar las herramientas de anotacion. La revision de cumplimiento senala las herramientas basadas en la nube. Los cronogramas se retrasan.

Etapa 3: El pivote. Enfrentando progreso lento, los equipos intentan enfoques diferentes: un modelo diferente, una estrategia de prompting diferente, mas computo, mas ingenieros. Estos se sienten como accion. Rara vez arreglan el problema real.

Etapa 4: El estancamiento. Despues de varios pivotes, el proyecto esta sobre presupuesto, fuera de cronograma y por debajo de las expectativas. El problema original de datos no ha sido abordado — se ha trabajado alrededor de el, generando deuda tecnica y problemas de confiabilidad.

Etapa 5: La autopsia. La conclusion es tipicamente algo sobre preparacion organizacional, limitaciones del modelo o desafios de infraestructura. El problema subyacente de datos se reconoce brevemente, si acaso.

La razon por la que el problema de datos queda subponderado en las autopsias es que no se siente como un fallo de estrategia. Se siente como un fallo de ejecucion — un problema mundano e inglorioso que deberia haber sido resuelto por alguien del equipo. Admitir que la etapa de preparacion de datos fue el cuello de botella se siente como admitir que no hiciste el trabajo basico. Asi que los equipos buscan explicaciones mas sofisticadas.

Por Que Se Culpa al Modelo Cuando los Datos Son la Causa

Hay una razon por la que la calidad del modelo es el diagnostico incorrecto mas comun.

La calidad del modelo es medible. Puedes calcular precision, F1, puntajes BLEU, calificaciones de preferencia humana. Cuando un modelo tiene bajo rendimiento, la metrica te lo dice claramente. La calidad de los datos es mucho mas dificil de medir — especialmente antes del entrenamiento, cuando los problemas son latentes.

Datos de entrenamiento deficientes producen modelos que parecen funcionar hasta que no lo hacen. Un modelo entrenado con datos etiquetados de forma inconsistente parecera aprender y producira salidas que parecen plausibles. La inconsistencia se muestra como un techo de rendimiento — el modelo no mejora mas alla de cierto punto independientemente de los cambios de hiperparametros. Pero este techo se ve, desde afuera, como una limitacion del modelo. Los equipos buscan un modelo mas grande, o una arquitectura diferente, o mas computo de entrenamiento. Nada funciona porque nada aborda la causa raiz.

Lo mismo aplica al volumen de datos. Los equipos que creen que tienen un problema de calidad de datos a veces intentan resolverlo con cantidad: recolectar mas ejemplos, generar datos sinteticos, ejecutar mas rondas de anotacion. Si los datos subyacentes son ruidosos o etiquetados inconsistentemente, mas de lo mismo solo amplifica el problema. El modelo entrena con un dataset mas grande de la misma calidad y produce los mismos resultados (o a veces peores).

Los Cinco Patrones de Fallo

En las organizaciones con las que hemos trabajado y hablado, los fallos de AI empresarial en la etapa de datos caen en cinco patrones reconocibles.

1. Comenzar Antes de Que los Datos Esten Listos

El patron mas comun es simplemente comenzar el entrenamiento del modelo antes de que los datos de entrenamiento hayan sido preparados adecuadamente. Esto usualmente es un problema de presion de cronograma: los hitos requieren progreso demostrable, y "todavia estamos preparando datos" no se siente como progreso para los stakeholders.

El resultado es predecible. Los equipos entrenan con datos imperfectos, ven resultados imperfectos, iteran sobre el entrenamiento en lugar de sobre los datos, y pasan meses haciendo mejoras marginales sobre un techo establecido por la calidad de los datos, no por la capacidad del modelo.

La investigacion de MIT Sloan encontro que los programas de AI ganadores invierten las proporciones tipicas de gasto, destinando 50 al 70% del cronograma del proyecto para la preparacion de datos antes de que comience cualquier entrenamiento. Esto es incomodo porque retrasa las salidas visibles. Tambien mejora dramaticamente las tasas de exito.

2. El Stack de Herramientas Fragmentado

La mayoria de los equipos empresariales usan de tres a siete herramientas para la preparacion de datos: un parser de documentos para ingesta, una plataforma de anotacion para etiquetado, una biblioteca de puntuacion de calidad para limpieza, potencialmente una herramienta de datos sinteticos para aumento. Cada herramienta es capaz en aislamiento. La integracion entre ellas es donde vive el fallo.

Sin formato de datos compartido significa codigo de conversion personalizado en cada punto de transicion. Sin trazabilidad de auditoria compartida significa que no puedes demostrar cumplimiento con un solo reporte de linaje. Cuando cualquier herramienta individual se actualiza, el codigo de conexion personalizado se rompe. Tiempo de ingenieria ML que deberia ir hacia construir modelos va hacia mantener plomeria.

3. Sin Trazabilidad de Auditoria

En industrias reguladas — salud, legal, servicios financieros, defensa — los sistemas de AI requieren proveniencia de datos demostrable. De donde vino este ejemplo de entrenamiento? Quien lo anoto? Fue modificado? Que version del esquema de etiquetado estaba vigente cuando fue etiquetado?

La mayoria de los stacks de herramientas de preparacion de datos no pueden responder estas preguntas a lo largo de todo el pipeline. Las herramientas individuales pueden tener logs internos, pero no hay un registro de linaje unificado que abarque desde la ingesta hasta la exportacion. Esto no es solo un riesgo de cumplimiento — es una senal de calidad. Los equipos que no pueden rastrear los datos de entrenamiento hasta su fuente no pueden identificar con confianza donde entraron los errores al pipeline.

4. La Brecha de Expertos de Dominio

Las personas mejor posicionadas para generar etiquetas de alta calidad son expertos de dominio: doctores para datos clinicos, abogados para documentos legales, ingenieros para especificaciones tecnicas. Las herramientas disponibles para etiquetado fueron construidas para cientificos de datos e ingenieros ML — requieren entornos Python, configuracion de Docker, familiaridad con linea de comandos o configuracion compleja de aplicaciones web.

El resultado es que los expertos de dominio son excluidos del proceso de anotacion completamente (y reemplazados por ingenieros ML que estan menos calificados para juzgar la correccion especifica del dominio) o requieren tanto soporte para usar las herramientas que la ventaja de throughput de la experiencia de dominio se consume en configuracion y sobrecarga operacional.

5. El Bloqueador de Cumplimiento

Para industrias reguladas, las herramientas cloud-native frecuentemente no son permisibles. HIPAA restringe donde pueden procesarse los datos de pacientes. GDPR controla las transferencias de datos transfronterizas. Las reglas de privilegio legal restringen el manejo de documentos de clientes. Las politicas internas de seguridad de informacion agregan restricciones adicionales.

La mayoria de las herramientas comerciales de preparacion de datos son cloud-native. Los equipos en industrias reguladas aceptan el riesgo de cumplimiento (aceptando responsabilidad que pueden no entender completamente), construyen sus propias herramientas (costoso y lento) o recurren a procesos manuales que no escalan.

Como Se Ve Cambiar el Enfoque

Las organizaciones que navegan exitosamente la adopcion de AI empresarial comparten algunas caracteristicas que las distinguen de las que se estancan.

Tratan la preparacion de datos como la fase principal del proyecto, no como un paso preliminar. En lugar de gastar el 10% del cronograma del proyecto en datos y el 90% en desarrollo del modelo, invierten esto. La preparacion de datos es el hito. El entrenamiento es lo que sucede cuando los datos estan listos.

Miden la calidad de datos antes de entrenar. Esto significa ejecutar auditorias de calidad en datasets etiquetados, verificar tasas de consistencia de etiquetas, validar que las distribuciones de datos de entrenamiento coincidan con las distribuciones esperadas en produccion y confirmar que la calidad de parseo es adecuada en todos los formatos de documentos en alcance.

Involucran a expertos de dominio en la anotacion desde el inicio. Esto requiere herramientas que los expertos de dominio puedan operar sin soporte de ingenieria ML — herramientas que se instalan como aplicaciones, no como entornos de desarrollo. Las ganancias de productividad y calidad de la anotacion por expertos de dominio consistentemente superan la inversion en configuracion de herramientas.

Establecen una trazabilidad de auditoria unica a lo largo de todo el pipeline. Esto no es solo un requisito de cumplimiento — es un requisito de higiene de ingenieria. Poder rastrear cualquier ejemplo de entrenamiento desde el documento fuente hasta la exportacion, con un registro de cada transformacion aplicada, es esencial para depurar fallos del modelo y para satisfacer auditores regulatorios.

Usan herramientas on-premise en entornos regulados. Esto no es opcional para organizaciones de salud, legales y servicios financieros. Es una restriccion que moldea cada decision de seleccion de herramientas desde el inicio.

La Verdad Incomoda Sobre los Cronogramas de AI Empresarial

Las expectativas de cronograma para proyectos de AI empresarial estan sistematicamente mal calibradas.

Cuando una organizacion comienza un proyecto de AI empresarial con el objetivo de ajustar un modelo con documentos internos, la estimacion inicial tipica es de tres a seis meses. La estimacion realista, considerando la etapa de preparacion de datos, es mas frecuentemente de nueve a dieciocho meses — con el tiempo adicional casi enteramente en preparacion de datos.

Esto no es un consejo de desesperanza. Es un argumento para adelantar el trabajo. Los equipos que asignan tiempo realista a la preparacion de datos e invierten en herramientas que hagan esa preparacion eficiente pueden completar proyectos en nueve a doce meses. Los equipos que intentan comprimir la preparacion de datos y comenzar el entrenamiento prematuramente frecuentemente pasan doce a veinticuatro meses alcanzando el mismo umbral de calidad — o nunca lo alcanzan.

La matematica no es complicada. La disciplina para hacerlo en el orden correcto es dificil.

---

Lectura Relacionada

• Lo Que 27 Equipos de AI Empresarial Nos Dijeron Sobre Su Problema de Preparacion de Datos — investigacion primaria sobre donde realmente se estan atascando los equipos de AI empresarial
• El Costo Oculto de Unir Docling, Label Studio y Cleanlab — un desglose detallado de como las herramientas fragmentadas componen los fallos de preparacion de datos
• La Hoja de Ruta de Adopcion de AI Empresarial: Digitalizar, Limpiar, Etiquetar, Entrenar — un enfoque estructurado para escalonar proyectos de AI empresarial para mayores tasas de exito