Tu empresa no tiene un problema de IA. Tiene un problema de datos.

Por qué la mayoría de los proyectos de IA en empresas LATAM fracasan antes de empezar, y qué trabajo de ingeniería de datos hay que hacer primero para que funcionen.

“Le compré a mi proveedor el módulo de IA y no funciona.” Esta frase la escuchamos en casi cada primera reunión con un cliente nuevo. Y en el 90% de los casos, el problema no está en la IA.

Está en lo que hay debajo de la IA: la infraestructura de datos. Esa parte invisible, poco glamorosa, que nadie menciona en los demos de venta pero que decide si el proyecto funciona o termina archivado.

¿Por qué falla la IA en empresas que “ya tienen datos”?

La respuesta corta: tener datos no es lo mismo que tener datos utilizables.

Una empresa de 150 empleados en el sector salud puede tener millones de registros distribuidos entre su HIS, su sistema de facturación, su CRM de pacientes y una carpeta de Google Drive con Excel. Esos datos existen. Pero no están integrados, no tienen un modelo común, y nadie los transforma de manera consistente antes de usarlos.

Cuando esa empresa contrata un módulo de IA —para predicción de demanda, para triaje automático, para detección de anomalías en facturación— el módulo recibe esa mezcla. Y lo que produce es basura con presentación bonita.

Esto no es un problema tecnológico nuevo. Es un problema de orden.

El stack que nadie ve

Cuando hablamos de “implementar IA” en una empresa, la conversación casi siempre empieza en la capa más visible: el modelo, la interfaz, el dashboard. Pero hay tres capas debajo que tienen que funcionar primero:

1. Integración de fuentes ¿Tus datos están en un solo lugar accesible o distribuidos en cinco sistemas que no se hablan? La primera tarea de ingeniería de datos es conectar esas fuentes y crear un flujo consistente de información hacia un repositorio central (puede ser tan simple como una base de datos PostgreSQL bien modelada).

2. Calidad y limpieza Duplicados, campos vacíos, formatos inconsistentes, registros con errores de carga histórica. Estos problemas no desaparecen solos — se propagan hacia arriba y envenenan cualquier análisis o modelo que los consuma. La limpieza no es un paso de una sola vez: es un proceso que tiene que automatizarse y monitorearse.

3. Modelado y transformación Los datos crudos del sistema operativo no tienen el formato que necesita el análisis. Una venta en el sistema contable es una fila con 30 campos técnicos. Para que sea útil en un reporte o en un modelo de IA, hay que transformarla: calcular márgenes, agrupar por categoría, vincular con el cliente, calcular la fecha correcta. Eso es transformación de datos, y tiene que vivir en un pipeline automatizado, no en una hoja de cálculo que alguien actualiza los viernes.

El caso que vimos en salud

Un centro médico con tres sedes en Colombia llevaba dos años con un sistema de gestión clínica (HIS). Tenían datos de pacientes, consultas, diagnósticos, medicamentos y resultados de laboratorio. Querían implementar un modelo predictivo para identificar pacientes con riesgo de no completar tratamientos crónicos.

Contrataron a un proveedor de IA. Seis meses después, el proyecto estaba paralizado.

El diagnóstico cuando llegamos: el HIS registraba los datos, pero cada sede lo había configurado de manera distinta. El campo “diagnóstico principal” tenía tres formatos diferentes según la sede. El 40% de los registros de seguimiento no tenían fecha de atención correcta — la fecha del sistema era la de carga administrativa, no la de la consulta. Y los datos de laboratorio vivían en un sistema separado que nunca se había integrado al HIS.

El modelo de IA no tenía ningún problema. El problema era que no había forma de armarle un dataset coherente con lo que existía.

Lo que hicimos antes de volver a hablar de predicción:

• Mapear las tres fuentes (HIS × 3 configuraciones + laboratorio)
• Definir un modelo de datos unificado para paciente, consulta y resultado
• Construir pipelines de transformación que normalizaban y cargaban en un repositorio central
• Implementar reglas de validación automáticas para detectar inconsistencias futuras

Ese trabajo tomó ocho semanas. Después, el modelo predictivo se implementó en dos semanas y funcionó desde el primer día.

¿Cuándo aplica esto y cuándo no?

Este problema aplica a empresas que:

• Tienen más de un sistema operativo generando datos (HIS, ERP, CRM, facturación, etc.)
• Llevan más de dos años con esos sistemas y nunca hicieron un trabajo de integración
• Tienen equipos que preparan reportes manualmente extrayendo de múltiples fuentes
• Quieren implementar IA, analytics avanzado o automatizaciones sobre esos datos

Cuándo no aplica: si tu empresa tiene una sola fuente de datos bien estructurada y los reportes ya salen de manera automatizada, el problema de integración probablemente no es tu bloqueador. Ahí sí tiene sentido ir directo a la capa analítica o de modelos.

Cómo detectar si este es tu problema

Tres síntomas concretos que indican que la capa de datos es el cuello de botella:

1. El reporte tarda más de 48 horas Si para armar un reporte de cierre alguien tiene que extraer datos de varios sistemas, pegarlos en Excel y hacer cálculos manuales, tenés un problema de integración. No de análisis.

2. Los números no cuadran entre sistemas El ERP dice una cosa, el CRM dice otra, la facturación dice una tercera. Si hay tres versiones de la misma métrica según de dónde la saques, los datos no están integrados ni modelados de manera consistente.

3. El equipo de datos pasa más tiempo preparando que analizando Si el 60-70% del tiempo de tu equipo técnico es “conseguir y limpiar los datos”, el problema está en la capa de abajo, no en las capacidades del equipo.

El trabajo que viene primero

Antes de evaluar cualquier solución de IA o analytics avanzado, hay un conjunto de preguntas que tiene que responderse:

• ¿Cuáles son todas las fuentes de datos que generamos?
• ¿Están conectadas o cada área tiene su isla?
• ¿Hay un lugar centralizado donde viven los datos procesados?
• ¿Quién es responsable de la calidad de esos datos?
• ¿Qué decisiones de negocio necesitan qué datos, con qué frecuencia?

Con esas respuestas se puede diseñar una arquitectura de datos adecuada al tamaño y presupuesto real de la empresa. No hay una solución única: para una empresa de 80 personas puede ser suficiente un PostgreSQL con pipelines simples en Python. Para una de 500 puede tener sentido incorporar dbt y un data warehouse más robusto. La clave es no sobredimensionar ni subdimensionar.

Lo que sí es universal: ese trabajo tiene que ocurrir antes de hablar de IA.

Takeaway accionable

Esta semana, hacé una sola pregunta a tu equipo: ¿cuánto tiempo tarda en estar listo el reporte de cierre de mes y cuántas personas lo tocan antes de llegar a vos?

Si la respuesta involucra más de dos personas y más de dos días, tenés la evidencia de que la capa de datos necesita trabajo. Ese es el punto de partida, no el modelo de IA.

---

Preguntas frecuentes

¿Cuánto tiempo lleva resolver los problemas de integración de datos?

Depende de la cantidad de fuentes y la calidad de los datos existentes. En proyectos que hemos visto, el rango va de 6 semanas (empresa con 2 fuentes relativamente limpias) a 4-6 meses (empresa con 5+ sistemas con años de datos sucios). Lo importante es que es un trabajo finito y planificable, no un pozo sin fondo.

¿Se puede implementar IA mientras se resuelven los datos?

En algunos casos sí, si hay una fuente de datos que ya está limpia y permite construir un caso de uso acotado. Pero no es lo recomendable como estrategia general — corrés el riesgo de construir sobre bases inestables y tener que rehacer el trabajo después.

¿Esto requiere reemplazar los sistemas actuales?

Casi nunca. El enfoque más común es mantener los sistemas operativos existentes (HIS, ERP, CRM) y construir una capa de integración y transformación por encima, sin tocarlos. Los sistemas siguen funcionando igual; lo que cambia es cómo se consolidan y procesan los datos para análisis.

¿El open source es suficiente para esto?

Sí, para la mayoría de las empresas de 50 a 500 empleados. PostgreSQL, dbt, Airflow o n8n, y una capa de visualización como Metabase o Superset cubren el 90% de los casos sin costo de licencia y sin depender de un proveedor específico.

¿Por dónde empiezo si no sé qué tengo?

Por un diagnóstico. Antes de diseñar soluciones hay que mapear el estado actual: qué fuentes existen, cómo están conectadas, qué decisiones dependen de esos datos, qué tan confiables son. Con eso en mano, las prioridades se vuelven obvias.