Respuesta directa
En pocas palabras
Antes de lanzar o modificar un CRM con IA, delimita el tratamiento y su versión, identifica a las personas afectadas, mapea cada acción sobre datos, valida finalidad, consentimiento o excepción, roles, transferencias y derechos, y describe escenarios de daño. Después asigna controles, prueba su operación y decide si avanzar, limitar, rediseñar o detener. Para una empresa privada en México, esta evaluación es un método operativo de responsabilidad y gestión de riesgo; no debe presentarse como una DPIA universalmente obligatoria sin verificar la ley, el sector, los contratos y las jurisdicciones aplicables.
Empieza por la decisión que debe tomarse
La evaluación existe para decidir antes de exponer personas y datos. Define si autorizará un piloto, un lanzamiento, una integración, un nuevo proveedor, una automatización o una ampliación. Registra patrocinador, responsable, revisores, fecha límite y autoridad para aprobar, condicionar, pausar o rechazar. Sin una decisión concreta, el documento se vuelve inventario sin consecuencia.
Congela el escenario evaluado: propósito, usuarios, población, países, modelo, instrucciones, fuentes, herramientas, permisos, integraciones, regiones y versión. Una evaluación de resúmenes internos no autoriza prospección automática, scoring de personas o uso de conversaciones para entrenamiento. Todo cambio material debe reabrir el análisis.
Distingue obligación jurídica, práctica de riesgo y DPIA
La LFPDPPP vigente para particulares exige observar licitud, finalidad, lealtad, consentimiento, calidad, proporcionalidad, información y responsabilidad. También exige medidas administrativas, técnicas y físicas considerando el riesgo, las consecuencias para las personas, la sensibilidad y el desarrollo tecnológico. Esos deberes sostienen una revisión previa y documentada, pero la ley federal aplicable a particulares no debe resumirse como una obligación universal de completar una DPIA con formato GDPR para cada CRM.
Verifica además reglas sectoriales, laborales, de consumo, contratos, países de las personas, localización de proveedores y finalidades concretas. El GDPR sí regula una evaluación de impacto específica en su artículo 35 para tratamientos probablemente de alto riesgo. La ley mexicana para sujetos obligados del sector público contiene otra figura expresa. No traslades automáticamente ninguno de esos regímenes a una empresa privada; documenta cuál aplica y por qué.
| Criterio | Qué determina | Resultado esperado |
|---|---|---|
| Revisión jurídica | Qué leyes, contratos y reglas sectoriales aplican | Obligaciones y condiciones verificadas para el caso |
| Evaluación operativa de privacidad | Qué acciones sobre datos pueden afectar a las personas | Riesgos, controles, residual y decisión trazable |
| DPIA del GDPR | Si el artículo 35 aplica a un tratamiento probablemente de alto riesgo | Contenido y consulta previa exigidos por ese régimen |
Identifica personas y resultados de privacidad
Incluye contactos, prospectos, clientes, usuarios, personal, visitantes de Buyer Rooms y personas mencionadas en notas, correos, archivos o conversaciones. Añade quienes no usan el producto pero reciben una inferencia, una prioridad, una exclusión o un mensaje basado en sus datos. Separa población prevista, personas incidentales y grupos que pueden soportar una carga desproporcionada.
Describe resultados concretos: exposición, pérdida de control, contacto inesperado, perfil incorrecto, discriminación, fraude, vigilancia laboral, dificultad para ejercer derechos o asociación entre identidades. Evita la etiqueta genérica riesgo reputacional. Explica qué acción de datos produce qué efecto, para quién, durante cuánto tiempo y con qué posibilidad de corrección.
Mapea el ciclo completo y las capas de IA
Traza origen, recopilación, validación, almacenamiento, búsqueda, recuperación, inferencia, generación, visualización, exportación, transferencia, respaldo, bloqueo y eliminación. Incluye formularios, importadores, correo, calendario, transcripciones, notas, documentos, APIs, soporte y analítica. Para cada nodo registra categorías, volumen, personas, finalidad, acceso, sistema, región y retención.
No detengas el mapa en la tabla del CRM. Examina fragmentos recuperados, prompts, contexto de herramientas, salidas, embeddings, memorias, feedback, evaluaciones, telemetría y registros. Una operación puede ser problemática aunque sea técnicamente correcta: combinar fuentes, inducir una revelación, inferir un atributo o mantener datos más tiempo del esperado también puede afectar la privacidad.
Prueba finalidad, necesidad, proporcionalidad y ruta jurídica
Escribe cada finalidad de forma que una persona pueda comprender el resultado. Separa finalidades necesarias de secundarias, tratamiento ordinario de categorías sensibles o financieras y datos aportados de inferencias. Vincula aviso, consentimiento o excepción aplicable, mecanismo de revocación, derechos y responsable de la interpretación. No uses interés comercial como frase que absorbe cualquier uso futuro.
Compara alternativas: no recopilar, reducir campos, calcular localmente, conservar solo el resultado, agregar datos, usar sintéticos, eliminar texto libre, exigir una acción humana o mantener el proceso manual. La proporcionalidad no se demuestra porque una función sea útil. Registra por qué el beneficio requiere ese dato, ese detalle, ese plazo y esa audiencia.
Asigna roles, proveedores y transferencias por flujo
Identifica responsable, persona encargada, tercero receptor, subencargados y equipos internos para cada tratamiento. El nombre comercial de un proveedor no decide el rol. Revisa instrucciones, uso propio, entrenamiento, soporte, regiones, acceso remoto, subprocesamiento, devolución, eliminación, incidentes y asistencia a derechos. Conserva contratos y configuraciones vigentes, no solo respuestas de preventa.
Marca límites de confianza y cada transferencia dentro o fuera de México. Comprueba aviso, consentimiento o excepción cuando correspondan y obligaciones contractuales. Si no puedes demostrar qué entidad recibe entradas, salidas, feedback o telemetría, no declares el flujo evaluado. Limita datos, permisos o proveedor antes de aprobar.
Formula escenarios de acciones problemáticas sobre datos
Describe cada escenario como condición, acción de datos, persona y consecuencia. Por ejemplo: una integración mezcla contactos de dos workspaces; Copilot recupera una nota sensible; una transcripción convierte una conjetura en atributo; una exportación conserva personas que ya se opusieron; o soporte accede desde una región no aprobada. Incluye acciones legítimas mal configuradas, errores humanos y comportamiento emergente, no solo ataques.
NIST PRAM propone analizar y priorizar riesgos a partir de acciones problemáticas sobre datos. Puedes usar sus cuatro bloques —objetivos y gobernanza, diseño y mapa, priorización, y selección de controles— como estructura adaptable. Es una metodología voluntaria, no una certificación ni sustituto de la ley mexicana.
Prioriza impacto y posibilidad sin esconder líneas rojas
Valora severidad para la persona, alcance, duración, reversibilidad, capacidad de detección, posibilidad y distribución. Conserva evidencia e incertidumbre detrás de cada nivel. No promedies hasta convertir un escenario grave y poco frecuente en verde. Una línea roja puede bloquear el lanzamiento aunque la puntuación total mejore.
Separa riesgo inherente del residual. El inherente describe el escenario antes de controles; el residual, después de controles implementados y probados. No reduzcas la calificación por una política todavía no aplicada, una promesa del proveedor o una función del roadmap. Registra supuestos, desacuerdos y autoridad que acepta el residual.
Conecta cada control con una ruta de daño
Selecciona controles preventivos, detectivos, correctivos y de recuperación donde interrumpen la ruta. Pueden incluir minimización, segregación, permisos por operación, autenticación, aislamiento de workspace, redacción, cifrado, listas de proveedores, filtros de recuperación, revisión humana, límites de exportación, registros, alertas, corrección, bloqueo, eliminación y modo manual.
Cada control necesita alcance, dueño, estado, dependencia, prueba y evidencia. Un aviso no corrige acceso excesivo; cifrado no legitima una finalidad; revisión humana sin tiempo ni autoridad no controla una decisión; y un filtro visible no protege una API. Si el control introduce otra carga para las personas, inclúyela en el residual.
Prueba el recorrido con datos sintéticos y roles negativos
Crea casos sintéticos para dato ordinario, sensible, financiero, texto libre, inferencia, menor privilegio, otro workspace, cuenta desactivada, proveedor caído y persona que retira consentimiento o ejerce oposición. Recorre interfaz, API, búsqueda, Copilot, exportación, logs, respaldo, bloqueo y eliminación. La ausencia de datos reales protege la prueba sin volverla superficial.
Registra versión, precondición, rol, entrada, acción, esperado, observado, evidencia y decisión. Prueba controles por separado y como recorrido. Incluye recuperación: una restauración no debe reactivar permisos, propósitos o registros bloqueados. Un control se considera disponible cuando opera en el entorno aprobado, no cuando existe en una presentación.
Cierra con un gate y condiciones verificables
La resolución debe ser explícita: avanzar, avanzar con condiciones, pilotar con alcance limitado, rediseñar, pausar o no avanzar. Adjunta riesgos aceptados, controles pendientes, población, datos, proveedores, fecha, aprobadores, evidencia y criterio de salida. Una condición sin dueño, fecha y verificación es una recomendación, no un gate.
Define líneas rojas: base o finalidad sin resolver, acceso cruzado, categoría prohibida, proveedor no evaluado, derechos inviables, control crítico fallido, evidencia insuficiente o residual fuera de tolerancia. La presión comercial no cambia el tratamiento; si cambia la decisión, registra quién asumió autoridad y sobre qué evidencia.
Vigila el residual y reabre la evaluación ante cambios
Convierte riesgos prioritarios en señales: accesos denegados, recuperaciones cruzadas, datos sensibles detectados, exportaciones, quejas, correcciones, solicitudes, excepciones vencidas, eliminaciones pendientes y cambios de proveedor. Define fuente, denominador, umbral, dueño y respuesta. Una métrica agregada no sustituye muestras ni feedback de personas afectadas.
Reabre la evaluación cuando cambien propósito, población, categoría, fuente, modelo, prompt, herramienta, permiso, proveedor, región, retención, autonomía o escala; también tras un incidente, una queja material o un control fallido. Reconcíliala periódicamente con producción para detectar deriva entre el diseño aprobado y el tratamiento real.
Conserva un expediente pequeño pero reconstruible
El expediente mínimo contiene decisión, alcance, versión, mapa de datos, personas, finalidades, avisos y bases revisadas, roles, proveedores, escenarios, criterios, controles, pruebas, residual, aprobaciones, condiciones y disparadores. Enlaza a la fuente responsable y conserva integridad, vigencia y acceso limitado. No copies datos personales innecesarios dentro de la propia evaluación.
Distingue afirmación, evidencia, supuesto y pendiente. Versiona cambios sin borrar decisiones anteriores. Esto permite explicar qué sabía el equipo al aprobar, qué control comprobó y por qué reabrió el análisis. La trazabilidad ayuda a rendir cuentas, pero no convierte el expediente en certificación 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. No determina por sí solo la ley aplicable, la finalidad legítima, la validez del consentimiento, los roles de cada entidad, una transferencia, el nivel de riesgo ni la aceptación del residual. Esas decisiones corresponden a la organización y a sus especialistas.
Evalúa la configuración, usuarios, datos, integraciones, proveedores y procesos reales. Esta guía ofrece un método operativo basado en fuentes públicas; no constituye asesoría legal, no sustituye una DPIA cuando otro régimen la exige y no garantiza cumplimiento. El objetivo es impedir que un uso nuevo llegue a producción sin alcance, riesgo, controles, prueba, responsable y salida verificables.
Preguntas frecuentes
Dudas comunes sobre este proceso
¿La LFPDPPP obliga a toda empresa privada a realizar una DPIA?
La LFPDPPP vigente para particulares establece principios, responsabilidad y medidas de seguridad basadas en riesgo y consecuencias, pero no conviene afirmar que impone un formato universal de DPIA para todo CRM. Deben revisarse además sector, contratos, jurisdicciones, tipo de tratamiento y otras normas aplicables. La evaluación operativa sigue siendo una forma útil de demostrar decisiones y controles sin atribuirle un efecto jurídico que no se haya verificado.
¿Cuándo conviene hacer una evaluación de impacto en privacidad?
Antes de recopilar o reutilizar datos para un nuevo propósito, conectar IA o un proveedor, tratar categorías de alto impacto, perfilar personas, ampliar población o país, automatizar decisiones, aumentar permisos o modificar retención. También debe reabrirse tras incidentes, quejas materiales, controles fallidos o cambios de arquitectura.
¿Cuál es la diferencia entre evaluación de privacidad y evaluación general de impacto de IA?
La evaluación general estudia beneficios y daños del sistema sobre personas, grupos, operación y organización. La de privacidad se concentra en acciones sobre datos, expectativas, control de las personas, principios, derechos, roles, transferencias y riesgos derivados del tratamiento. Se conectan, pero una no sustituye a la otra.
¿Qué debe bloquear el lanzamiento?
Una finalidad o ruta jurídica sin resolver, categorías no autorizadas, acceso entre workspaces, proveedor o transferencia sin evaluar, imposibilidad de atender derechos, fallo de un control crítico, evidencia insuficiente o riesgo residual fuera de tolerancia. Cada línea roja debe tener autoridad y criterio explícitos antes de la prueba.
¿Se puede usar NIST PRAM en México?
Sí, como metodología voluntaria para mapear acciones de datos, priorizar problemas y seleccionar controles. Debe adaptarse a la organización y conectarse con las obligaciones mexicanas, sectoriales, contractuales y de otras jurisdicciones. NIST PRAM no es una ley mexicana, una auditoría ni una certificación.