Todo 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 duele: los casos límite de los 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?

Basta preguntar a dos áreas qué cuenta como caso abierto, cliente activo o pedido completado: con frecuencia salen dos respuestas, ambas defendibles y ambas en uso hoy en un informe 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: ¿se puede ver qué pasó?

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 alguien pregunta cuál era la respuesta correcta para cualquier campo y descubre 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, el problema no es de datos de entrenamiento y no se resuelve con esfuerzo. Es 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 la operación es, en los hechos, un usuario con permiso de leerlo todo.

Si el 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 informe 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 hacen falta datos limpios. Hacen falta estos datos.

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

"Primero hay que arreglar 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. Empieza en una decisión que hoy no se puede tomar rápido. Detrás de esa decisión hay entre cinco y quince campos, no varios cientos. El equipo arregla identidad, definiciones, historia y acceso solo para esos campos, construye contra ellos y lo pone en producción.

Después viene la siguiente decisión, que reutiliza el trabajo de identidad ya hecho, 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 vale la pena rastrear los datos detrás de esa única decisión: ahí hay 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.