La Ley 21.719 es la norma que regula la protección y el tratamiento de los datos personales en Chile y crea la Agencia de Protección de Datos Personales. Se publicó en el Diario Oficial el 13 de diciembre de 2024, modifica la Ley 19.628 y entra en plena vigencia el 1 de diciembre de 2026. Establece principios exigibles para todo tratamiento de datos, un deber de reporte de vulneraciones de seguridad y un régimen de multas de hasta 20.000 UTM.
La mayoría de los planes de adecuación que circulan hoy en Chile se concentran en lo visible: política de privacidad, consentimiento, cláusulas con encargados. Todo eso es necesario. Ninguno de esos frentes alcanza el lugar donde las organizaciones reguladas acumulan más copias de datos personales sin control: los entornos no productivos.
La base jurídica de esa afirmación está en la propia ley. Su artículo 2° define el tratamiento de datos como cualquier operación o procedimiento técnico, automatizado o no, que permita recolectar, procesar, almacenar, comunicar, transmitir o utilizar datos personales. Almacenar una copia de producción en un ambiente de QA es, literalmente, tratamiento. Y como tal, queda sujeto a los mismos principios y obligaciones que el sistema del que procede. La diferencia está en el control: producción tiene responsable asignado, gestión de accesos y registro de auditoría. La copia en desarrollo, con frecuencia, no.
Qué exige la Ley 21.719 a partir del 1 de diciembre de 2026
La Ley 21.719 modifica la Ley 19.628 y reconstruye el régimen chileno de protección de datos sobre tres piezas con consecuencias operativas directas.
Primero, crea la Agencia de Protección de Datos Personales. Entre sus funciones, el artículo 30 bis incluye dictar instrucciones y normas generales obligatorias, interpretar administrativamente la normativa y fiscalizar su cumplimiento, con potestad para requerir información y sancionar. La ley crea además el Registro Nacional de Sanciones y Cumplimiento, un registro público administrado por la Agencia. Bajo la Ley 19.628, Chile carecía de una autoridad con capacidad efectiva de fiscalización y sanción en materia de datos personales. A partir del 1 de diciembre de 2026, esa capacidad existe y está concentrada en un organismo dedicado.
Segundo, el artículo 3° establece los principios que rigen todo tratamiento: licitud y lealtad, finalidad, proporcionalidad, calidad, responsabilidad, seguridad, transparencia e información, y confidencialidad. Tres de ellos aplican de forma directa sobre los ambientes de desarrollo, prueba, integración y analítica.
El principio de finalidad exige que los datos se recolecten con fines específicos, explícitos y lícitos, y prohíbe tratarlos con fines distintos a los informados al momento de la recolección, salvo las excepciones que la propia norma enumera: fines compatibles con los autorizados, una relación contractual que lo justifique, nuevo consentimiento del titular o disposición legal. Validar un cambio de esquema durante un sprint difícilmente encaja en los fines informados al titular cuando se recolectó su RUT o su historial de siniestros. Reutilizar producción en QA es, antes que un problema de seguridad, un problema de licitud.
El principio de proporcionalidad limita el tratamiento a los datos estrictamente necesarios, adecuados y pertinentes para esos fines. Y añade una regla que interesa de forma directa a los equipos de datos: los datos personales solo pueden conservarse durante el tiempo necesario para cumplir la finalidad, tras lo cual deben ser suprimidos o anonimizados. La conservación indefinida no es una opción: cumplida la finalidad, el texto legal ordena elegir entre suprimir el dato o anonimizarlo, sin perjuicio de las excepciones que la propia ley establezca. Una copia de producción antigua que sobrevive en un ambiente de integración, sin finalidad vigente que la justifique ni excepción legal que la ampare, contraviene esa regla por su sola existencia.
El principio de seguridad obliga al responsable a garantizar estándares adecuados de protección contra el tratamiento no autorizado o ilícito y contra la pérdida, filtración, daño accidental o destrucción. El artículo 14 quinquies lo desarrolla: medidas técnicas y organizativas apropiadas al riesgo, que incluyan, entre otras, la seudonimización y el cifrado de datos personales. Y el artículo 14 quáter añade el deber de protección desde el diseño y por defecto: las medidas deben aplicarse con anterioridad al tratamiento y durante él. Es el mismo planteamiento que sostiene la seguridad por diseño en arquitecturas de desarrollo.
Tercero, el régimen sancionatorio. El artículo 35 fija amonestación escrita o multa de hasta 5.000 UTM para las infracciones leves, hasta 10.000 UTM para las graves y hasta 20.000 UTM para las gravísimas. En caso de reincidencia —definida en el artículo 36 como dos o más sanciones firmes en los últimos treinta meses— la Agencia puede aplicar hasta el triple de la multa; y si el infractor no califica como empresa de menor tamaño según la Ley 20.416, la multa puede alcanzar el 2% o el 4% de los ingresos anuales por ventas y servicios en Chile, según la infracción sea grave o gravísima, aplicándose el monto más gravoso. Ante infracciones gravísimas reiteradas en un período de veinticuatro meses, la Agencia puede además suspender las operaciones de tratamiento hasta por treinta días. En banca, seguros y salud, la inscripción en un registro público de sanciones tiene un costo comercial que puede superar al de la multa.
La ley también incentiva la prevención. El artículo 49 permite adoptar voluntariamente un modelo de prevención de infracciones —un programa de cumplimiento con delegado de protección de datos incluido— que la Agencia certifica conforme al artículo 51. Haber cumplido diligentemente los deberes de dirección y supervisión, verificado mediante esa certificación, opera como circunstancia atenuante según el artículo 36. La señal es clara: la ley valora la evidencia por encima de la declaración de propósitos.
Cómo afecta la Ley 21.719 a los entornos de desarrollo, pruebas y analítica
El inventario real de una organización mediana en un sector regulado no se limita a dos ambientes. Son varios, y cada uno multiplica la superficie expuesta.
Desarrollo y pruebas unitarias, donde los equipos necesitan datos de prueba con forma realista para reproducir defectos. Integración y preproducción, que suele ser una réplica casi exacta de producción por definición. Analítica y ciencia de datos, donde los conjuntos se copian a un repositorio y permanecen durante años. Formación y demostraciones comerciales, donde la copia sale del perímetro. Soporte de segundo nivel, que restaura extractos de producción para diagnosticar un caso puntual y rara vez los elimina después. Y los ambientes de terceros que reciben copias para migraciones o desarrollos externalizados.
Cada una de esas copias es tratamiento bajo la definición del artículo 2°, y hereda las obligaciones del original. La ley reconoce al titular el derecho de rectificación —modificar o completar datos inexactos, desactualizados o incompletos— y el derecho de supresión. Un responsable que conserva copias no inventariadas de sus bases difícilmente puede acreditar que una supresión alcanzó a todos los ejemplares del dato. Y si uno de esos ambientes sufre una vulneración de seguridad, la obligación de reporte del artículo 14 sexies aplica en los mismos términos que si hubiera ocurrido en producción: es una brecha reportable.
Sobre ese reporte conviene precisión, porque la información que circula es desigual. El artículo 14 sexies obliga a reportar a la Agencia, por los medios más expeditos posibles y sin dilaciones indebidas, las vulneraciones que ocasionen destrucción, filtración, pérdida o alteración de datos personales, o el acceso o comunicación no autorizados, cuando exista un riesgo razonable para los derechos y libertades de los titulares. No fija un plazo en horas, a diferencia del RGPD y sus 72 horas; numerosas publicaciones trasladan esa cifra por analogía. Adoptarla como objetivo interno de respuesta es una decisión razonable; presentarla como exigencia literal de la ley chilena no lo es. Cuando la vulneración afecta datos sensibles, datos de menores de catorce años o datos de carácter económico, financiero, bancario o comercial, el responsable debe además comunicarla a los titulares afectados en lenguaje claro y sencillo.
Anonimización y seudonimización en la Ley 21.719: la diferencia es jurídica
El artículo 2° define la anonimización como el procedimiento irreversible en virtud del cual un dato personal no puede vincularse o asociarse a una persona determinada, ni permitir su identificación, por haberse destruido o eliminado el nexo con la información que la identifica. Y cierra con la consecuencia relevante: un dato anonimizado deja de ser un dato personal. Queda, por tanto, fuera del ámbito de aplicación de la norma.
La seudonimización, definida en el mismo artículo, opera de otro modo: es un tratamiento que impide atribuir los datos a un titular sin utilizar información adicional, siempre que esa información figure por separado y bajo medidas técnicas y organizativas que impidan la reidentificación. El dato seudonimizado sigue siendo un dato personal. La ley la menciona expresamente como medida de seguridad en el artículo 14 quinquies, y ese es su lugar: reduce el riesgo, no extingue las obligaciones. Toda aplicación práctica de la anonimización a los requisitos de la Ley 21.719 parte de esa distinción.
Para un arquitecto, la distinción se traduce en una pregunta concreta: ¿existe en algún punto de la organización una tabla, una clave o un procedimiento que permita revertir la transformación? Si la respuesta es afirmativa, el proceso es de seudonimización, y ese ambiente permanece sujeto a la ley en su totalidad.
La irreversibilidad que exige la definición legal tampoco se alcanza suprimiendo únicamente los identificadores directos. Los proyectos de enmascaramiento construidos con scripts propios suelen tratar el dato columna por columna, sin evaluar si la combinación de atributos restantes permite singularizar a una persona. Una anonimización coherente con la exigencia de irreversibilidad requiere tratar el conjunto completo e incorporar la evaluación del riesgo de reidentificación como parte del procedimiento.
Todo ello debe ocurrir sin degradar la utilidad del dato. Si la transformación rompe la integridad referencial entre esquemas, invalida los formatos que el sistema verifica o altera la distribución que la prueba necesitaba medir, el equipo de desarrollo volverá a solicitar producción. Ese es el punto donde fracasan estos proyectos: no por ausencia de controles, sino porque el resultado no era utilizable.
Cómo prepararse para la Ley 21.719 antes de diciembre de 2026
Cinco preguntas ordenan el diagnóstico, y todas deben responderse con evidencia documentada.
Cuántos ambientes no productivos existen, quién autorizó su creación y en qué fecha se refrescaron por última vez desde producción. En qué tablas y columnas de esos ambientes residen datos personales, y cuáles califican como datos sensibles bajo la definición de la ley. Quién dispone hoy de acceso de lectura a esas bases, incluidos los proveedores externos. Qué registro queda cuando alguien consulta esa información. Y de qué manera se acredita ante un fiscalizador que el dato presente en QA no permite reidentificar a ninguna persona.
Esta última pregunta ordena a las anteriores, y no es una exigencia inventada: el artículo 3° dispone que el responsable deberá ser capaz de acreditar la licitud del tratamiento que realiza. La carga de la prueba es del responsable. Sin trazabilidad del proceso —origen del conjunto, reglas aplicadas, autorización correspondiente y destino de la entrega— la afirmación de que los ambientes de prueba están anonimizados carece de valor probatorio. Formalizar ese circuito es, en la práctica, lo que resuelve una estrategia de gestión de datos de prueba.
Para quien prefiera un punto de partida estructurado, la guía de preparación para la Ley 21.719 recoge las obligaciones que afectan a los equipos técnicos, el papel de la anonimización en entornos de desarrollo y pruebas, y un autodiagnóstico para evaluar el grado de preparación de la organización.
Dónde se sitúa Gigantics
El reto operativo es real y no se resuelve mediante una directiva interna. El desarrollo, las pruebas y la analítica requieren datos que se comporten como los de producción, disponibles en plazos compatibles con los ciclos de entrega. Restringir el acceso a producción sin un reemplazo utilizable conduce de forma sistemática al mismo resultado: excepciones autorizadas, copias informales y un inventario incompleto.
Gigantics opera sobre ese punto con tres capacidades que se corresponden con obligaciones concretas de la ley. El descubrimiento y la clasificación de datos personales en las bases de origen responden a la necesidad de saber qué se trata y dónde, condición previa de cualquier acreditación de licitud. La anonimización y el enmascaramiento con preservación de la integridad referencial y del comportamiento del dato permiten aplicar la transformación que el artículo 3° contempla como destino del dato, sin degradar la utilidad que los entornos de trabajo requieren. Y el aprovisionamiento repetible de subconjuntos a cada ambiente, con registro de cada operación, produce el rastro documental —qué reglas se aplicaron sobre qué campos, bajo qué autorización y hacia qué destino— con el que se acredita el cumplimiento de los principios de proporcionalidad y seguridad ante la Agencia.