La retención de datos personales suele quedar resuelta por una costumbre: conservar todo mientras exista espacio. Así se acumulan postulaciones antiguas, exportaciones del CRM y carpetas de clientes sin actividad. Para una empresa, el problema es explicar por qué sigue necesitando esos datos, quién responde por ellos y qué ocurrirá cuando termine esa necesidad. Comprar almacenamiento no resuelve esa decisión.

Una política útil conecta cada conjunto de datos con una finalidad, un plazo justificable y un evento que permita calcularlo. Esa definición corresponde al negocio y debe considerar las obligaciones aplicables. TI necesita esas decisiones para implementarlas; no debería tener que inventarlas al configurar una aplicación.

Retención de datos personales: un plazo necesita una razón

No existe un número de años que sirva para toda la información de una empresa. Un documento sujeto a una obligación de conservación y una lista de interesados en una campaña pueden requerir tratamientos distintos. El criterio debe identificar qué obliga o justifica mantener los datos y hasta cuándo. La salvaguarda 3.4 de CIS propone documentar límites mínimos y máximos de retención: conservar menos de lo necesario también puede ser un problema.

En Chile, el artículo 6 de la Ley 19.628 ya contempla eliminar o cancelar datos cuando su almacenamiento carece de fundamento legal o han caducado. Las modificaciones introducidas por la Ley 21.719, con entrada en vigor el 1 de diciembre de 2026, explicitan la conservación limitada al tiempo necesario para la finalidad, con excepciones previstas legalmente. Esto exige revisar cada proceso y sus obligaciones; no autoriza una eliminación masiva basada solamente en la antigüedad del archivo.

Definir desde qué momento corre el plazo

Un plazo resulta ambiguo si nadie sabe cuándo empieza. Puede depender del cierre de una solicitud, del término de una relación contractual o de otro hecho pertinente al proceso. La fecha de creación de una copia no debería reiniciar automáticamente esa cuenta.

Pensemos en selección de personal. Los antecedentes de una candidatura cerrada y los documentos de una persona contratada cumplen finalidades diferentes. Aplicarles una regla idéntica por estar en la misma plataforma evita una decisión incómoda, pero no la resuelve. El dueño del proceso debe explicar la diferencia y validar su tratamiento con quienes conocen las exigencias legales correspondientes.

Las copias también forman parte del problema

Eliminar un registro de la aplicación principal puede dejar intactos sus datos en planillas, correos, ambientes de prueba o servicios externos. Por eso, el mapa de datos personales y sus flujos ayuda a delimitar dónde debe operar la regla. El inventario ubica la información; la política decide cuánto tiempo necesita conservarse.

Los respaldos requieren un tratamiento compatible con su propósito de recuperación. Como criterio de gestión, conviene definir su vencimiento, restringir el uso ordinario de los datos que contienen y prever qué ocurre si una restauración vuelve a introducir registros que ya debían retirarse. Una dificultad técnica necesita una solución evaluada y documentada, no convertirse en una excepción indefinida.

Las excepciones deben tener un responsable

Una controversia, investigación u obligación específica puede justificar suspender la eliminación de determinados antecedentes. La excepción debería delimitar qué información se preserva, su motivo, quién la autoriza y cuándo se revisará. Extender esa suspensión a toda una base de datos por comodidad multiplica la información retenida sin explicar su necesidad.

El Marco de Privacidad de NIST 1.0 relaciona las políticas de tratamiento y retención con responsabilidades y procesos de revisión. Sirve como referencia de gobierno, no como sustituto de la legislación chilena. En la práctica, negocio define la necesidad; asesoría jurídica contrasta obligaciones; y TI evalúa si la regla puede cumplirse en aplicaciones, archivos y proveedores.

Decidir el destino y comprobar el resultado

Cuando termina la conservación justificada, eliminar y anonimizar son decisiones distintas. Quitar el nombre no garantiza anonimato si otros campos permiten identificar a la persona. Si la empresa necesita conservar estadísticas, debe evaluar si puede obtenerlas sin mantener registros identificables. Cuando corresponde retirar soportes, el borrado seguro de datos aborda la ejecución técnica de una decisión que ya debería estar resuelta.

La evidencia útil no se limita a una política aprobada. Una muestra de registros vencidos permite comprobar si la regla funciona, si existen copias olvidadas y si las excepciones siguen justificadas. Los hallazgos deberían llevar a corregir el proceso y asignar responsables, sin convertir la revisión en otra planilla abandonada.

Si la empresa conserva información por inercia, conviene revisar sus criterios antes de automatizar eliminaciones. El servicio de protección de datos personales de AllDefense permite abordar esa conversación desde los procesos y los riesgos de la organización.

Fuentes consultadas

• BCN: Ley 19.628, artículo 6 y Ley 21.719, proporcionalidad y disposiciones transitorias.
• CIS Controls: salvaguarda 3.4 sobre retención de datos.
• NIST Privacy Framework 1.0: políticas, responsabilidades y gestión del tratamiento.

Rodrigo Zamora

Un notebook sale de la empresa porque terminó su arriendo, cambió su usuario o dejó de funcionar. El retiro está aprobado y el activo desaparece del inventario. Sin embargo, eso no demuestra que hayan desaparecido las planillas de remuneraciones, los documentos de clientes o las copias de trabajo que guardaba. El borrado seguro de datos permite abordar ese cierre: decidir cómo tratar la información residual y qué evidencia aceptar antes de entregar el equipo.

Para gerencia, TI y quienes supervisan la privacidad, la pregunta útil es qué autoriza la salida de cada soporte. Una orden de transporte acredita un traslado; una factura de reciclaje acredita un servicio. Ninguna reemplaza por sí sola la evidencia sobre los datos.

Qué significa un borrado seguro de datos

La guía NIST SP 800-88 Rev. 2 aborda la sanitización como un proceso que vuelve inviable acceder a los datos objetivo frente a un nivel de esfuerzo determinado. Distingue clear, orientado a impedir recuperaciones simples mediante la interfaz habitual; purge, que ofrece protección frente a técnicas de laboratorio más avanzadas; y destroy, que además deja el soporte inutilizable para almacenar datos.

Esas categorías no son nombres intercambiables de una aplicación. La elección depende de la sensibilidad de la información, del soporte y de su destino. Borrar archivos o formatear no demuestra automáticamente que se haya logrado el resultado requerido. Tampoco corresponde exigir muchas pasadas de sobrescritura como indicador universal de seguridad: en ciertos SSD, las áreas no accesibles al usuario hacen insuficiente ese criterio.

La discusión comienza antes del retiro. El Control 3 de CIS vincula identificación, clasificación, manejo, conservación y disposición de los datos. Si la empresa desconoce qué información guardaba el equipo, le faltará una base para justificar el tratamiento elegido.

Resolver primero qué conservar y qué eliminar

Retirar un equipo no autoriza a eliminar toda su información. El responsable del proceso debe resolver qué documentos siguen siendo necesarios y dónde quedarán disponibles, considerando las restricciones aplicables con las áreas competentes. Copiar todo a una carpeta compartida para después olvidarla tampoco cierra el problema: solo cambia su ubicación.

El mapa de datos personales ayuda a ubicar esas dependencias. Después corresponde separar dos decisiones: autorizar la conservación de lo necesario y aprobar la eliminación del soporte que cambia de manos. La evaluación de tecnología sin soporte responde cuándo renovar o retirar; aquí se trata de comprobar qué ocurre con los datos al hacerlo.

Un certificado debe poder vincularse con el soporte

Imagine una devolución de veinte computadores arrendados. El proveedor entrega un certificado global, pero dos unidades habían recibido discos de reemplazo. Si el documento solo identifica los computadores, queda abierta una pregunta: ¿cuáles soportes fueron tratados y dónde terminaron los retirados? Es un ejemplo hipotético de una brecha de trazabilidad, no una acusación contra un proveedor.

NIST propone registrar antecedentes como identificación del medio, método y técnica utilizados, herramientas, resultado, responsables y destino. Esa información permite relacionar la evidencia con el activo concreto. Un documento comercial genérico no responde necesariamente esas preguntas.

Las aclaraciones oficiales de NIST distinguen verificar el resultado técnico de validar su suficiencia. La primera actividad revisa la ejecución y sus errores; la segunda evalúa si lo obtenido resulta aceptable para los datos involucrados. Un mensaje de éxito no reemplaza esa decisión.

Tratar las excepciones antes de la entrega

Un disco averiado o un equipo que no enciende requiere una resolución explícita. Conviene mantenerlo bajo custodia mientras se determina una alternativa; incluirlo en el mismo lote que los equipos tratados diluye una diferencia relevante. El contrato de retiro debería permitir separar estos casos y conservar evidencia de su destino.

El borrado criptográfico tampoco consiste simplemente en quitar una contraseña. NIST exige condiciones sobre el cifrado previo, su robustez y la eliminación de las claves pertinentes. Si se desconoce cómo fue protegido el soporte, corresponde evaluar la alternativa con especialistas, no presumir que estar cifrado resuelve cualquier escenario.

Una revisión útil puede comenzar con una muestra de retiros recientes: reconstruir qué salió, quién autorizó el tratamiento y qué evidencia quedó. Si esas respuestas no coinciden, la prioridad es corregir el proceso antes del siguiente lote. AllDefense aborda brechas del ciclo de vida mediante su servicio de protección de datos personales. El resultado buscado es una decisión de retiro justificable, no acumular certificados que nadie puede relacionar con los equipos.

Rodrigo Zamora

Contratar una plataforma, externalizar remuneraciones o almacenar información en la nube no transfiere automáticamente las decisiones sobre los datos personales. La diferencia entre responsable y encargado del tratamiento define quién determina para qué se usan los datos, quién actúa siguiendo instrucciones y qué debe quedar regulado con el proveedor. Confundir estos papeles deja vacíos contractuales precisamente donde la empresa necesita demostrar control.

Responsable y encargado del tratamiento: la decisión separa los roles

El responsable determina los fines y los medios esenciales del tratamiento. Decide, por ejemplo, por qué se recopilan ciertos datos, qué resultado se busca, durante cuánto tiempo son necesarios y con quién pueden comunicarse. El encargado procesa información por cuenta del responsable y dentro del encargo recibido. Puede aportar capacidad técnica y proponer cómo prestar el servicio, pero no debería reutilizar los datos para una finalidad propia incompatible con las instrucciones.

La diferencia no depende solo del nombre escrito en el contrato. Importa observar quién toma las decisiones reales. Si un proveedor define por su cuenta una nueva finalidad o utiliza la información fuera del encargo, su posición puede dejar de corresponder a la de un simple encargado. La Ley 21.719 contempla que, bajo determinadas conductas ajenas a lo convenido, el tercero sea considerado responsable para los efectos legales correspondientes.

No todo proveedor ocupa un único papel

Una misma empresa puede actuar como encargada en una operación y como responsable en otra. Un proveedor tecnológico podría alojar una base de clientes siguiendo instrucciones y, a la vez, tratar los datos de contacto de sus propios usuarios para administrar la relación comercial. Son tratamientos distintos, con propósitos y responsabilidades que no conviene mezclar.

Tampoco basta con asumir que toda externalización convierte al proveedor en encargado. Si ambas partes deciden conjuntamente elementos determinantes del tratamiento, o si cada una persigue fines propios, el análisis cambia. La guía del Comité Europeo de Protección de Datos resulta útil como referencia comparada porque trata estas funciones como conceptos operativos: la actividad efectiva pesa más que la etiqueta elegida por las partes.

El contrato debe describir el tratamiento real

El régimen incorporado por la Ley 21.719 a la Ley 19.628 establece que el tratamiento mediante un tercero mandatario o encargado se regirá por contrato. El texto debe considerar el objeto y duración del encargo, su finalidad, los tipos de datos tratados, las categorías de titulares y los derechos y obligaciones de las partes. Estos elementos no son una cláusula decorativa: delimitan qué puede hacer el proveedor con la información.

Una descripción genérica, como “prestar servicios informáticos”, entrega poca claridad frente a una solicitud de derechos, un cambio de alcance o un incidente. El contrato debería corresponder al flujo verdadero: qué información recibe el proveedor, desde dónde, para qué operación, por cuánto tiempo y qué ocurre al finalizar. El mapa de datos personales ayuda a reunir esa base antes de negociar condiciones.

Subcontratar no debe borrar la trazabilidad

Los servicios digitales suelen apoyarse en otras compañías para alojamiento, soporte, mensajería o analítica. Esa cadena puede ser legítima, pero la organización necesita conocerla. La Ley 21.719 dispone que el encargado no podrá delegar total o parcialmente el encargo sin autorización específica y escrita del responsable, y mantiene su responsabilidad sobre lo delegado en los términos establecidos por la norma.

En la práctica, la autorización pierde valor si no se identifica al subencargado, la función que cumplirá y el lugar desde el cual tratará la información. También es importante que los compromisos relevantes sigan la cadena contractual. De otro modo, el responsable podría exigir controles a su proveedor directo que no alcanzan a la infraestructura donde finalmente residen o se procesan los datos.

Los derechos y la seguridad necesitan acuerdos operativos

Ante una solicitud de acceso, rectificación o supresión, el responsable debe saber qué información conserva el encargado y en qué plazo puede obtenerla o modificarla. Algo similar ocurre con la seguridad: se requiere acordar cómo se comunicarán incidentes, quién preservará evidencias, qué medidas se aplicarán y cómo se verificará el cierre del servicio. La obligación contractual debe poder ejecutarse, no quedar reducida a una declaración amplia de cumplimiento.

La profundidad del control dependerá del riesgo. Un servicio que trata datos sensibles o sostiene una operación crítica requiere mayor evidencia que un proveedor con acceso limitado a datos de contacto. Esta evaluación permite ajustar exigencias, revisiones y niveles de supervisión sin imponer el mismo tratamiento contractual a todas las relaciones.

Definir el rol antes de firmar evita correcciones tardías

La pregunta inicial no debería ser qué plantilla contractual utilizar, sino quién decide realmente el propósito y los elementos esenciales de cada tratamiento. Después corresponde identificar instrucciones, dependencias, subcontrataciones, medidas de seguridad y condiciones de término. Si el servicio ya existe, la misma revisión permite comparar el contrato con la operación y detectar diferencias.

AllDefense puede apoyar este análisis mediante sus servicios de Protección de Datos Personales y Revisión de Cumplimiento. El resultado esperado es una relación verificable: cada tratamiento con un propósito definido, instrucciones coherentes y responsabilidades que puedan demostrarse cuando el titular, la organización o la autoridad necesiten respuestas.

Fuentes consultadas

Biblioteca del Congreso Nacional: Ley 21.719; Biblioteca del Congreso Nacional: Ley 19.628, texto actualizado; Comité Europeo de Protección de Datos: Directrices 07/2020.

Rodrigo Zamora

Una empresa puede tener políticas de privacidad, cláusulas contractuales y controles técnicos, pero seguir sin saber con precisión dónde están sus datos personales. El mapa de datos personales permite ordenar esa realidad: identifica qué información se recopila, con qué finalidad, en qué sistemas circula, quién accede a ella, cuánto tiempo se conserva y qué terceros intervienen. Sin esa visión, las decisiones de cumplimiento suelen apoyarse en supuestos.

La Ley 21.719 no exige un documento con ese nombre. Sin embargo, obliga al responsable a acreditar la licitud del tratamiento, limitar los datos a finalidades determinadas, facilitar el ejercicio de derechos y adoptar medidas de seguridad acordes con la naturaleza y el riesgo del tratamiento. Cumplir esas obligaciones requiere conocer el recorrido real de la información, no solamente las aplicaciones que aparecen en un inventario tecnológico.

La Ley 21.719 exige entender el tratamiento

El texto legal incorpora principios de finalidad, proporcionalidad, responsabilidad, seguridad y transparencia. También reconoce derechos de acceso, rectificación, supresión, oposición, portabilidad y bloqueo. Para responder una solicitud de acceso, por ejemplo, la empresa necesita saber qué datos mantiene, su origen, los fines del tratamiento, los destinatarios y el período de conservación. Si esa información está dispersa entre áreas, proveedores y planillas, el problema no se resuelve instalando un portal de atención.

Lo mismo ocurre con la protección desde el diseño. La norma dispone que las medidas técnicas y organizativas deben aplicarse antes y durante el tratamiento. La decisión correcta depende del contexto: no requiere el mismo resguardo una base de contactos comerciales que un proceso con datos de salud, menores de edad, antecedentes financieros o perfilamiento automatizado.

Un mapa de datos personales no es una lista de sistemas

Un inventario de aplicaciones puede indicar que la empresa utiliza un CRM, una plataforma de remuneraciones y un servicio de marketing. El mapa debe ir más allá: relaciona cada proceso con las categorías de datos, sus titulares, la finalidad, el fundamento del tratamiento, los accesos, las integraciones, los encargados externos, la conservación y la eliminación. Esa relación permite detectar cuándo una misma información se replica en lugares que el área propietaria ya no controla.

En una operación de retail, por ejemplo, los datos pueden nacer en una compra, continuar en el sistema de fidelización, llegar a una plataforma de campañas y terminar en reportes descargados por usuarios internos. Revisar únicamente la base principal deja fuera integraciones, copias locales y servicios contratados. Allí suelen aparecer brechas de retención, permisos excesivos o usos secundarios que nunca fueron evaluados como un tratamiento distinto.

Dónde aparecen las brechas que la tecnología no corrige

Las plataformas de privacidad ayudan a administrar consentimientos, solicitudes o evaluaciones, pero necesitan información confiable. Si la empresa carga un inventario incompleto, automatiza una visión incompleta. El resultado puede ser una política que declara una finalidad mientras la operación utiliza los datos para otra, o una respuesta al titular que omite repositorios administrados por proveedores.

El mapa también revela decisiones que no pertenecen exclusivamente a TI. Negocio define para qué usa la información; Legal y Cumplimiento revisan su fundamento; Seguridad evalúa exposición y controles; Tecnología conoce integraciones y almacenamiento; Compras gestiona la relación con encargados. Cuando una sola área intenta reconstruir el ciclo completo, suele obtener una fotografía parcial.

Del inventario a decisiones basadas en riesgo

La Ley 21.719 exige medidas de seguridad proporcionales a la naturaleza, alcance, contexto y fines del tratamiento, junto con la probabilidad y gravedad de los riesgos para las personas. Además, contempla evaluaciones de impacto cuando una operación pueda producir un riesgo alto, incluidos ciertos tratamientos masivos, perfilamientos, monitoreo sistemático y uso de datos sensibles.

Un mapa de datos personales permite aplicar ese criterio. Ayuda a distinguir los procesos que requieren una revisión profunda de aquellos con exposición limitada, priorizar controles, identificar terceros críticos y definir dónde una evaluación de impacto resulta necesaria. También entrega una base verificable para una revisión de cumplimiento o una auditoría de seguridad, evitando evaluar controles sin conocer primero el tratamiento que deben proteger.

El resultado debe servir para decidir

El valor del levantamiento no está en producir una planilla extensa. Está en que la empresa pueda responder con claridad qué datos necesita, qué usos puede justificar, dónde se encuentran las copias, quién debe intervenir ante una solicitud o incidente y qué tratamientos concentran mayor riesgo. Si esas respuestas no existen, todavía falta conectar la documentación con la operación.

La preparación frente a la Ley 21.719 conviene comenzar por esa realidad operativa. AllDefense apoya a las organizaciones en el levantamiento de brechas, riesgos y medidas técnicas u organizativas mediante su servicio de protección de datos personales. La tecnología puede venir después, cuando la empresa ya sabe qué necesita controlar y por qué.

Fuentes

• Biblioteca del Congreso Nacional: Ley 21.719
• ISO/IEC 27701:2025 — Privacy information management systems
• European Data Protection Board: Secure personal data

Rodrigo Zamora