Las leyes de privacidad dan forma al diseño

🌐 También en 28 idiomas

English · 日本語 · 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 · Español (México) · 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 4 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: Conoce tus datos · Siguiente: El consentimiento y el derecho al olvido

La pregunta que responde este módulo: ¿Qué le piden a un diseño de Salesforce las regulaciones de privacidad y de sector?

Cuando trabajé en Australia, conocí a muchos aspirantes a arquitecto que nunca habían oído hablar del GDPR. Los europeos a menudo no han oído hablar de la ley de privacidad de California, ni de la de Canadá, ni de la de Brasil. Es natural: conoces las reglas de donde trabajas. Pero estas leyes cruzan fronteras, y dan forma al diseño de los sistemas aunque ninguna trate de Salesforce. Por eso pertenecen a un curso de arquitectura de datos.

No necesitas convertirte en abogado. Sí necesitas ver que una regulación puede cambiar dónde se guardan los datos, qué recopilas, quién los ve, para qué puedes usarlos, cuánto tiempo los conservas, adónde los envías, si puedes eliminarlos, qué historial guardas y qué puedes demostrar después. No son solo preguntas legales. Son preguntas de arquitectura de datos.

Este módulo es orientación de arquitectura, no asesoramiento legal. Los equipos legales y de cumplimiento deciden qué leyes aplican y qué exigen. El arquitecto convierte esos requisitos en un diseño que se puede hacer cumplir.

Las leyes no se detienen en la frontera

Primero, el mayor malentendido: “no estamos en Europa, así que el GDPR no aplica”. Quizá sí, quizá no. El ámbito territorial del GDPR alcanza a organizaciones de fuera de la UE que ofrecen bienes o servicios a personas en la UE, o que controlan su comportamiento allí (artículo 3 del Reglamento (UE) 2016/679 (opens in a new tab)). Así que dónde tiene su sede tu empresa no es el final de la pregunta. ¿Dónde están tus clientes, tus empleados, las personas cuyos datos guardas, tus sistemas, tus encargados del tratamiento? ¿Por dónde viajan los datos? Es otra vez el panorama del capítulo 4. No puedes tomar buenas decisiones de privacidad sin saber adónde van los datos.

Las regulaciones que deberías reconocer

Estos son los nombres que un arquitecto debería conocer, con lo que cubre cada uno. Es una tabla para reconocerlas, no una matriz de aplicabilidad: no la leas y decidas “tenemos clientes en California, así que aplica el requisito X”. Esa decisión es del área legal. Tu trabajo es saber lo suficiente para hacer la pregunta antes de construir el sistema.

Ley o estándar	Dónde o qué	Por qué un arquitecto debería reconocerla
GDPR (RGPD) (opens in a new tab)	Unión Europea	Datos personales, tratamiento lícito, derechos de las personas, retención, transferencias, privacidad desde el diseño
CCPA, modificada por la CPRA (opens in a new tab)	California	Los derechos de los consumidores sobre la información personal que las empresas recopilan sobre ellos
PIPEDA (opens in a new tab)	Canadá	Cómo tratan la información personal las organizaciones del sector privado
LGPD (opens in a new tab)	Brasil	La ley general de protección de datos personales de Brasil
Privacy Act 1988 (opens in a new tab)	Australia	Cómo tratan la información personal las organizaciones, según los Australian Privacy Principles
HIPAA (opens in a new tab)	Sanidad en EE. UU.	La información de salud protegida en los contextos cubiertos
PCI DSS (opens in a new tab)	Tarjetas de pago	La protección de los datos de las cuentas de tarjetas de pago
Sarbanes-Oxley (SOX) (opens in a new tab)	Empresas cotizadas en EE. UU.	Los controles y la evidencia detrás de la información financiera
COPPA (opens in a new tab)	EE. UU., menores en línea	La información personal recopilada en línea de menores

La lista crece (más estados de EE. UU. tienen sus propias leyes), y las leyes cambian. Por eso no quiero que memorices una tabla y creas que aprendiste arquitectura de privacidad. Aprende los nombres, y luego aprende las preguntas que los sobreviven.

Lo que las leyes tienen en común

Los detalles cambian, pero las grandes leyes de privacidad vuelven una y otra vez a las mismas pocas cosas, y cada una cae sobre la arquitectura.

Derechos. Las personas pueden pedir ver sus datos, corregirlos, borrarlos y llevárselos; con las leyes de California y de Brasil también pueden negarse a que se vendan. Cada una de esas solicitudes significa encontrar los datos de la persona, todos.

Transferencias. El RGPD y la LGPD controlan los datos personales que salen de su jurisdicción y piden una protección adecuada allí adonde van; PIPEDA espera el mismo nivel de protección cuando un tercero trata los datos, esté donde esté. Es el panorama otra vez: ¿qué flechas cruzan una frontera?

Notificación de brechas. Cuando se exponen datos personales, las leyes esperan que avises a las autoridades, y a veces a las personas afectadas, dentro de un plazo que varía según la ley. No puedes notificar sobre datos que no sabías que tenías, ni decir qué se expuso si no encuentras las copias.

Responsabilidad proactiva. Tienes que poder demostrar el cumplimiento: registros de lo que tratas y por qué, evaluaciones de impacto para los tratamientos de alto riesgo y, con el RGPD y la LGPD, un delegado de protección de datos. La arquitectura tiene que producir esos registros.

Empieza por lo que es personal

Antes de proteger la información personal, encuéntrala. Una parte es obvia: el nombre, la dirección de casa, el teléfono, el correo electrónico. Otra no lo es: la ubicación, los identificadores de dispositivos, las direcciones IP, las imágenes, los datos de comportamiento, cualquier cosa que pueda vincularse con una persona. Y el contexto importa. Una entrega de Steve Trucking lleva el nombre, la dirección, el número de teléfono, las notas de entrega y las fotos del destinatario. Una foto puede mostrar una caja en un porche, o una persona, o el interior de una casa. La entrega son datos operativos, pero algunos de sus atributos son personales. Por eso el módulo 3 clasificó los campos: la privacidad empieza por saber qué guardas.

¿Dónde viven?

“En Salesforce”. Probablemente no solo en Salesforce. ¿Vinieron de un socio minorista? ¿Se copiaron a Snowflake, los ingirió Data 360, se escribieron en un log de integración, los exportó un usuario, quedaron en el historial de campos, se archivaron, se copiaron a un sandbox, se pasaron a un socio, se usaron en la conversación de un agente? Los datos personales se esparcen. Así que cuando el área legal pregunta “¿dónde guardamos la información de esta persona?”, “sabemos dónde está el valor actual” no es una respuesta. Quiero el panorama y el linaje: adónde fueron las copias.

Click to enlarge

Un número de teléfono, muchas copias. La privacidad también se aplica a las copias.

¿Por qué se te permite usarlos?

Tener datos y tener permiso para usarlos no es lo mismo. Steve Trucking tiene el número de teléfono de un destinatario para coordinar la entrega de hoy. ¿Eso lo convierte en una lista de marketing? No. La base legal depende de la jurisdicción y de la situación, y eso lo orienta el área legal, pero la arquitectura tiene que llevar la respuesta: por qué se recopilaron, qué uso se autorizó, si hacía falta consentimiento, si se dio, si se retiró, y para qué canal, qué dirección y qué propósito. El permiso para usar los datos tiene que poder representarse como datos, porque un documento de política no puede tomar una decisión en tiempo de ejecución. El próximo módulo lo modela.

Recopilar menos es una decisión de arquitectura

Uno de los controles de privacidad más fuertes es no recopilar los datos, o no copiarlos donde no hacen falta. ¿Necesita Snowflake el número de teléfono del destinatario? ¿Necesita la analítica la dirección completa? ¿Necesita el sandbox fotos reales de las entregas? ¿Necesita un agente los datos personales del destinatario para responder esta pregunta? Si no, el control más fuerte puede ser no ponerlos ahí. Cada copia que no haces es una que no tienes que proteger, conservar, eliminar, seguir en cuanto al consentimiento, auditar ni declarar en una brecha de seguridad. Los datos sensibles más baratos de gobernar son los que nunca copiaste.

La retención es parte del modelo

“Por ahora lo guardaremos todo” es una política de retención. Solo que es mala. Para los datos importantes quiero saber en el momento del diseño cuánto tiempo los necesitamos y por qué; si una regulación fija un mínimo u otra fija un máximo; cuándo empieza a correr el reloj; y qué pasa al final: eliminar, archivar, desidentificar, y ¿dónde están las copias? Los registros financieros pueden tener que conservarse durante un período fijado. El código del portón de un destinatario no tiene ningún propósito años después de la entrega. Esas decisiones no esperan a que la base de datos sea grande.

Anonimizado, seudonimizado, cifrado, enmascarado

Reemplaza “Jane Smith” por 7F92A1. ¿Está anonimizada Jane? No si otra tabla sigue diciendo 7F92A1 = Jane Smith. Eso es seudonimización: el identificador directo se reemplaza, pero los datos pueden volver a vincularse usando información que se guarda aparte, y según el GDPR los datos seudonimizados siguen siendo datos personales (artículo 4, punto 5). La anonimización va más allá: los datos ya no pueden vincularse razonablemente con la persona (considerando 26). Así que cuando alguien dice “no hace falta eliminarlo, solo quitaremos el nombre”, ten cuidado. Si la persona todavía puede identificarse razonablemente, no has cruzado esa línea. Si un resultado cumple la ley lo decide el área legal; el trabajo del arquitecto es decir exactamente qué hace el sistema: ¿se puede volver a vincular, qué claves quedan, dónde están los mapeos?

Usa las palabras con precisión, porque resuelven problemas distintos. El cifrado protege los datos de la divulgación no autorizada; un usuario autorizado todavía puede descifrarlos. El enmascaramiento cambia lo que ven determinados usuarios o entornos. La seudonimización separa la identidad directa pero conserva un camino de vuelta. La anonimización elimina la capacidad razonable de identificar a la persona. Solo la última saca los datos de la categoría de “personales”.

La regulación se convierte en requisitos

El área legal no necesita decirme que cree un conjunto de permisos; ese es mi lado de la línea. El área legal podría decir “solo los empleados con una necesidad legítima de negocio pueden acceder a esta categoría de información personal”. Entonces traduzco: ¿quiénes son, cómo identificamos la categoría, cómo se concede el acceso, qué pasa cuando alguien cambia de puesto, puede leerla una integración, puede leerla un agente, puede exportarse, y cómo demostramos quién la vio? Los dueños fijan la política; los arquitectos la hacen cumplir. El área legal y la de cumplimiento establecen la obligación, los dueños de los datos fijan la política de negocio, y el arquitecto diseña el cumplimiento.

Click to enlarge

De la regulación a la evidencia: Legal interpreta, el dueño fija la política, el arquitecto hace que funcione y que se pueda demostrar.

Y el cumplimiento no es un producto. No puedes comprar “cumplimiento: activado”. El cifrado puede apoyar un requisito, las funciones de auditoría aportan evidencia, las herramientas de retención ejecutan la política, los datos de consentimiento sostienen el uso permitido, pero licenciar una función no hace que una arquitectura cumpla. El cumplimiento viene del diseño completo: personas, políticas, procesos, datos, controles y evidencia. Salesforce es parte de él, no todo. Y si una política importa lo suficiente para hacerla cumplir, pregunta si importa lo suficiente para demostrarla: ¿quién accedió a este registro el 17 de marzo, quién cambió este campo, qué contenía esa exportación? El módulo 6 cubre la evidencia.

La privacidad cambia el panorama

En Steve Trucking, los datos personales del destinatario llegan a través de tres integraciones con socios. Salesforce los necesita para hacer las entregas; los equipos necesitan una parte, solo para sus propias paradas, solo ese día; Snowflake quiere analítica de las entregas; finanzas necesita lo suficiente para facturar, pero no lo que ve el equipo. Y un socio minorista nunca debe ver a los destinatarios de otro. La privacidad cambia las flechas: ciertos campos no van a Snowflake, la analítica recibe una versión menos identificable, los equipos ven solo sus paradas, la retención posterior es distinta de la operativa. El requisito de privacidad no se queda al lado del diagrama del panorama. Lo cambia.

Preguntas que sobreviven a las regulaciones

Las regulaciones cambian, así que lleva contigo un conjunto duradero de preguntas para cualquier dato sensible o regulado:

• ¿Qué es? ¿Datos personales, sensibles, financieros, de salud, de pago, de menores o regulados de otra forma?
• ¿Dónde vive? Cada copia: integraciones, historial, analítica, archivos, sandboxes, logs, uso por la IA.
• ¿Por qué podemos usarlo? ¿Qué propósito y qué base legal aplican? ¿Interviene el consentimiento?
• ¿Quién puede usarlo? Personas, sistemas, socios, integraciones, agentes.
• ¿Cuánto tiempo lo conservamos, y qué pasa al final?
• ¿Puede la persona ejercer sus derechos sobre él? Acceso, rectificación, supresión, portabilidad, oposición, según lo que disponga la ley.
• ¿Podemos demostrar lo que pasó? Accesos, cambios, exportaciones, consentimiento, eliminación, retención.

El gobierno de la IA se está convirtiendo en ley

La IA agrega otro consumidor de datos gobernados. ¿Puede un sistema de IA usar estos datos, para qué propósito, como base (grounding), combinados con qué, repetidos en su resultado, registrados dónde, durante cuánto tiempo? El gobierno de la IA está pasando de la política de la empresa a la ley: el Reglamento de Inteligencia Artificial de la Unión Europea (Reglamento (UE) 2024/1689 (opens in a new tab)) es el primer ejemplo amplio. Lo que exige depende del sistema y del uso. La dirección para los arquitectos está clara: la IA no queda fuera del gobierno de datos; es otro consumidor de datos gobernados.

Lo que decide aquí un arquitecto

• Dónde entran, viven, se mueven y se copian los datos regulados o sensibles en todo el panorama.
• Cómo la política legal y de cumplimiento se convierte en requisitos que se pueden hacer cumplir, sin que el arquitecto interprete la ley.
• Si cada sistema que recibe datos sensibles los necesita, o bastaría con una versión menos identificable.
• Cómo la retención, la eliminación, la anonimización, la seudonimización, la protección y la evidencia dan forma al ciclo de vida de los datos.
• Qué evidencia tiene que existir para mostrar que los controles importantes funcionaron de verdad.

Las regulaciones no se convierten en arquitectura por poner sus nombres en una diapositiva. Se convierten en arquitectura cuando cambian cómo se recopilan, se clasifican, se mueven, se protegen, se conservan, se eliminan y se demuestran los datos.

Explora

• Las fuentes oficiales de las regulaciones están enlazadas en la tabla de arriba, consultadas el 2026-10-14.
• Reglamento (UE) 2016/679 (GDPR/RGPD) (opens in a new tab): artículo 3 (ámbito territorial), artículo 4, punto 5 (seudonimización), considerando 26 (información anónima).
• Reglamento (UE) 2024/1689 (Reglamento de Inteligencia Artificial) (opens in a new tab), EUR-Lex.