La resolución de entidades se está convirtiendo en infraestructura de IA, no en limpieza de datos

Hace un tiempo, vi a un agente de IA dar una respuesta confiadamente incorrecta por una razón completamente aburrida. Una empresa tenía dos registros para el mismo cliente corporativo. Uno contenía el nombre comercial anterior y un contacto de finanzas. El otro contenía el nombre legal nuevo que la empresa había adoptado después de una adquisición, junto con una dirección de facturación diferente. Al agente se le hizo una pregunta sencilla: ¿esta cuenta está en buen estado? Encontró un registro, vio que no había facturas vencidas y dijo que sí. Las facturas vencidas estaban archivadas bajo el otro nombre.

Nada fue inventado. El modelo razonó limpiamente sobre los datos que se le proporcionaron. Los datos simplemente sucedieron que describían a dos clientes donde, en el mundo real, había uno. El error no estaba en el modelo de lenguaje. Estaba en la unión.

He llegado a pensar que este es uno de los riesgos más subestimados en la IA empresarial, y uno de los menos discutidos. Hablamos interminablemente sobre la precisión del modelo, el diseño de la solicitud y la gobernanza. Hablamos mucho menos sobre si un sistema realmente sabe a qué entidad del mundo real se refiere un registro determinado. Esa pregunta tiene un nombre. Se llama resolución de entidades, y después de sesenta años en segundo plano, se está convirtiendo silenciosamente en una pieza de infraestructura en vivo.

El problema cambió de tiempo

Durante la mayor parte de su vida laboral, “¿estos dos registros son la misma entidad?” era una pregunta de limpieza. La ejecutabas en batch, en un programa de gestión de datos maestros, un almacén o una canalización de análisis. Nunca fue perfecta, pero era tolerable, porque la salida era un informe que alguien leía la semana siguiente. Si dos registros de la misma proveedor no se fusionaban, una cifra de gasto salía ligeramente mal, un analista lo notaba y se corregía en la próxima ejecución. El sistema tenía holgura en él. El tiempo absorbía los errores.

Un agente de IA elimina esa holgura. Cambia el tiempo de la pregunta de “eventualmente” a “ahora”. Cuando un agente está a punto de aprobar un reembolso, enrutar un caso, actualizar un perfil o responder a una pregunta de cumplimiento, la entidad resuelta ya no alimenta un panel. Alimenta una acción. El costo de una unión incorrecta pasa de un número que está ligeramente mal a algo que sucede en el mundo, inmediatamente, y a menudo sin un humano en el bucle para atraparlo.

Ese es el cambio que vale la pena considerar. El problema subyacente es antiguo y bien entendido. Lo que es nuevo es que lo hemos conectado directamente a sistemas que actúan por sí mismos.

Un problema estadístico de la década de 1960

La resolución de entidades no llegó con los grandes modelos de lenguaje. Llegó con tarjetas perforadas. En 1959, H. B. Newcombe y sus colegas publicaron un breve artículo en Science sobre la vinculación automática de registros vitales, que describía cómo una computadora podría decidir si un registro de nacimiento y un registro de matrimonio se referían a la misma persona. Una década después, Ivan Fellegi y Alan Sunter le dieron a la idea una teoría matemática formal, definiendo los tres resultados que cualquier sistema de coincidencia aún produce hoy: una vinculación, una no vinculación y una posible vinculación que una persona necesita revisar.

Hay un detalle en esa línea que vale la pena destacar, porque es la parte que la gente más a menudo se equivoca. La vinculación de registros nunca fue solo una coincidencia exacta en una dirección de correo electrónico o un ID compartido. Desde el principio fue probabilística. Pesaba la evidencia de que dos registros estuvieran de acuerdo en un apellido, una fecha, un lugar, y producía una puntuación, porque los datos ingresados por humanos son desordenados y las claves exactas fallan constantemente. La resolución de entidades moderna todavía funciona de esta manera. Combina reglas deterministas, donde un identificador estable compartido es decisivo, con coincidencia probabilística y difusa de aprendizaje automático que hace frente a errores tipográficos, apodos, campos transpuestos, abreviaturas y la docena de pequeñas formas en que la misma persona o empresa aparece de manera diferente en los sistemas. Un buen informe sobre el campo traza una línea ininterrumpida desde esos registros vitales de la década de 1950 hasta los métodos de agrupación y aprendizaje automático utilizados ahora.

Lo que realmente ha cambiado es cuándo necesitamos la respuesta. Los investigadores escribían sobre resolver entidades en el momento de la consulta, en lugar de puramente con anticipación, mucho antes de la actual ola de IA. En ese momento era una optimización interesante. Ahora es más cercana a un requisito.

Por qué los agentes lo convierten en infraestructura

La mayoría de los sistemas de IA empresariales no responden desde la memoria del modelo. Recuperan. El patrón popularizado como generación aumentada con recuperación tiene un agente que extrae contexto relevante en el momento de la pregunta y razona sobre él. Esto es, en general, algo bueno. Ancla las respuestas en sus datos en lugar de en la memoria del modelo.

Pero conlleva una consecuencia que es fácil de perder. El agente hereda lo que el paso de recuperación le entrega. Si la recuperación devuelve un cliente fragmentado, tres registros parciales que nunca se conectaron, el agente razonará sobre tres clientes. Si la recuperación devuelve una unión incorrecta, dos empresas diferentes colapsadas en un solo perfil, el agente razonará sobre una. La ambigüedad ya sentada en sus sistemas de origen se pasa directamente y se presenta al modelo como un hecho establecido. El modelo no tiene forma de saber que la unión fue incorrecta, al igual que usted no lo sabría al leer un resumen ordenado de registros que nunca había visto.

Así que la resolución no puede ser un pensamiento posterior que se ejecuta una vez cada trimestre y aterriza en una tabla separada. La entidad tiene que ser ensamblada cuando se ingiere el dato, y la vista resuelta actual de ella tiene que ser recuperable en el instante en que el agente pregunta. Eso es una dependencia de tiempo de ejecución. Se comporta mucho más como una base de datos o un servicio de autenticación que como un proyecto de limpieza de datos periódico, y tiene que ser diseñado, monitoreado y confiado de la misma manera que trataría cualquier otro sistema que su aplicación llama en tiempo real.

La brecha de preparación que nadie nombra con precisión

La industria ya siente que algo falta aquí. El Índice de preparación para la IA de Cisco 2025 encontró que el 83 por ciento de las organizaciones planean implementar agentes autónomos, mientras que solo alrededor de un tercio siente que su infraestructura está realmente lista para ellos, y solo alrededor de un cuarto se siente equipado para controlar y gobernar lo que esos agentes realmente hacen. La más reciente encuesta sobre el estado de la IA de McKinsey describe una brecha similar desde la otra dirección: alrededor del 88 por ciento de las organizaciones ahora utilizan IA en al menos una función, sin embargo, la mayoría no la han escalado en toda la empresa.

Cuando la gente explica esa brecha, tienden a recurrir a dos palabras: calidad de los datos y gobernanza. Ambas importan, y ninguna es opcional. Pero hay una pregunta más estrecha sentada debajo de ellas que los datos limpios y bien gobernados no responden por sí solos. ¿Puede el sistema decir a qué entidad del mundo real se refiere un registro determinado, en todos los lugares donde vive ese registro, en este momento? Puedes mantener datos de alta calidad en cada sistema individual y aún así fallar en esa prueba, porque el fallo no vive dentro de un sistema. Vive en los espacios entre ellos, donde el mismo cliente lleva tres caras ligeramente diferentes.

Qué verificar antes de dejar que un agente actúe

Si tratas la resolución de entidades como infraestructura en vivo, puedes inspeccionarla como infraestructura. Los modos de fallo operativos son específicos y verificables: identidades divididas que deberían ser una, fusiones falsas de registros que deberían permanecer separados, reglas de supervivencia obsoletas que siguen promoviendo una dirección superada, identificadores persistentes perdidos y agentes que heredan la ambigüedad del sistema de origen como si fuera una verdad resuelta.

Una prueba de preparación práctica no requiere un nuevo modelo o una nueva categoría de proveedores. Ensámbla un conjunto de entidades que genuinamente entiendas. Pásalo por el mismo camino de recuperación que utiliza tu agente, no una copia limpia separada construida para la demostración. Luego mide las cosas que realmente deciden los resultados: cuántas fusiones falsas y divisiones falsas, cómo maneja la ambigüedad genuina, dónde se encuentran sus umbrales de confianza, cuándo escala a un humano en lugar de adivinar y cómo pasa limpiamente a tus controles de datos maestros y gobernanza existentes. Si un equipo no puede responder a esas preguntas, el agente está actuando sobre una identidad que no puede verificar, y la confianza en su salida está mal colocada.

Ninguno de esto reemplaza la gestión de datos maestros, la gobernanza, las plataformas de datos de clientes o el almacén. Esas responden a diferentes preguntas, y siguen siendo necesarias. La gobernanza decide qué puede hacer un agente. La resolución de entidades decide a quién o a qué se refiere. La primera es madura en la mayoría de las organizaciones grandes. La segunda es la capa que muchos están a punto de descubrir que necesitan junto a ella, en tiempo real, en el momento en que dejan que un agente actúe en lugar de aconsejar.

El agente que vi no necesitaba un modelo más inteligente. Necesitaba saber que dos nombres eran un cliente antes de que se le permitiera sonar seguro. A medida que les damos a estos sistemas autoridad real para actuar, esa disciplina silenciosa de sesenta años deja de ser limpieza y comienza a ser soportante.