Tu DPO te reenvía un correo. Asunto: "para la auditoría necesitamos demostrar privacidad por diseño y por defecto bajo la Ley 21.719". Le pides referencias. Te manda el artículo 25 del GDPR (porque Chile lo importa casi literal) y tres PDFs de la AEPD española. Ninguno habla de Chile. Ninguno te dice cómo demostrarlo en los 200 laptops que tu equipo administra.
Y ahí estás. Con un principio jurídico claro en el papel, una fecha en la cabeza (diciembre de 2026), y la sensación incómoda de que entre la política y la implementación hay una zona gris donde tu organización vive hoy.
Privacidad por diseño y por defecto suena a doctrina hasta que alguien te pregunta cómo se aplicó en el laptop que un comercial llevó la semana pasada a una visita en Antofagasta. Hasta que un auditor te pide evidencia de que cada equipo entregado en los últimos doce meses salió con cifrado activado por defecto. Hasta que la Agencia de Protección de Datos te abre un proceso y descubres que tu defensa son políticas en PDF, no bitácoras operativas.
Nota rápida: si trabajas en una PYME chilena sin equipo IT estructurado, tenemos una guía dedicada a privacidad para PYMES que se ajusta mejor a tu realidad. Esta guía es para organizaciones medianas y grandes con responsabilidad de demostrar cumplimiento ante la Agencia.
Esta guía traduce el principio de la Ley 21.719 a tres cosas concretas: qué exige realmente, dónde se rompe en la operación de una empresa chilena, y cómo construir la evidencia operativa que un auditor puede verificar. La Agencia no te va a auditar leyendo tus políticas. Te va a auditar pidiendo registros, bitácoras y comportamientos demostrables sobre cada endpoint que toca datos personales.
Qué exige la Ley 21.719 sobre privacidad por diseño y por defecto
Tu DPO te dice que la 21.719 te obliga a privacidad por diseño y por defecto. Pero la ley no llega con manual de IT, llega con principios. Lo que hay debajo:
La Ley 21.719 incorpora dos principios complementarios. El primero, "por diseño", obliga a integrar la protección de datos desde el momento en que un proceso, sistema o producto se concibe. No es un parche posterior. Es una decisión arquitectónica.
El segundo, "por defecto", exige que la configuración inicial entregue el máximo nivel de protección sin que el titular tenga que hacer nada. La privacidad no es algo que el usuario active. Viene activada.
Ambos principios encajan dentro de la responsabilidad proactiva que la ley chilena adopta del GDPR. Esto cambia el juego: ya no basta con declarar buenas intenciones. Tienes que demostrar, con evidencia, que tu organización aplica los controles antes de que ocurra el incidente. La carga de la prueba está en ti, no en el regulador.
Marcela, jefa de IT en una empresa de logística con operación en cinco regiones, lo resume con honestidad: "tenemos las políticas firmadas hace dos años. Lo que no tenemos es cómo demostrar que se aplicaron en cada uno de los 320 equipos que entregamos en ese tiempo". Esa brecha entre política y aplicación es exactamente lo que la responsabilidad proactiva busca cerrar.
La conexión natural está con la evaluación de impacto (DPIA) que la ley exige para tratamientos de alto riesgo. La primera prueba documental de que diseñaste con privacidad es haber hecho esa evaluación antes del despliegue, no después de la fiscalización. Y aunque el SERP español domina el contenido sobre Privacy by Design, la Biblioteca del Congreso Nacional de Chile (BCN) publicó un informe oficial sobre el principio aplicado al contexto local. Es fuente citable si tu DPO te pide referencias chilenas.
Quick win: Identifica un proceso de IT que vas a lanzar el próximo trimestre. Revísalo bajo dos preguntas: ¿se diseñó con privacidad desde el inicio o se va a parchear después? ¿La configuración por defecto entrega máxima protección o máxima funcionalidad? Si la respuesta a alguna es la segunda opción, ya tienes una conversación que llevarle al equipo antes del go-live.
Los siete principios (y cuál suele romperse primero en una empresa chilena)
Ann Cavoukian, ex Comisionada de Privacidad de Ontario, formuló los siete principios fundacionales de Privacy by Design en los noventa. La Unión Europea los incorporó al GDPR. Chile los hereda vía Ley 21.719. La teoría está clara. La práctica, no tanto.
Los siete principios y dónde se rompen en una organización chilena promedio:
1. Proactivo, no reactivo. El principio dice: previene problemas antes de que ocurran. Donde se rompe: la mayoría de las decisiones técnicas se toman primero, y la revisión de privacidad llega después, cuando ya hay tickets reportando algo raro.
2. Privacidad como configuración por defecto. El principio dice: el usuario no tiene que activar nada. Donde se rompe: la imagen base de los equipos que IT entrega activa telemetría, sincronización a clouds personales y permisos abiertos. Productividad ganó sobre privacidad sin que nadie lo discuta.
3. Privacidad integrada en el diseño. El principio dice: la protección es parte del producto, no un agregado. Donde se rompe: el DPO no se entera de los proyectos hasta que están en producción y alguien pide aprobación legal.
4. Funcionalidad completa, suma positiva. El principio dice: privacidad y funcionalidad coexisten, no son trade-off. Donde se rompe: cualquier conversación donde alguien dice "si lo hacemos así, el equipo no va a poder trabajar". Esa frase indica que nadie está buscando el diseño que satisface ambas.
5. Seguridad de extremo a extremo. El principio dice: protección a lo largo de todo el ciclo de vida del dato. Donde se rompe: el dato está cifrado en reposo pero la copia que el comercial sincronizó a su laptop personal viaja sin cifrar a una nube no corporativa. Es el caso de Vicente, ejecutivo de cuentas, que respalda todo en su Google Drive personal porque "así no pierdo nada cuando viajo".
6. Visibilidad y transparencia. El principio dice: las prácticas son verificables. Donde se rompe: hay políticas publicadas, pero nadie puede demostrar con un log que se aplican.
7. Respeto por la privacidad del usuario. El principio dice: el titular es el centro. Donde se rompe: el formulario sigue pidiendo el RUT, la fecha de nacimiento y el teléfono cuando solo se necesita un correo.
Estos siete principios ya están en los principios fundamentales de la Ley 21.719 que tu DPO probablemente te ha citado. La pregunta operativa no es si los conoces. Es cuáles aplica tu organización hoy con evidencia, y cuáles existen solo en políticas.
Quick win: Marca con un highlighter los dos principios que tu organización aplica bien y los dos que no. Esa es tu lista corta de prioridades para los próximos noventa días.
Dónde se rompe la privacidad por diseño en la operación real
Los principios suenan limpios. La operación, no.
Pensemos en Andrea, ingeniera de IT en una empresa de servicios con 180 colaboradores distribuidos en Santiago, Concepción y Antofagasta. La política de privacidad dice que los datos personales se tratan con minimización, finalidad clara y proporcionalidad. La realidad:
Los comerciales en regiones usan sus propios celulares para sincronizar correos corporativos (BYOD informal). La fuerza de campo en Antofagasta tiene laptops sin gestión central porque el último intento de MDM no funcionó con la conectividad satelital. El último cierre de proceso de empleado (Pedro, ex-vendedor) dejó un MacBook que volvió a la oficina, pero nadie tiene evidencia documentada de que se borró antes de reasignarlo. Y un proveedor SaaS que el equipo de marketing contrató el mes pasado almacena datos de prospectos sin que el DPO haya revisado el tratamiento.
Cada uno de esos puntos es un agujero en el principio de privacidad por diseño. Y cada uno es invisible hasta que un incidente lo hace visible.
El patrón común: la privacidad depende de la disciplina del usuario, no de un control técnico. Y la disciplina, sin enforcement, falla.
Otra cara del mismo problema es la gobernanza de datos. Si no sabes qué datos tiene tu organización, dónde viven y quién accede a ellos, no puedes diseñar protección. El principio de privacidad por diseño se sostiene sobre un inventario que la mayoría de las organizaciones chilenas no tiene completo.
Hay un caso concreto que suele aparecer. Una solicitud ARCO llega a la inbox del DPO: un ex-cliente pide la supresión de sus datos. El DPO va al equipo de IT. IT busca dónde están esos datos. Los encuentra en cinco lugares: el CRM, una carpeta compartida, el backup mensual, un Excel local en el laptop de un comercial, y un export que alguien hizo para una campaña hace seis meses. Cumplir el plazo legal con esa arquitectura es una carrera contra reloj.
Quick win: Lista hoy los cinco procesos donde la privacidad de datos depende de que el usuario haga lo correcto (no de un control técnico que enforce el comportamiento). Esa es tu superficie de riesgo prioritaria.
¿Cómo aterrizas el principio en tu fleet de endpoints?
Los siete principios y la teoría legal son el qué. El endpoint es el dónde. Y la diferencia entre cumplir y demostrarlo se juega en tres capas operativas.
Capa 1 — Visibilidad: no diseñas protección para lo que no sabes que existe.
El nivel cero de privacidad por diseño es un inventario completo y always-on de cada dispositivo que toca datos personales. Esto incluye los laptops corporativos, los móviles, las tablets, y los equipos BYOD si tu política los permite. Sin este inventario, todo lo que sigue es declarativo: no puedes proteger lo que no rastreas, y no puedes documentar lo que no ves.
Diego, jefe de IT en una compañía de retail con 350 colaboradores, lo plantea así: "mientras no tenga el inventario en un dashboard, todo lo demás vive en mi cabeza. Y mi cabeza no sirve como evidencia en una auditoría". Esa es la regla operativa de la Capa 1.
La pregunta operativa: ¿en cuántos dispositivos tu organización procesa datos personales hoy, y cuántos de esos están en un dashboard centralizado que puedas mostrar mañana?
Capa 2 — Control: los mecanismos que aplican el principio.
Aquí viven los controles técnicos concretos: cifrado activado desde el aprovisionamiento, privilegios mínimos por cuenta, capacidad de bloqueo y borrado remoto verificable, geolocalización always-on con alertas cuando un dispositivo sale de zonas autorizadas. Cada uno de estos controles materializa un principio. El cifrado por defecto es el principio "por defecto" hecho técnica. El borrado remoto es la capacidad de ejercer derechos ARCO sin esperar al usuario. La geolocalización es la visibilidad del ciclo de vida del dato físico.
Si quieres profundizar en el detalle de cada control técnico que la Ley 21.719 espera, ya tienes nuestra guía de controles técnicos mínimos mapeada al texto legal.
Capa 3 — Evidencia: cada decisión y cada acción dejan huella.
Esta es la capa que casi todas las organizaciones subestiman. Bitácoras de aprovisionamiento (qué configuración salió en cada equipo), registros de cifrado activado por dispositivo, logs de wipe ejecutado con timestamp, historial de configuraciones aplicadas. Sin esta capa, los principios existen en política y no en práctica operativa. Y la Agencia chilena audita la práctica, no la política.
Una nota práctica: las tres capas no son secuenciales. No esperes a tener "perfecta visibilidad" antes de implementar controles, ni "todos los controles" antes de generar evidencia. Avanza en las tres en paralelo, midiendo gap por capa.
Para operar las tres capas a escala, necesitas una plataforma que combine inventario always-on, control remoto sobre cada dispositivo y bitácora completa de cada acción. Herramientas de gestión y seguridad de endpoints como Prey integran las tres capas en un único dashboard, lo que cierra la distancia entre tener la política y poder demostrar la aplicación frente a una fiscalización.
Quick win: Para cada una de las tres capas, identifica una cosa que tu organización ya hace bien y una que falta. Tienes el mapa de prioridades para el próximo trimestre, ordenado por dependencia operativa (sin visibilidad no hay control, sin control no hay evidencia).
¿Qué configuraciones debe entregar IT activadas por defecto?
"Por defecto" es la parte del principio que más se ignora. Y la más fácil de demostrar.
La lógica es directa. Cada equipo nuevo que IT entrega es una oportunidad de aplicar privacidad por defecto. No hay que migrar, no hay que retrofitear. Solo hay que configurar bien la imagen base antes del primer arranque.
Las configuraciones que un equipo corporativo debería entregar ya activadas:
- Telemetría minimizada en el sistema operativo (Windows, macOS y móviles tienen paneles de privacidad con configuraciones por defecto que activan envío de diagnóstico, ubicación y uso de apps a fabricantes)
- Permisos de aplicación cerrados (cámara, micrófono, ubicación, accesibilidad)
- Cifrado de disco activado en el aprovisionamiento, no como tarea posterior del usuario
- Backups apuntando a infraestructura corporativa, no a iCloud personal o Google Drive privado
- Navegador corporativo con bloqueo de cookies de terceros, no rastreo, sesiones aisladas por perfil
Carolina, jefa de IT en una clínica privada en Las Condes, lo cuenta así: "nuestra primera auditoría de cumplimiento técnico la pasamos en parte porque cambiamos el pliego con Compras. Pedimos que los equipos llegaran con BitLocker activado de fábrica. Antes lo hacíamos manualmente al desempacar y se nos olvidaba en uno de cada veinte". Ese cambio en la cadena de adquisición es privacidad por defecto en su forma más operativa.
Esto conecta con los marcos de ciberseguridad que la organización adopte: cuando ISO 27001 o el marco de Ley 21.663 pide "configuraciones reforzadas", la respuesta operativa es exactamente esta. No es una capa adicional, es la implementación del mismo principio desde el ángulo de seguridad.
Quick win: Documenta tu imagen base actual con captura de pantalla de las configuraciones de privacidad. Compárala con la imagen base ideal. La diferencia entre ambas es tu lista de cambios para el próximo lote de equipos que tu equipo entregue.
Cómo demostrar a la Agencia chilena que sí lo aplicaste
Tu MPI está documentado. Tus políticas están firmadas. La fiscalizadora se sienta en tu sala y la primera pregunta no es sobre el papel. Es sobre los logs.
La Ley 21.719 no se conforma con la política. Exige evidencia operativa, y la Agencia de Protección de Datos Personales tiene facultades fiscalizadoras desde la entrada en vigencia.
¿Qué tipo de evidencia? Tres categorías que conviene tener listas antes de que llegue la primera solicitud:
Políticas documentadas. El nivel base. Documentos firmados, fechas claras, vigencia, audiencia. Esto lo tiene casi todo el mundo. No alcanza por sí solo, pero sin esto no hay cumplimiento posible.
Bitácoras operativas. Esta es la capa que muchas organizaciones subestiman. Logs de qué equipo se cifró cuándo y por quién. Registros de cada wipe ejecutado, con timestamp y motivo. Historial de cambios de configuración aplicados al fleet. Listado de accesos otorgados y revocados durante un período. Esta es la evidencia que un auditor pide cuando quiere ver si la política tiene reflejo en la realidad.
Reportes de acción ante incidentes. Cuando algo pasa (un equipo perdido, una solicitud ARCO, una sospecha de filtración), la documentación de qué hizo IT, en qué plazo, con qué resultado. Esta evidencia conecta directamente con los plazos de notificación de la ley y con la diligencia debida que un Modelo de Prevención de Infracciones busca acreditar.
Hay un escenario que conviene mentalizar. Una tablet con historial clínico se pierde en el aeropuerto de Pudahuel. Antes del incidente, la organización tenía: inventario que listaba la tablet como entregada a una doctora, configuración por defecto que activó cifrado en el aprovisionamiento, política de retención que mantenía solo los datos necesarios, capacidad de bloqueo remoto disponible. Cuando la doctora reporta la pérdida a las 14:30, IT bloquea el dispositivo a las 14:33, ejecuta wipe a las 14:38 y genera un reporte con timestamps automáticos. El DPO tiene a las 15:00 una bitácora completa para evaluar si hubo brecha notificable.
Si esa bitácora no existe, la conversación con la Agencia es distinta. Si existe, el principio de responsabilidad proactiva se demuestra solo.
Para organizaciones que estén implementando un Modelo de Prevención de Infracciones (MPI), esta capa de evidencia es el insumo central. El MPI exige que demuestres controles efectivos antes del incidente, y la bitácora operativa es la materialización técnica de esa demostración.
Una plataforma como Prey deja huella de cada acción ejecutada sobre cada dispositivo: cuándo se bloqueó, cuándo se borró, dónde estaba en cada check-in, quién lo gestionó. Esa bitácora es exactamente la evidencia que la responsabilidad proactiva de la Ley 21.719 exige cuando llega la fiscalización.
Quick win: Lista los tres procesos de privacidad más importantes de tu organización (por ejemplo: aprovisionamiento de equipos, respuesta a solicitudes ARCO, cierre de proceso de empleado). Para cada uno, identifica qué bitácora demuestra que el proceso se ejecutó. Si la respuesta es "no tenemos bitácora", ya tienes los próximos tres proyectos del trimestre.
Conclusión
La privacidad por diseño y por defecto no es una doctrina jurídica que se aplica desde la oficina del DPO. Es una disciplina operativa que vive en cada laptop, móvil y tablet donde corren los datos personales. La Ley 21.719 lo deja claro: la responsabilidad proactiva no se demuestra con políticas, se demuestra con evidencia.
Las tres capas operativas (visibilidad, control y evidencia) son las que separan a la organización que cumple en teoría de la que puede demostrarlo en una fiscalización. La visibilidad te dice qué dispositivos procesan datos. El control te permite aplicar los principios en cada uno. La evidencia es lo que muestras al auditor cuando llegue.
Diciembre de 2026 no es una fecha lejana. Es la fecha en que la Agencia de Protección de Datos empieza a fiscalizar con dientes. Las organizaciones que llegan con las tres capas funcionando ya tienen su defensa armada. Las que llegan con políticas en PDF descubren que la responsabilidad proactiva se mide en bitácoras, no en intenciones.
Empieza por la capa de visibilidad esta semana. Mapea tu fleet. El resto se construye sobre esa base.
Preguntas frecuentes
¿Qué dice la Ley 21.719 sobre privacidad por diseño y por defecto?
La Ley 21.719 incorpora el principio de privacidad por diseño y por defecto dentro de la responsabilidad proactiva que exige a responsables del tratamiento. Esto significa que las organizaciones deben integrar la protección de datos desde el diseño de procesos y productos, configurar la máxima protección por defecto, y demostrar con evidencia operativa que aplicaron estos controles antes de cualquier fiscalización por parte de la Agencia.
¿Cuál es la diferencia entre privacidad por diseño y privacidad por defecto?
Privacidad por diseño obliga a integrar la protección de datos desde la concepción del proceso o sistema, no como agregado posterior. Privacidad por defecto exige que la configuración inicial entregue el máximo nivel de protección sin que el titular tenga que activarla. El primer principio aplica al diseño arquitectónico; el segundo aplica a la configuración base que el usuario recibe sin tocar nada.
¿Cuándo empieza a fiscalizar la Agencia de Protección de Datos chilena?
La Ley 21.719 entra en vigencia en diciembre de 2026, momento en que la Agencia de Protección de Datos Personales asume facultades fiscalizadoras y sancionatorias. Las multas pueden llegar hasta 20.000 UTM por infracciones gravísimas (aproximadamente USD 1,5 millones), con incrementos para organizaciones que reinciden o demoran en remediar.
¿Cómo demuestro a la Agencia que mi organización aplica privacidad por diseño?
La evidencia operativa se construye en tres capas: políticas documentadas y firmadas, bitácoras operativas (logs de configuraciones aplicadas, wipes ejecutados, accesos otorgados) y reportes de respuesta ante incidentes con timestamps verificables. Una bitácora generada por una plataforma de gestión de endpoints es más sólida que un Excel mantenido manualmente, porque incluye huella automática de cada acción.
¿La privacidad por diseño es obligatoria para PYMES chilenas?
Sí, el principio aplica independiente del tamaño de la organización, aunque la Ley 21.719 establece criterios proporcionales según el riesgo y la escala del tratamiento. Para empresas pequeñas sin equipo IT estructurado, tenemos una guía dedicada con un enfoque adaptado a esa realidad operativa y a las prioridades reales de una PYME.
Demuestra privacidad por diseño con evidencia operativa, no con PDFs
La privacidad por diseño y por defecto vive o muere en el endpoint. Si quieres ver cómo una plataforma de gestión y seguridad de endpoints te entrega el inventario always-on, el cifrado gestionado, el wipe remoto verificable y la bitácora completa que la Agencia de Protección de Datos chilena espera ver en una fiscalización, agenda una demo de Prey y revísalo aplicado a tu fleet.
.avif)