Preguntas sobre la Ley 21.719 de Protección de Datos Personales
Estas son las preguntas que dejaron los asistentes al webinar de Plutto, Buk y Carey sin resolver en vivo. Las agrupamos en tres bloques y las respondimos en detalle, con un enfoque general e informativo.
Prevención: este documento recoge algunas de las consultas formuladas por los asistentes al webinar y las responde con un enfoque general e informativo, sin constituir asesoría legal para un caso concreto. Los criterios aquí expuestos se basan en el estado de la normativa a la fecha de su elaboración y varios aspectos operativos de la Ley N° 21.719 quedan sujetos a reglamentos e instrucciones de la Agencia de Protección de Datos Personales, por lo que pueden precisarse o variar. Además, la calificación de los roles, las bases de licitud y la proporcionalidad de las medidas dependen de los flujos y circunstancias concretas de cada organización, de modo que su aplicación práctica requiere un análisis particular.
Bloque 1
Responsable, encargado y delegado: los roles en la Ley 21.719
¿Cómo fijar quién es el responsable de datos? ¿Basta con que esté en el papel o en el contrato, o debemos enfocarnos en las funciones?
La calificación de responsable es una cuestión meramente fáctica. Depende de quién decide, en los hechos, los fines y los medios del tratamiento: para qué se usan los datos y cómo. Por eso el contrato no constituye el rol, lo documenta.
La consecuencia práctica es más fuerte de lo que suele asumirse. Aunque un sujeto obligado tenga todos sus documentos en orden señalando que es encargado (acuerdos de tratamiento suscritos, registros de actividades de tratamiento completos, cláusulas impecables), si trata los datos para una finalidad distinta de la instruida, la ley no se limita a decir que asume más riesgo: dispone expresamente que se le considerará responsable para todos los efectos legales. Eso implica responder personalmente por las infracciones y, además, solidariamente con el responsable por los daños. El cambio de rol no requiere acuerdo ni declaración de nadie: opera por el solo hecho de desviarse del encargo. Ningún documento resiste una operación que lo contradice.
Ahora bien, que la calificación sea fáctica también funciona en el sentido inverso, y ahí está la oportunidad. Implica que el enfoque de protección de datos debe estar presente desde el diseño del producto y desde los documentos que regulan la relación. Un buen manejo de políticas, cláusulas y autorizaciones permite construir un relato que efectivamente concuerde con las obligaciones que cada parte asume como responsable o como encargado. El contrato no salva una realidad distinta, pero una realidad bien diseñada y bien documentada sí se sostiene.
Para fijar el rol en la práctica conviene contestar unas pocas preguntas operativas, más útiles que la etiqueta contractual. Pero con una precisión que evita el error más común: no cualquier decisión convierte a alguien en responsable. Un encargado toma decisiones todos los días (qué proveedor de hosting contrata, qué tecnología de cifrado aplica, cómo organiza sus equipos de soporte) ninguna de ellas lo transforma en responsable. Lo que define el rol son las decisiones determinantes sobre los fines y los medios: para qué se tratan los datos, qué categorías se recogen y de qué titulares, a quién se comunican y bajo qué base de licitud.
Hay dos zonas donde este análisis suele fallar. La primera son los proveedores que se declaran "responsables autónomos" sobre los datos que se les entregan: si es efectivo, la relación no se regula como un encargo sino como una comunicación entre responsables, con bases de licitud propias para cada uno, y conviene revisar si esa declaración se condice con lo que el servicio realmente hace. La segunda son los usos secundarios: analítica propia, mejora de producto, entrenamiento de modelos o campañas comerciales. Es el punto exacto donde un encargado se desliza hacia responsable sin que nadie lo advierta, y donde el rol cambia sin que se haya firmado nada nuevo.
En la práctica, conviene mapear los flujos de datos uno por uno, clasificar el rol por hechos y no por la carátula del contrato, dejar constancia escrita del análisis y de sus fundamentos, y revisar esa clasificación cada vez que cambie materialmente el servicio, se incorpore un subproveedor o aparezca un uso nuevo de los datos. Ese registro es, además, una de las mejores evidencias de diligencia si alguna vez hay que explicar el esquema ante la Agencia.
Resumen: El rol de responsable no lo decide el contrato, lo decide quién toma las decisiones importantes sobre los datos: para qué se recopilan, con quién se comparten y bajo qué reglas. El que decide eso es el responsable, aunque el contrato diga otra cosa.
El delegado de protección de datos personales debe ser independiente en su acción. ¿Debe ser externo? ¿Puede ser el oficial de cumplimiento o el sujeto responsable? ¿Cuál es su función específica?
La ley no exige que el delegado de protección de datos sea externo. Exige que cuente con autonomía respecto de la administración en las materias relacionadas con protección de datos y que, si desempeña otras funciones, estas no generen conflictos de interés. Además, el responsable debe proporcionarle medios y facultades suficientes para ejercer su función.
La designación del delegado es, en general, voluntaria. Sin embargo, si la organización adopta voluntariamente un modelo de prevención de infracciones, la designación del delegado y la definición de sus medios y facultades pasan a ser elementos mínimos de ese modelo.
Por tanto, el delegado puede ser interno o externo. La ley no privilegia ninguna alternativa. Un delegado interno puede conocer mejor los procesos y sistemas; uno externo puede aportar mayor distancia y especialización. También es posible combinar un responsable interno con apoyo externo, siempre que se preserve la autonomía, se eviten conflictos y existan medios efectivos para cumplir sus funciones.
El oficial de cumplimiento puede desempeñar simultáneamente esta función, porque la ley permite que el delegado tenga otras funciones. No obstante, debe verificarse caso a caso que no participe en decisiones que luego deba supervisar y que sus responsabilidades no comprometan su independencia.
Si por "sujeto responsable" se entiende el dueño o la máxima autoridad de una micro, pequeña o mediana empresa, podría asumir personalmente las tareas de delegado. En organizaciones de mayor tamaño, que la misma persona defina las finalidades y medios del tratamiento y supervise esas decisiones puede generar un conflicto de interés; por ello, debe preferirse una separación clara de funciones, salvo que pueda acreditarse autonomía efectiva.
En cuanto a sus funciones específicas, la ley las delimita con bastante detalle y conviene leerlas como un rol de asesoría y supervisión, más que de fiscalización interna. Al delegado le corresponde informar y asesorar al responsable y a quienes tratan datos bajo su dirección; promover y participar en el diseño e implementación de la política de protección de datos; supervisar su cumplimiento y el de la normativa; impulsar la formación del personal; asistir en la identificación de riesgos y en la definición de las medidas para mitigarlos; elaborar un plan anual de trabajo y rendir cuenta de su gestión; absolver las consultas de los titulares; y actuar como punto de contacto y contraparte de la Agencia, con deber de secreto sobre lo que conozca en el ejercicio del cargo. Conviene precisar, además, que designar un delegado no traslada hacia él la responsabilidad legal del responsable: el rol aporta capacidad técnica, orden y evidencia de diligencia, pero las obligaciones siguen radicadas en la organización.
Resumen: El delegado no tiene que ser externo, pero sí independiente: que nadie le pase por encima en temas de datos y que no tenga conflictos de interés. Puede ser interno, externo o el mismo oficial de cumplimiento, siempre que se cuide su autonomía. Ojo: nombrar un delegado no traspasa la responsabilidad legal, esa sigue siendo de la empresa.
La Agencia de Protección de Datos, ¿será la encargada de certificar los modelos de cumplimiento de protección de datos?
Sí, habrá una certificación, y la ley radica esa función en la Agencia. Lo que aún queda por precisar es cómo operará en la práctica: el reglamento deberá regular los requisitos, modalidades y procedimientos para implementar, certificar, registrar y supervisar esos modelos.
Conviene partir por un punto que ordena todo lo demás: el modelo de cumplimiento es voluntario, y por lo tanto la certificación también lo es. Nadie está obligado a adoptar un modelo de prevención de infracciones ni a someterlo a aprobación. La certificación aparece cuando la empresa decide voluntariamente someter su modelo a validación.
La pregunta natural es entonces para qué sirve. No es un seguro contra multas ni un eximente de responsabilidad: la certificación habilita una atenuante específica, al acreditar que la empresa cumplió diligentemente sus deberes de dirección y supervisión. Eso conecta con algo importante de esta ley: no es un régimen de responsabilidad estricta. Que ocurra un incidente no implica sanción automática; se evalúan las medidas de control que la empresa efectivamente adoptó. El modelo certificado es, precisamente, el vehículo para acreditar esas medidas. A eso se suma un efecto menos comentado: los modelos certificados quedan en un registro público, lo que tiene valor reputacional y comercial frente a clientes corporativos que hoy ya preguntan por esto en sus procesos de compra.
El certificado, además, no es perpetuo. Tiene una vigencia acotada (la ley la fija en tres años) y está sujeto a supervisión y a causales de revocación. Es decir, supone mantener el modelo vivo, no archivarlo una vez obtenido. Y no debe confundirse con las certificaciones privadas de seguridad de la información, como ISO 27001 o SOC 2: son mecanismos distintos, con alcances distintos, y una no reemplaza a la otra.
Resumen: Sí, la Agencia certificará modelos de cumplimiento, pero es voluntario. No te libra de multas, sirve como atenuante si demuestras que actuaste con diligencia, y da respaldo reputacional (queda en un registro público). Dura tres años, hay que mantenerlo vivo, y no es lo mismo que un ISO 27001 o SOC 2.
Bloque 2
Contratos y cláusulas con tus proveedores para la Ley de Protección de Datos Personales
¿Qué cláusulas se deben incorporar en los contratos de proveedores de servicios, como por ejemplo los subcontratistas de mano de obra o los servicios tecnológicos? Y por otra parte, ¿se debe modificar el contrato de los trabajadores contratados directamente por mi empresa?
Son dos conversaciones distintas y conviene no mezclarlas.
Con proveedores que tratan datos por cuenta de tu empresa (por ejemplo, servicios tecnológicos o plataformas), la ley define un contenido mínimo para el contrato de encargo, que incluye: qué datos recibe el proveedor, para qué puede usarlos, si puede o no subcontratar, qué medidas de seguridad aplica y qué ocurre con los datos al terminar la relación. Ese es el piso, pero puede variar según los distintos flujos de tratamiento.
Con los trabajadores propios, la respuesta suele sorprender: no se trata de copiar un DPA al contrato de trabajo. En Chile es común incluir cláusulas de autorización de uso de datos, pero en una relación laboral el consentimiento difícilmente es "libre" por la asimetría entre las partes. No se pide autorización al trabajador para pagarle el sueldo: eso se justifica en el cumplimiento del contrato. La tendencia es que los contratos laborales se simplifiquen en materia de datos y el peso se traslade a los avisos de privacidad y al reglamento interno, reservando el consentimiento para casos puntuales (beneficios voluntarios, control biométrico de asistencia, ciertos estándares corporativos).
Un buen punto de partida puede ser:
- Un anexo de tratamiento estandarizado para todo proveedor con acceso a datos personales. Rol, instrucciones, categorías de datos, seguridad, subencargados, aviso de incidentes y devolución o eliminación al término son buenas cláusulas para partir.
- Del lado laboral: aviso de privacidad claro, revisión del reglamento interno y una definición explícita de la base de licitud de cada tratamiento, a partir de un análisis previo, en lugar de pedir consentimiento para todo.
Resumen: Son dos temas distintos. Con proveedores que tratan tus datos, la ley pide un contrato de encargo con contenido mínimo: qué datos reciben, para qué, qué seguridad aplican, si pueden subcontratar y qué pasa al terminar. Con tus trabajadores no se trata de pedir autorización para todo, el peso se puede ir trasladando a los avisos de privacidad y al reglamento interno apoyados de otras bases de licitud, dejando el consentimiento solo para casos puntuales.
Si generamos un DPA, ¿debe estar sí o sí firmado por ambas partes? ¿O basta con el documento que generan algunas plataformas?
Lo relevante no es la firma manuscrita, sino poder acreditar que existe un acuerdo vinculante entre responsable y encargado, con el contenido que la ley exige y con evidencia de qué versión se aceptó y cuándo.
Un DPA unilateral o los términos estándar de una plataforma pueden servir, siempre que la aceptación sea inequívoca y el texto cubra efectivamente el flujo real: qué datos, para qué finalidades, qué subencargados, qué plazos y qué pasa al terminar. La postura más segura sigue siendo una aceptación electrónica trazable o la firma de ambas partes sobre un anexo de tratamiento. La debilidad típica de las políticas genéricas no es la firma: es que describen un servicio distinto del que efectivamente contrataste.
Por dónde partiríamos:
- Guardar evidencia de la versión aceptada, la fecha y las partes. Las plataformas actualizan sus términos y esa trazabilidad es la que se pide después.
- Contrastar el DPA estándar con tu flujo real. Si no cubre el contenido mínimo legal, o no refleja el servicio efectivamente contratado, deja abierta la puerta a sanciones.
Resumen: Lo importante no es la firma a mano, sino poder demostrar que hay un acuerdo válido, qué versión se aceptó y cuándo. Los términos estándar de una plataforma pueden servir si cubren tu caso real y la aceptación es clara. Guarda evidencia de la versión aceptada y revisa que el texto refleje el servicio que de verdad contrataste.
¿Qué pasa si ese proveedor es puntual, ocasional y no tengo un contrato, solo una orden de compra?
La orden de compra es, finalmente, un contrato. El problema no está en su forma sino en su contenido: casi nunca regula qué se espera de cada parte cuando aparece un problema.
Ese es el momento en que se nota. Ante un incidente, una orden de compra típica no dice en cuántas horas el proveedor debe avisar, qué medidas de seguridad se comprometió a aplicar, si podía o no derivar la tarea a un tercero, ni qué ocurre con la información una vez terminado el servicio. Nada de eso se puede improvisar el día que pasa algo.
Por eso conviene separar dos situaciones. Si el proveedor solo presta un servicio sin acceder a datos personales, la orden de compra puede ser suficiente, y basta con regular elementos adicionales cuando el servicio tenga sensibilidad operativa. Pero si la empresa actúa como responsable y contrata a un tercero que va a tratar datos por su cuenta, la orden de compra no basta: ahí se necesita un contrato de encargo con el contenido que exige la ley.
Un punto que suele pasar inadvertido: muchas órdenes de compra remiten a términos de referencia, condiciones generales o políticas internas (propias o del proveedor) que nadie leyó en detalle. Esas remisiones pueden estar imponiendo obligaciones no mapeadas, y conviene revisarlas antes de asumir que la orden es un documento simple.
Resumen: Una orden de compra también es un contrato. Si el proveedor no toca datos personales, puede bastar. Pero si trata datos por tu cuenta, la orden no alcanza: necesitas un contrato de encargo. Y cuidado cuando la orden de compra dice "según los términos de referencia" o "según las condiciones generales" y nadie leyó esos documentos: ahí pueden esconderse obligaciones para ambas partes, así que conviene leerlos antes.
¿Cómo afecta la ley a los acuerdos de confidencialidad con los proveedores? ¿Tendrán mayor relevancia legal?
Sí ganan relevancia, aunque por una razón algo distinta de la que uno esperaría: no porque el NDA se vuelva más poderoso, sino porque la confidencialidad de los datos personales dejó de depender de él. Hasta ahora, si querías que un proveedor guardara reserva sobre la información que le entregabas, tenías que pactarlo. Con la nueva ley, la confidencialidad pasa a ser un principio y un deber propio del tratamiento de datos personales: existe aunque nadie haya firmado un NDA, y alcanza tanto al responsable como al proveedor que trata datos por su cuenta. El NDA deja de ser la fuente de la obligación y pasa a ser una herramienta para administrarla y para acreditar diligencia.
De ahí viene el verdadero cambio de peso. Antes, romper la confidencialidad sobre datos personales era, en lo principal, un incumplimiento entre privados, con las consecuencias que las partes hubieran acordado. Ahora ese mismo hecho puede además constituir una infracción frente a la Agencia, con un tercero fiscalizando y sancionando. La conducta no cambió; sí cambió quién puede reclamar por ella.
Tres puntos que conviene revisar en los NDA vigentes:
- Los plazos. Muchos NDA fijan una vigencia de confidencialidad de dos o tres años. Ese plazo acota lo que las partes se deben entre sí, pero no acota el deber legal sobre los datos personales, que se rige por su propia lógica. Un NDA vencido no es una autorización.
- Las exclusiones. Es estándar excluir de la confidencialidad la "información que se haya hecho pública". Aplicada sin matices a datos personales, esa cláusula es riesgosa: el dato de fuente pública dejó de tener exención automática y sigue exigiendo una base de licitud demostrable. Que un dato sea consultable no lo vuelve de libre disposición.
- El objeto. Un NDA generalmente regula qué se puede contar; el tratamiento de datos personales exige además definir qué se puede hacer con ellos (para qué, por cuánto tiempo, con quién se comparten y qué ocurre al terminar la relación). Son planos distintos y conviene que ambos estén cubiertos, sea en un mismo instrumento o en un anexo.
Resumen: Los NDA ganan relevancia, pero cambia la lógica: ahora la confidencialidad de los datos personales existe por ley aunque nadie firme un NDA, y un tercero (la Agencia) puede sancionar. Revisa tres cosas en tus NDA actuales: los plazos (el deber legal no vence a los 2 o 3 años), las exclusiones ("información pública" no libera los datos personales) y el objeto (además de qué se puede contar, hay que definir qué se puede hacer con los datos).
¿Es necesario incorporar cláusulas de protección de datos personales en aquellos contratos suscritos con anterioridad a la entrada en vigor de la Ley N° 21.719 que actualmente no contemplan disposiciones sobre esta materia?
Sí, conviene hacerlo, y es uno de los frentes que más tiempo toma, porque depende también de la disposición de cada contraparte.
La entrada en vigencia no valida hacia atrás lo ya firmado. La ley no anula los contratos anteriores ni exige reabrir toda la carpeta contractual, pero sus obligaciones recaen sobre el tratamiento de datos, que es una actividad continua: si ese tratamiento sigue ocurriendo después de la entrada en vigencia, debe cumplir el estándar legal con independencia de cuándo se firmó el contrato que lo sustenta. Y el contrato es, además, donde ese cumplimiento se demuestra.
Al revisar contratos antiguos, lo que suele faltar no es una cláusula puntual sino el esqueleto completo del encargo: qué datos recibe el proveedor y para qué puede usarlos, reglas de subcontratación, medidas de seguridad, plazo de aviso ante incidentes y qué ocurre con la información al terminar la relación. Son justamente los puntos que se vuelven urgentes el día que pasa algo, y ese día ya es tarde para negociarlos.
Por dónde partiríamos:
- Priorizar por riesgo y no por orden de archivo: primero los proveedores que tratan más datos, datos sensibles o datos de más titulares.
- Aprovechar las ventanas de renovación, y revisar las renovaciones automáticas. Si nadie hace nada, esos contratos se prorrogan con el texto antiguo y el problema se traslada intacto.
Resumen: Sí, conviene actualizar los contratos antiguos si el tratamiento de datos sigue ocurriendo. La ley no anula lo ya firmado, pero sus obligaciones aplican igual. Empieza por los proveedores que tratan más datos o datos sensibles, y aprovecha las renovaciones para meter las cláusulas antes de que los contratos se prorroguen solos con el texto viejo.
Bloque 3
Cómo auditar y gestionar a tus proveedores bajo la Ley 21.719
¿Es posible dar algún ejemplo más concreto de cómo prepararse? Se habla de "conocer al proveedor", pero ¿conocer qué cosa?
Conocer al proveedor no es conocer su reputación comercial: es conocer el tratamiento real que hace de tus datos. Qué datos toca, para qué, dónde los guarda, quién accede, con qué subencargados trabaja (incluidos modelos de IA), qué seguridad aplica, en cuánto tiempo te avisa una brecha y qué hace con la información cuando termina el contrato son algunas de las preguntas que hay que ir haciendo.
Una forma simple de empezar la conversación: tomar los tres a cinco proveedores que más datos de personas tocan y mandarles un correo con cuatro preguntas.
- Rol y contrato. ¿Bajo qué rol tratan datos personales: qué datos tratan, para qué y por cuánto tiempo? ¿Está reflejado en nuestro contrato?
- Subproveedores. ¿Qué subproveedores utilizan para la prestación de los servicios?
- Incidentes y seguridad. ¿En cuántas horas nos avisan una brecha, por contrato? ¿Qué principales medidas de seguridad tienen aplicadas a la fecha?
- Terminación. ¿Dónde quedan nuestros datos al terminar la relación, cómo los recuperamos y en qué plazo se eliminan?
Resumen: Conocer al proveedor es saber qué hace de verdad con tus datos: qué toca, dónde los guarda, quién accede, con qué subcontratistas trabaja, qué seguridad aplica y qué pasa al terminar el contrato.
¿Podemos establecer una cláusula en el contrato con el proveedor que nos permita realizar auditorías a sus procedimientos? ¿Cuál es la frecuencia recomendable? ¿La ley establece la frecuencia?
Sí, y de hecho es una cláusula muy habitual en el esquema Responsable/Encargado. No es obligatoria, así que puede haber negociación: puede depender de las políticas internas del proveedor, de quién asume el costo, en qué condiciones y con qué alcance.
Un buen argumento para defenderla es que el encargado es, en el fondo, un mandatario: si actúa por cuenta del Responsable y bajo sus instrucciones, poder revisar el estado de ejecución del encargo es una herramienta lógica del mandante. Dicho eso, la cláusula no abre una puerta indiscriminada de control sobre el proveedor, ni exime de responsabilidad al Responsable por el solo hecho de tenerla o haberla ejercido.
¿Y cada cuánto hay que auditar?
La ley no fija una frecuencia. No hay un "una vez al año" que cumplir ni un plazo que se pueda incumplir por sí solo. Lo que sí supone es que las medidas de protección se verifiquen periódicamente y que la empresa pueda mostrar un criterio detrás de esa periodicidad, en línea con la lógica de gestión de riesgos sobre la que se construye toda la normativa. Por ejemplo, segmentar por riesgo: no es lo mismo un proveedor con acceso a datos sensibles que uno que solo trata datos de fuente pública. Otro ejemplo es establecer auditorías por gatillantes que revelen riesgo, como un cambio de subproveedores o un incidente.
Resumen: Sí, puedes incluir una cláusula para auditar al proveedor; es habitual, aunque no obligatoria, así que se negocia. La ley no fija cada cuánto: la idea es revisar según el riesgo (más seguido si tratan datos sensibles) y auditar cuando pase algo que lo amerite, como un cambio de subcontratista o un incidente.
¿Quieres el ebook completo?
Toda esta información, con más contexto y recomendaciones prácticas, está en un ebook descargable sobre la Ley 21.719.