Lo Que 27 Equipos de AI Empresarial Nos Dijeron Sobre Su Problema de Preparacion de Datos

Realizamos 27 llamadas de descubrimiento en industrias reguladas durante un periodo de seis meses. Las conversaciones abarcaron empresas de ingenieria y construccion, organizaciones de salud, practicas legales, equipos de servicios financieros, startups de AI on-device y agencias de AI que construyen para clientes empresariales.

Preguntamos sobre objetivos de adopcion de AI, herramientas actuales, bloqueadores y donde realmente se estaba gastando el tiempo. Esperabamos una variedad de respuestas. Obtuvimos un patron tan consistente que era casi inquietante.

Nueve ICPs distintos nombraron la preparacion de datos como su dolor numero uno con AI — sin que se los pidieramos, antes de preguntar directamente. Los problemas especificos diferian: formatos de archivos, restricciones regulatorias, complejidad de etiquetado, restricciones de infraestructura. Pero la causa raiz siempre era la misma. Habia una capa faltante entre los datos crudos del negocio y los datos listos para AI, y nadie tenia una buena respuesta para cerrarla.

Esto es lo que nos dijeron.

Los Equipos Con Quienes Hablamos

Las 27 llamadas se desglosaron aproximadamente asi:

• Empresas de ingenieria y construccion (4): Gestionando grandes archivos de documentos — BOQs, especificaciones, planos de ingenieria, informes de proyecto — con anos de datos acumulados en PDFs, archivos escaneados y formatos heredados.
• Organizaciones de salud (5): Notas clinicas, registros de pacientes, informes de radiologia, datos de facturacion. Los requisitos de cumplimiento HIPAA significaban que las herramientas en la nube estaban efectivamente fuera de consideracion.
• Practicas legales y empresas legal-tech (4): Bibliotecas de contratos, expedientes de casos, presentaciones regulatorias. El privilegio de datos y la confidencialidad del cliente creaban restricciones similares a las de salud.
• Servicios financieros y fintech (3): Registros de transacciones, documentos de cumplimiento, evaluaciones de riesgo. Los requisitos de trazabilidad de auditoria regulatoria agregaban una capa de complejidad por encima del tooling estandar de AI.
• Empresas de AI on-device y edge (4): Construyendo productos de AI disenados para ejecutarse localmente en hardware. Sus propios pipelines de preparacion de datos estaban bloqueando los cronogramas de desarrollo de productos.
• Agencias de AI (5): Construyendo sistemas de AI para clientes empresariales. El problema que reportaban usualmente era un proxy de los problemas de sus clientes — estaban absorbiendo la complejidad de preparacion de datos ellos mismos.
• Startups de AI en etapa temprana (2): Toma de notas, inteligencia documental, gestion del conocimiento. Equipos mas pequenos pero el mismo problema de datos, comprimido en tiempo del fundador.

En todos estos, 9 equipos nombraron la preparacion de datos como el cuello de botella principal de su proyecto de AI — antes de la seleccion del modelo, antes de la infraestructura, antes de la revision de cumplimiento. En la mayoria de los casos, ya habian abordado esas otras areas. Los datos eran lo que quedaba.

Que Significaba Realmente "Preparacion de Datos" Para Cada Segmento

Uno de los hallazgos mas interesantes fue que "preparacion de datos" significaba cosas genuinamente diferentes dependiendo de la industria — pero la experiencia de dolor era identica.

Para las empresas de ingenieria y construccion, preparacion de datos significaba convertir un archivo de 700GB de especificaciones PDF, documentos de ingenieria dibujados a mano y BOQs escaneados en datos estructurados que pudieran entrenar un modelo para extraer partidas, cantidades y estimaciones de costos. El Lider de AI en una de estas empresas lo dijo claramente:

"El problema no es fine-tuning sino limpiar y preparar los datos diversos."

La diversidad es el desafio. Un solo proyecto podria involucrar PDFs con tablas incrustadas, planos escaneados, archivos Excel en formatos propietarios y notas manuscritas. Pasar de eso a un dataset limpio y etiquetado requiere parseo, normalizacion, deduplicacion y anotacion experta — y no hay una sola herramienta que maneje la cadena completa.

Para los equipos de salud, preparacion de datos significaba algo diferente: redaccion de PHI antes de que cualquier procesamiento pudiera comenzar, luego extraccion de estructura de notas clinicas escritas en taquigrafia no estandar, luego etiquetado por clinicos que no son cientificos de datos. El requisito de cumplimiento no es incidental — determina que herramientas son permisibles y cuales no.

Para los equipos legales, el desafio era similar pero con la complejidad agregada del privilegio. No puedes enviar documentos de clientes a una API en la nube para parsearlos. Necesitas herramientas de parseo que se ejecuten localmente, herramientas de etiquetado que los expertos de dominio (abogados, no ingenieros ML) puedan operar, y una trazabilidad de auditoria que pueda sobrevivir al descubrimiento.

Para las empresas de edge AI, la preparacion de datos estaba bloqueando cronogramas de producto. Su problema era el throughput de anotacion — las clases objetivo cambian a medida que los productos evolucionan, las herramientas de anotacion requieren ingenieria ML para operar, y la dependencia de ingenieros para ejecutar lo que es fundamentalmente una tarea de expertos de dominio estaba ralentizando todo. El equipo en una startup de edge AI nos dijo:

"El etiquetado de datos es el desafio principal — las clases objetivo cambian frecuentemente."

Ese ultimo punto — las clases objetivo cambian frecuentemente — es subestimado. En AI empresarial, el esquema de etiquetado no es fijo. Evoluciona a medida que los equipos aprenden mas sobre el problema. Cada vez que cambia, las herramientas de anotacion necesitan reconfigurarse, lo cual requiere tiempo de ingenieria ML. Esto hace que el problema sea dinamico, no solo grande.

Para las agencias de AI, el problema era que estaban absorbiendo los problemas de datos de sus clientes. Un fundador de agencia nos dijo:

"Los clientes en salud y legal empresarial tienen mas probabilidad de preocuparse por soluciones on-premise."

La agencia no estaba manejando directamente los datos — estaban disenando el sistema que lo haria. Pero los requisitos on-premise de sus clientes moldeaban cada decision tecnologica, y el panorama fragmentado de herramientas disponibles hacia ese proceso de diseno significativamente mas dificil de lo necesario.

Los Cinco Tipos de Problemas de Preparacion de Datos

A traves de las 27 llamadas, surgieron cinco categorias distintas de problemas de preparacion de datos. La mayoria de los equipos tenian al menos dos. Varios tenian los cinco.

1. El Problema de Ingesta

Los datos crudos existen en formatos que los pipelines de entrenamiento de AI no pueden consumir directamente. PDFs, imagenes escaneadas, exportaciones de bases de datos heredadas, formatos de archivo propietarios, documentos manuscritos. Antes de que cualquier limpieza o etiquetado pueda ocurrir, estos archivos necesitan ser parseados en texto estructurado o datos estructurados.

Esto es mas dificil de lo que suena. El parseo de PDF que funciona para PDFs digitales limpios falla en documentos escaneados. El OCR que funciona en texto impreso falla en notas manuscritas. La extraccion de tablas que funciona en PDFs tabulares simples falla en especificaciones de ingenieria complejas de multiples columnas. La variedad de formatos de archivo en un archivo tipico de documentos empresariales es enorme, y ninguna herramienta de parseo individual los maneja todos de forma confiable.

2. El Problema de Limpieza

El texto crudo parseado es ruidoso. Errores de OCR, artefactos de formato, secciones duplicadas entre documentos, terminologia inconsistente entre equipos o periodos de tiempo. Antes de que los datos puedan etiquetarse, necesitan limpiarse — y la limpieza a escala empresarial requiere un esfuerzo manual significativo o herramientas sofisticadas que la mayoria de los equipos no tienen.

El CTO de una empresa de AI on-device describio bien la expectativa estandar:

"Hacer el proceso de limpieza de datos significativamente mas facil, aunque solo sea 80% automatizado, seria un gran impulsor."

Nota el "80%" — esto no es una solicitud de automatizacion perfecta. Los equipos saben que siempre se necesita algo de revision humana. Lo que necesitan es que el primer 80% no requiera ingenieros ML escribiendo scripts personalizados de Python.

3. El Problema de Etiquetado

Para aprendizaje supervisado e instruction-tuning, los datos necesitan ser etiquetados. Las personas mejor posicionadas para etiquetarlos — los expertos de dominio — tipicamente no son lo suficientemente tecnicos para operar las herramientas de etiquetado disponibles sin configuracion y soporte significativos. Esto crea una dependencia de ingenieros ML para ejecutar pipelines de anotacion que deberian ejecutarse en tiempo de expertos de dominio.

Encontramos este patron en salud (doctores que necesitan etiquetar notas clinicas), legal (abogados que necesitan anotar clausulas contractuales) y construccion (ingenieros que necesitan identificar y categorizar partidas de BOQ). En cada caso, la herramienta de anotacion en si era el cuello de botella, no la experiencia de los anotadores.

4. El Problema de Cumplimiento

En industrias reguladas, los datos no pueden moverse a la nube para procesamiento. HIPAA, GDPR, privilegio legal y politicas internas de gobernanza de datos imponen restricciones sobre donde pueden ir los datos y quien puede verlos. La mayoria de las herramientas comerciales de preparacion de datos para AI son cloud-native. Esto significa que las empresas reguladas aceptan el riesgo de cumplimiento, construyen sus propias herramientas o recurren a procesos manuales.

Una empresa de ciberseguridad puso esta restriccion en terminos claros:

"La mayoria de las herramientas de AI procesan inferencia sobre la nube, haciendo que los datos sean esencialmente publicos."

Esta no es una preocupacion marginal. Es una incompatibilidad estructural entre como se disena la mayoria de las herramientas de AI y donde viven los datos empresariales regulados. La consecuencia es que las organizaciones reguladas hacen AI de manera diferente o no hacen AI en absoluto.

5. El Problema de Integracion

Para los equipos que ya habian ensamblado una cadena de herramientas — un parser aqui, una herramienta de anotacion alla, una biblioteca de limpieza encima — el problema era unirlas. Sin formato de datos compartido. Sin trazabilidad de auditoria compartida. Codigo de conexion personalizado que se rompe cuando cualquier herramienta individual se actualiza. Tiempo de ingenieria ML gastado manteniendo plomeria en lugar de construir modelos.

Este es el problema que parece resuelto desde afuera pero esta consumiendo activamente recursos por dentro. Un fundador de startup de AI de toma de notas nos dijo simplemente:

"Los datos son el mayor problema."

No el entrenamiento. No la inferencia. No el despliegue. Los datos. Y ya habian intentado el enfoque de herramientas fragmentadas.

Por Que el Entrenamiento de Modelos Casi Nunca Fue el Problema Declarado

Este es el hallazgo que mas nos sorprendio cuando dimos un paso atras y miramos el agregado.

El entrenamiento de modelos — la actividad que recibe mas atencion en la prensa de AI, mas inversion de capital de riesgo y mas talento de ingenieria — rara vez se menciono como cuello de botella. Los equipos no decian "necesitamos un mejor modelo base" o "necesitamos mejor infraestructura de entrenamiento." Decian: no podemos llegar al entrenamiento porque nuestros datos no estan listos.

Esto se alinea con la investigacion mas amplia. El consenso de la industria ubica el 60-80% del tiempo de proyectos ML en preparacion de datos, no en entrenamiento de modelos. Forrester y Capital One encuestaron a 500 lideres de datos empresariales y encontraron que el 73% identifico la calidad y preparacion de datos como la barrera numero uno para el exito de AI. El patron que vimos en 27 llamadas es consistente con lo que la investigacion muestra a escala.

La razon es estructural: el entrenamiento de modelos es un problema resuelto en el sentido de que las herramientas son maduras, la infraestructura existe y el proceso esta bien entendido. La preparacion de datos no esta resuelta. Es especifica del dominio, especifica del formato, especifica del cumplimiento y especifica de la organizacion de maneras que las herramientas generalizadas manejan mal.

Lo Que los Equipos Estaban Haciendo Actualmente

Cuando preguntamos como los equipos estaban manejando actualmente la preparacion de datos, las respuestas cayeron en tres categorias:

Categoria 1: Cadenas de herramientas cosidas. Tres a siete herramientas individuales, cada una manejando una parte del pipeline, conectadas por codigo personalizado escrito y mantenido por ingenieros ML. El stack mas comun: un parser de documentos (frecuentemente Docling o Unstructured.io), una herramienta de anotacion (usualmente Label Studio) y una biblioteca de limpieza (tipicamente Cleanlab o scripts personalizados). La generacion de datos sinteticos, cuando era necesaria, agregaba Distilabel o similar. Cada herramienta tiene su propia configuracion, su propio formato de datos, su propia carga de mantenimiento.

Categoria 2: Procesos manuales. En industrias reguladas donde el enfoque de cadena de herramientas chocaba con paredes de cumplimiento, los equipos recurrian a hojas de calculo, revision manual y procesamiento documento por documento. Esto funciona pero no escala mas alla de pilotos pequenos.

Categoria 3: Nada aun. Varios equipos no habian comenzado la preparacion de datos en absoluto. Tenian objetivos de adopcion de AI, tenian una idea general de que datos de entrenamiento necesitaban y estaban bloqueados en el primer paso. El panorama de herramientas era demasiado fragmentado, demasiado tecnico o demasiado dependiente de la nube para encontrar un punto de entrada.

Ninguno de estos equipos describio su enfoque actual como satisfactorio. Los equipos de cadena de herramientas cosida querian reducir la sobrecarga de ingenieria. Los equipos de procesos manuales querian moverse mas rapido. Los equipos que no habian comenzado querian un lugar para empezar.

La Capa Faltante

Lo que emergio de las 27 llamadas fue una imagen clara de lo que estaba ausente en el panorama de herramientas de AI empresarial: un entorno unificado de preparacion de datos on-premise disenado para industrias reguladas.

Los componentes individuales existen. Los parsers de documentos existen. Las herramientas de anotacion existen. Las bibliotecas de puntuacion de calidad existen. Lo que no existe — o no existia, al momento de estas llamadas — es un unico entorno que maneje el pipeline completo (ingestar, limpiar, etiquetar, aumentar, exportar) sin requerir ingenieria ML para pegar herramientas, sin enviar datos fuera de la organizacion, y sin exigir que los expertos de dominio aprendan a operar herramientas de desarrollador.

Esto no es una brecha de funcionalidad en ninguna herramienta individual. Es una capa que el ecosistema no ha construido.

Implicaciones para la Adopcion de AI Empresarial

La imagen que pintaron estas 27 llamadas es de un panorama de AI empresarial donde el factor limitante rara vez es en lo que la prensa se enfoca. No es la capacidad del modelo. No es la disponibilidad de computo. No es la voluntad organizacional.

Es la brecha entre los datos que las organizaciones tienen y los datos que sus sistemas de AI necesitan — y la ausencia de herramientas disenadas para cerrar esa brecha en entornos regulados y on-premise.

El 65% de los despliegues de AI empresarial que actualmente se estancan estan estancandose mayormente en esta capa. Las organizaciones que estan teniendo exito estan invirtiendo fuertemente en ingenieria ML para construir y mantener pipelines personalizados, o estan operando en segmentos donde las herramientas en la nube son aceptables y los datos ya estan relativamente limpios.

Para el resto — industrias reguladas, organizaciones con archivos complejos de documentos, equipos que necesitan expertos de dominio involucrados en la anotacion — la brecha de herramientas es real. Reconocerla claramente es el primer paso para cerrarla.

---

Lectura Relacionada

• Los Proyectos de AI Empresarial Fallan en la Etapa de Datos — No en la Etapa del Modelo — las razones estructurales por las que la preparacion de datos es donde la mayoria de los proyectos de AI empresarial se estancan
• El Costo Oculto de Unir Docling, Label Studio y Cleanlab — un desglose detallado del impuesto de integracion que pagan los equipos que ejecutan stacks de herramientas fragmentados
• Tus Ingenieros ML No Deberian Estar Haciendo Esto — por que el bloqueo de expertos de dominio esta ralentizando los pipelines de anotacion en industrias reguladas