La gestión de datos personales dejó de ser una tarea administrativa o técnica para convertirse en un desafío estratégico prioritario. Con la Ley 21.719, las organizaciones enfrentan nuevas exigencias que requieren una coordinación absoluta entre diversos equipos y roles. Definir con claridad quién hace qué entre el DPO, el responsable de datos, TI y las áreas de negocio es crítico para evitar sanciones y operar eficientemente sin duplicar esfuerzos.
Dónde surgen las fricciones entre DPO, TI y negocio
La entrada en vigencia de la Ley 21.719 elevó significativamente el estándar de responsabilidad organizacional. Con multas que pueden alcanzar las 20.000 UTM en casos gravísimos, la pregunta ya no es solo si la empresa cumple, sino cómo coordina internamente ese cumplimiento.
En este contexto, la fricción no surge por mala intención, sino por una distribución poco clara de responsabilidades. Cuando no se define con precisión quién decide, quién ejecuta y quién supervisa, surgen duplicidades, vacíos operativos y riesgos innecesarios.
La normativa establece principios de seguridad y responsabilidad que exigen una colaboración transversal y impiden que la protección de datos se gestione en silos aislados. Creer que un solo departamento puede garantizar el cumplimiento es un error; la ley exige medidas técnicas y organizativas integradas, y la falta de comunicación entre áreas expone a la organización a sanciones directas y vulnerabilidades críticas.
La protección de datos ha dejado de ser un tema técnico o legal aislado y se ha convertido en un ejercicio de coordinación estructural.
El Delegado de Protección de Datos (DPO) según la Ley 21.719: Supervisor, no ejecutor
La Ley 21.719 establece que el DPO, o Delegado de Protección de Datos debe contar con autonomía respecto de la administración en el ejercicio de sus funciones. Su rol no es ejecutar la operación diaria, sino informar, asesorar y supervisar el cumplimiento normativo, garantizando que sus tareas no generen conflictos de intereses con otras responsabilidades dentro de la organización.
Para delimitar correctamente su alcance, es fundamental distinguir sus atribuciones de las tareas operativas:
Lo que SÍ hace el DPO:
- Informa y asesora: Guía al responsable de datos y a los empleados sobre las obligaciones legales y reglamentarias que deben cumplir (Art. 50, letra a). Promueve el entrenamiento y participación que fomenten la formación de quienes participan en el tratamiento de datos.
- Supervisa el cumplimiento: Vigila la aplicación de la ley y de las políticas internas de privacidad dentro del ámbito de su competencia (Art. 50, letra c).
- Gestiona riesgos: Asiste en la identificación de riesgos asociados al tratamiento y propone medidas para resguardar los derechos de los titulares (Art. 50, letra e).
- Interlocutor oficial: Actúa como punto de contacto y cooperación con la Agencia de Protección de Datos Personales (Art. 50, letra h).
Lo que NO hace el DPO:
- No toma decisiones de negocio: No define los fines y medios del tratamiento, ya que esa es la función exclusiva del Responsable de Datos (Art. 2, letra n).
- No implementa seguridad técnica: No es quien configura firewalls o aplica parches; la implementación de medidas técnicas y organizativas de seguridad corresponde a las áreas de TI y Seguridad bajo la dirección del Responsable (Art. 14 quinquies).
- No asume roles en conflicto: No puede ejercer funciones que comprometan su independencia o fiscalización, como aprobar la viabilidad comercial de un producto que él mismo debe auditar.
El Responsable de Datos: Quién decide los fines y los medios
El "Responsable de Datos" no es un cargo técnico, es la entidad que detenta el poder de decisión. La ley lo define explícitamente como la persona natural o jurídica que determina los fines y medios del tratamiento, convirtiéndolo en el dueño absoluto del riesgo regulatorio. No puede delegar su responsabilidad final ni escudarse detrás de proveedores externos.
Sus obligaciones son intransferibles y estructuran la base del cumplimiento legal:
- Definición de propósito: Es quien decide para qué se usan los datos y debe asegurar que el tratamiento se limite estrictamente a esos fines.
- Garantía de seguridad: Debe adoptar las medidas necesarias para asegurar la confidencialidad, integridad, disponibilidad y resiliencia de los sistemas.
- Carga de la prueba: Le corresponde acreditar ante la autoridad que el tratamiento de datos fue realizado de forma lícita y leal.
Para evitar confusiones operativas, la distinción de roles es clave:
- TI construye la "bóveda": Implementa las medidas técnicas y organizativas, como el cifrado y la seudonimización, para garantizar la seguridad adecuada al riesgo.
- El DPO verifica la cerradura: Supervisa el cumplimiento de la ley y las políticas internas dentro de su ámbito de competencia.
- El Responsable decide el contenido: Determina qué información se ingresa al sistema y asume la responsabilidad legal si decide almacenar o procesar datos de manera ilícita.
TI: Los arquitectos de la seguridad
El área de Tecnología de la Información (TI), usualmente junto a un Director de Seguridad de la Información (CISO), funcionan como los ejecutores de la protección técnica. Lo ideal es, junto al responsable de datos, implementar medidas que garanticen la confidencialidad, integridad, disponibilidad y resiliencia de los sistemas. Esto implica desplegar cifrado, seudonimización y protocolos de recuperación ante incidentes.
Existe un límite preciso en su actuación: TI provee la infraestructura segura, pero no decide el ciclo de vida del dato. No les corresponde determinar los fines del tratamiento ni los plazos de conservación, variables regidas por los principios de finalidad y proporcionalidad que debe definir el negocio.
Lo que SÍ hacen:
- Implementan controles técnicos: Aplican cifrado y medidas de seguridad acordes al riesgo y al estado de la técnica.
- Garantizan la continuidad: Aseguran la capacidad de restaurar el acceso a los datos de forma rápida tras un incidente físico o técnico.
- Verifican la eficacia: Realizan evaluaciones regulares para comprobar que las medidas técnicas y organizativas funcionan correctamente.
- Detectan vulneraciones: Identifican brechas de seguridad para reportarlas y permitir la gestión del incidente.
Lo que NO hacen:
- No definen la retención: No deciden por cuánto tiempo se almacenan los datos; solo ejecutan la eliminación cuando se cumple el plazo legal o comercial.
- No autorizan nuevos usos: No tienen potestad para habilitar el uso de bases de datos para finalidades distintas a las originales sin validación del responsable.
- No determinan la licitud: No evalúan si existe consentimiento o interés legítimo para procesar la información, ya que esa es una definición legal y estratégica.
Responsabilidades compartidas: Dónde nacen las fricciones
La normativa impone obligaciones que ninguna área puede resolver en solitario, generando zonas grises operativas donde la falta de coordinación transforma un requisito legal en una crisis interna. Mientras el Responsable de Datos persigue objetivos estratégicos y TI asegura la infraestructura, la ley exige procesos integrados de seguridad y privacidad que requieren una sincronización perfecta para evitar sanciones.
El peligro del “Compliance Huérfano”
Las zonas grises entre departamentos suelen ser el lugar donde el cumplimiento se desmorona. Llamamos “Compliance Huérfano” a aquellas obligaciones críticas que, por no encajar con exactitud en la descripción de cargo tradicional de TI, Legal o Negocio, quedan sin un dueño claro. En la práctica, son tareas que todos asumen que "alguien más" está gestionando, hasta que la Agencia notifica una fiscalización o una multa.
Estos son tres ejemplos clásicos de tareas huérfanas que generan riesgo inmediato:
- Inventarios de datos invisibles (Shadow IT): Ocurre cuando un área de negocio contrata un software o servicio en la nube para procesar datos de clientes sin validarlo con TI ni informar al DPO. Esto genera flujos de información que no aplican las medidas de protección desde el diseño y por defecto exigidas por la ley, dejando al Responsable ciego sobre qué datos tiene y dónde están.
- Solicitudes ARCO en el limbo administrativo: Un titular ejerce su derecho de supresión enviando un correo a atención al cliente. El equipo de soporte lo reenvía a Legal porque "suena a abogado", y Legal espera que TI borre el registro. Sin un proceso definido, el plazo legal de 30 días corridos vence sin respuesta , convirtiendo una gestión administrativa de un derecho ARCO en una infracción sancionable.
- La retención de datos "por si acaso": TI mantiene copias de seguridad antiguas y Negocio conserva historiales de ex-clientes indefinidamente para posibles análisis futuros. Nadie asume la responsabilidad de ejecutar la eliminación o anonimización, violando directamente el principio de proporcionalidad, que obliga a suprimir los datos una vez que se ha cumplido la finalidad para la que fueron recolectados.
Cómo estructurar la gobernanza: Modelo RACI práctico
Para eliminar las zonas grises y asegurar que cada obligación de la Ley 21.719 tenga un dueño claro, las organizaciones deben implementar herramientas de gestión y estructuras probadas. Un modelo RACI no solo asigna tareas, sino que define la responsabilidad final ante la autoridad y el negocio, evitando que las funciones críticas queden sin ejecución por falta de definición o suposiciones erróneas.
Esta matriz permite visualizar quién debe actuar en cada etapa del cumplimiento normativo:
- R (Responsable de ejecución): Es quien realiza la actividad técnica o administrativa. Por ejemplo, TI ejecutando parches de seguridad o Legal redactando cláusulas contractuales.
- A (Aprobador / Accountable): Es quien rinde cuentas por el resultado y tiene la última palabra. Según la ley, este rol recae en el Responsable de Datos (la organización representada por su máxima autoridad), quien responde por las sanciones.
- C (Consultado): Son los expertos cuyo input es bidireccional y necesario antes de tomar una decisión. Este es el rol natural del DPO, quien debe informar y asesorar sobre los riesgos y el cumplimiento.
- I (Informado): Son aquellos que necesitan saber el resultado de una acción o decisión, como el área de comunicaciones o atención al cliente tras un incidente.
Ejemplo aplicado: Gestión de una Vulneración de Seguridad (Art. 14 sexies)
En el caso de una filtración de datos que genere riesgos para los titulares, la matriz RACI clarifica el flujo de trabajo para cumplir con el reporte obligatorio a la Agencia y a los afectados:
- Detección y contención técnica del incidente:
- R (TI / CISO): Detecta la brecha, aísla los sistemas afectados y ejecuta los protocolos de recuperación.
- A (Gerente de Tecnología): Aprueba los recursos necesarios para la contención.
- C (DPO): Es consultado sobre las implicancias normativas inmediatas.
- I (Negocio): Es informado inmediatamente sobre la interrupción operativa de sus servicios.
- Evaluación de riesgo para los derechos de los titulares:
- R (DPO / Legal): Evalúa si la vulneración representa un riesgo razonable para los derechos y libertades de las personas, determinando si es obligatorio reportar.
- C (TI): Provee la información forense sobre qué datos fueron comprometidos.
- C (Negocio): Provee contexto sobre la sensibilidad comercial de los datos afectados y el perfil de los clientes.
- Comunicación a la Agencia y a los Titulares:
- R (DPO): Prepara y envía la notificación a la Agencia describiendo la naturaleza de la vulneración y sus efectos.
- A (Responsable de Datos / Directorio): Aprueba la comunicación pública o directa a los clientes afectados, asumiendo la responsabilidad corporativa.
- R/I (Comunicaciones / Marketing): Recibe la información para modificar el mensaje y gestionar la reputación de la marca.
Aliados estratégicos de cumplimiento
La implementación exitosa de la Ley 21.719 depende menos de la burocracia y más de una arquitectura de colaboración fluida. Establecer canales formales en los que TI, Legal y Negocio se alineen desde el diseño elimina zonas grises y transforma la gobernanza en un habilitador de confianza, no en un freno operativo.
Pero la ley no exige solo estructuras claras, sino responsabilidad demostrable. No basta con definir roles en una matriz RACI: la organización debe poder acreditar que sus medidas técnicas funcionan y que los riesgos están gestionados de manera efectiva.
En entornos híbridos, donde los datos personales circulan a través de múltiples dispositivos, el endpoint se convierte en un punto crítico de control. Sin visibilidad sobre qué equipos acceden a información sensible, qué protecciones tienen activas y cómo se responde ante una vulneración, el cumplimiento pierde sustento probatorio.
La verdadera solidez surge cuando gobernanza y control técnico trabajan en conjunto. Claridad de roles, trazabilidad operativa y capacidad de demostrar diligencia son, finalmente, la base de un Modelo de Prevención de Infracciones robusto. Porque en el nuevo marco regulatorio chileno, lo que no puede probarse, simplemente no existe.
