El consentimiento y el derecho al olvido

🌐 También en 28 idiomas

English · Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · Nederlands · العربية · עברית · Українська · हिन्दी · Русский · Svenska · Dansk · Norsk bokmål · Suomi · Français (Canada) · Deutsch (Schweiz)

Imagen generada con IA

Traducido con IA. Aún no revisado por la comunidad. Leer en inglés

Módulo 5 de 6 del capítulo Calidad y gobierno de datos, capítulo 5 del curso Data Architect. Cada módulo se sostiene por sí solo. Anterior: Las leyes de privacidad dan forma al diseño · Siguiente: Proteger, conservar y demostrar

La pregunta que responde este módulo: ¿Cómo diseñas para el consentimiento, y para borrar a una persona?

Steve Trucking tiene el número de teléfono de un destinatario. Pregunta sencilla: ¿podemos enviarle un mensaje de texto? Quizá. ¿Sobre la entrega de hoy? ¿Sobre la de mañana? ¿Podemos usar el número para una promoción? ¿Y si dijo que no a los mensajes de texto, o que sí a las novedades de la entrega pero no al marketing, y luego cambió de opinión?

Ahora la otra dirección. El destinatario dice: elimina mi información personal. ¿Dónde está? En Salesforce, probablemente, pero ya aprendimos que esa no es la respuesta completa. Vino de un socio minorista. Puede estar en una plataforma de datos de clientes, en el historial de campos, en un archivo, en una nota de entrega, en una exportación, en un log de integración, en la conversación de un agente. El consentimiento y la eliminación suenan a preguntas de política, pero al final el sistema tiene que responderlas. Eso es arquitectura.

El consentimiento son datos

El primer principio: el consentimiento son datos. No lo reduzcas a Has_Opted_In__c = true. La pregunta real nunca es solo “¿dio su consentimiento?”. Es consentimiento ¿para qué, por qué canal, en qué dirección o número, con qué propósito, cuándo, ha cambiado, y podemos demostrarlo? Si el negocio toma decisiones a partir de esas respuestas, tienen que guardarse como datos estructurados. Un párrafo en una política de privacidad no basta, y una casilla en un formulario web tampoco: la casilla captura un evento; la arquitectura tiene que conservar lo que significa ese evento.

Usa el modelo que Salesforce ya construyó

Mi posición: usa el modelo de consentimiento estándar siempre que puedas, en lugar de reconstruir lo mismo con campos personalizados. El modelo de datos de consentimiento de Salesforce gestiona el consentimiento en cuatro niveles, cada uno una pregunta más concreta (Understand the Salesforce Consent Data Model (opens in a new tab), en inglés):

• Consentimiento global, en el objeto Individual: ¿quién es esta persona, y ha dicho que no a todo?
• Consentimiento por canal de interacción (Contact Point Type Consent): ¿podemos usar este tipo de canal, como SMS o correo electrónico?
• Consentimiento por punto de contacto: ¿y este número de teléfono o esta dirección de correo concretos?
• Propósito de uso de los datos (Data Use Purpose): ¿por qué motivo: avisos de entrega, servicio, marketing?

Juntos, la arquitectura puede responder “¿podemos usar la información de esta persona, a través de este punto de contacto, para este propósito?”, lo que es mucho más útil que “consentimiento = sí”. Puede participar cualquier registro que se relacione con una persona: prospectos, contactos, cuentas personales, usuarios.

Click to enlarge

Cuatro preguntas, cada una más concreta que la anterior. Un único indicador de aceptación no responde bien ninguna.

El propósito importa

Un socio minorista le envía a Steve Trucking el número de un destinatario para que el equipo pueda coordinar la entrega. Eso no convierte al destinatario en un prospecto de marketing. Los mismos datos pueden tener usos permitidos distintos: coordinar la entrega, hacer seguimiento de servicio, marketing, personalización con IA. Si la política o la ley los tratan de forma distinta, el modelo tiene que distinguirlos. La pregunta no es ¿tenemos el número de teléfono? Es ¿qué se nos permite hacer con él?

Y el consentimiento no siempre es la base legal. Algunos usos se apoyan en otros fundamentos que prevé la ley, y eso lo determina el área legal. No construyas una arquitectura que suponga que cada decisión de privacidad es una casilla de aceptación. Sostén lo que diga la política: si un uso depende del consentimiento, modela y haz cumplir el consentimiento; si aplica otra base, igual guarda lo necesario para decidir si el uso está permitido.

El consentimiento tiene un ciclo de vida y una autoridad

La gente da su consentimiento, lo retira, cambia sus preferencias, cambia de número. El negocio agrega propósitos nuevos; las leyes cambian. Así que diseña el ciclo de vida: qué se eligió, cuándo, cómo, para qué propósito y qué pasa cuando se retira. Y aquí se pone interesante: cuando un destinatario retira su consentimiento, Salesforce lo sabe. ¿Lo sabe la plataforma de mensajería? ¿La analítica? ¿El agente? Un consentimiento que vive en un sistema mientras otros actúan con un permiso desactualizado no es gran cosa como control.

Eso significa preguntar qué sistema es la referencia para el consentimiento. ¿Salesforce, una plataforma de preferencias, otro lugar? Sea cual sea la respuesta, no dejes que cinco sistemas decidan por su cuenta si la misma persona aceptó el mismo uso. El consentimiento necesita lo que necesita cualquier dato gobernado: un dueño, un registro de referencia, una forma de sincronizarlo y su cumplimiento.

Ahora la persona dice: olvídame

El primer instinto es eliminar el contacto y darlo por hecho. Pero los datos de la persona pueden estar en un contacto, una entrega, una nota de entrega, un caso, una foto, en el historial de campos, en Snowflake, en un archivo, en un log de integración, en un índice de búsqueda o en el historial de conversaciones de un agente. Por eso mi posición sobre el borrado empieza antes: en la práctica, la eliminación es rara y difícil, así que controla primero adónde van los datos personales. Diseña para que lleguen al menor número de lugares posible. Luego, cuando llega una solicitud, ofúscalos o desvincúlalos donde eso cumpla la política, y persigue cada copia: el historial de campos, los archivos, Data 360 y, ahora, los índices de búsqueda y las conversaciones de los agentes.

No empieces la búsqueda cuando llega la solicitud. Para entonces es demasiado tarde para empezar a entender el panorama. El diccionario, el linaje y la clasificación del módulo 3 no eran papeleo; son lo que hace esto posible. Ya sabes qué campos guardan datos personales y adónde fueron las copias.

Click to enlarge

Una solicitud de olvido es una decisión para cada copia.

El reloj está corriendo

Estas solicitudes vienen con plazos. Con el RGPD, la organización tiene que atender la solicitud de una persona sin demora indebida y dentro del mes siguiente a recibirla; para solicitudes complejas o numerosas, ese plazo puede ampliarse otros dos meses, pero hay que informar a la persona dentro del primer mes, con los motivos (artículo 12, apartado 3, del Reglamento (UE) 2016/679 (opens in a new tab)). Otras leyes fijan sus propios plazos; Legal te dirá cuáles aplican. En cualquier caso, un mes no es suficiente para descubrir el panorama. Ese es el plazo que el mapa de copias tiene que ganarle.

¿Eliminar, desidentificar o conservar?

Una solicitud no significa necesariamente que todo desaparezca en todas partes. Algunos registros deben o pueden conservarse; algunos registros operativos pueden quedarse pero dejar de identificar a la persona; algunos datos pueden desidentificarse. Lo deciden la política y la ley aplicables; la arquitectura sostiene cada resultado, lugar por lugar: eliminarlo, desidentificarlo o conservarlo con un requisito aprobado (y entonces, ¿quién puede verlo, durante cuánto tiempo, por qué?).

Recuerda la distinción del módulo 4. Desvincular cuenta como olvidar solo cuando la persona no puede volver a identificarse razonablemente. Los datos seudonimizados siguen siendo datos personales. No uses la ofuscación como un atajo para esquivar un requisito legal.

No puedes eliminar lo que no puedes encontrar

Antes de poder borrar a alguien, tienes que encontrarlo. La solicitud llega desde una dirección de correo electrónico. Un socio minorista envió “Jane Smith”, otro “J. Smith”, y el número de teléfono cambió. El destinatario no es un contacto en absoluto; sus datos están en cada entrega. La misma persona recibió entregas de dos socios distintos. Un sistema la conoce por su correo, otro por un ID externo. El borrado depende de la identidad, y no quieres eliminar los datos de otra persona porque tu emparejamiento fue demasiado agresivo. La arquitectura de identidad es parte de la arquitectura de privacidad.

Steve Trucking lo hace todavía más difícil. Un socio minorista nunca debe ver las entregas ni los destinatarios de otro. Si la misma persona recibió entregas de dos socios, las operaciones tienen que mantener separadas esas relaciones, mientras que privacidad puede necesitar encontrar a la persona en ambos. No resuelvas la privacidad rompiendo la frontera de seguridad, y no protejas la frontera haciendo imposibles las solicitudes de privacidad. La arquitectura tiene que hacer las dos cosas.

Las fotos y el texto libre también son datos

Es fácil pensar en la privacidad como campos: nombre, correo, teléfono, dirección. Pero Steve Trucking toma millones de fotos de entregas al año, y algunas muestran personas o el interior de una casa. Una política de retención o de borrado que solo mira los campos estructurados está incompleta; también lo está una que ignora los archivos, los documentos, las transcripciones, los logs y las instrucciones y respuestas de la IA.

Y el texto libre es peligroso. Quitas el nombre, el teléfono y la dirección, y luego encuentras esta nota de entrega: “Llamar a Jane al 602-555-0198. Código del portón 4821. El perro está en el patio”. Ahí está. Clasificar las notas de entrega como sensibles te dice que puede haber un problema; no encuentra ni quita los datos personales que hay dentro del texto. A veces la mejor respuesta es impedir que lleguen ahí detalles personales innecesarios. Controla primero adónde van los datos personales.

Privacy Center es una herramienta, no toda la arquitectura

Privacy Center de Salesforce ayuda a ejecutar estos procesos. Sus políticas de derecho al olvido se construyen por objeto, para capturar todo lo que quieres eliminar, y se ejecutan contra el registro de un cliente concreto (Delete Data with Right to Be Forgotten Policies (opens in a new tab), en inglés). Es útil. Pero “compramos Privacy Center, así que terminamos” no es una arquitectura. Los datos de la persona pueden vivir fuera del alcance de cualquier herramienta: Data 360, el almacén de datos, los sistemas de los socios, los archivos, los logs, la búsqueda, los archivos adjuntos, las conversaciones de los agentes. La empresa sigue necesitando una respuesta de empresa, y tienes que comprobar qué cubre realmente cada herramienta antes de confiar en ella.

Portabilidad y prueba

Algunas leyes también dan a las personas el derecho a obtener una copia de sus datos. Fíjate en que es el mismo problema de búsqueda: la eliminación pregunta ¿dónde están los datos de esta persona, para poder actuar sobre ellos? La portabilidad pregunta ¿dónde están, para poder entregarlos? Las dos se apoyan en la identidad, la clasificación, el linaje, el inventario de sistemas y la propiedad.

Y luego: ¿cómo demuestras que lo hiciste? Solicitud recibida, identidad verificada, sistemas revisados, acciones realizadas, excepciones registradas, datos conservados justificados, finalización registrada. Aquí hay una tensión real: estás quitando los datos personales de alguien mientras conservas suficiente evidencia para demostrar que gestionaste bien la solicitud. Precisamente por eso los arquitectos no deberían inventarse por su cuenta las reglas de retención. El área legal y la de cumplimiento deciden qué evidencia tiene que quedar; la arquitectura la conserva sin conservar los datos que se suponía que debía quitar.

Más allá del examen: lo que cambia la IA. La IA crea propósitos nuevos y copias nuevas. El permiso para usar los datos para prestar un servicio no cubre automáticamente usarlos como base de un agente, para personalizar o para entrenar; el Propósito de uso de los datos es el lugar natural para distinguirlos. Y los datos personales pueden sobrevivir en las instrucciones, el contexto de base, las conversaciones, los resúmenes, los índices de búsqueda y vectoriales, y los logs. “Eliminamos el registro de origen” no es una respuesta completa si la capa de IA todavía recuerda.

Lo que decide aquí un arquitecto

• Cómo se modelan el consentimiento y el uso permitido, para que los sistemas puedan responder quién, qué canal, qué punto de contacto y qué propósito.
• Qué sistema es la referencia para el consentimiento, y cómo llegan las retiradas a cada sistema que actúa sobre él.
• Por dónde pueden esparcirse los datos personales: campos, texto libre, archivos, historial, analítica, archivos históricos, integraciones, búsqueda e IA.
• Cómo una solicitud encuentra a la persona correcta y determina eliminar, desidentificar o conservar con aprobación en cada lugar.
• Qué evidencia queda para demostrar que se gestionaron el consentimiento y las solicitudes de privacidad.

El consentimiento y el borrado parecen opuestos (¿podemos usar estos datos? ¿podemos dejar de usarlos y quitarlos?), pero se apoyan en las mismas bases: identidad, propósito, clasificación, linaje, propiedad, cumplimiento y evidencia. Usa el modelo de consentimiento estándar, controla adónde van los datos personales, sabe dónde están las copias y diseña el proceso de borrado antes de que llegue la primera solicitud. Cuando alguien pregunta “¿pueden olvidarme?”, la arquitectura necesita una respuesta mejor que “creemos que sí”.

Explora

• Ayuda de Salesforce, Understand the Salesforce Consent Data Model (opens in a new tab) (en inglés), consultado el 2026-10-14.
• Reglamento (UE) 2016/679 (GDPR/RGPD) (opens in a new tab), artículo 12, apartado 3, el plazo para atender una solicitud, consultado el 2026-10-14.
• Ayuda de Salesforce, Delete Data with Right to Be Forgotten Policies (opens in a new tab) (Privacy Center, en inglés), consultado el 2026-10-14.