Antes de razonar hay que saber quién es quién

Una ontología nos dice qué clase de cosa es cada registro. Pero en la
empresa real, la misma entidad aparece con diez nombres distintos. Hasta
que no resolvemos eso, cualquier razonamiento sobre el conocimiento
empresarial está construido sobre una arena.

Introducción

Ayer definimos la ontología como la especificación explícita de un dominio:
clases, relaciones, restricciones. Pero hay un problema que la ontología no
resuelve por sí sola, y que aparece en la primera reunión con cualquier
equipo de datos: ¿qué entidad concreta representa este registro?

Porque en la empresa real, «ACME» no es una entidad. «ACME», «ACME LTD»,
«ACME UK», «Acme Group», «Customer #49281», «ACME (UK) Ltd — oficina de
Manchester» pueden ser, según el sistema y el momento, la misma entidad,
dos entidades distintas, o una entidad con dos filiales. Y hasta que no
sepamos cuál de las tres es la realidad, no podemos razonar sobre nada.

El problema

Una entidad financiera está construyendo un agente de compliance para
KYC/AML (Know Your Customer / Anti-Money Laundering). El agente tiene que
responder preguntas como «¿Tiene este cliente alguna relación con una
entidad en una lista de sanciones?» o «¿Cuál es el grupo al que pertenece
este cliente?».

El problema: el cliente al que llaman «ACME» aparece en sus sistemas así:

Son seis registros. ¿Es una entidad o seis? La respuesta correcta, que solo
sabe el analista de KYC, es: una entidad madre (ACME Group) con dos filiales
(ACME LTD y ACME UK Ltd), de las que una tiene una cuenta a su nombre y
otra opera como corresponsal. Y esa estructura es exactamente lo que el
agente necesita para responder correctamente a la pregunta de sanciones.

Si el agente trata los seis registros como seis clientes distintos, va a
decir que «ACME UK» no tiene relación con «ACME Group» y va a pasar un
control de sanciones que debería haber detenido. Si los trata como un único
cliente, va a mezclar perfiles de riesgo que son distintos y va a generar
falsos positivos que van a saturar al equipo de compliance.

En ambos casos, el agente no razonó mal. La identidad de las entidades no
estaba resuelta, y sobre esa identidad todo lo demás se construyó.

El concepto

Entity Resolution (resolución de entidades) es el proceso de identificar,
unificar y mantener la identidad de las entidades del mundo real a través de
múltiples fuentes de datos. Tiene tres operaciones fundamentales:

1. Matching (pareado). Decidir si dos registros, posiblemente de
   distintos sistemas, se refieren a la misma entidad real. «ACME LTD» y
   «ACME UK LIMITED» — ¿misma entidad o dos?
2. Deduplicación. Unificar los registros que corresponden a la misma
   entidad en una única representación canónica, conservando la trazabilidad
   de de dónde venía cada dato.
3. Identidad a lo largo del tiempo. Mantener la identidad cuando la
   entidad cambia de nombre, se fusiona, se escinde o se reestructura.
   «ACME Group» compró «Beta Corp» en 2024: ahora son una entidad, pero sus
   historiales son distintos.

La entity resolution no es un problema de strings. «ACME LTD» y «ACME UK
LIMITED» se parecen, pero «ACME» y «ACME & SONS» no. Y a veces dos entidades
distintas se parecen muchísimo (dos empresas «Acme» en distintas
jurisdicciones). Los métodos van desde el simple (normalización +
similaridad de nombre + coincidencia de atributos como CIF/NIF) hasta los
complejos (modelos de aprendizaje supervisado sobre pares anotados, razonamiento
sobre grafos de relación). Pero el principio es el mismo: decidir qué es la
misma cosa, con evidencia y con trazabilidad.

Y aquí está el punto clave para la serie: la entity resolution es una
condición previa del conocimiento empresarial fiable. Sin ella:

• La ontología (ayer) no se puede aplicar: no sabes a qué entidad concreta
  asignarle la clase.
• Las relaciones (mañana) no se pueden construir: no sabes quién se
  relaciona con quién.
• El knowledge graph (próximos días) se convierte en un grafo de
  duplicados: seis nodos para la misma empresa, cada uno con una parte del
  historial.
• Y el agente, en lugar de razonar sobre la empresa, razona sobre una
  colección de registros que no sabe si son la misma cosa.

Arquitectura

En el diagrama de la serie, la entity resolution se sitúa justo sobre la
semántica y bajo el conocimiento, como el proceso que convierte
registros en entidades:

                KNOWLEDGE
                     ↑
          ┌──────────┴──────────┐
          ↓                     ↓
      ONTOLOGY          ENTITY RESOLUTION
   (clases, relaciones,   (matching, dedup,
    restricciones)         identidad) → ENTIDADES
          ↓                     ↓
          └──────────┬──────────┘
                     ↓
                SEMANTICS
                     ↓
                   DATA

La ontología dice qué clase de cosa es; la entity resolution dice qué
cosa concreta es. Juntas, producen las entidades canónicas sobre las que se
construye el resto del conocimiento.

Caso de uso

La entidad financiera, con su caso de KYC/AML. Descomponemos:

1. Problema. El control de sanciones y el análisis de grupos de
   clientes dependen de saber quién es quién, y hoy esa información está
   dispersa en seis sistemas con nombres inconsistentes. Un error de
   identidad puede significar una violación regulatoria o, en el otro
   extremo, un falso positivo que bloquea un cliente legítimo.
2. Decisión. Determinar el grupo al que pertenece un cliente y si algún
   miembro del grupo está en una lista de sanciones.
3. Conocimiento necesario. Qué entidades componen el grupo ACME; cuál es
   la entidad madre y cuáles las filiales; qué relación (propiedad,
   corresponsal, cuenta) existe entre ellas; qué entidad está en la lista de
   sanciones.
4. Datos. Los seis registros de la tabla, más el CIF/NIF, el registro
   mercantil, la estructura de propiedad (en un sistema de grupos), y las
   listas de sanciones (externo).
5. Relaciones. ACME Group → posee → ACME LTD; ACME Group → posee →
   ACME UK Ltd; ACME UK Ltd → tiene cuenta → Customer #49281; ACME UK Ltd
   → figura en → lista de sanciones.
6. Contexto. La consulta la hace el equipo de compliance (permisos
   altos); la lista de sanciones se actualizó hace 3 días; hay una
   investigación abierta sobre el grupo ACME.
7. Memoria. El grupo ACME se investigó el año pasado por una operación
   sospechosa; la conclusión y el responsable están en el historial de
   casos.
8. Razonamiento. Unificar los seis registros en el grupo ACME; recorrer
   las relaciones de propiedad; comprobar que ACME UK Ltd está en la lista
   de sanciones; concluir que el grupo tiene una exposición.
9. Acción. Alertar al equipo de compliance con la cadena de evidencia
   (qué registros se unificaron, qué relación, qué entrada de la lista);
   abrir el caso.
10. Infraestructura. Entity resolution (unificar los seis registros en
    el grupo) + grafo de relaciones de propiedad + las listas de sanciones
    como fuente externa + la memoria del caso previo + la trazabilidad de
    toda la cadena. Sin la entity resolution, la cadena empieza rota.

El caso demuestra la regla: la tecnología (grafo, agente) aparece como
consecuencia de la necesidad (saber a qué grupo pertenece un cliente para
un control de sanciones), no como punto de partida.

Trade-offs

• Coste. La entity resolution de calidad es cara: requiere atributos
  fiables (CIF, registro mercantil), pares anotados para entrenar modelos, y
  un proceso de revisión humana de los casos borde.
• Complejidad. Los casos borde (dos «Acme» reales, una fusión, una
  escisión) no se resuelven con una regla: requieren juicios que hay que
  documentar y mantener.
• Exactitud vs. cobertura. Un umbral de matching estricto produce pocos
  falsos positivos pero deja duplicados (cobertura baja); un umbral laxo
  unifica bien pero mezcla entidades distintas (falsos positivos). En
  compliance, el error de mezclar dos entidades distintas es más caro que el
  de dejar un duplicado.
• Mantenimiento. Las entidades cambian: se renombran, se fusionan, se
  escinden. La identidad canónica tiene que actualizarse o el grafo se
  corrompe silenciosamente.
• Trazabilidad. Cada unificación tiene que ser auditable: qué registros
  se unieron, por qué, con qué evidencia, y quién lo aprobó. En entornos
  regulados, una unificación sin trazabilidad es una violación en potencia.
• Limitación honesta: la entity resolution resuelve la identidad de los
  registros que existen. Si la entidad no aparece en ningún sistema (un
  proveedor informal, una entidad en efectivo), el proceso no la puede
  crear. Trabaja con lo que hay; no inventa lo que falta.

Implicación para la empresa

Para el CDO, la entity resolution es el activo de identidad de la
organización: la respuesta a «¿quiénes son nuestros clientes, proveedores y
contrapartes, de verdad?». Y es un activo que hoy, en la mayoría de las
empresas, no existe como tal: existe como una colección de IDs
inconsistentes.

Para el equipo de compliance (y en general, para cualquier función regulada),
la entity resolution es lo que convierte un control de «buscar el nombre en
una lista» en un control de «recorrer el grupo y sus relaciones». La
diferencia es la diferencia entre un falso negativo y una detección real.

Para la alta dirección, el mensaje es de riesgo: cada decisión que un agente
tome sobre un cliente, un proveedor o una contraparte depende de que la
identidad de esa entidad esté resuelta. Y hoy, en muchos casos, no lo está.

Conclusión

La entity resolution es la condición previa del conocimiento empresarial
fiable: sin saber qué entidad concreta representa cada registro, la
ontología no se puede aplicar, las relaciones no se pueden construir y el
agente razona sobre una colección de duplicados. Hoy la hemos visto como el
puente entre la semántica (qué clase de cosa) y el conocimiento (qué cosa
concreta, y cómo se relaciona).

Y eso nos lleva a la siguiente pieza: ahora que sabemos quién es quién,
¿y cómo se relacionan? Porque el negocio, recordemos, no vive en las
entidades aisladas. Vive en lo que las une.

Siguiente artículo

Mañana: Los datos describen entidades. El negocio vive en sus relaciones.. Veremos por qué una cadena como «cliente → posee → contrato →
cubre → producto → depende de → componente → suministrado por → proveedor»
es más que una curiosidad de ingeniería: es el mapa donde realmente está el
negocio.

Fuentes

• Definición de trabajo de la ICE: ver serie, Día 1.
• La entity resolution es un problema clásico de data integration y
  record linkage; se presenta aquí en términos operativos para entornos
  empresariales y regulados.