Gobernar La Prospección De IA Con Aprobaciones MCP

Revise el acceso para cada acción: las lecturas requieren los permisos correspondientes, los cambios de registros necesitan vistas previas y claves de reintento, y los envíos también requieren una política activa revisada por el responsable. Incluya consentimiento, exclusiones, licencias y jurisdicciones en la revisión.

¿Qué nivel de riesgo aplica a cada escritura?

Use tools/list para descubrir las herramientas disponibles para su conexión. La disponibilidad depende de los permisos concedidos y del acceso del espacio de trabajo. Empiece con permisos de lectura; pida a un administrador que revise el acceso que falta en lugar de solicitar permisos amplios.

¿Cómo debe un equipo obtener vista previa y aprobar un borrador?

1. Construya la lista candidata desde lecturas respaldadas por información y elimine duplicados contra registros CRM y supresión.
2. Llame a la escritura con dry_run: true y una UUID idempotency_key generada. Revise respuestas de validación y política sin crear registros.
3. Pida al propietario que compruebe audiencia, procedencia de fuente, afirmaciones, personalización, remitente, consentimiento y supresión, usos y jurisdicciones restringidos, y licencia antes de activar la política de envío.
4. Reintente con dry_run: false y la misma clave tras que la política esté ACTIVE. Una clave repetida devuelve el resultado original en lugar de un duplicado.

Señales -> Leads -> Enriquecimiento -> Decisión -> Contacto -> Pipeline

Un registro de envío respalda la investigación; no prueba demanda ni permiso para contactar a una persona. Mantenga esa advertencia en la nota de revisión.

¿Qué requiere una revisión de política de envío?

Antes de habilitar envíos, un responsable debe revisar la audiencia, el remitente, las afirmaciones del mensaje, el consentimiento, las exclusiones, las jurisdicciones aplicables, las licencias y los límites de presupuesto. Use un policy_id activo para los envíos permitidos y previsualice con dry_run: true. Una política permanente puede autorizar varios envíos; no implica que una persona apruebe cada mensaje por separado. Pause el trabajo si la elegibilidad o la autorización no están claras.

¿Cómo se audita y revoca?

Revise los permisos, los cambios de política y los registros de actividad disponibles antes de ampliar el acceso. Guarde solo ID de solicitudes sin datos sensibles y metadatos operativos en notas compartidas. Retire la conexión al terminar el proyecto o cuando ya no sea necesaria; revoque y sustituya cualquier credencial que pueda haberse filtrado.

¿Cuáles son preguntas habituales sobre gobernanza de prospección MCP?

¿Debe cada borrador necesitar aprobación?

Los borradores necesitan revisión del propietario; los envíos necesitan una política vigente ACTIVE más la revisión humana de la política antes de la activación. Mantenga ambos pasos incluso para volúmenes pequeños.

¿Qué ocurre cuando la misma escritura se envía dos veces?

Reutilizar idempotency_key devuelve el primer resultado. Una clave nueva crea un registro o envío nuevo, así que nunca rote claves al reintentar.

¿Puede un token limitarse a borradores sin envíos?

Sí. Conceda leads:create o campaigns:create sin emails:send ni sms:send. Las herramientas de envío ausentes en tools/list confirman el límite.

¿Qué respuestas necesitan a una persona?

Bajas, objeciones, referidos y respuestas ambiguas o sensibles van a una persona. Las reglas de pausa deben detener más envíos ante rebotes, quejas y falta de encaje.

¿Qué pertenece al registro de revisión de políticas?

Motivo de cuenta, fuente, rol del contacto, afirmaciones del mensaje, remitente, ID de política, clave de idempotencia, revisor y próxima acción.

¿Cuándo debe eliminarse el acceso?

Elimine concesiones al fin del proyecto, cambio de rol, cambio de proveedor o cualquier sospecha de filtración. Conserve el historial de request_id para la revisión.