Eliminación de datos

Envía tu solicitud

Solicita la eliminación de tus datos relacionados con los servicios de MCLLENT.

Alcance

Este procedimiento aplica a datos relacionados con usuarios procesados por soluciones de MCLLENT que utilicen:

Meta

• WhatsApp Business Platform.
• whatsapp_business_management.
• whatsapp_business_messaging.
• public_profile, cuando resulte aplicable a la integración.

Microsoft Azure

• Azure Storage Account.
• Azure Blob Storage.
• Neo4j desplegado sobre infraestructura Azure.
• Archivos de logs almacenados en Blob Storage.

El procedimiento también aplica a cualquier referencia, identificador o dato derivado que permita asociar información almacenada por MCLLENT con un usuario determinado.

Marco de referencia

Este procedimiento se sustenta en:

México

• Ley Federal de Protección de Datos Personales en Posesión de los Particulares vigente, publicada el 20 de marzo de 2025 y reformada el 14 de noviembre de 2025.
• Reglamento de la Ley Federal de Protección de Datos Personales en Posesión de los Particulares. La Cámara de Diputados continúa listándolo como reglamento vigente.
• Aviso de Privacidad Integral de MCLLENT.

Meta

• Condiciones de la Plataforma de Meta.
• Documentación de Meta para solicitudes de eliminación de datos.
• Requisitos y políticas aplicables a WhatsApp Business Platform.

Microsoft

• Addendum de Protección de Datos de Productos y Servicios de Microsoft.
• Condiciones correspondientes a los servicios de Microsoft Azure.

El Aviso de Privacidad existente de MCLLENT ya contempla cancelación ARCO, conservación, eliminación, seguridad y mecanismos para limitar el tratamiento.

Arquitectura considerada

Para esta versión del procedimiento se establece el siguiente flujo lógico:

El usuario de WhatsApp interactúa con WhatsApp Business Platform / Meta, que se conecta con la aplicación MCLLENT y Microsoft Azure. En Azure, Neo4j relaciona usuario, relaciones, contexto y datos derivados; Blob Storage almacena mensajes, adjuntos, archivos y logs.

Los mensajes y adjuntos almacenados en Blob Storage deberán mantenerse cifrados.

El DPA de Microsoft establece controles de cifrado, gestión de acceso, privilegio mínimo, registro, seguridad y eliminación para los servicios cubiertos, y a la vez atribuye al cliente responsabilidad sobre los componentes que éste configura o controla dentro de Azure.

Identificación de usuario

MCLLENT utilizará dos identificadores principales para relacionar una solicitud con la información almacenada:

• wa_id proporcionado en el contexto de WhatsApp Business Platform.
• mcllent_user_id o identificador interno único de MCLLENT.

El sistema deberá mantener una correspondencia entre ambos identificadores que permita localizar de manera consistente los registros asociados con el usuario.

El número telefónico podrá utilizarse como dato auxiliar de verificación cuando resulte estrictamente necesario, pero no deberá constituir la única llave técnica de eliminación.

Periodos de conservación operativa

Dado que MCLLENT conservará la información exclusivamente por necesidades operativas temporales, se establecen los siguientes periodos objetivo:

Estos periodos no impiden la eliminación anticipada cuando corresponda por solicitud válida del titular, de Meta, por terminación de finalidad o por obligación legal.

Meta exige que los datos de su Plataforma no se conserven cuando ya no sean necesarios para una finalidad permitida y establece obligaciones de eliminación cuando corresponda.

Canal para solicitar la eliminación

Para esta versión, MCLLENT utilizará como mecanismo de solicitud:

Correo: privacidad@mcllent.com.mx

Asunto recomendado:
Solicitud de eliminación de datos

La página pública:

https://mcllent.com.mx/sitioMCL/data-deletion.html

Información mínima de la solicitud

La persona solicitante deberá proporcionar información suficiente para localizar sus datos, por ejemplo:

• Nombre.
• Número de WhatsApp asociado.
• Correo electrónico, cuando corresponda.
• Servicio de MCLLENT utilizado.
• Empresa relacionada con la interacción, cuando corresponda.
• Descripción de la solicitud.

MCLLENT no solicitará contraseñas, tokens, App Secrets, claves de acceso ni credenciales de Meta o WhatsApp para validar una solicitud.

Roles y responsabilidades

MCLLENT podrá utilizar proveedores o subproveedores necesarios para proporcionar sus servicios

Registro de la solicitud

Al recibir una solicitud, Seguridad de la Información generará un folio único, por ejemplo:

DEL-2026-000001

El expediente deberá registrar como mínimo:

• Folio
• Fecha de recepción
• Canal
• Estado
• mcllent_user_id
• wa_id cuando sea necesario
• Origen de la solicitud
• Repositorios involucrados
• Responsables asignados
• Fecha límite de respuesta
• Acciones realizadas
• Fecha de cierre
• Resultado

No deberá copiarse al expediente el contenido completo de conversaciones o adjuntos salvo que resulte estrictamente necesario para resolver una incidencia específica .

Validación de identidad

Área Legal verificará razonablemente que la persona solicitante corresponda con los datos cuya eliminación pretende.

Podrán utilizarse elementos como:

• correspondencia del número de WhatsApp;
• información de contacto previamente registrada;
• wa_id;
• identificador interno;
• información adicional mínima para resolver discrepancias.

La validación deberá ser proporcional al riesgo y evitar recopilar nuevos datos innecesarios.

Análisis de procedencia

Área Legal determinará si la solicitud puede ejecutarse directamente o si existe una causa que requiera conservar temporalmente determinados registros.

Cuando exista una obligación legal o contractual de conservación, dichos datos no deberán continuar utilizándose para las finalidades operativas ordinarias.

El Reglamento contempla que, cuando proceda la cancelación, puede establecerse un periodo de bloqueo con el objeto de determinar posibles responsabilidades y, terminado dicho periodo, realizar la supresión correspondiente.

Si fuera el caso, el expediente deberá registrar de forma concreta cualquier excepción. En estos escenarios se sustentar con una base legal, contractual o de seguridad identificable.

Correlación técnica

MCLLENT mantendrá procedimientos para detectar, analizar, contener y atender incidentes de seguridad relacionados con los servicios que proporciona.

Cuando un incidente afecte datos administrados mediante una plataforma de terceros, MCLLENT realizará las acciones y notificaciones que resulten aplicables conforme a las condiciones de dicha plataforma y la legislación correspondiente.

Una vez autorizada la búsqueda, Desarrollo deberá resolver:

La correlación relaciona wa_id con mcllent_user_id para localizar objetos Blob y nodos o relaciones de Neo4j.

El objetivo es disponer de un inventario técnico de toda la información directamente asociada con el usuario.

Eliminación en Azure Blob Storage

El Área de Operaciones TI deberá localizar los objetos asociados al mcllent_user_id, wa_id o ambos.

Según corresponda, se eliminarán:

• mensajes almacenados.
• archivos serializados.
• Adjuntos.
• Imágenes.
• Documentos.
• Audio.
• Video.
• archivos temporales.
• metadata identificable.
• logs que contengan información personal y puedan asociarse de forma razonable al usuario.

La eliminación deberá contemplar tanto el contenido cifrado como los metadatos o referencias que permitan identificarlo.

No será suficiente borrar únicamente el archivo principal si permanece un índice o referencia que permita recuperar o reconstruir la asociación con el usuario, se deberá de garantizar la eliminación de las relaciones del usuario.

Eliminación de Neo4j

Las solicitudes relacionadas con acceso, rectificación, cancelación, oposición o eliminación de datos personales serán atendidas conforme al Aviso de Privacidad de MCLLENT y la legislación aplicable

Desarrollo deberá buscar registros asociados con:

wa_id

y

mcllent_user_id.

Cuando corresponda, deberán eliminarse o anonimizarse:

• Propiedades personales.
• Nodos de usuario.
• Nodos de conversación.
• Relaciones vinculadas al usuario.
• Datos derivados directamente de la conversación.
• Referencias a archivos eliminados.
• Identificadores que ya no tengan finalidad operativa.

Antes de eliminar un nodo deberá evaluarse el impacto sobre relaciones compartidas que pertenezcan legítimamente a otros usuarios o al cliente.

Cuando una relación deba conservarse por razones técnicas válidas, los elementos identificables del usuario deberán eliminarse o anonimizarse de forma que no sea razonablemente posible reconstruir su identidad a partir del registro restante.

Eliminación en logs

Cuando los logs almacenados en Blob Storage contengan identificadores personales como:

wa_id, número telefónico, mcllent_user_id, contenido de mensajes u otros valores asociados directamente al usuario,

deberán incluirse en el análisis de eliminación.

Para reducir esta carga operativa, el diseño de logging de MCLLENT deberá, en la medida técnicamente viable:

• Evitar almacenar contenido completo de mensajes.
• Evitar almacenar datos personales innecesarios.
• Utilizar identificadores técnicos.
• Aplicar enmascaramiento o seudonimización.
• Limitar la retención.

Tokens y autorizaciones

Si la solicitud implica además la terminación completa de la relación del usuario o de la conexión correspondiente, Desarrollo deberá identificar y, cuando aplique:

• Eliminar referencias de autorización.
• Revocar asociaciones técnicas.
• Invalidar credenciales derivadas.
• Eliminar tokens almacenados relacionados con la sesión o usuario.

Los secretos generales de la aplicación de MCLLENT no deberán eliminarse como consecuencia de una solicitud individual, ya que no pertenecen al usuario.

Solicitudes originadas por Meta

Aunque MCLLENT utilice inicialmente una URL pública con instrucciones y no un callback automático, el procedimiento deberá contemplar las solicitudes que Meta comunique mediante sus mecanismos de desarrollador.

La documentación de Meta señala que periódicamente pueden proporcionarse identificadores de usuarios que solicitaron eliminación y que el desarrollador debe atenderlos rápidamente. También señala que los identificadores que no estén presentes en los registros del desarrollador pueden ignorarse.

Por ello:

Desarrollo y Seguridad de la Información deberán revisar y atender las notificaciones que Meta genere respecto de solicitudes de eliminación asociadas a la app.

Cuando exista un identificador de Meta válido:

El identificador de Meta se correlaciona con el usuario MCLLENT; se revisan Blob Storage, Neo4j y logs, se valida el resultado y se cierra la solicitud.

Si el identificador no existe en los sistemas de MCLLENT, deberá registrarse:

Resultado: dato no localizado.

No deberán inventarse asociaciones para intentar identificar al usuario.

Plazos

Para solicitudes que constituyan ejercicio del derecho de cancelación:

Determinación: MCLLENT comunicará su respuesta dentro de un plazo máximo de 20 días contados desde la recepción de la solicitud completa.

Ejecución: si resulta procedente, MCLLENT hará efectiva la acción correspondiente dentro de los 15 días siguientes a la comunicación de la determinación.

Los plazos podrán ampliarse una sola vez por un periodo igual cuando las circunstancias lo justifiquen, conforme al marco aplicable.

El Reglamento también relaciona el procedimiento de cancelación con dichos periodos y con la figura de bloqueo cuando corresponda.

No obstante, las solicitudes provenientes de Meta deberán procesarse sin demora indebida y tan pronto como resulte técnica y jurídicamente posible, ya que Meta indica que espera que los desarrolladores eliminen rápidamente los datos solicitados.

Verificación posterior

Seguridad de la Información no deberá cerrar la solicitud hasta recibir confirmación de las áreas técnicas correspondientes.

Como mínimo deberá verificarse:

Comunicación de cierre

Cuando la solicitud haya concluido, Soporte o Área Legal notificará al solicitante.

La comunicación deberá indicar, según corresponda:

• Que la solicitud fue procesada.
• Que los datos fueron eliminados.
• Que determinados datos fueron anonimizados.
• Que determinados datos no fueron localizados.
• Puede que cierta información permanecerá bloqueada temporalmente por una causa legal o contractual.

No deberán comunicarse detalles internos que comprometan:

• Arquitectura.
• Secretos.
• Claves.
• Controles de seguridad.
• Credenciales.
• Información de otros usuarios.

Backups

MCLLENT utilizará mecanismos de respaldo soportados por Microsoft Azure con Locally Redundant Storage (LRS) para proteger la información operativa almacenada en Azure.

LRS mantiene múltiples copias sincronizadas de los datos dentro de la región primaria de Azure. Microsoft documenta que LRS protege frente a fallas de hardware como discos, servidores o racks y que las réplicas mantienen el mismo estado de los datos.

Para efectos del presente procedimiento:

• Los respaldos de información operativa deberán utilizar redundancia local LRS cuando así se configure.
• Las copias redundantes no deberán considerarse repositorios independientes para fines de conservación.
• Cuando un dato sea eliminado o sobrescrito en el almacenamiento principal, la operación se replica sobre las copias LRS que forman parte del mismo servicio de almacenamiento.
• LRS se utilizará como mecanismo de resiliencia frente a fallas de infraestructura y no como mecanismo para conservar versiones históricas de datos personales.
• Los periodos de retención de mensajes, adjuntos y logs definidos por MCLLENT aplicarán igualmente aunque la infraestructura utilice redundancia LRS.
• La configuración de redundancia no deberá utilizarse para extender artificialmente la conservación de información más allá de los plazos definidos en este procedimiento.

Microsoft señala expresamente que las réplicas LRS reflejan el mismo estado actual: las eliminaciones y sobrescrituras se aplican a todas las copias. La redundancia está diseñada para proteger contra fallas de infraestructura, no contra operaciones de modificación o eliminación de datos.

Alcance de protección

MCLLENT reconoce que LRS mantiene las copias dentro de la región primaria y ofrece menor resiliencia que opciones como ZRS, GRS o GZRS frente a fallas de mayor alcance. En particular, Microsoft advierte que LRS no protege frente a determinados eventos que afecten completamente al centro de datos.

Para esta V1, MCLLENT utilizará LRS conforme a sus necesidades operativas actuales. La adopción futura de redundancia por zona o geográfica deberá evaluarse por separado considerando requisitos de continuidad, disponibilidad, residencia de datos, privacidad y costo.

Eliminación de datos y respaldo LRS

Cuando MCLLENT reciba y autorice una solicitud de eliminación, la eliminación deberá ejecutarse sobre el recurso lógico correspondiente en Azure.

En un esquema LRS, no será necesario ejecutar manualmente el borrado sobre cada una de las copias redundantes internas, debido a que Azure administra dichas réplicas como parte del mismo servicio y las operaciones de eliminación aplicadas al dato se reflejan en todas las copias LRS.

El procedimiento será:

Solicitud aprobada → Identificación wa_id / mcllent_user_id → Eliminación en Blob Storage / Neo4j → Azure replica el nuevo estado mediante LRS → Validación de eliminación lógica → Registro de evidencia → Cierre.

Seguridad de la Información deberá validar que:

• El objeto o registro ya no sea accesible desde los sistemas de MCLLENT.
• No existan referencias activas en Neo4j.
• No permanezcan metadatos que permitan reconstruir la asociación con el usuario.
• Los logs sujetos a eliminación hayan sido tratados conforme al procedimiento.
• No existan mecanismos adicionales de versionado, snapshots, soft delete o backup histórico configurados que puedan conservar versiones previas.

No reutilización de información eliminada

Una vez ejecutada una eliminación, MCLLENT no deberá recuperar los datos eliminados para:

• Analítica.
• Marketing.
• Entrenamiento.
• Creación de perfiles.
• Enriquecimiento de bases.
• Nuevas finalidades operativas.

Los registros técnicos mínimos conservados como evidencia de cumplimiento no podrán utilizarse para reconstruir las conversaciones eliminadas.