Privacidad desde el diseño en la Ley 21.719: qué exige el artículo 14 quater y cómo se aplica

Durante años, la privacidad desde el diseño se enseñó en Chile como una buena práctica: algo que los equipos maduros hacían y el resto postergaba. La Ley 21.719 cambia esa conversación. Su artículo 14 quater convierte la protección desde el diseño y por defecto en un deber del responsable, con criterios explícitos para evaluarlo. Y como la ley entrará en vigencia el 1 de diciembre de 2026, las decisiones de arquitectura que tu equipo está tomando ahora son exactamente las que quedarán bajo escrutinio. Si quieres el panorama completo, parte por nuestra guía sobre la ley de protección de datos en Chile.

Este artículo está escrito para quienes toman esas decisiones: equipos de producto y desarrollo, arquitectos de software, TI, delegados de protección de datos y gerencias de innovación. No es un resumen legal exhaustivo ni sustituye una asesoría para tu caso concreto. Es una traducción del texto del artículo 14 quater a decisiones concretas de formularios, integraciones, configuraciones por defecto, analítica y retención, con ejemplos de antes y después.

¿Qué es la privacidad desde el diseño y por defecto en la Ley 21.719?

Es un deber legal del responsable, establecido en el artículo 14 quater de la Ley 21.719 de Chile, que obliga a incorporar la protección de datos en la construcción misma de un producto, sistema o proceso, y no como una capa añadida al final. La norma tiene dos partes: cómo diseñas y cuánto tratas por defecto.

La distinción importa porque cambia el momento en que interviene la protección de datos dentro de la organización. Bajo el enfoque tradicional, el área legal o el delegado revisaban un sistema ya construido y pedían ajustes cosméticos: agregar un aviso, corregir un texto de consentimiento, pedir una casilla más. El artículo 14 quater desplaza esa conversación hacia atrás en el tiempo, al momento en que se decide qué campos tendrá un formulario, qué tabla guardará qué información, qué eventos enviará el frontend a la herramienta de analítica y cuánto tiempo vivirá cada registro.

Conviene ser claro sobre el estatus normativo: en Chile esto no será una guía de buenas prácticas ni un estándar voluntario de industria. Es un deber del responsable, ubicado en el mismo bloque de obligaciones que el deber de secreto o confidencialidad (artículo 14 bis), el deber de información y transparencia (artículo 14 ter) y el deber de adoptar medidas de seguridad (artículo 14 quinquies). Que la Ley 21.719 entre en vigencia recién el 1 de diciembre de 2026 no lo hace menos relevante hoy: significa que el plazo para incorporarlo al ciclo de desarrollo es ahora, porque los sistemas que estarán operando ese día son los que hoy se están diseñando.

• Desde el diseño: medidas técnicas y organizativas adecuadas, con anterioridad y durante el tratamiento.
• Por defecto: solo los datos específicos y estrictamente necesarios para la finalidad.
• Estatus: deber legal del responsable en la Ley 21.719, no una recomendación voluntaria.
• Destinatario real: quien decide la arquitectura, no solo quien redacta la política de privacidad.

¿Qué exige exactamente el artículo 14 quater y cuáles son sus dos obligaciones?

El artículo 14 quater de la Ley 21.719 contiene dos obligaciones que suelen leerse como una sola y que conviene separar. La primera exige al responsable aplicar medidas técnicas y organizativas adecuadas desde el diseño, con anterioridad y durante el tratamiento. La segunda exige garantizar que, por defecto, solo se traten los datos específicos y estrictamente necesarios.

La primera obligación —la protección desde el diseño— tiene tres componentes que vale la pena leer con atención. Habla de medidas técnicas, es decir, controles que viven en el código y la infraestructura: seudonimización, cifrado, segregación de ambientes, control de acceso granular. El texto legal no enumera esos controles uno por uno; son ejemplos habituales de la práctica, no una lista impuesta por la ley. Habla también de medidas organizativas, que viven en cómo trabaja la gente: quién aprueba un nuevo campo de datos, qué revisión pasa una integración antes de salir a producción, cómo se capacita a los equipos. Y habla de un momento: con anterioridad y durante el tratamiento. No es una revisión única al lanzar, sino un deber que se mantiene mientras el tratamiento exista.

La segunda obligación —la protección por defecto— es más concreta y, en la práctica, más fácil de auditar. Se trata de que la configuración inicial del sistema, aquella que opera sin que el titular tome ninguna decisión activa, sea ya la más protectora. Si un usuario debe entrar a las preferencias para dejar de compartir su ubicación, para restringir la visibilidad de su perfil o para desactivar una comunicación comercial, la configuración por defecto está trabajando en contra del criterio del artículo 14 quater. La regla práctica es simple: lo que el titular no eligió expresamente, no debería tratarse si no es estrictamente necesario para la finalidad.

En términos de gobierno interno, esto significa que la pregunta que abre un proyecto cambia. Ya no es "¿qué datos podemos recoger?" sino "¿cuál es el conjunto mínimo de datos sin el cual esta funcionalidad no existe?". Todo lo que esté fuera de ese conjunto necesita una justificación explícita y documentada, o simplemente no se recoge.

• Obligación 1 (desde el diseño): medidas técnicas y organizativas adecuadas, antes y durante el tratamiento.
• Obligación 2 (por defecto): tratar únicamente los datos específicos y estrictamente necesarios.
• Las medidas técnicas viven en el código y la infraestructura; las organizativas, en los procesos y roles.
• El deber es continuo: acompaña al tratamiento durante toda su vida, no solo al lanzamiento.

¿Qué factores manda considerar el artículo para elegir las medidas y definir el mínimo?

El artículo 14 quater de la Ley 21.719 no deja la adecuación al criterio libre del responsable: entrega factores de ponderación para las medidas y criterios para evaluar el "por defecto". Conocerlos es lo que permitirá justificar decisiones frente a la Agencia de Protección de Datos Personales, porque el artículo no contiene una lista cerrada de controles obligatorios. Ten presente, eso sí, que el artículo 14 septies faculta a la Agencia para determinar mediante instrucción general los estándares o condiciones mínimas de los deberes de información (artículo 14 ter) y de seguridad (artículo 14 quinquies), de modo que parte del detalle técnico se conocerá con esas instrucciones.

Los cuatro factores para determinar qué medidas son adecuadas son: el estado de la técnica, los costos de implementación, la naturaleza, ámbito, contexto y fines del tratamiento, y los riesgos asociados. El primero significa que lo razonable hace cinco años puede no serlo hoy; si el cifrado en reposo se volvió estándar en tu industria, no ofrecerlo es difícil de defender. El segundo reconoce que la proporcionalidad económica existe: el costo es un factor que la norma manda ponderar, no una excusa general para no hacer nada. El tercero exige mirar qué datos son (no es lo mismo un correo corporativo que un dato de salud, que la Ley 21.719 trata como sensible en los artículos 16 y 16 bis), a cuántas personas alcanza y para qué. El cuarto pone el foco donde corresponde: en el riesgo para los derechos de los titulares, no solo en el riesgo para la empresa.

Los cuatro criterios del "por defecto" son operativos y se pueden convertir directamente en una lista de verificación de producto: el número de datos recogidos, la extensión del tratamiento, el plazo de conservación y su accesibilidad. Traducidos: cuántos campos pides, cuántas operaciones haces con ellos, cuánto tiempo los guardas y cuánta gente puede verlos. Estos cuatro criterios son, en la práctica, la mejor guía de revisión que el artículo 14 quater entrega a un equipo técnico, porque cada uno se responde con una decisión concreta y verificable en el sistema.

• Factor 1 — Estado de la técnica: qué es razonablemente exigible hoy, no hace cinco años.
• Factor 2 — Costos de implementación: la proporcionalidad económica se pondera, no se invoca como excusa general.
• Factor 3 — Naturaleza, ámbito, contexto y fines del tratamiento: qué datos, sobre cuántas personas y para qué.
• Factor 4 — Riesgos asociados: el foco está en los derechos de los titulares.
• Criterios del "por defecto": número de datos recogidos, extensión del tratamiento, plazo de conservación y accesibilidad.
• Estándares mínimos de información y seguridad: el artículo 14 septies permite a la Agencia diferenciarlos por instrucción general.

¿Cómo se traduce el artículo 14 quater en decisiones concretas de producto?

Se traduce en cinco frentes que cualquier equipo puede revisar esta semana: los campos de los formularios, la configuración inicial de las cuentas, lo que envías a analítica, lo que compartes en integraciones y cuánto tiempo conservas cada registro. En todos ellos, el cambio suele ser una decisión de diseño, no un proyecto de infraestructura.

El caso más frecuente es el formulario de registro. Un flujo típico en Chile pide nombre completo, RUT, correo, teléfono, fecha de nacimiento, dirección y empresa para crear una cuenta que, funcionalmente, solo necesita un correo verificado y una contraseña. Aplicando el criterio de "número de datos recogidos" del artículo 14 quater, el rediseño es evidente: dos campos obligatorios en el registro y el resto solicitado más tarde, en el momento en que efectivamente se necesita (el RUT al facturar, la dirección al despachar). No solo se alinea mejor con la norma: suele mejorar la conversión.

El segundo frente son las configuraciones por defecto. Perfiles públicos por defecto, geolocalización activada por defecto, casillas de comunicaciones comerciales premarcadas, historial compartido con todo el equipo por defecto. Cada una de esas decisiones traslada al titular la carga de protegerse, cuando el artículo 14 quater la pone en el responsable. En el caso específico de la ubicación, además, el artículo 16 sexies exige informar de manera clara, suficiente y oportuna el tipo de datos de geolocalización que se tratarán, la finalidad y la duración del tratamiento, y si esos datos se comunicarán o cederán a un tercero para la prestación de un servicio con valor añadido.

El tercero es la analítica y las integraciones. Muchos equipos envían el payload completo del usuario a herramientas de terceros porque es lo que trae la implementación por defecto del SDK. Ahí entran dos medidas técnicas concretas: la seudonimización —enviar un identificador interno en lugar del correo o el RUT— y el filtrado explícito de campos en la capa de integración. El cuarto es el borrado programado: definir un plazo de conservación por tipo de dato y ejecutarlo con un job automático, en lugar de acumular indefinidamente "por si acaso".

¿En qué momento del ciclo de vida se aplica y cómo lo documentas?

Se aplica desde el descubrimiento del producto y se mantiene mientras el tratamiento exista, porque el artículo 14 quater de la Ley 21.719 exige medidas adoptadas con anterioridad y durante el tratamiento. En la práctica, esto significa insertar tres puntos de control en el flujo de trabajo que tu equipo ya usa, sin crear un proceso paralelo.

El primer punto de control es el descubrimiento. Antes de escribir la primera línea de código, el equipo define qué datos personales necesita la funcionalidad, con qué finalidad y por cuánto tiempo. Es la conversación más barata de todas: cambiar un modelo de datos en una pizarra cuesta minutos; cambiarlo con seis meses de producción encima cuesta un trimestre. El segundo punto es la revisión previa al despliegue: una verificación corta contra los cuatro criterios del "por defecto" (número de datos, extensión, conservación y accesibilidad), idealmente como ítem de la definición de terminado.

El tercero es la revisión periódica. El deber es continuo, así que corresponde volver a mirar un tratamiento cuando cambia su finalidad, cuando se incorpora una tecnología nueva, cuando aparece un proveedor distinto o cuando el volumen de datos crece de forma significativa. Un ciclo anual, más revisiones gatilladas por cambios relevantes, es un estándar razonable de gestión, aunque la ley no fije esa periodicidad.

La documentación es lo que convierte todo esto en algo demostrable. El artículo 14 quater no describe un formato de registro, pero el principio de responsabilidad del artículo 3 apunta en esa dirección: sin evidencia escrita, acreditar que diseñaste con criterio es prácticamente imposible. Lo mínimo útil es un registro por funcionalidad que consigne los datos tratados y su finalidad, la justificación de por qué cada campo es necesario, las alternativas más protectoras que se evaluaron y por qué se descartaron (aquí entran el estado de la técnica y los costos de implementación), la configuración por defecto aprobada, los plazos de conservación con su fundamento y quién aprobó cada decisión, con fecha. Ese documento no necesita ser extenso; necesita existir, estar fechado y ser recuperable.

• Punto de control 1: definición de datos, finalidad y retención en el descubrimiento del producto.
• Punto de control 2: verificación contra los cuatro criterios del "por defecto" antes del despliegue.
• Punto de control 3: revisión periódica y ante cambios de finalidad, tecnología, proveedor o volumen.
• Evidencia mínima: justificación por campo, alternativas descartadas, configuración por defecto, plazos de conservación y aprobador con fecha.

¿Cómo se relaciona con la evaluación de impacto y con las medidas de seguridad?

Son tres piezas de un mismo engranaje dentro de la Ley 21.719, y confundirlas lleva a duplicar trabajo o a dejar huecos. La evaluación de impacto regulada en el artículo 15 ter sirve para analizar los riesgos de un tratamiento; la protección desde el diseño del artículo 14 quater es lo que haces con esos hallazgos al construir el tratamiento; y el deber de adoptar medidas de seguridad del artículo 14 quinquies protege lo que finalmente se decidió tratar.

La secuencia lógica ayuda a ordenar los equipos. Primero se analiza el riesgo del tratamiento previsto (artículo 15 ter). Si ese análisis revela, por ejemplo, que un flujo concentra datos sensibles de miles de personas en una sola base accesible por todo el equipo de soporte, la respuesta correcta no es agregar más controles encima: es rediseñar. Segregar la base, reducir los campos, seudonimizar los identificadores y restringir el acceso son decisiones propias del artículo 14 quater. Recién después, sobre el diseño ya minimizado, se aplican los controles de seguridad del artículo 14 quinquies: cifrado, respaldos, gestión de accesos, monitoreo.

El orden no es un detalle académico. Aplicar seguridad sobre un diseño que recoge datos innecesarios es proteger muy bien información que nunca debiste tener. Y hay un beneficio operativo directo: cuantos menos datos personales guardas, menor es la superficie expuesta ante un incidente y menor es el alcance de una eventual notificación de brecha bajo el artículo 14 sexies, que obliga a reportar a la Agencia, por los medios más expeditos posibles y sin dilaciones indebidas, cuando exista un riesgo razonable para los derechos y libertades de los titulares, y a comunicar a los titulares en casos como los datos sensibles, los de niños y niñas menores de catorce años o los referidos a obligaciones económicas, financieras, bancarias o comerciales.

Conviene además ordenar las expectativas sobre las consecuencias. El artículo sexto transitorio contempla que, durante los primeros doce meses posteriores a la entrada en vigencia, cuando proceda alguna sanción respecto de empresas calificadas como de menor tamaño según el artículo segundo de la ley N° 20.416, la Agencia podrá aplicar como sanción una amonestación por escrito. Es una facultad de la Agencia, no una inmunidad automática: no alcanza a quienes no califican como empresa de menor tamaño, no exime del cumplimiento sustantivo y esa amonestación igualmente queda sujeta al deber de registro del artículo 39.

Un último punto sobre expectativas realistas. Cumplir el artículo 14 quater no elimina el riesgo regulatorio ni garantiza un resultado favorable ante la Agencia: reduce la superficie de exposición y, sobre todo, te deja en condiciones de explicar por qué diseñaste como diseñaste. Con la Ley 21.719 entrando en vigencia el 1 de diciembre de 2026, esa capacidad de explicar —con documentos, fechas y responsables— es probablemente el activo más valioso que un equipo de producto puede construir en los meses que quedan.

• Artículo 15 ter — evaluación de impacto: analiza los riesgos del tratamiento previsto.
• Artículo 14 quater — desde el diseño y por defecto: decide cómo se construye y cuánto se trata.
• Artículo 14 quinquies — medidas de seguridad: protege lo que se decidió tratar.
• Artículo 14 sexies — brechas: menos datos guardados significa menor alcance de una eventual notificación.
• Régimen transitorio: durante los primeros doce meses, la Agencia podrá aplicar amonestación escrita a empresas de menor tamaño (ley 20.416); es una facultad y queda registrada.

Preguntas frecuentes

¿La privacidad desde el diseño es obligatoria en Chile?

Sí. En Chile, el artículo 14 quater de la Ley 21.719 la establece como un deber del responsable, no como una buena práctica opcional. Exige medidas técnicas y organizativas adecuadas antes y durante el tratamiento, y que por defecto solo se traten los datos estrictamente necesarios. La ley entrará en vigencia el 1 de diciembre de 2026.

¿Cuál es la diferencia entre "desde el diseño" y "por defecto"?

Son dos obligaciones distintas dentro del mismo artículo 14 quater de la Ley 21.719. "Desde el diseño" se refiere al cuándo y al cómo: adoptar medidas técnicas y organizativas adecuadas con anterioridad y durante el tratamiento. "Por defecto" se refiere al cuánto: garantizar que solo se traten los datos específicos y estrictamente necesarios para la finalidad.

¿Qué factores debo considerar para decidir qué medidas son "adecuadas"?

El propio artículo 14 quater manda ponderar cuatro elementos: el estado de la técnica, los costos de implementación, la naturaleza, ámbito, contexto y fines del tratamiento, y los riesgos asociados. El artículo no fija una lista cerrada de controles obligatorios: la adecuación se justifica ponderando esos cuatro factores y dejándolo documentado por escrito.

¿Qué significa concretamente "por defecto" en un producto digital?

Significa que la configuración inicial, sin que el titular toque nada, ya debe tratar solo lo estrictamente necesario. El artículo 14 quater fija cuatro criterios para evaluarlo: el número de datos recogidos, la extensión del tratamiento, el plazo de conservación y su accesibilidad. Perfiles privados por defecto, campos opcionales y retención acotada son la traducción práctica.

¿La Ley 21.719 obliga a certificarse en ISO 27001 o algún estándar técnico?

No. La Ley 21.719 no exige ISO 27001, NIST ni ninguna certificación técnica específica. La única certificación que contempla es la del modelo de prevención de infracciones ante la Agencia, regulada en el artículo 51, y su adopción es voluntaria. Los estándares técnicos ayudan como evidencia de diligencia, pero no reemplazan el análisis del artículo 14 quater.

¿En qué momento del ciclo de vida del producto debo aplicar el artículo 14 quater?

Antes y durante. El artículo 14 quater habla de medidas adoptadas con anterioridad y durante el tratamiento, así que el momento natural es el descubrimiento y el diseño de la solución, no la revisión legal previa al lanzamiento. Al ser un deber continuo, conviene revisar los tratamientos vigentes cuando cambian la finalidad, la tecnología o el riesgo.

¿Cómo se relaciona con la evaluación de impacto del artículo 15 ter?

Se complementan. La evaluación de impacto regulada en el artículo 15 ter sirve para analizar los riesgos de un tratamiento; la protección desde el diseño del artículo 14 quater es lo que haces con esos hallazgos: rediseñar el flujo, reducir campos, seudonimizar o acortar la retención. Una alimenta a la otra dentro del mismo proceso.

¿Cómo demuestro que cumplí con la privacidad desde el diseño?

Con evidencia escrita y fechada de las decisiones. Guarda el inventario de datos por funcionalidad, la justificación de cada campo, las alternativas descartadas con su motivo, la configuración por defecto aprobada, los plazos de conservación y el responsable de cada decisión. El principio de responsabilidad del artículo 3 respalda esa exigencia práctica de trazabilidad.

¿Esto aplica también a las empresas pequeñas?

Sí. El deber del artículo 14 quater alcanza a todo responsable en Chile. La proporcionalidad opera dentro del propio artículo, que manda ponderar los costos de implementación. Por su parte, el artículo 14 septies permite a la Agencia diferenciar estándares mínimos de información y seguridad según el tamaño de la entidad conforme a la ley 20.416.

¿Qué pasa si mi sistema ya está en producción y no fue diseñado así?

No estás fuera de plazo, pero sí en deuda técnica. Como la Ley 21.719 entrará en vigencia el 1 de diciembre de 2026, conviene priorizar por riesgo: primero los flujos con datos sensibles o de menores de edad, luego los formularios y la analítica de alto volumen. Documenta el plan de remediación con fechas y responsables.

Fuentes oficiales

• Ley 21.719 — Texto oficial, Biblioteca del Congreso Nacional (Ley Chile)

Este artículo tiene fines informativos y no constituye asesoría legal para un caso particular.