Tu proyecto de IA es un proyecto de datos, y casi todo el trabajo va antes

Nos piden IA. Casi siempre encontramos un proyecto de datos.

Suena a evasiva de consultor, así que aquí va la afirmación concreta: en la mayoría de los proyectos, lo que impide tener un sistema de IA útil no es la capacidad del modelo, ni el presupuesto, ni la capacidad de ingeniería. Es que la organización no puede responder de forma confiable a qué se refiere un registro, qué significa un campo, qué pasó antes, o quién tiene permiso de verlo.

Esas cuatro preguntas son todo el juego. Un modelo encima de una organización que puede responderlas es transformador. Un modelo encima de una que no puede va a producir resultados fluidos y seguros sobre los que después dos áreas van a discrepar, lo cual es peor que nada, porque parece una respuesta.

Los cuatro problemas, en el orden en que muerden

1. Identidad: ¿es la misma cosa?

Un cliente en tres sistemas, escrito de tres maneras. Un estudiante que se transfirió, cambió de apellido y ahora existe dos veces. Un proveedor que también es cliente bajo una razón social ligeramente distinta.

Es el problema menos glamoroso del software empresarial y el que con más confiabilidad detiene todo lo que va después. También se concentra justo donde más te importa: los casos límite de tus datos de identidad rara vez son los registros inactivos. Son las transferencias, los clientes que regresan, las relaciones multi-entidad, las personas cuya situación es complicada. Es decir: la población sobre la que se le iba a preguntar a cualquier modelo útil.

Describimos el mismo problema en educación superior, donde unir los registros de tutoría, inscripción y becas es el trabajo que tiene que preceder a cualquiera de las aplicaciones interesantes. Es el mismo problema en siniestros, en manufactura y en práctica clínica. Siempre es este problema.

2. Definiciones: ¿dos personas quieren decir lo mismo?

Pregúntale a dos áreas qué cuenta como caso abierto, cliente activo o pedido completado, y con frecuencia vas a obtener dos respuestas, ambas defendibles y ambas en uso hoy en un reporte en el que alguien confía.

Automatizar encima de ese desacuerdo es el error más caro de esta categoría, porque lo industrializa. El resultado es consistente, rápido y seguro, y está equivocado para el área que no escribió la especificación. Hemos visto una plataforma de datos de dieciocho meses llegar a una pregunta que resultó irrespondible exactamente por esto.

La solución no es técnica y no es cara. Es una junta que nadie quiere presidir.

3. Historia: ¿puedes ver qué pasó realmente?

Los modelos aprenden de ejemplos de respuestas correctas. Un número sorprendente de operaciones nunca ha registrado una.

La operación de siniestros para la que construimos una plataforma rastreaba 93 campos por expediente en una hoja de cálculo, lo cual suena a muchos datos hasta que preguntas cuál era la respuesta correcta para cualquier campo, y descubres que el archivo guarda el estado actual y no las decisiones que lo produjeron. Quién cambió la reserva, cuándo y por qué no está ahí. Estaba en un correo.

Si nadie escribió nunca cuál era el resultado correcto, no tienes un problema de datos de entrenamiento que se resuelva con esfuerzo. Tienes un problema de recolección que solo se resuelve con tiempo, y debería empezar ahora y no al inicio del proyecto que lo necesita.

4. Acceso: ¿quién tiene permiso de saber esto?

El último es el que aparece tarde y mata calendarios. Un modelo que puede responder cualquier pregunta sobre tu operación es, en los hechos, un usuario con permiso de leerlo todo.

Si tu modelo de permisos vive en la interfaz y no en los datos, que es el arreglo normal en sistemas viejos, entonces una capa de recuperación sobre esos datos acaba de saltarse calladamente años de control de acceso. Esto se descubre en revisión de seguridad, en el mes cinco, y no es una corrección menor.

Por qué "los datos los limpiamos después" siempre pierde

Porque el modelo no falla ruidosamente con datos malos. Falla de forma plausible.

Un pipeline con una unión rota no truena. Produce respuestas para los registros que sí coincidieron y omite en silencio los que no, y el resultado se ve enteramente razonable: un reporte con números, ligeramente equivocados, en una dirección que nadie puede ver. Para cuando alguien lo nota, el número ya estuvo en tres presentaciones de dirección.

Es el mismo argumento que el costo de equivocarse: lo que importa no es la tasa de error sino si el error se detecta. Datos malos más un modelo es el peor caso en ese eje, porque la fluidez del modelo disfraza activamente el defecto.

No necesitas datos limpios. Necesitas estos datos.

Aquí está la parte que salva proyectos, y va en contra de cómo suele venderse este trabajo.

"Primero arregla los datos" es un consejo que produce parálisis, un programa de dos años y un comité de gobernanza. La mayoría de las organizaciones no puede arreglar todos sus datos y no debería intentarlo, porque la mayoría de sus datos no sostiene ninguna decisión que alguien esté esperando.

La versión productiva es estrecha. Elige una decisión que hoy no se pueda tomar rápido. Rastrea hacia atrás los campos de los que depende esa decisión, casi siempre entre cinco y quince, no varios cientos. Arregla identidad, definiciones, historia y acceso solo para esos campos. Construye la cosa. Ponla en producción.

Después hazlo otra vez para la siguiente decisión, reutilizando el trabajo de identidad que ya hiciste, porque esa parte compone y casi nada más lo hace.

Es el mismo argumento de secuencia que hacemos sobre operaciones de nearshoring: algo real en producción en meses, cada paso pagando el siguiente, en lugar de una plataforma que no sirve hasta que está terminada.

El diagnóstico, en una pregunta

Cuando un cliente nos pide un sistema de IA, preguntamos qué decisión cambiaría, y quién la tomaría distinto.

Si la respuesta es específica, sea "detendríamos el embarque", "le hablaríamos a ese cliente esta semana" o "no pagaríamos esa factura todavía", entonces rastrea los datos detrás de esa única decisión y tienes un proyecto acotado, financiable y con un resultado visible.

Si la respuesta es "tendríamos mejor visibilidad", ahí todavía no hay proyecto. Hay una conversación pendiente, y va a ahorrar lo que hubiera costado la plataforma.

Las organizaciones que obtengan valor real de la IA en los próximos dos años no serán las que compraron los mejores modelos. Serán las que pasaron este periodo capaces de decir, sin una semana de conciliación, qué es cierto sobre su propia operación.

Ese trabajo de base es nuestra práctica de datos y analítica, y es lo menos emocionante y más duradero que hacemos.