Privacidad desde el Diseño: Guía Práctica para Implementarla conforme a la Ley 21.719

La mayoría de las organizaciones trata la privacidad como una corrección tardía — un ajuste hecho después de que el sistema ya está en producción, el formulario ya recopila datos innecesarios y el proceso de RRHH ya comparte información personal con más departamentos de lo que debería. Este enfoque reactivo no solo es ineficiente: es exactamente lo opuesto de lo que exige la Ley 21.719.

El Art. 14 quáter de la Ley 21.719 establece el deber de protección desde el diseño y por defecto: los responsables del tratamiento deben implementar medidas técnicas y organizativas apropiadas desde la fase de concepción del sistema o proceso, con el fin de garantizar los principios de protección de datos y los derechos de los titulares. No es una recomendación — es una obligación legal.

Esta guía traduce el concepto de Privacy by Design en acciones concretas: desde los principios fundacionales hasta checklists aplicables a software, procesos de negocio y contratación de proveedores.

---

Qué es Privacy by Design

Privacy by Design (PbD) — o Privacidad desde el Diseño — es un enfoque que incorpora la protección de datos personales directamente en la arquitectura de sistemas, procesos y prácticas organizacionales, desde el inicio del proyecto. No se trata de añadir privacidad después, como una capa de barniz: se trata de hacerla parte estructural de lo que se está construyendo.

El concepto fue formalizado en 2009 por la Dra. Ann Cavoukian, entonces Comisionada de Información y Privacidad de Ontario, Canadá. En 2010, fue adoptado como resolución por la Asamblea Internacional de Comisionados de Protección de Datos y Privacidad. En 2023, obtuvo un estándar internacional con la publicación de la ISO 31700-1:2023 — Consumer protection — Privacy by design for consumer goods and services —, que establece 30 requisitos de alto nivel para incorporar privacidad en productos y servicios.

En Chile, el concepto está positivado en los Arts. 14 quáter y 14 quinquies de la Ley 21.719, reforzados por el principio de responsabilidad proactiva del Art. 3°(e).

El fundamento legal: Arts. 14 quáter y 14 quinquies

Art. 14 quáter — Deber de protección desde el diseño y por defecto

El Art. 14 quáter establece la obligación de los responsables del tratamiento de implementar, desde la fase de concepción del sistema o proceso:

• Medidas técnicas apropiadas para garantizar los principios de protección de datos
• Medidas organizativas que aseguren que, por defecto, solo se traten los datos necesarios para cada finalidad
• Configuraciones de privacidad que sean las más protectoras como estándar

Tres puntos merecen atención:

1. "Desde la fase de concepción" — la protección no comienza en la implementación, sino en la planificación. Cuando el equipo está diseñando flujos, definiendo requisitos o elaborando wireframes, la privacidad ya debe estar en la mesa.

2. "Por defecto" — no basta proyectar con privacidad; es necesario garantizar que la configuración inicial del sistema sea la más restrictiva posible en términos de privacidad.

3. "Medidas técnicas y organizativas" — PbD no se limita a cifrado y controles de acceso. Incluye medidas organizacionales: políticas, capacitaciones, procesos de aprobación, revisiones periódicas.

Art. 14 quinquies — Deber de adoptar medidas de seguridad

El Art. 14 quinquies complementa con la obligación de adoptar medidas de seguridad adecuadas frente a tratamientos no autorizados, pérdida, filtración, destrucción o daño accidental, considerando el estado del arte, los costos y la naturaleza de los riesgos.

El incumplimiento de estos artículos puede fundamentar sanciones de la APDP, incluyendo multas de hasta 20.000 UTM (aproximadamente USD 1.400.000) para infracciones gravísimas.

---

Los 7 principios fundacionales de Privacy by Design

Ann Cavoukian definió siete principios que sustentan el enfoque de Privacy by Design. A continuación, cada principio se presenta con su definición original y traducido al contexto práctico de la Ley 21.719.

1. Proactivo, no reactivo — Preventivo, no correctivo

Definición original: "The Privacy by Design approach anticipates and prevents privacy invasive events before they happen."

En la práctica: Realizar una evaluación de impacto antes de lanzar un nuevo sistema, no después del primer incidente. Incluir el análisis de privacidad en el kickoff de proyectos, no en la homologación. Elaborar la EIPD al inicio del proyecto, cuando aún es posible modificar la arquitectura sin costos elevados.

2. Privacidad como configuración predeterminada

Definición original: "Personal data must be automatically protected in any system or process. No user intervention is required to safeguard personal information."

En la práctica: Los campos opcionales en formularios deben ser efectivamente opcionales — no pre-marcados. El intercambio de datos debe comenzar desactivado. Las cookies no esenciales deben requerir opt-in explícito, no opt-out. La configuración más restrictiva de privacidad debe ser la predeterminada.

3. Privacidad incorporada al diseño

Definición original: "Privacy is embedded into the design and architecture of IT systems and business practices. It is not bolted on as an add-on, after the fact."

En la práctica: La minimización de datos debe definirse en el modelado de la base de datos, no mediante un filtro posterior. Los controles de acceso granulares deben ser parte de la arquitectura del sistema, no de una política escrita que nadie implementa. La anonimización debe pensarse en el diseño del data warehouse, no aplicarse retroactivamente.

4. Funcionalidad total — Suma positiva, no suma cero

Definición original: "Privacy by Design seeks to accommodate all legitimate interests and objectives in a positive-sum 'win-win' manner."

En la práctica: Un sistema de analítica puede proporcionar insights de negocio sin rastrear usuarios individualmente. Un CRM puede personalizar la atención sin almacenar datos excesivos. La privacidad y la funcionalidad no son opuestos — diseñar con PbD frecuentemente resulta en sistemas más eficientes.

5. Seguridad de extremo a extremo — Protección durante todo el ciclo de vida

Definición original: "Privacy by Design extends securely throughout the entire lifecycle of the data involved."

En la práctica: Los datos deben protegerse desde la recopilación hasta el descarte. Esto incluye cifrado en tránsito y en reposo, políticas de retención con plazos definidos, procedimientos de descarte seguro e inventario completo de los datos personales en todo el ciclo. Los datos que cumplieron su finalidad deben eliminarse — no "guardarse por precaución".

6. Visibilidad y transparencia — Mantener abierto

Definición original: "Privacy by Design seeks to assure all stakeholders that whatever the business practice or technology involved, it is in fact operating according to the stated promises and objectives."

En la práctica: Las prácticas de tratamiento de datos deben ser verificables. Esto significa políticas de privacidad claras y precisas (no genéricas), registros de actividades auditables, logs que permitan rastrear quién accedió a qué datos y auditorías periódicas de privacidad que validen el cumplimiento real.

7. Respeto por la privacidad del usuario — Centrado en el titular

Definición original: "Privacy by Design requires architects and operators to keep the interests of the individual uppermost by offering such measures as strong privacy defaults, appropriate notice, and empowering user-friendly options."

En la práctica: El titular debe tener control efectivo sobre sus datos. Los mecanismos de consentimiento deben ser claros y granulares. Los canales para el ejercicio de derechos (acceso, rectificación, supresión) deben ser de fácil acceso y funcionar de verdad — no un correo que nadie responde.

---

Privacy by Design vs. Privacy by Default

Los dos conceptos son complementarios, pero distintos:

Privacy by Design es el enfoque macro: incorporar privacidad en la arquitectura del sistema, en el proceso de negocio, en la decisión tecnológica. Se trata de cómo el sistema es diseñado.

Privacy by Default es uno de los resultados del Privacy by Design: las configuraciones iniciales del sistema deben proteger la privacidad del titular sin que él necesite hacer nada. Se trata de cómo el sistema se comporta cuando nadie modifica las configuraciones.

Aspecto	Privacy by Design	Privacy by Default
Alcance	Todo el proyecto (arquitectura, procesos, tecnología)	Configuraciones iniciales del producto/servicio
Cuándo	Desde la concepción hasta el descarte	En el momento de la entrega/lanzamiento
Ejemplo	Diseñar un CRM que no almacena RUT innecesariamente	El CRM, al ser instalado, ya viene con perfil de visibilidad restringido
Ley 21.719	Art. 14 quáter (diseño)	Art. 14 quáter (por defecto) + principio de proporcionalidad Art. 3°(c)

Analogía: Privacy by Design es el proyecto arquitectónico de un edificio seguro. Privacy by Default es la puerta que ya viene con llave.

---

PbD en el ciclo de desarrollo de software

La implementación de PbD en software exige que la privacidad participe en cada etapa del ciclo de desarrollo — no solo en la etapa de seguridad.

Fase 1: Requisitos

• Identificar qué datos personales tratará el sistema y con qué bases jurídicas
• Definir finalidades específicas para cada dato recopilado
• Documentar el principio de proporcionalidad: listar cada campo y justificar su necesidad
• Clasificar datos por sensibilidad (dato personal, sensible, de menor)
• Evaluar si es necesaria una EIPD para el tratamiento propuesto

Fase 2: Diseño / Arquitectura

• Modelar la base de datos con solo los campos estrictamente necesarios
• Definir períodos de retención por categoría de dato
• Diseñar controles de acceso basados en roles (RBAC) o atributos (ABAC)
• Establecer segregación de ambientes (desarrollo, homologación, producción)
• Planificar seudonimización o anonimización donde sea aplicable
• Incluir mecanismos de consentimiento granular, si la base jurídica es el consentimiento

Fase 3: Implementación

• Cifrado en tránsito (TLS) y en reposo para datos sensibles
• Validación de entradas para prevenir inyección de datos maliciosos
• Registro de acceso a datos personales (quién, cuándo, qué dato, qué acción)
• Tratamiento de errores que no exponga datos personales en mensajes de error o stack traces
• Separación de datos personales de datos de telemetría/analítica

Fase 4: Pruebas

• Pruebas de seguridad (SAST, DAST) con foco en exposición de datos personales
• Verificación de que los datos de prueba no contienen datos personales reales
• Validación de que los controles de acceso funcionan según lo proyectado
• Prueba de flujos de eliminación y anonimización
• Validación de que los logs no registran datos personales innecesarios

Fase 5: Despliegue y Operación

• Configuraciones predeterminadas con máxima privacidad (privacy by default)
• Monitoreo de accesos anómalos a datos personales
• Procedimiento de respuesta a incidentes documentado y probado
• Revisión periódica de permisos de acceso
• Proceso de descarte seguro al final del ciclo de vida

---

PbD en procesos de negocio

Privacy by Design no es exclusivo del área de TI. Los procesos de negocio que tratan datos personales — y prácticamente todos lo hacen — deben incorporar privacidad desde su concepción.

RRHH y Gestión de Personas

• Reclutamiento: Definir qué datos se recopilan en cada etapa del proceso. No solicitar datos sensibles (ej.: foto, estado civil, religión) que no sean necesarios para el cargo. Establecer plazo de retención para currículos de candidatos no seleccionados.
• Incorporación: Recopilar solo los datos necesarios para el registro del trabajador. Separar datos laborales (obligatorios por ley) de datos complementarios (opcionales). Informar las finalidades de cada dato recopilado.
• Desvinculación: Definir qué datos del ex-trabajador serán retenidos (obligaciones laborales y previsionales) y por cuánto tiempo. Eliminar accesos a sistemas inmediatamente. Remover datos de sistemas que no tienen base jurídica para retención.

Marketing y Comunicación

• Campañas: Segmentar con base en datos agregados, no en perfiles individuales detallados. Obtener consentimiento específico para cada canal (correo, SMS, WhatsApp). Facilitar la baja en toda comunicación.
• CRM: Implementar campos de consentimiento granular (marketing, newsletters, encuestas). Configurar expiración automática de consentimientos no renovados. Registrar el origen y la fecha de cada consentimiento obtenido.
• Analítica: Preferir métricas agregadas. Configurar anonimización de IPs. Evaluar si la analítica server-side reduce la recopilación de datos personales sin perder insights relevantes.

Ventas y Atención al Cliente

• Propuestas comerciales: Recopilar solo los datos necesarios para la elaboración de la propuesta — no para alimentar el CRM con información que el prospecto no autorizó.
• Atención al cliente: Implementar verificación de identidad proporcional al riesgo. Registrar solo lo necesario en el historial de atención. Restringir el acceso a datos financieros del cliente a quien efectivamente lo necesita.

---

PbD en procurement y contratación de proveedores

La decisión de contratar a un proveedor que trata datos personales es, en sí misma, una decisión de privacidad. Privacy by Design aplicado a procurement significa evaluar la privacidad antes de la contratación, no después.

Checklist PbD para evaluación de proveedores

1. ¿El proveedor recopila solo los datos necesarios para prestar el servicio contratado?
2. ¿Dónde se almacenarán los datos? Si es fuera de Chile, ¿hay garantías adecuadas para la transferencia internacional?
3. ¿El proveedor tiene política de retención con plazos definidos y descarte seguro?
4. ¿Existe cláusula contractual que limite el uso de los datos a la finalidad contratada?
5. ¿El proveedor notifica incidentes de seguridad en un plazo compatible con las exigencias de la Ley 21.719?
6. ¿El proveedor permite auditoría de las prácticas de protección de datos?
7. ¿Hay subencargados? Si es así, ¿la cadena de responsabilidad está documentada?

Estas preguntas deben ser parte del proceso de homologación de proveedores, no un análisis posterior a la contratación.

---

Ejemplos concretos de aplicación

Ejemplo 1: Formulario web de registro

Sin PbD:

• Formulario con 25 campos, incluyendo RUT, fecha de nacimiento, género, ingresos mensuales — para un simple registro de newsletter
• Todos los campos obligatorios
• Checkbox de consentimiento pre-marcado
• Datos almacenados indefinidamente
• Sin política de privacidad vinculada

Con PbD:

• Formulario con 3 campos: nombre, correo y área de interés (para segmentación de contenido)
• Solo el correo es obligatorio
• Checkbox de consentimiento desmarcado por defecto, con enlace a la política de privacidad
• Datos retenidos por 24 meses o hasta revocación del consentimiento
• Mecanismo de baja en todo correo enviado
• Registro de la fecha, hora y forma de obtención del consentimiento

Ejemplo 2: Aplicación móvil

Sin PbD:

• App solicita acceso a cámara, micrófono, contactos, ubicación y almacenamiento en la instalación — aunque solo use la cámara
• Analítica envía datos personales a servidor externo sin consentimiento
• Datos permanecen en el dispositivo tras la desinstalación
• Sin opción de eliminación de cuenta

Con PbD:

• App solicita cada permiso solo en el momento de uso de la funcionalidad correspondiente
• Analítica usa identificadores anónimos; los datos personales permanecen en el dispositivo
• La desinstalación activa la limpieza de datos locales
• Opción de eliminación de cuenta accesible en máximo 2 toques
• Cifrado local para datos sensibles almacenados en el dispositivo

Ejemplo 3: Sistema interno de gestión

Sin PbD:

• Todos los usuarios ven todos los datos de todos los clientes
• Los logs registran datos personales completos (nombre, RUT, dirección)
• Datos de clientes inactivos retenidos indefinidamente
• Exportación de datos sin restricción ni registro

Con PbD:

• RBAC con perfiles granulares: atención ve datos de contacto, finanzas ve datos de facturación, gerencia ve indicadores agregados
• Los logs registran identificadores internos, no datos personales
• Política de retención automática: clientes inactivos por más de 5 años tienen datos anonimizados
• La exportación de datos personales requiere justificación, aprobación y genera registro de auditoría

---

Framework de evaluación PbD: 10 preguntas

Use estas 10 preguntas para evaluar si Privacy by Design fue efectivamente aplicado en un proyecto, sistema o proceso. Cada pregunta puede responderse con "Sí", "Parcialmente" o "No" — el objetivo es identificar brechas antes de que se conviertan en problemas.

Minimización y finalidad

1. ¿Cada dato personal recopilado tiene una finalidad documentada y una base jurídica identificada? Si no es posible justificar por qué se recopila ese dato, no debería recopilarse.

2. ¿El sistema recopila solo los datos estrictamente necesarios para las finalidades declaradas? Los campos "bueno tenerlos" o "puede ser útil en el futuro" violan el principio de proporcionalidad.

Configuraciones y estándares

3. ¿Las configuraciones predeterminadas del sistema son las más restrictivas posibles en términos de privacidad? El intercambio, la visibilidad y la recopilación deben comenzar en el mínimo — no en el máximo.

4. ¿El consentimiento, cuando aplica, se obtiene de forma activa, específica y registrada? Los checkboxes pre-marcados, consentimientos genéricos o agrupados no cumplen con la Ley 21.719.

Seguridad y ciclo de vida

5. ¿Los datos están protegidos en tránsito y en reposo con medidas proporcionales al riesgo? Cifrado, controles de acceso, segmentación de red, backup seguro.

6. ¿Existen plazos de retención definidos y mecanismos de descarte seguro implementados? La retención indefinida sin base jurídica viola el principio de proporcionalidad (Art. 3°(c) Ley 21.719).

Transparencia y derechos

7. ¿El titular puede entender cómo se tratan sus datos con la información disponible? Política de privacidad en lenguaje accesible, avisos contextuales, transparencia real.

8. ¿Los derechos de los titulares (acceso, rectificación, supresión, portabilidad) pueden ejercerse de forma efectiva? Canal funcional, plazo de respuesta definido (30 días hábiles), proceso documentado.

Gobernanza y documentación

9. ¿Las decisiones de privacidad están documentadas y son auditables? Registro de evaluaciones de impacto, decisiones de diseño, justificativas de bases jurídicas.

10. ¿Existe un responsable designado y un proceso de revisión periódica de las medidas de privacidad? PbD no es un evento, es un proceso continuo que requiere gobernanza permanente.

Cómo usar el framework

• 0–3 "Sí": La privacidad no está incorporada al proyecto. Acción correctiva urgente.
• 4–6 "Sí": Fundamentos básicos presentes, pero brechas significativas. Plan de acción necesario.
• 7–8 "Sí": Buen nivel de madurez. Enfocar en las brechas restantes.
• 9–10 "Sí": Excelente. Mantener monitoreo y revisión periódica.

---

Cómo documentar que PbD fue aplicado

Documentar la aplicación de Privacy by Design es tan importante como aplicarlo. En caso de fiscalización por la APDP o de un incidente de seguridad, la documentación demuestra que la organización adoptó una postura preventiva — lo que puede ser atenuante en la dosimetría de eventual sanción.

Documentos esenciales

1. Registro de Evaluación de Privacidad Para cada nuevo proyecto, sistema o proceso que trate datos personales, documentar:

• Datos personales involucrados y sus finalidades
• Bases jurídicas aplicables
• Medidas de seguridad adoptadas
• Decisiones de diseño que priorizaron privacidad
• Riesgos identificados y cómo fueron mitigados

2. Evaluación de Impacto en la Protección de Datos (EIPD) Obligatoria cuando el tratamiento puede generar riesgos elevados para los titulares (Art. 15 ter Ley 21.719). Debe reflejar las decisiones de PbD y demostrar que se consideraron alternativas menos intrusivas.

3. Registro de Actividades de Tratamiento El inventario de datos personales es la base documental del PbD. Sin saber qué datos existen, dónde están y por qué se tratan, es imposible aplicar privacidad desde la concepción.

4. Actas de decisión y evidencias de proceso Registros de reuniones donde se discutió privacidad, correos con aprobaciones del DPD, checklists de evaluación completados, revisiones de código con foco en privacidad. Evidencias de que la privacidad fue considerada — no solo declarada.

---

La ISO 31700 y el futuro del PbD

La publicación de la ISO 31700-1:2023 marcó un avance significativo: por primera vez, existe un estándar internacional dedicado exclusivamente a Privacy by Design. El estándar establece 30 requisitos de alto nivel organizados en tres ejes:

1. Empoderamiento y transparencia: garantizar que los consumidores comprendan y controlen cómo se tratan sus datos.
2. Institucionalización y responsabilidad: crear estructuras organizacionales que soporten PbD de forma sostenible.
3. Ecosistema y ciclo de vida: considerar privacidad en toda la cadena de valor y durante todo el ciclo de vida del dato.

La ISO 31700 puede servir como referencia técnica para organizaciones que deseen ir más allá del mínimo legal. La conformidad con la ISO 31700 no sustituye la conformidad con la Ley 21.719 — y viceversa —, pero se complementan.

---

Próximos pasos para implementar PbD

Privacy by Design no es un proyecto con fecha de conclusión — es un cambio de mentalidad que se incorpora gradualmente a la cultura organizacional. Para comenzar:

1. Realice un inventario de datos personales para entender el estado actual del tratamiento en la organización.
2. Aplique el framework de 10 preguntas a los sistemas y procesos más críticos.
3. Incorpore la evaluación de privacidad al proceso de aprobación de nuevos proyectos y proveedores.
4. Capacite a los equipos — desarrolladores, product managers, RRHH, marketing — para que la privacidad sea responsabilidad compartida, no exclusiva del DPD.
5. Documente todo: decisiones, evaluaciones, justificativas. La documentación es la prueba de que PbD fue aplicado.

Los Arts. 14 quáter y 14 quinquies de la Ley 21.719 no dejan margen para interpretación: la protección de datos comienza en la concepción. Las organizaciones que adoptan Privacy by Design no solo cumplen la ley — construyen productos y procesos más eficientes, más confiables y más respetuosos con las personas cuyos datos tratan.

---

Confidata ayuda a las organizaciones a incorporar privacidad desde la concepción en cada proceso y sistema. De la evaluación de madurez al inventario automatizado de datos personales, ofrecemos las herramientas que transforman Privacy by Design de concepto en práctica documentada. Conozca la plataforma.