Cómo construimos un sistema de resolución de identidad.
Para reportes generados con IA.
Busca "Maria Garcia, software engineer" en LinkedIn. Obtendrás más de 400 resultados. Ahora imagina que tu sistema de briefings con IA elige a la persona equivocada y redacta un perfil detallado, coherente y completamente incorrecto.
Ese fue exactamente el problema con el que nos encontramos al construir el pipeline automático de briefings de Reedy Meet. Los LLM son extraordinarios sintetizando información, pero no son, por diseño, herramientas de verificación de identidad. No tienen un mecanismo nativo para detectar cuándo los resultados de "Michael Smith" están mezclando datos de tres personas distintas con el mismo nombre. Resolverlo requiere un enfoque diferente: cuantificar la certeza en lugar de inferirla.
Vista general del detalle de la reunión.
La idea central: la identidad en la web no es binaria
No existe un umbral claro que separe "esta es la persona correcta" de "no lo es". La evidencia disponible varía demasiado. A veces tienes cinco señales independientes confluyendo en el mismo perfil. Otras veces, una sola mención en un directorio desactualizado de 2019.
Modelar esa incertidumbre como un valor continuo entre 0 y 1 no es solo una decisión de diseño elegante. Es lo que permite que el resto del sistema esté calibrado con lo que sabe y sea honesto con lo que no sabe. La confianza con la que afirmas algo debe ser proporcional a la evidencia que lo respalda.
Ese índice se traduce en cuatro niveles operativos que controlan directamente cómo se redacta el briefing:
| Nivel | Rango | Qué hace el sistema |
|---|---|---|
| HIGH | ≥ 0.90 | Hechos redactados de forma directa: "Elena es ingeniera de ML en Nexus AI." |
| MEDIUM | 0.60–0.89 | Lenguaje matizado: "Según fuentes web, Elena trabaja en Nexus AI." |
| LOW | 0.30–0.59 | Solo se incluyen campos de alta confianza; el resto se omite. |
| FAILED | < 0.30 | No se genera briefing. El silencio es mejor que el ruido. |
La diferencia entre HIGH y MEDIUM no es cosmética. Cómo presentas un hecho cambia el peso que le da el lector y la confianza que deposita en el sistema.
Contexto: una barrera de control dentro de un pipeline más grande
El sistema de generación de briefings funciona como un agente que encadena varias herramientas: búsqueda, extracción, verificación y síntesis. Este artículo cubre solo la etapa de verificación: la barrera de control que se sitúa entre los resultados de búsqueda en crudo y el informe final.
El modelo de puntuación se ejecuta para cada participante externo de una reunión. Los participantes internos —los que comparten dominio de correo con el anfitrión— se excluyen por completo. La resolución de identidad solo es relevante para personas ajenas a la organización, así que no se aplica una penalización: se hace una exclusión contextual antes de evaluar ninguna señal.
Diez señales, cada una con un peso
La premisa es sencilla: una sola señal puede fallar o llevar a confusión. Diez señales independientes apuntando en la misma dirección son mucho más difíciles de rebatir.
Cada señal es binaria (se activa o no se activa) y cada una tiene un peso según su poder discriminativo real. Las señales positivas suman a la puntuación; las negativas restan.
Señales positivas
| Señal | Peso | Qué valida |
|---|---|---|
| Coincidencia exacta de correo | +0.25 | ¿El correo de la persona aparece literalmente en algún resultado indexado? El correo es un identificador único y aporta evidencia directa. |
| Consistencia de dominio | +0.30 | ¿En qué porcentaje de resultados coaparecen nombre y empresa esperada? Un ratio superior al 70% es una señal fuerte. También funciona con Gmail. |
| Coincidencia semántica del dominio corporativo | +0.20 | ¿El dominio del correo (john@acme.com) coincide semánticamente con una empresa como "Acme Corp"? Es distinto a la consistencia estadística del punto anterior. |
| LinkedIn verificado | +0.25 | No basta con que exista un LinkedIn. El perfil debe mostrar explícitamente nombre y empresa esperada. |
| Nombre y cargo en el encabezado del resultado | +0.15 | ¿Nombre y empresa aparecen juntos en el título o encabezado del resultado? Los títulos suelen tener más peso semántico que el cuerpo. |
| Consistencia del cargo | +0.10 | ¿El cargo actual aparece en dos o más fuentes independientes? |
| Actividad reciente | +0.05 | ¿Hay indicadores de actualidad ("2025", "2026", "recientemente")? Tiene poco peso, pero ayuda como desempate. |
Señales negativas
| Señal | Penalización | Qué valida |
|---|---|---|
| Empresa en conflicto | −0.20 | Los resultados asocian a la persona con una empresa conocida distinta de la esperada. |
| Nombre genérico sin identificadores | −0.15 | Nombre muy común sin LinkedIn claro, empresa o cargo específico. Solo penaliza cuando realmente faltan identificadores. |
| Información desactualizada | −0.10 | Predominan indicadores de información antigua: "former", "previously", "ex-", o años como 2020–2022. |
El cálculo
Puntuación = suma de los pesos de las señales activadas Índice final = clamp(Puntuación, 0, 1)
Veámoslo con dos casos concretos.
Elena Rodriguez — elena.rodriguez@nexusai.com
| Señal | ¿Activa? | Contribución |
|---|---|---|
| Coincidencia exacta de correo | ✓ | +0.25 |
| Consistencia de dominio | ✓ (9/10 resultados mencionan nexusai) | +0.30 |
| Coincidencia semántica del dominio corporativo | ✓ | +0.20 |
| LinkedIn verificado | ✓ | +0.25 |
| Nombre y cargo en el encabezado | ✗ | 0 |
| Consistencia del cargo | ✓ ("Ingeniera de ML" en 3 fuentes) | +0.10 |
| Actividad reciente | ✓ | +0.05 |
| Empresa en conflicto | ✗ | 0 |
| Nombre genérico | ✗ | 0 |
| Información desactualizada | ✗ | 0 |
Puntuación bruta: 1.15 → ajustada a 1.00 → HIGH
Carlos Lopez — carlos.lopez@gmail.com
| Señal | ¿Activa? | Contribución |
|---|---|---|
| Coincidencia exacta de correo | ✗ (no indexado) | 0 |
| Consistencia de dominio | ✗ (resultados dispersos entre 5+ personas) | 0 |
| Coincidencia semántica del dominio corporativo | ✗ (correo genérico) | 0 |
| LinkedIn verificado | ✗ (varios perfiles, sin empresa clara) | 0 |
| Nombre y cargo en el encabezado | ✗ | 0 |
| Consistencia del cargo | ✗ (cargos contradictorios entre fuentes) | 0 |
| Actividad reciente | ✓ | +0.05 |
| Empresa en conflicto | ✗ | 0 |
| Nombre genérico | ✓ | −0.15 |
| Información desactualizada | ✓ | −0.10 |
Puntuación: −0.20 → ajustada a 0.00 → FAILED
Gmail no es el problema en sí. El problema es la ausencia total de señales positivas combinada con un nombre muy común. Un Carlos Lopez con Gmail, LinkedIn activo, empresa clara y cargo consistente puntuaría de forma muy distinta.
Cuando la primera pasada no es suficiente: desambiguación adaptativa
Los casos por debajo de 0.7 no pasan directamente a FAILED. En su lugar, el sistema activa una segunda búsqueda más específica con todos los identificadores disponibles:
"Carlos Lopez" "carlos.lopez@gmail.com" "DataCorp" "LinkedIn profile"
Cada resultado de esa búsqueda secundaria se trata como un candidato y se puntúa con otra escala:
| Condición | Puntos |
|---|---|
| Correo literal en el contenido del resultado | +50 |
| Dominio corporativo en la URL | +30 |
| Empresa esperada en el contenido | +20 |
| Nombre en el título del resultado | +15 |
| URL de LinkedIn | +10 |
| Información reciente | +10 |
El mejor candidato gana solo si supera 40 puntos y aventaja al segundo por más de 20 puntos. Si el margen es menor, se marca como "demasiado ajustado para decidir" y no se genera briefing.
En producción, esta segunda capa resuelve aproximadamente el 85% de los casos que no pasaron la primera.
Confianza por campo, no solo índice global
Un índice global de 0.75 no significa que todos los datos del perfil sean igual de fiables. La empresa y el cargo actual pueden estar respaldados por cinco fuentes, mientras que la formación aparece en un único resultado de 2019. Tratarlos igual sería un error.
El sistema clasifica cada campo por prioridad y por número de señales críticas activadas:
- Campos de alta prioridad (empresa, cargo, LinkedIn): verificados si el índice ≥ 0.6
- Campos de prioridad media (experiencia, web corporativa): verificados solo si el índice ≥ 0.9 o al menos 2 señales críticas
- Campos de baja prioridad (formación, noticias antiguas): siempre no verificados
El generador de briefings recibe instrucciones explícitas para cada nivel:
- Datos verificados → redactar como afirmaciones directas
- Datos no verificados → redactar con lenguaje condicional ("según fuentes web...") u omitir
El resultado es un informe honesto sobre su propio nivel de certeza, no una mezcla indiferenciada de hechos y suposiciones.
¿Por qué no entrenar un clasificador?
Dos razones.
La razón pragmática es sencilla: etiquetar suficientes casos para entrenar un modelo fiable tiene un coste real en tiempo y dinero. Pesos ajustados de forma iterativa alcanzan tasas de error del 2–3% en casos HIGH, lo cual es suficiente para este problema.
La más importante es la interpretabilidad. Cuando el sistema devuelve un MEDIUM de 0.67, puedes ver exactamente por qué: qué señales se activaron, cuáles no y qué información faltaba. Un modelo de caja negra devuelve un número sin explicación. En un producto donde la confianza depende de poder auditar las decisiones, esa diferencia pesa más que una mejora marginal de precisión.
Además, los pesos son simplemente parámetros. Si coincidencia_exacta_correo resulta más discriminativo de lo esperado, puedes subirlo de 0.25 a 0.30 sin necesidad de volver a entrenar el modelo.
Números de producción
Distribución del índice sobre todos los participantes procesados:
| Nivel | Proporción |
|---|---|
| HIGH (≥ 0.9) | 42% |
| MEDIUM (0.6–0.9) | 31% |
| LOW (0.3–0.6) | 18% |
| FAILED (< 0.3) | 9% |
El 73% de los casos alcanza confianza suficiente para generar briefing. El 27% restante refleja limitaciones reales del sistema, no un fallo de diseño. Un sistema honesto con la incertidumbre es más útil que uno que la disimula.
De la validación manual semanal (50 casos aleatorios):
- Falsos positivos (HIGH incorrecto): 2–3%
- Falsos negativos (LOW/FAILED siendo la persona correcta): 8–10%, sobre todo por cambios recientes de trabajo aún no reindexados
- Precisión en casos HIGH/MEDIUM: ~88%
El 23% de los casos activa la capa de desambiguación. De esos, el 85% se resuelve con confianza suficiente para continuar.
Modos de fallo conocidos
El sistema funciona especialmente bien para profesionales del sector tecnológico con presencia digital activa: ingenieros con GitHub, LinkedIn, blogs o ponencias en conferencias. También para directivos con cobertura en prensa.
Tres escenarios reducen el rendimiento de forma consistente:
Cambios recientes de trabajo. La web tarda semanas o meses en reindexar. Si alguien cambió de empresa hace tres semanas, puede seguir apareciendo con el cargo anterior. La puntuación cae correctamente, pero el sistema no siempre puede determinar cuál es la versión vigente.
Profesionales en sectores tradicionales. El sistema está optimizado para entornos tecnológicos, donde la huella digital es mayor. En sectores con baja presencia online, las puntuaciones bajan aunque la persona sea identificable por otras vías.
Homónimos dentro de la misma empresa. Dos personas con el mismo nombre en la misma compañía pueden confundir al sistema incluso cuando el dominio coincide. Es la principal fuente de falsos positivos, con un 2–3% en casos HIGH.
Vista del reporte generado para un participante.
Conclusión
Resolver la identidad en la web es un problema de acumulación de evidencia, no de búsqueda. La distancia entre "encontrar información sobre alguien" y "verificar que esa información pertenece a esa persona concreta" parece sutil, pero cambia por completo el diseño del sistema.
El modelo de puntuación descrito aquí no es perfecto, como ningún sistema heurístico. Pero es interpretable, ajustable y está calibrado en la dirección correcta: prefiere el silencio antes que errores con apariencia de certeza.
En productos donde un error de identidad erosiona la credibilidad, esa es exactamente la postura adecuada.
Iniciemos tu proyecto
Te acompañamos con soluciones a medida, desde la idea hasta la implementación.