El cambio de fondo: Chile pasa de una ley de datos de los años 90 a un marco moderno, alineado con el estándar europeo (GDPR). Aparece una autoridad con dientes, sanciones reales y, sobre todo, la obligación de construir la privacidad dentro de los sistemas, no de pegarla por fuera con una política en un PDF.
1. Qué cambia y por qué importa ahora
La Ley N° 21.719 moderniza la protección de datos personales en Chile y reemplaza el régimen anterior (Ley N° 19.628, de 1999). Sus puntos clave:
- Nace una autoridad real: la Agencia de Protección de Datos Personales (APDP), con potestad fiscalizadora y sancionatoria.
- Sanciones con peso: las infracciones se clasifican en leves, graves y gravísimas, con multas que para los casos gravísimos pueden alcanzar miles de UTM. El incumplimiento deja de ser barato.
- Principios obligatorios: licitud, finalidad, proporcionalidad, calidad, responsabilidad (accountability), seguridad, transparencia y confidencialidad.
- Período de transición: la ley contempla un plazo de adecuación antes de su plena entrada en vigencia. Traducción para tu equipo: la ventana para prepararse es corta y ya empezó.
Verifica las fechas exactas. Los plazos de vigencia y los montos de las multas son los datos que más rápido envejecen y los que más cuestan equivocarse. Confirma siempre contra el texto oficial en la Biblioteca del Congreso Nacional (LeyChile) y con asesoría legal antes de tomar decisiones.
2. De la política al código: qué es la ingeniería de privacidad
El gran salto no es escribir una nueva política de privacidad. Es que la ley exige privacidad desde el diseño y por defecto (privacy by design & by default): la protección de datos tiene que estar incorporada en la arquitectura del sistema desde el primer commit, no como un parche al final.
Eso convierte la privacidad en una disciplina de ingeniería. Lo que antes resolvía un abogado con un documento, ahora lo resuelven decisiones técnicas concretas:
- Minimización de datos → no guardar campos "por si acaso". Si no lo necesitas para una finalidad declarada, no lo recolectas.
- Privacidad por defecto → la opción más protectora viene activada de fábrica; el usuario no tiene que ir a "apagar" el rastreo.
- Retención y borrado automático → los datos tienen fecha de vencimiento programada, no viven para siempre en una tabla olvidada.
- Seudonimización y cifrado → separar identidad de comportamiento, cifrar en reposo y en tránsito.
3. Cambios concretos en tus sistemas y tus datos
Si lideras tecnología o datos en una empresa, estos son los frentes de trabajo reales que aparecen con la nueva ley:
Inventario y mapa de datos (data mapping)
No puedes proteger lo que no sabes que tienes. El primer entregable es un Registro de Actividades de Tratamiento (RAT / RoPA): qué datos personales tratas, dónde viven, con qué finalidad, bajo qué base de licitud, quién accede y a quién se los compartes.
Bases de licitud y gestión del consentimiento
Cada tratamiento necesita una base legal explícita (consentimiento, ejecución de un contrato, obligación legal, interés legítimo, etc.). Si te apoyas en el consentimiento, debe ser libre, informado, específico e inequívoco, y tan fácil de retirar como de otorgar. En la práctica esto exige una plataforma de gestión de consentimiento que registre qué aceptó cada persona, cuándo y para qué.
Los derechos de las personas como funcionalidades del producto
Los derechos ARCO+ (acceso, rectificación, cancelación, oposición, más portabilidad y bloqueo) dejan de ser un correo que alguien responde a mano. Tienen plazos legales, así que necesitan ser features: endpoints y flujos que permitan exportar, corregir o eliminar los datos de una persona de forma trazable y dentro del plazo.
Regla práctica: si un usuario te pide "elimina todos mis datos" y tu equipo no sabe en cuántos sistemas viven ni cómo borrarlos sin romper nada, aún no estás listo. El derecho de supresión es el mejor test de madurez de tu arquitectura de datos.
4. Seguridad y notificación de brechas
La ley eleva la seguridad de medida recomendable a obligación con consecuencias. Dos cambios duros para los equipos técnicos:
- Medidas de seguridad apropiadas al riesgo: control de acceso, cifrado, registro de auditoría, gestión de proveedores (encargados de tratamiento) y respuesta a incidentes documentada.
- Deber de notificar brechas: ante una vulneración que afecte datos personales, hay que notificar a la autoridad y, según el caso, a las personas afectadas, en plazos acotados. Esto obliga a tener detección, runbooks y un proceso de comunicación listos antes de que ocurra el incidente.
5. Gobernanza: DPO, evaluaciones de impacto y modelo de prevención
- Delegado de Protección de Datos (DPO): en ciertos casos será necesario designar un responsable que vele por el cumplimiento y sirva de puente con la autoridad.
- Evaluación de Impacto (EIPD / DPIA): los tratamientos de alto riesgo (perfilamiento, datos sensibles, vigilancia a gran escala, uso de IA sobre datos personales) deben evaluarse antes de lanzarse.
- Modelo de prevención de infracciones: contar con un programa de cumplimiento documentado puede atenuar la responsabilidad. La gobernanza deja de ser opcional.
6. El cruce con la IA: dónde se pone más serio
Acá es donde esto toca de lleno a nuestra comunidad. Entrenar o usar modelos de IA con datos de personas activa todas las exigencias anteriores, y suma fricción extra:
- Datos sensibles: salud, biometría, origen, opiniones políticas o religiosas tienen protección reforzada. Meterlos en un prompt o en un dataset de entrenamiento sin base legal es un riesgo directo.
- Decisiones automatizadas y perfilamiento: aparecen derechos específicos cuando una decisión que afecta a una persona se toma solo con un algoritmo.
- Minimización vs. "datos para entrenar": la cultura de "guardemos todo para el modelo" choca de frente con el principio de minimización.
- IA local como mitigación: ejecutar modelos on-premise o en el edge (Ollama, LM Studio, hardware propio) reduce la superficie de exposición frente a enviar datos personales a APIs de terceros. Es una de las razones por las que insistimos tanto en la IA soberana de laboratorio.
7. Roadmap de ingeniería para los próximos meses
Un orden de trabajo realista para un equipo que parte de cero:
- 1. Descubrir: levanta el inventario de datos y el RAT/RoPA. Sabe qué tienes y dónde.
- 2. Clasificar: marca qué es dato personal y qué es dato sensible. Asigna base de licitud a cada tratamiento.
- 3. Minimizar: elimina lo que no necesitas y define políticas de retención y borrado.
- 4. Construir derechos: implementa acceso, rectificación, supresión y portabilidad como flujos reales.
- 5. Gestionar consentimiento: despliega un sistema que registre y permita revocar el consentimiento.
- 6. Endurecer seguridad: cifrado, control de acceso, logs y un plan de respuesta a brechas.
- 7. Gobernar: define DPO si corresponde, procesos de EIPD y un modelo de prevención documentado.
Aviso importante: este artículo es material educativo de la comunidad, no es asesoría legal. La interpretación de la ley, los plazos de vigencia y los montos de las sanciones deben confirmarse con un especialista y con el texto oficial vigente antes de tomar cualquier decisión.
8. Para seguir profundizando
- LeyChile — BCN — texto oficial de la Ley N° 21.719 y normas relacionadas.
- GDPR.eu — referencia del estándar europeo en el que se inspira la ley chilena.
- OWASP Top 10 for LLM Applications — riesgos de seguridad al tratar datos con LLMs.
- La caja de herramientas IA LATAM — modelos locales y seguridad para tratar datos con menos exposición.
"La privacidad no se cumple con un documento: se construye en la arquitectura. La ley solo está poniendo fecha de entrega a algo que la buena ingeniería ya debía hacer."
¿Tu empresa ya está adaptándose? Comparte tu experiencia y dudas con la comunidad.
Conversa en la comunidad