Normalización: mismo cliente, cinco identificadores

Trae datos de cinco sistemas y vas a encontrar al mismo cliente cinco veces: con identificadores distintos, el nombre escrito de dos formas, fechas en tres formatos y un campo de “estado” que significa algo distinto en cada uno.

Un modelo de IA no lo nota. Lee lo que le dan y responde con total seguridad. Por eso la segunda etapa de cada proyecto es la normalización: convertir muchas descripciones incompatibles en una sola forma, consistente y validada, antes de que pase nada inteligente.

Dónde lo aprendimos

Estuvimos a cargo de la capa de integraciones y datos de una plataforma de IA para profesionales legales y de salud. Su asistente necesitaba los registros propios de cada práctica: clientes y pacientes, casos, notas, resultados de pruebas. Venían de sistemas de gestión de casos, de gestión de prácticas, de historias clínicas y de bienestar, cada uno con su propia idea de qué es un contacto, una nota o un resultado.

Un modelo, aplicado en la puerta

• Un adaptador por fuente. Cada adaptador habla el idioma de un sistema, con su autenticación y sus manías, y nada más.
• Un modelo tipado y validado por cada tipo de registro. Prácticas, personas, notas y resultados tienen cada uno una sola forma, revisada al entrar.
• Resolutores de identificadores. Los identificadores y campos de cada fuente se mapean al modelo compartido, para que “la misma persona” sea de verdad una sola persona.
• Rechazar, no reparar en silencio. Un registro que no encaja falla de forma visible y queda registrado. Nunca se cuela hasta el asistente como “probablemente está bien”.

La misma lección, fuera del sector salud

En el producto de coaching de ventas con IA que construimos, dos de los mayores problemas iniciales no tenían nada que ver con la calidad de la IA. Las llamadas se le atribuían al vendedor equivocado, y las grabaciones de capacitación se contaban como llamadas de ventas. Los dos eran problemas de normalización, y los dos habrían confundido a un gerente más que cualquier error del modelo.

Preguntas para hacerle a tus propios datos

• Si el mismo cliente existe en dos sistemas, ¿cuál gana, y quién lo decidió?
• ¿Qué pasa con un registro que no encaja: se rechaza, se repara o se deja pasar?
• ¿Podrías rastrear cualquier respuesta de tu IA hasta los registros que usó?

Tener datos limpios y consistentes es necesario, pero no suficiente. Un sistema puede recibir registros perfectos y aun así devolver una respuesta equivocada con total seguridad. Detectar eso es la tercera etapa: la confianza.