Agentes con gobierno documentado sobre el CRM

Contexto

Un grupo empresarial B2B lleva su pipeline comercial en un CRM, donde se decide el forecast y la reunión semanal de ventas de cada vertical. Sobre una réplica analítica de ese CRM se construyó una capa de agentes de IA: visualización de pipeline, chat en lenguaje natural, control de calidad de dato con aviso automático y un canal de mensajería corporativo. El sistema es de solo lectura: detecta, avisa y verifica, no escribe sobre el CRM.

Problema

El forecast se decidía sobre un CRM con datos vencidos: oportunidades con cierre en el pasado, sin línea de negocio ni margen, a nombre de usuarios inactivos, y leads sin calificar por más de un mes. Ocho reglas de negocio documentan esos casos.

La causa no era el CRM sino la ausencia de un circuito que detectara esos huecos y verificara su corrección; la revisión dependía de reportes manuales, y nadie no técnico podía consultarlo en lenguaje natural. Una restricción de diseño fijó el alcance: el dato se corrige únicamente en el CRM, fuente de verdad.

Solución

Se diseñó como agentes de IA sobre la réplica analítica, bajo un marco de gobierno con criticidad por nivel y fases de autonomía explícitas.

• Reglas de negocio en archivos versionados y auditables: la higiene del pipeline y los criterios de la reunión semanal se releen en cada corrida, sin tocar código.
• Aislamiento de datos a nivel de base, no por instrucción al modelo: bloqueo por defecto y lista de tablas permitidas, extendida al canal de mensajería.
• Catálogo de modelos con presupuesto por llamada: el sistema sugiere el modelo, pero el cambio siempre es decisión humana y queda auditado.
• Canal de mensajería resuelto con una herramienta de plataforma ya administrada por IT, dentro del mismo perímetro de gobierno.

Resultados

• 78 cambios registrados en el repositorio de trabajo entre junio y agosto de 2026, 74 con coautoría de IA, y 31 migraciones de base de datos.
• Una corrida incremental de ingesta detectó los cambios reales del período en menos de un minuto.
• Un control detectó registros duplicados inflando la vista de avisos; el ajuste al ciclo de vida bajó el conteo a los casos reales, y esos avisos se cierran solos cuando el dato se corrige en el CRM.
• El aviso automático, probado en una corrida de ejecución, cubrió a todos los vendedores con problemas detectados tras sumar responsables de respaldo sin comercial activo.
• El sistema opera en un ambiente de desarrollo con datos reales; el paso a producción queda fuera de este caso.

Arquitectura y decisiones

La réplica analítica se construyó en una base de datos relacional independiente del CRM transaccional, con una ingesta completa inicial y corridas incrementales posteriores. El aislamiento de datos por usuario en el chat en lenguaje natural se resolvió con seguridad a nivel de fila forzada en la base, con política de bloqueo por defecto y lista explícita de tablas permitidas, en lugar de delegar ese control a la instrucción del modelo.

La orquestación y la ingesta se resolvieron con servicios nativos del mismo proveedor cloud que ya administra la identidad corporativa, en reemplazo de una herramienta externa autoalojada evaluada al inicio del proyecto; el canal de mensajería se resolvió con una herramienta de plataforma ya administrada por el área de IT, para que su gobierno quedara dentro del mismo perímetro. El motor de lenguaje se definió sobre un catálogo multi-proveedor con costo por llamada y presupuesto asociado, de forma que el modelo sugerido para cada tarea pueda cambiarse sin tocar el resto del sistema, siempre con una decisión humana de por medio y su registro correspondiente. El acceso directo al CRM en vivo mediante un protocolo de integración quedó evaluado como complemento futuro de la réplica analítica, no como su reemplazo.