La escena se repite en directorios de todos los tamaños: alguien vuelve de un seminario, muestra un caso espectacular de IA aplicada, y la pregunta cae sobre la mesa: “¿Y nosotros por qué no estamos haciendo esto?”
Se aprueba un piloto. Se contrata una consultora o se arma un equipo interno. Hay entusiasmo, hay presupuesto, hay una presentación con un roadmap.
Tres meses después, el proyecto está empantanado en una conversación que nadie anticipó: “¿Por qué el cliente ‘Constructora Los Álamos’ aparece cuatro veces en el sistema con tres RUTs distintos?”
He visto esta película varias veces, y el final casi nunca depende del modelo, del proveedor ni del presupuesto. Depende de algo mucho más aburrido: el estado de los datos que ya tenías.
El malentendido de fondo
El marketing de la IA vende una promesa implícita: la inteligencia del modelo compensa el desorden de tus datos. Es una promesa atractiva, porque ordenar datos es caro, lento y nadie gana un bono por hacerlo.
Pero es falsa en el caso general, y es falsa por una razón que no tiene nada de técnica:
Importante (El principio que ningún modelo deroga)
Un modelo de IA no sabe lo que tu empresa sabe. Sabe lo que tus datos dicen. Si tus datos dicen que tienes cuatro clientes llamados Los Álamos, que la partida “varios” concentra el 30% del gasto, y que hay dos versiones de la planilla de costos que no cuadran entre sí, la IA razonará impecablemente sobre esa ficción.
Esto no es nuevo. Es el mismo garbage in, garbage out de siempre, con un agravante moderno: los sistemas de IA generativa producen respuestas fluidas, seguras y bien redactadas. El desorden de entrada ya no se nota en la salida. Antes, un reporte hecho sobre datos malos se veía malo. Ahora se ve impecable, y eso es más peligroso, no menos.
Dónde muere el piloto, exactamente
Los proyectos de IA que he visto fracasar no murieron en el modelo. Murieron en alguna de estas cuatro estaciones, todas anteriores a cualquier algoritmo:
1. La entidad que no existe
Quieres un asistente que responda “¿cuánto le hemos vendido a este cliente?”. Pero “cliente” no es una entidad en tus sistemas: es un texto libre escrito distinto en facturación, en CRM y en la planilla del vendedor. Antes de cualquier IA, alguien tiene que decidir (y mantener) qué es un cliente, cuál es su identificador, y quién es dueño de esa definición. Eso es un problema de gobernanza de datos , y ninguna API lo resuelve por ti.
2. El dato que vive en una planilla paralela
El sistema oficial dice una cosa, pero “la planilla de la Carola” (esa que el área realmente usa) dice otra. El piloto se conecta al sistema oficial y produce respuestas que el equipo descarta de inmediato: “esos números están malos, los buenos los tengo yo”. La IA quedó automatizando la versión de la realidad que nadie usaba.
3. La historia que no se guardó
Quieres predecir atrasos de proyectos, pero tu sistema solo guarda el estado actual de cada proyecto: cada actualización sobrescribe la anterior. No hay historia, y sin historia no hay nada que aprender. El dato que necesitabas para entrenar el modelo de 2026 había que empezar a guardarlo en 2023.
4. El campo que se llena para poder avanzar
El formulario exige “causa del atraso” y terreno pone “otros” el 80% de las veces, porque la lista de opciones no calza con la realidad y el camión está esperando. Cualquier modelo entrenado sobre ese campo aprenderá, con gran precisión estadística, que la causa principal de atrasos es “otros”.
Advertencia (La señal de alerta temprana)
Si en la reunión de kickoff del piloto nadie puede responder “¿dónde está la tabla maestra de X?” sin que se genere un debate, el proyecto ya está en riesgo. No es un problema que el proveedor de IA vaya a resolver: es el problema que el proveedor va a descubrir, facturando por hora.
”Pero la IA también sirve para limpiar datos”
Cierto, y es de las mejores noticias de los últimos años. Los LLMs son genuinamente buenos para tareas de limpieza que antes eran infernales: estandarizar direcciones escritas de veinte formas, clasificar glosas de texto libre, detectar duplicados difusos, mapear categorías entre sistemas.
Pero nota el cambio de marco, porque es todo el punto de este artículo: eso no es “hacer un piloto de IA”. Eso es usar IA como herramienta dentro de un proyecto de calidad de datos. El entregable no es un chatbot para el directorio: es una tabla maestra confiable. Es menos glamoroso y vale diez veces más.
La diferencia práctica:
| Piloto de IA típico | Proyecto de datos asistido por IA |
|---|---|
| Parte por el caso de uso vistoso | Parte por el inventario de datos |
| El data cleaning es un “imprevisto” | El data cleaning es el proyecto |
| Entregable: demo que funciona con datos curados a mano | Entregable: datos que cualquier proyecto futuro puede usar |
| Muere al tocar producción | Habilita los diez pilotos siguientes |
El orden correcto de las operaciones
Si tu empresa quiere subirse a la IA en serio, mi recomendación es invertir el roadmap habitual:
- Inventario honesto (2–4 semanas). ¿Qué datos tenemos, dónde viven, quién los produce, cuáles tienen dueño y cuáles son planillas huérfanas? No necesitas herramientas: necesitas entrevistas y honestidad.
- Una entidad maestra a la vez. Elige la entidad más transversal (clientes, proyectos, productos) y déjala impecable: identificador único, dueño asignado, proceso de alta definido. Usa LLMs para la deduplicación inicial si quieres; el mantenimiento es proceso, no tecnología.
- Cierra la llave del dato sucio. De nada sirve limpiar lo histórico si los formularios siguen produciendo basura. Cada campo obligatorio que se llena “para poder avanzar” es deuda que se acumula diariamente.
- Recién ahí, el piloto. Y elige uno cuyo insumo sea la entidad que ya limpiaste. La probabilidad de éxito cambia de categoría, y el piloto valida no solo la IA, sino la inversión en datos que hiciste antes.
Consejo (El test de los 5 minutos)
Antes de aprobar cualquier piloto de IA, pide esto: “muéstrenme la tabla de donde saldrán los datos, elijamos 20 filas al azar y verifiquemos cuántas están correctas y completas”. Si el ejercicio incomoda, acabas de ahorrarte varios meses y bastante plata. Si nadie sabe qué tabla abrir, ahorraste todavía más.
La ventaja injusta de quien ordena primero
Hay una lectura optimista de todo esto, y es con la que quiero cerrar.
Como los modelos son ya un commodity (todos tus competidores tienen acceso exactamente a los mismos), la ventaja competitiva se movió por completo al insumo. Y el insumo es, precisamente, lo que no se puede comprar con una suscripción: datos propios, ordenados, con historia y con dueño.
La empresa que pasó los últimos años cultivando una cultura de datos básica (bases de datos en vez de planillas, entidades maestras, formularios que capturan realidad) puede adoptar cada avance de IA en semanas. La que no, empieza cada piloto con los mismos seis meses de arqueología de RUTs duplicados.
La IA no va a arreglar tus datos sucios. Pero tus datos limpios van a multiplicar cada peso que inviertas en IA. El orden de esa frase es todo el roadmap.
Resumen (TL;DR)
Los pilotos de IA no mueren en el modelo: mueren en entidades sin definición, planillas paralelas, historia que nunca se guardó y campos rellenados con basura. La IA sí ayuda a limpiar datos, pero eso convierte el proyecto en uno de calidad de datos asistido por IA, que es exactamente lo que deberías hacer primero. Con los modelos convertidos en commodity, la ventaja competitiva es el insumo: datos propios, limpios y con dueño.