Respuesta directa
En pocas palabras
Gestionar consentimiento en un CRM exige identificar la finalidad y el requisito aplicable, mostrar información comprensible, registrar la decisión con su contexto y versión, propagar preferencias a todos los canales y permitir un retiro sencillo. Una casilla aislada no demuestra el recorrido completo. En México, la conclusión debe validarse contra la LFPDPPP vigente, su Reglamento y las reglas sectoriales aplicables.
Trata el consentimiento como una decisión, no como una casilla
El consentimiento es una manifestación de voluntad vinculada con datos, finalidades y contexto. Una marca booleana sin texto, fecha, medio ni versión no permite saber qué entendió la persona ni qué tratamiento autorizó. Antes de diseñar la interfaz, identifica quién es el responsable, qué datos se usan, para qué resultado, qué canal interviene, qué tercero participa y qué regla permite o exige el tratamiento.
Esta guía prepara un modelo operativo para revisión de privacidad y asesoría jurídica. No determina si un caso concreto requiere consentimiento, si aplica una excepción ni qué modalidad basta. La LFPDPPP vigente, su Reglamento, disposiciones sectoriales, contratos y circunstancias de la relación necesitan análisis competente. El objetivo es que la decisión jurídica pueda convertirse en un control demostrable dentro del CRM y sus integraciones.
Construye una matriz de finalidades antes de elegir la modalidad
Enumera recorridos reales: responder una solicitud, administrar una cuenta, gestionar una oportunidad, preparar una propuesta, habilitar una Buyer Room, prestar soporte, medir operación, enviar contenido comercial o enriquecer un registro. Para cada finalidad registra personas, datos, fuente, sistema, dueño, resultado, conservación, terceros y decisión jurídica. Evita usar comercial como una bolsa que mezcla servicio, seguimiento solicitado, prospección y publicidad.
Distingue finalidades que originan o son necesarias para la relación de aquellas secundarias que pueden detenerse sin impedir el servicio principal. Esa clasificación no debe inventarla el formulario ni el equipo de ventas. Privacidad y asesoría jurídica la validan; producto implementa una elección separada cuando corresponda. Si dos finalidades tienen distintos efectos, conservar una sola preferencia vuelve imposible demostrar qué aceptó o rechazó la persona.
| Criterio | Pregunta correcta | Control esperado |
|---|---|---|
| Servicio | ¿Qué necesita la relación? | Alcance y uso delimitados |
| Seguimiento | ¿Qué contacto fue solicitado? | Canal y contexto conservados |
| Secundaria | ¿Puede rechazarse por separado? | Preferencia granular |
| Transferencia | ¿Quién recibe y para qué? | Decisión y destinatario trazables |
Distingue consentimiento tácito, expreso y expreso por escrito
La LFPDPPP vigente permite que el consentimiento se manifieste de forma expresa o tácita, con las excepciones y requisitos que establece. Define el tácito cuando, puesto a disposición el aviso, la persona no manifiesta voluntad en contrario. Para datos financieros o patrimoniales exige consentimiento expreso salvo excepciones aplicables; para datos sensibles exige consentimiento expreso y por escrito mediante los mecanismos previstos.
No traduzcas estas categorías automáticamente a un componente de interfaz. Voz, firma, acción electrónica o signo inequívoco pueden requerir distinta evidencia, autenticación y experiencia. La ausencia de respuesta no debe convertirse en tácito si el aviso no fue puesto a disposición en el momento correcto, el propósito era ambiguo o otra disposición exige manifestación expresa. Conserva la decisión jurídica que justifica la modalidad y la versión implementada.
Haz que la elección sea informada, específica y libre
Presenta responsable, datos relevantes, finalidad, efecto, terceros cuando corresponda, medio de retiro y acceso al aviso antes de la decisión. Usa lenguaje directo y opciones equivalentes en visibilidad. No preselecciones una finalidad secundaria ni escondas el rechazo detrás de más pasos, colores débiles o frases que sugieren que el servicio se perderá cuando no es cierto. La persona debe distinguir qué es necesario y qué es opcional.
Evita consentimiento agrupado para grabación, personalización, prospección, transferencia y analítica si cada actividad necesita una evaluación distinta. Tampoco fuerces granularidad artificial con veinte interruptores incomprensibles. Agrupa por efecto que una persona pueda anticipar y que los sistemas puedan ejecutar. Prueba comprensión con usuarios representativos y conserva los hallazgos; una redacción aprobada internamente puede seguir siendo confusa en un teléfono o durante una llamada.
Guarda un recibo de decisión sin crear una nueva exposición
Registra identificador de la persona o relación, finalidad, estado, modalidad, texto o versión, aviso asociado, canal, fecha, zona horaria, fuente y prueba de la acción. Cuando exista representante o una sesión autenticada, conserva la relación necesaria. No guardes capturas completas, documentos o contenido de sesión si un evento firmado y la versión inmutable bastan para reconstruir la decisión.
Separa el recibo de la preferencia vigente. El recibo explica qué ocurrió en un momento; la preferencia controla lo que puede ocurrir ahora. Mantén historial append-only para auditoría y un estado operacional fácil de consultar. Protege ambos con permisos, retención y registro de cambios. Una persona de ventas no debería poder reactivar una finalidad restringida editando una nota o borrando la evidencia anterior.
Diseña un centro de preferencias con significados estables
Modela preferencias por finalidad y canal, no por nombres internos de campañas. Explica qué cambia al desactivar correo comercial, llamadas, mensajería, personalización o análisis opcional. Muestra también lo que continuará cuando resulte necesario para la relación o una obligación aplicable, sin presentarlo como una decisión que la persona puede modificar si el sistema no la hará efectiva.
Utiliza estados explícitos como permitido, rechazado, retirado, restringido, no solicitado y no aplicable. Evita null como significado múltiple. Incluye fecha de vigencia y fuente de autoridad cuando haya conflicto. La interfaz debe ser accesible, funcionar sin patrón oscuro y confirmar el resultado. Si una preferencia necesita tiempo para propagarse, informa el estado pendiente sin seguir activando nuevas campañas durante la ventana.
Propaga la preferencia a cada canal y proveedor
Construye una fuente de autoridad y publica cambios hacia correo, telefonía, mensajería, automatizaciones, data warehouse, analítica, enriquecimiento y proveedores. Cada consumidor debe confirmar versión, estado y fecha. Una etiqueta no contactar dentro del CRM no protege si la herramienta de campañas mantiene una lista antigua o si un representante exporta contactos antes de sincronizar.
Diseña idempotencia, reintentos, cola de errores y conciliación. Ante una falla, el comportamiento seguro suele ser impedir una nueva acción secundaria hasta resolver el estado, no asumir autorización. Mide latencia de propagación, destinos pendientes, reactivaciones y discrepancias. El dashboard debe mostrar controles ejecutados y excepciones, no solo el número de personas que aceptaron.
Conserva una supresión mínima que evite la reactivación
Una baja puede requerir conservar un identificador mínimo para impedir que el contacto vuelva a entrar por otra lista. Define qué dato se necesita, con qué finalidad, por cuánto tiempo, quién lo consulta y cómo se protege. No mantengas el perfil comercial completo bajo la etiqueta de supresión. Separa bloqueo preventivo de uso activo y documenta la autoridad que sostiene la conservación.
Prueba importaciones, duplicados, alias, fusiones, cambio de dominio y restauración desde respaldo. Una coincidencia demasiado estrecha permite reactivar a la misma persona; una demasiado amplia bloquea a otra. Registra confianza y revisión para casos ambiguos. Si cambia el identificador principal, conserva la relación necesaria entre identidades sin transformar la lista de supresión en un nuevo sistema de perfilado.
Haz que retirar el consentimiento sea sencillo y verificable
La ley vigente permite revocar el consentimiento en cualquier momento sin efectos retroactivos y exige que el aviso establezca mecanismos y procedimientos. El Reglamento indica mecanismos sencillos y gratuitos, al menos por el mismo medio por el que se otorgó cuando no lo impida una disposición legal. Modela recepción, identidad proporcional, finalidad, fecha efectiva, sistemas alcanzados, confirmación y cualquier límite aplicable.
No confundas revocación con cancelación total, oposición, baja de un canal o terminación contractual. Aclara el resultado que busca la persona y ejecuta cada mecanismo necesario. Cuando datos ya fueron remitidos a encargados y siguen siendo tratados, el Reglamento contempla comunicar la revocación para que procedan a lo conducente. Conserva la instrucción, confirmación y pendientes sin duplicar innecesariamente datos personales.
Detén usos nuevos hasta renovar la decisión necesaria
El artículo 11 de la LFPDPPP vigente limita el tratamiento a las finalidades previstas en el aviso y exige obtener nuevamente el consentimiento si se pretende una finalidad distinta. Implementa un gate de cambio: describe la finalidad propuesta, datos, personas, efecto, IA, terceros, conservación y compatibilidad con el recorrido original. Privacidad decide si requiere nuevo aviso, nueva decisión u otro control.
No reutilices un consentimiento histórico porque el texto contenía frases amplias. Antes de activar una característica, relaciona cada población con la versión que vio y la decisión que tomó. Si falta cobertura, no incluyas esas personas por defecto. Diseña migraciones explícitas y conserva quién aprobó la conclusión. Un feature flag debe poder limitar la nueva finalidad hasta que información, contratos y preferencias estén listos.
No conviertas una fuente pública o una lista comprada en permiso universal
La LFPDPPP contempla supuestos en los que no se exige recabar consentimiento, entre ellos ciertos datos en fuentes de acceso público. Eso no elimina automáticamente los principios de licitud, finalidad, lealtad, calidad, proporcionalidad, información y responsabilidad. Verifica que la fuente cumpla la definición aplicable, conserva procedencia y fecha, limita campos y revisa el uso propuesto antes de importar.
Para listas de terceros, documenta proveedor, cadena de obtención, texto presentado, finalidades, modalidad, evidencia, actualizaciones, supresiones y derecho de auditoría. Una garantía contractual genérica no demuestra una decisión de cada persona. Si la organización no puede explicar origen o restricciones, bloquea la activación comercial y corrige la fuente. Aplica el aviso y mecanismo correspondiente cuando los datos no fueron obtenidos directamente.
Reevalúa la decisión cuando la IA cambia el efecto sobre la persona
Mapea si el Copilot resume, clasifica, recomienda, infiere, graba, transcribe, personaliza o evalúa. Identifica datos de entrada, contexto recuperado, salida, feedback, proveedor y decisiones humanas. No asumas que una finalidad de administrar clientes cubre cualquier inferencia futura. Si aparece una nueva finalidad o datos adicionales, activa el gate de cambio antes de enviar información al modelo.
Mantén preferencia y restricción fuera del prompt como control de sistema. El modelo no debe decidir si una persona puede recibir una campaña ni interpretar una frase libre como autorización. Filtra recuperación y herramientas según estado vigente; registra qué regla permitió la acción. En Cerravi, Copilot prepara contexto y sugerencias para revisión humana. Esa supervisión no sustituye información, consentimiento o límites aplicables.
Prueba conflictos, reimportaciones y fallas de sincronización
Crea identidades sintéticas con combinaciones: servicio permitido y marketing rechazado; correo retirado y llamada vigente; dato financiero con decisión expresa; fuente indirecta; proveedor sin confirmación; nueva finalidad; perfil fusionado; usuario desactivado y respaldo restaurado. Ejecuta formulario, API, importación, automatización y cambio administrativo. Compara estado esperado con eventos y efectos observados.
Incluye carreras: campaña programada mientras llega el retiro, dos sistemas que escriben estados distintos y reintento después de una falla parcial. El resultado debe ser determinista y conservador. Revisa que la interfaz no muestre éxito antes de persistir, que la conciliación detecte discrepancias y que una exportación no omita restricciones. Repite después de cambiar esquema, proveedor, identidad, modelo o aviso.
Aplica la decisión en Cerravi sin convertirla en garantía jurídica
Cerravi organiza cuentas, contactos, oportunidades, actividades, propuestas y Buyer Rooms. Copilot prepara contexto y siguientes pasos para revisión humana. El equipo que usa el producto define responsable, finalidades, fuentes, canales, integraciones, proveedores y plazos. Cerravi no determina automáticamente cuándo se requiere consentimiento, si una excepción aplica ni qué modalidad satisface una obligación concreta.
Antes de lanzar, configura estados y permisos, conecta supresiones, documenta proveedores, publica mecanismos coherentes y prueba el recorrido completo. Conserva el recibo y la preferencia con retención aprobada. Revisa periódicamente discrepancias y finalidades nuevas. Esta guía no constituye asesoría legal ni certificación. Una implementación confiable demuestra la cadena desde información y decisión hasta propagación, efecto, retiro y evidencia.
Preguntas frecuentes
Dudas comunes sobre este proceso
¿Qué diferencia hay entre consentimiento tácito y expreso en México?
La LFPDPPP vigente considera expreso el manifestado verbalmente, por escrito, por medios electrónicos, signos inequívocos u otra tecnología. Considera tácito el supuesto en que, puesto a disposición el aviso, la persona no manifiesta voluntad en contrario. La modalidad válida depende de los datos, finalidad, excepciones y demás disposiciones aplicables; no debe elegirse solo por comodidad técnica.
¿Una casilla en un formulario basta para demostrar consentimiento?
No necesariamente. La organización necesita poder relacionar persona, finalidad, datos, texto o aviso presentado, modalidad, acción, canal, fecha y versión, además de demostrar que la preferencia se aplicó. Una casilla sin contexto puede probar un clic, pero no qué decisión informada tomó la persona ni qué sistemas la respetaron.
¿Se puede usar un contacto para una finalidad nueva?
El artículo 11 de la LFPDPPP vigente establece que, si el responsable pretende tratar datos para una finalidad distinta de las previstas en el aviso, debe obtener nuevamente el consentimiento. El equipo debe detener la activación, evaluar el cambio, actualizar información y controles, identificar la población cubierta y obtener la decisión que corresponda antes del nuevo uso.
¿Retirar el consentimiento obliga a borrar todos los datos?
No debe asumirse. La revocación, la oposición, la cancelación, una baja comercial y la terminación contractual persiguen resultados diferentes. Debe aclararse la finalidad alcanzada, aplicar la decisión y revisar obligaciones o límites pertinentes. Puede conservarse evidencia mínima o información bloqueada cuando exista una finalidad y autoridad vigentes, sin reutilizarla para el uso retirado.
¿Cómo evitar que una persona dada de baja vuelva a una campaña?
Mantén una fuente de autoridad para preferencias, una supresión mínima, propagación idempotente, conciliación y pruebas de reimportación, duplicados, fusiones, cambios de correo y restauraciones. Cada herramienta debe consultar el estado vigente antes de actuar. La evidencia debe mostrar tanto el evento de baja como la ausencia de nuevas acciones dentro de la finalidad alcanzada.