Depuración de una base B2B con agentes: un piloto medido

Contexto

Un grupo empresarial B2B mantiene una base comercial de unos 1.600 contactos, con nombre, correo, empresa y campos comerciales internos. Como toda base así, envejece sola: las personas cambian de empresa sin que nada lo señale. Sobre esa base se desarrolló un proyecto interno de verificación de contactos en una red profesional.

Problema

Ningún registro tenía una clave estable por persona —una URL de perfil— para volver a verificarlo más adelante; sin ella, cada depuración arrancaba de cero, inviable a la escala de la base. Las vías comerciales tampoco resolvían la causa: la carga masiva en herramientas de venta social no está permitida por políticas de privacidad, el enriquecimiento de datos de terceros cobra por contacto y la búsqueda manual no escala.

Un segundo problema apareció al ejecutar: el criterio inicial exigía coincidencia exacta entre empresa cargada y empresa encontrada. Un primer lote de 20 contactos encontró solo 3 —15%—, y dos de esos tres eran personas que ya habían cambiado de empresa: el criterio descartaba el dato más valioso.

Solución

El trabajo se ordenó en dos etapas: un agente sobre un primer bloque para cerrar el método, y un script que lo reproduce sin costo de agente para el resto. Antes de buscar, se limpió la base —26 correcciones y 22 registros irrecuperables eliminados—, y quedaron 1.595 registros trazables.

• Un agente con navegador procesó 80 contactos en siete lotes de 10, cada uno con nota de qué funcionó y cuánto costó.
• Se dejó de exigir coincidencia exacta de empresa y se registró la empresa actual como dato: el lote siguiente pasó de 15% a 60% de hallazgo.
• Se migró a la búsqueda estándar del sitio, con 58% menos costo por contacto.
• Desde el sexto lote se validó por historial laboral completo, para no perder a quienes cambiaron de empresa ni confundir homónimos.

El script para el resto guarda avance de forma incremental y exige confirmación humana antes de arrancar. Ningún archivo con datos personales queda en el historial del proyecto; sí se versiona a propósito la configuración de gobierno del agente.

Resultados

• La metodología quedó validada sobre un primer bloque de 80 contactos verificados de una base de 1.595.
• De esos 80: 31 identificados, 13 para revisión manual, 7 con nombre común y 29 sin perfil; en 37 quedó capturada la URL de perfil, ancla para la próxima verificación.
• Quedaron entregados la base depurada, la metodología por lote y dos versiones del script.
• El caso documenta la fase piloto del proyecto, hoy detenido: la prueba de la segunda versión del script y el procesamiento del resto de la base no se iniciaron.

Arquitectura y decisiones

El diseño separó identificación de reproducción a propósito: un agente con navegador para descubrir y ajustar el método sobre un primer bloque de contactos, y un script liviano para aplicarlo al resto de la base sin el costo de un agente completo. El script usa automatización de navegador para leer los resultados de búsqueda y un modelo de lenguaje liviano ejecutado en infraestructura propia para interpretarlos, con un límite de 150 contactos por hora para no forzar la plataforma consultada.

Una segunda versión del script agrega el dominio corporativo del correo como señal de búsqueda adicional, y un modo de prueba que corre sin el modelo local, pensado para aislar el efecto de las consultas del efecto del modelo antes de correr sobre el volumen restante. El criterio de gobierno del proyecto trató el riesgo de datos personales como el riesgo principal, por encima del de credenciales: ningún archivo con datos de contactos o resultados de búsqueda queda expuesto en el historial de cambios, mientras que la configuración que rige el comportamiento del agente sí se versiona, con la ejecución automática sin confirmación deshabilitada por diseño.