Auditoría inicial — hallazgos
P0 — Enriquecimiento de contactos sin autorización explícita ni suppression gate
La ruta de enriquecimiento acepta únicamenterecord_ids; la petición no
declara propósito, referencia de autorización, aceptación de derechos de
fuente ni versión de política. El servicio resuelve y persiste datos de
contacto tras la petición del usuario, pero en el flujo auditado no hay una
verificación de suppression u opt-out antes del enriquecimiento.
Evidencia: apps/api/src/radar/radar.controller.ts,
apps/api/src/radar/dto/radar.dto.ts y
apps/api/src/radar/radar-enrichment.service.ts.
Impacto: el producto aún no puede demostrar que la autorización de
enriquecimiento sea distinta del permiso posterior para exportar o enviar.
Mantener detrás de G2/G5 hasta tener un registro auditable de autorización y
un contrato de suppression.
P1 — Se pierde provenance del resolver al persistir
El contrato del verifier devuelveprovider y sources, pero el camino de
persistencia guarda source: null para endpoints resueltos y no persiste los
sources retornados. El fallback de buzón general también guarda
provider: null y source: null, aunque provenga de un proveedor.
Evidencia: apps/api/src/radar/ports/endpoint-verifier.port.ts,
apps/api/src/radar/contact-path.ts y
apps/api/src/radar/radar-enrichment.service.ts.
Impacto: no se pueden ejecutar con fiabilidad derechos por campo,
atribución, corrección, eliminación o disputas con el proveedor desde el
registro guardado. Persistir provenance y derechos antes de aprobar un
proveedor.
P1 — No hay retención ni eliminación de contactos aplicada en este flujo
Los datos de contacto se escriben en campos del record y en elcontact_path serializado, pero el camino auditado no tiene expiración por
proveedor, deletion handle, estado de suppression ni propagación hacia
índices, exports, drafts o sistemas de campañas.
Impacto: las promesas de retención/eliminación del Trust Pack serían
aspiracionales para contactos. Implementar expiración y propagación, y
probarla con fixtures de proveedores y exports antes de publicar plazos
concretos.
P1 — Nylas está verificado para la beta y debe mantenerse acotado
origin/staging contiene la integración Nylas para conectar Gmail/Outlook y
enviar campañas autorizadas. El alcance beta es deliberadamente send-only: no
lee, lista, busca ni gestiona el inbox o respuestas dentro de Brein. El E2E,
OAuth y los controles del proveedor ya fueron verificados para la beta.
Impacto: no ampliar la beta hacia inbox, replies o automatización autónoma.
La etiqueta correcta es beta verificada / alcance send-only.
P0 — No lanzar outreach como capacidad autónoma
El producto debe mantener separado el descubrimiento, enriquecimiento, borrador y envío. Un proveedor que entrega un email no entrega autorización para contactar. Evidencia: la arquitectura actual separa enrichment de investigación y el flujo comercial documentado requiere permiso explícito de envío. Acción: gate G5 antes de habilitar Smartlead o cualquier envío automático.P1 — Privacy pública desalineada (resuelto en el árbol de reconciliación)
La versión anterior de la política pública describía principalmente identidad, workspace, GitHub, infraestructura y agentes. La versión reconciliada ya cubre licitaciones, fuentes comerciales, enriquecimiento, contactos, suppression y el alcance send-only de Nylas. Archivo:apps/web/src/app/(content)/privacy/page.tsx.
Acción: publicar la versión reconciliada después de la revisión visual y el merge; no publicar nombres o finalidades que no estén en el registro verificado.
P1 — Terms con jurisdicción y producto desalineados
Los Terms actuales remiten a la ley de Estados Unidos y no regulan con suficiente precisión la inteligencia comercial, datos de terceros, proveedores, outreach ni responsabilidades del cliente. Archivo:apps/web/src/app/(content)/terms/page.tsx.
Acción: reescribir las cláusulas de uso permitido, datos del cliente, fuentes, contactos, acciones externas, suspensión, eliminación y jurisdicción.
P1 — Trust page promete una lista de subprocessors incompleta para el producto comercial (resuelto en el árbol de reconciliación)
La versión anterior listaba infraestructura y proveedores de operación, pero no diferenciaba proveedores activos, condicionados, pilotos y no seleccionados. La versión reconciliada lista Nylas como activo sólo para send-only y mantiene Smartlead, Hunter y Tomba fuera de la lista activa cuando corresponde. Archivo:apps/web/src/app/(content)/trust/page.tsx.
Acción: publicar la versión reconciliada y mantener el registro público alineado con el registro de proveedores.