Respuesta directa
En pocas palabras
Aplicar privacidad desde el diseño significa transformar cada finalidad y riesgo en un requisito comprobable antes de construir o configurar el CRM. Aplicarla por defecto significa que una cuenta nueva recopila, comparte, conserva y expone solo lo necesario sin depender de que cada usuario cierre permisos después. En México, este patrón ayuda a instrumentar proporcionalidad, minimización, seguridad y responsabilidad bajo la LFPDPPP y su Reglamento; no debe describirse automáticamente como una obligación idéntica al artículo 25 del GDPR cuando ese régimen no aplica.
Empieza por el resultado de privacidad, no por una lista de funciones
Define qué debe poder esperar una persona cuando sus datos entran al CRM: que se usen para una finalidad comprensible, que solo acceda quien lo necesita, que una inferencia pueda revisarse, que una oposición se propague y que la información deje de estar disponible cuando termina su vigencia. Después convierte cada expectativa en un comportamiento del producto, una regla operativa y una prueba. “Cumplir privacidad” no es un requisito verificable; “un usuario comercial no puede exportar datos financieros sin un permiso adicional y un registro” sí lo es.
Delimita el tratamiento y la versión: población, países, fuentes, campos, finalidades, modelo, instrucciones, herramientas, integraciones, proveedores, regiones, roles y plazos. El diseño de un asistente que resume notas internas no cubre automáticamente prospección, scoring, entrenamiento, enriquecimiento o decisiones automatizadas. Cuando cambia una de esas piezas, revisa los requisitos afectados antes de ampliar el alcance.
Separa la obligación mexicana, el patrón de diseño y el artículo 25 del GDPR
La LFPDPPP vigente para particulares exige observar licitud, finalidad, lealtad, consentimiento, calidad, proporcionalidad, información y responsabilidad. Su Reglamento desarrolla necesidad, minimización y responsabilidad, y contempla procedimientos para atender y mitigar riesgos derivados de nuevos productos, servicios, tecnologías y modelos de negocio. Esa base permite traducir privacidad a decisiones tempranas, configuraciones y evidencia dentro de una empresa mexicana.
La expresión formal “protección de datos desde el diseño y por defecto” pertenece, entre otros marcos, al artículo 25 del GDPR. No afirmes que México reproduce automáticamente ese artículo para toda empresa privada. Documenta la ley, el sector, los contratos y las jurisdicciones aplicables. Cuando el GDPR u otra regla sí alcance el tratamiento, valida sus requisitos específicos con especialistas; cuando no, usa el patrón como práctica operativa vinculada a obligaciones mexicanas concretas, no como certificación prestada.
| Criterio | Qué aporta | Cómo documentarlo |
|---|---|---|
| LFPDPPP y Reglamento | Principios, responsabilidad, seguridad, derechos y medidas para el riesgo | Artículo, deber aplicable, decisión y evidencia de la organización |
| Patrón operativo | Requisitos tempranos y opciones inicialmente protectoras | Historia de usuario, configuración, prueba, dueño y excepción |
| Artículo 25 del GDPR | Obligación propia de ese régimen cuando resulta aplicable | Análisis de aplicabilidad y cumplimiento separado |
Traduce cada principio a un requisito que ingeniería pueda probar
Para cada finalidad, describe datos permitidos, fuente, uso, audiencia, plazo y salida. La finalidad se vuelve separación entre flujos; la proporcionalidad, campos mínimos y alternativas menos intrusivas; la calidad, fuente y mecanismo de corrección; la información, aviso y explicación en el momento adecuado; la responsabilidad, dueños, versiones, pruebas y decisiones. Mantén una matriz que conecte principio, requisito, componente, prueba, evidencia y aprobación.
Incluye requisitos negativos. El sistema no debe recuperar notas sensibles para una respuesta comercial ordinaria; una integración no debe importar contactos fuera del segmento aprobado; una exportación no debe incluir registros bloqueados; un prompt de usuario no debe ampliar permisos; y una restauración no debe reactivar una finalidad retirada. Los límites son más útiles cuando señalan qué debe ocurrir ante una solicitud inválida: negar, reducir, redactar, escalar o pedir revisión.
Minimiza en la captura, la inferencia y la observabilidad
Empieza cada campo en cero y exige una razón para añadirlo. Distingue dato obligatorio, opcional, derivado, libre y técnico. Sustituye texto abierto por opciones estructuradas cuando reduzca exposición sin impedir el trabajo. Si solo necesitas confirmar elegibilidad, conserva el resultado y no el documento completo. Si basta una métrica agregada, no envíes conversaciones identificables a analítica. La disponibilidad de una fuente no demuestra necesidad.
La IA crea capas que suelen quedar fuera del formulario: fragmentos recuperados, prompts, respuestas, embeddings, memorias, trazas, feedback y conjuntos de evaluación. Define el mínimo para cada una. Redacta antes de registrar, separa telemetría operativa de contenido, limita muestras y evita reutilizar entradas para entrenamiento por defecto. Una función de depuración temporal necesita caducidad y aprobación; de otro modo se convierte en una segunda base de datos sin gobierno.
Separa finalidades y conserva las preferencias como reglas ejecutables
No uses una casilla general para cubrir operación del CRM, marketing, perfilado, grabación, análisis y entrenamiento. Modela finalidades necesarias y secundarias por separado, con aviso, consentimiento o excepción revisados para el caso. Conserva versión, modalidad, fuente, fecha y alcance de cada decisión. El texto del aviso debe corresponder al comportamiento; publicar una finalidad que el sistema no puede aislar no crea control.
Propaga preferencias a campañas, Copilot, búsquedas, exportaciones, integraciones, colas y proveedores. Define precedencia cuando una persona se opone, retira consentimiento o corrige un dato mientras existe una automatización en curso. La opción inicial más protectora mantiene desactivado todo uso secundario que requiera una decisión adicional. Si un administrador puede cambiarla, registra quién, por qué, para qué población y desde cuándo.
Haz que acceso, visibilidad y compartición empiecen cerrados
Una cuenta nueva debe mostrar solo su workspace y el conjunto mínimo para el rol. Separa ver, buscar, recuperar para IA, editar, exportar, compartir, administrar y eliminar. Aplica permisos en servidor y en cada herramienta, no solo ocultando botones. Los enlaces públicos, Buyer Rooms, archivos, reportes y vistas compartidas necesitan expiración, audiencia, revocación y una vista previa de lo que recibirá la otra parte.
Evita herencias silenciosas: incorporar a una persona a un equipo no debe abrir datos históricos sin una regla explícita. Revisa cuentas de soporte, integraciones y procesos automáticos como identidades propias. Para operaciones de alto impacto, combina permiso específico, confirmación contextual, registro y, cuando corresponda, doble aprobación. El acceso temporal debe vencer aunque nadie recuerde retirarlo.
Controla recuperación, instrucciones, memoria y salidas de la IA
La autorización de la persona debe limitar también lo que el asistente puede recuperar y qué herramientas puede invocar. Filtra por workspace, rol, finalidad, categoría y estado antes de construir el contexto. Trata documentos, correos y páginas recuperadas como datos, no como instrucciones confiables. Aísla las instrucciones del sistema y bloquea acciones que intenten ampliar acceso, cambiar destinatarios o enviar información sin una confirmación autorizada.
Decide si la conversación tendrá memoria, qué elementos guarda, quién puede verlos y cuándo se eliminan. Separa borrador de acción: una respuesta generada no debe enviarse, cambiar una oportunidad o crear una transferencia por el solo hecho de parecer correcta. Muestra fuente y límites cuando ayuden a la revisión. Registra lo necesario para reconstruir una decisión sin conservar contenido personal indefinidamente.
Diseña los límites con proveedores, regiones y subencargados
Mapea qué entidad recibe cada entrada, salida, registro y señal de feedback. Revisa rol, instrucciones, uso propio, entrenamiento, región, soporte, subencargados, cifrado, incidentes, derechos, devolución y eliminación. La configuración real debe coincidir con el contrato y el aviso. Si el proveedor ofrece una opción para no usar datos con fines propios, decide y documenta su estado inicial antes de habilitar la integración.
Reduce el flujo antes de confiar en promesas contractuales: envía campos seleccionados, sustituye identificadores, recorta contexto y evita adjuntos completos cuando no son necesarios. Mantén una ruta para desactivar el proveedor sin perder el registro principal ni bloquear derechos. Un cambio de región, subencargado, modelo o término de uso debe disparar evaluación, no una actualización silenciosa en un inventario.
Incorpora conservación, bloqueo, eliminación y restauración desde el esquema
Asigna plazo y disparador por categoría y finalidad antes de crear la tabla o el bucket. Distingue dato activo, bloqueado, respaldado, legalmente conservado y anonimizado. Define qué ocurre al cerrar una oportunidad, terminar una relación, retirar una finalidad o vencer una cuenta. La eliminación manual como única ruta no escala y deja sin resolver copias, índices, embeddings, archivos, exportaciones y proveedores.
Prueba la cadena completa: solicitud, autorización, bloqueo cuando proceda, supresión primaria, propagación, vencimiento en respaldos y evidencia sin contenido innecesario. En una restauración, vuelve a aplicar listas de exclusión, preferencias, permisos y eliminaciones posteriores al respaldo. El diseño debe impedir que recuperar disponibilidad destruya decisiones de privacidad ya ejecutadas.
Haz posibles los derechos y la corrección antes de recibir la primera solicitud
Mantén identificadores y linaje suficientes para localizar datos por persona, fuente, workspace y proveedor. Diseña acceso, rectificación, cancelación y oposición como operaciones controladas, no como búsquedas artesanales. Separa lo observado de lo inferido, conserva fuente y permite corregir datos que alimentan recomendaciones. Una rectificación en la ficha no sirve si Copilot sigue recuperando una copia antigua.
Incluye excepciones y conflictos: identidades coincidentes, registros compartidos, datos de terceros en una nota, conservación obligatoria, investigación de fraude o una solicitud que no puede autenticarse. Cada caso requiere estado, autoridad, explicación y plazo. Prueba también la respuesta negativa: debe ser segura, comprensible y revisable sin revelar información de otra persona.
Prueba los valores por defecto y los caminos que intentan romperlos
Crea una organización nueva y verifica sin ajustes manuales: campos activos, permisos, enlaces, integraciones, telemetría, memoria, entrenamiento, retención y funciones secundarias. Después prueba roles negativos, otro workspace, cuenta desactivada, importación masiva, dato sensible, exportación, prompt injection, proveedor caído y restauración. Usa datos sintéticos representativos para observar el recorrido sin exponer información real.
Cada caso registra versión, precondición, identidad, entrada, acción, resultado esperado, resultado observado y evidencia. Comprueba API, tareas en segundo plano y herramientas, no solo interfaz. Añade pruebas de regresión cuando un defecto revele una ruta nueva. Una configuración protegida deja de serlo cuando un cambio de producto la restablece, una migración la omite o una integración la ignora.
Trata cada apertura como una excepción con vencimiento
Cuando el negocio necesite más datos, audiencia, retención o acceso, exige finalidad, población, duración, beneficio, riesgo, alternativa y aprobador. Aplica el cambio al alcance mínimo y conserva una reversión. Una preferencia más abierta nunca debe extenderse por analogía a otra finalidad. Las excepciones permanentes son señales de que el diseño y la política ya no coinciden.
Define métricas que puedan detectar deriva: cuentas con permisos amplios, enlaces sin vencimiento, campos opcionales siempre llenos, registros fuera de plazo, exportaciones, recuperaciones denegadas, usos secundarios, excepciones vencidas y cambios de proveedor. Cada señal necesita denominador, umbral, dueño y respuesta. Medir volumen sin poder corregir el comportamiento solo documenta la exposición.
Conserva evidencia de diseño, decisión y operación
El expediente mínimo conecta mapa de datos, finalidades, requisitos, arquitectura, configuraciones iniciales, proveedores, modelo de permisos, retención, pruebas, riesgos, excepciones y aprobaciones. Distingue afirmación, evidencia, supuesto y pendiente. Versiona capturas, resultados automáticos y decisiones sin copiar datos personales que no aportan prueba.
NIST Privacy Framework puede servir como lenguaje voluntario para identificar, gobernar, controlar, comunicar y proteger frente a riesgos de privacidad. Sus objetivos de ingeniería —predictibilidad, administrabilidad y disociabilidad— ayudan a revisar si las personas y operadores pueden comprender el tratamiento, administrar datos con granularidad y evitar asociaciones innecesarias. Úsalo como referencia adaptable, no como ley mexicana ni sello de cumplimiento.
Mantén claros los límites de Cerravi y de esta guía
Cerravi organiza contactos, cuentas, oportunidades, actividades, propuestas y Buyer Rooms, y presenta asistencia de Copilot para revisión humana. La organización sigue siendo responsable de definir finalidades, avisos, permisos, usuarios, fuentes, proveedores, conservación y respuestas a derechos según su operación. Una función disponible no determina que su uso sea necesario, proporcional o jurídicamente válido.
Evalúa la configuración y los procesos reales antes de usar datos personales. Esta guía ofrece un método operativo basado en fuentes públicas; no constituye asesoría legal, no garantiza cumplimiento y no reemplaza el análisis de leyes sectoriales, contratos o jurisdicciones adicionales. El resultado buscado es más concreto: que la opción normal reduzca exposición, que toda apertura sea consciente y que el equipo pueda demostrar cómo lo comprobó.
Preguntas frecuentes
Dudas comunes sobre este proceso
¿Privacidad desde el diseño y por defecto es obligatoria en México?
La LFPDPPP y su Reglamento exigen principios, responsabilidad, medidas de seguridad, minimización y atención del riesgo, que pueden instrumentarse mediante este patrón. No conviene afirmar que toda empresa privada mexicana está sujeta automáticamente a una obligación idéntica al artículo 25 del GDPR. Deben revisarse la ley, el sector, los contratos, las personas y las jurisdicciones aplicables al tratamiento concreto.
¿Cuál es la diferencia entre privacidad desde el diseño y privacidad por defecto?
Desde el diseño incorpora requisitos y controles cuando se decide la arquitectura, el flujo y la configuración. Por defecto hace que la opción inicial recopile, use, comparta y conserve solo lo necesario sin exigir que cada persona cierre aperturas después. Una organización necesita ambas: decisiones tempranas y un estado inicial protegido.
¿Qué cambia cuando el CRM usa inteligencia artificial?
Deben incluirse recuperación, prompts, salidas, embeddings, memorias, herramientas, feedback, evaluaciones, telemetría y proveedores de modelos. Los permisos del usuario deben limitar también el contexto y las acciones de la IA, y una salida generada debe permanecer separada de una acción ejecutada hasta pasar la revisión autorizada.
¿Qué configuraciones deberían quedar cerradas al crear una cuenta?
Usos secundarios, entrenamiento con datos del cliente, enlaces públicos sin vencimiento, exportaciones amplias, acceso entre equipos, conservación indefinida y memoria no necesaria. El conjunto exacto depende de la finalidad y el riesgo, pero cualquier apertura debe requerir rol, explicación, alcance, registro y, cuando corresponda, aprobación adicional.
¿Cómo se demuestra que el diseño funciona?
Con una matriz de requisitos, configuración versionada y pruebas de cuenta nueva, roles negativos, finalidades, preferencias, IA, proveedores, retención, derechos y restauración. La evidencia debe mostrar esperado y observado en el entorno aprobado. Una política, un contrato o una captura aislada no sustituyen el recorrido técnico y operativo.