La evaluación de impacto no la escribe el abogado: la ejecuta tu equipo de desarrollo
El artículo 15 ter hace cuatro preguntas, y tres solo puede responderlas con honestidad alguien capaz de abrir el esquema de la base de datos. Qué exige la ley, qué artefactos debería producir el equipo y por qué la carga de la prueba cambia el cálculo.
La evaluación de impacto en protección de datos se está vendiendo en Chile como un entregable legal. Un documento, con su portada, su metodología y su firma.
Lee el artículo 15 ter con atención y vas a encontrar otra cosa. La ley hace cuatro preguntas, y tres de ellas solo puede responderlas con honestidad alguien capaz de abrir el esquema de la base de datos y revisar quién consulta qué.
Esto no es un argumento contra los abogados. Es un argumento sobre quién tiene los datos para responder.
Qué exige el artículo 15 ter, exactamente
La obligación aparece cuando un tratamiento pueda producir "un alto riesgo para los derechos de las personas titulares", considerando su naturaleza, alcance, contexto, tecnología utilizada o fines. En ese caso hay que evaluar antes de iniciar las operaciones, no durante ni después.
Y la evaluación se requiere siempre en cuatro casos, que la ley lista textualmente:
a) Evaluación sistemática y exhaustiva de aspectos personales basada en tratamiento o decisiones automatizadas, como la elaboración de perfiles, que produzca efectos jurídicos significativos.
b) Tratamiento masivo de datos o a gran escala.
c) Tratamiento que implique observación o monitoreo sistemático de una zona de acceso público.
d) Tratamiento de datos sensibles y especialmente protegidos, en las hipótesis de excepción del consentimiento.
Sobre el contenido, el mismo artículo encarga a la Agencia de Protección de Datos Personales publicar una lista orientativa de tratamientos que requieren evaluación y las orientaciones mínimas para hacerla, considerando al menos la descripción de las operaciones, su finalidad, la evaluación de necesidad y proporcionalidad, la evaluación de riesgos y las medidas de mitigación.
Esos criterios todavía no existen
Varios artículos que circulan presentan esa lista como si fuera un requisito ya vigente. No lo es. La ley delega los criterios en la Agencia, y la Agencia aún no los ha publicado. Lo que sí está fijado es el piso: esos cinco elementos son el mínimo que las orientaciones deberán considerar.
Y una nota sobre cómo llamarla, porque vas a encontrar este trámite escrito de tres formas distintas según quién lo publique: AIPD, EIPD y DPIA, esta última heredada del RGPD europeo. La ley no usa ninguna de las tres. El artículo 15 ter la llama, simplemente, evaluación de impacto en protección de datos personales. Acá la escribo así, o "la evaluación" a secas — una sigla que cada consultora define a su manera no ayuda a nadie a entender de qué estamos hablando.
Una última precisión que se malinterpreta seguido: consultar a la Agencia es facultativo. El artículo dice que los responsables "podrán consultar" cuando el resultado muestre alto riesgo. No hay una autorización previa que esperar.
Las cuatro preguntas, traducidas
Toma los cinco elementos del inciso tercero y conviértelos en preguntas operativas. El cambio de idioma es revelador.
"Descripción de las operaciones de tratamiento" no se responde con el diagrama de la propuesta comercial. Se responde con el flujo real: qué endpoint recibe el dato, en qué tablas aterriza, qué jobs lo mueven, a qué servicios externos viaja, en qué logs queda escrito de paso, y en cuántos respaldos vive. Ese inventario casi nunca coincide con lo que el área de negocio cree que el sistema hace. La brecha entre ambos suele ser el hallazgo más valioso de todo el ejercicio.
"Necesidad y proporcionalidad" es, en términos de ingeniería, una pregunta sobre columnas. ¿Por qué existe ese campo? ¿Quién lo lee? ¿Cuándo fue la última vez que alguien lo consultó? El artículo 14 quáter refuerza este punto desde el otro lado: obliga a que, por defecto, solo se traten los datos "específicos y estrictamente necesarios", considerando el número de datos recogidos, la extensión del tratamiento, el plazo de conservación y su accesibilidad. Cuatro variables, las cuatro medibles en un sistema real.
"Evaluación de los riesgos" es modelamiento de amenazas con otro nombre. Qué pasa si se filtra esta tabla, quién queda expuesto y a qué. No es riesgo para la empresa: el artículo habla de riesgo para los derechos del titular, que es una cosa distinta y normalmente peor.
"Medidas de mitigación" es la única de las cuatro que la gente responde con facilidad, y también donde está la trampa. Volvemos a eso en un momento.
Los cuatro supuestos, leídos como ingeniero
El supuesto (a) no requiere inteligencia artificial. Un scoring de morosidad calculado con tres reglas en un CASE de SQL es una evaluación sistemática basada en tratamiento automatizado. Si de ese número depende que a alguien se le corte un servicio o se le niegue un beneficio, hay efecto jurídico significativo. La complejidad del algoritmo no es el criterio; la consecuencia para la persona, sí.
El supuesto (b), "tratamiento masivo de datos o a gran escala", es el más ambiguo de los cuatro y el que más gente descarta a la ligera. La ley no fija un número, y la lista orientativa de la Agencia todavía no existe. Mientras tanto, el criterio sensato no es cuántos registros tienes sino qué proporción de una población cubres y con qué granularidad. Un colegio con 900 alumnos tiene pocos registros en términos absolutos y prácticamente todos los datos de la vida escolar de 900 menores. Eso se parece bastante más a "gran escala" que una base de 50.000 correos para un newsletter.
El supuesto (c) aparece cuando hay cámaras. Si tu sistema integra CCTV, control de acceso biométrico o cualquier registro de presencia en un espacio al que entra público, cae acá sin mayor discusión.
El supuesto (d) es el que activa a la mayoría de los sistemas verticales. Datos de salud, biométricos, origen, afiliaciones. Un módulo de enfermería escolar, una ficha de lesiones en un gimnasio, un registro de alergias en un casino: todo eso es dato sensible, aunque el sistema completo no se sienta "de salud".
La parte que casi nadie menciona: la carga de la prueba
Acá está, para mí, el punto más relevante de toda la ley para un equipo técnico, y está en otro artículo.
El artículo 14 quinquies, después de listar las medidas de seguridad exigibles, cierra con esto: ante un incidente y en caso de controversia judicial o administrativa, corresponde al responsable acreditar "la existencia y el funcionamiento" de las medidas de seguridad adoptadas.
Existencia y funcionamiento son dos cosas distintas
La existencia se acredita con un documento: acá está la política de cifrado, acá el control de accesos. El funcionamiento no. Se acredita con evidencia de que el control operó durante el período en cuestión — logs con retención suficiente, registros de acceso, pruebas de restauración con fecha, y los resultados de las verificaciones periódicas que el mismo artículo exige.
Un equipo que documenta sus controles pero no puede demostrar que funcionaron tiene la mitad del trabajo hecho, y es la mitad barata.
El propio artículo 14 quinquies es bastante explícito sobre qué se espera, y su lista se lee como un backlog: seudonimización y cifrado de datos personales; capacidad de garantizar confidencialidad, integridad, disponibilidad y resiliencia permanentes; capacidad de restaurar el acceso a los datos de forma rápida tras un incidente; y un proceso de verificación y evaluación regulares de la eficacia de esas medidas.
Ninguna de esas cuatro se resuelve escribiendo un documento.
Los artefactos que debería producir el equipo
Si la evaluación la ejecuta ingeniería, sus entregables se parecen poco a un informe. En la práctica son estos, y casi todos son código o configuración:
Un inventario de datos generado desde el esquema, no transcrito a mano. Un script que recorra las tablas y clasifique columnas por categoría de dato es más confiable que una planilla, y se vuelve a correr cuando el esquema cambia. Una planilla queda obsoleta en el primer sprint.
Una matriz de accesos real, sacada de los roles y permisos que existen en el sistema, contrastada contra quién debería poder ver qué. La diferencia entre ambas columnas es el hallazgo.
La retención implementada como un job, no como una frase en una política. Si la política dice que los datos se eliminan a los cinco años y no hay nada que los elimine, la política es una declaración de incumplimiento firmada.
Evidencia de restauración, con fecha. Un respaldo que nunca se restauró no es un respaldo, es una intención. El artículo pide capacidad de restaurar de forma rápida; eso se prueba, no se declara.
Logs de acceso a datos sensibles con retención definida. Es lo que te permite responder "quién vio esto y cuándo" cuando la pregunta llegue, y llega justo cuando peor viene.
El registro de vulneraciones que exige el artículo 14 sexies. Vale la pena leerlo con cuidado si trabajas con menores: además de reportar a la Agencia sin dilaciones indebidas, hay que comunicar a los titulares cuando la vulneración afecta datos sensibles, datos de niños y niñas menores de catorce años, o datos económicos, financieros, bancarios o comerciales. Un sistema escolar cae en dos de esas tres categorías al mismo tiempo.
Dónde encaja en el ciclo de desarrollo
La tentación es tratarla como una fase previa: se hace una vez, se archiva, se pasa a construir.
No funciona así, y el motivo está en el texto. El artículo 14 quáter habla de aplicar medidas adecuadas desde el diseño "con anterioridad y durante el tratamiento". Durante. La evaluación describe un sistema que va a seguir cambiando, y cada cambio relevante la desactualiza.
Tratarla como un control recurrente es más honesto y bastante más barato. Un puñado de eventos debería disparar una revisión: una nueva categoría de dato en el modelo, una integración nueva que saca datos del sistema, un cambio en quién puede acceder a qué, y cualquier funcionalidad que tome decisiones automatizadas sobre personas. Si esos cuatro casos están escritos en la definición de terminado del equipo, la evaluación se mantiene viva sola.
El error que vas a ver más seguido
Hacer la evaluación sobre el sistema documentado en vez del sistema en producción.
Toda empresa con algunos años de operación tiene diferencias entre ambos. La integración que se armó rápido para un cliente y quedó. El reporte que alguien programó para que llegue por correo todos los lunes con más columnas de las necesarias. La copia de la base en el ambiente de pruebas con datos reales, que era temporal hace tres años. El endpoint que se dejó abierto para una migración que ya terminó.
Ninguna de esas cosas está en el diagrama. Todas están en el flujo de datos real, y son exactamente el tipo de hallazgo que la evaluación existe para encontrar.
Por eso el ejercicio sirve incluso a quien no está obligado a hacerlo. La evaluación es la excusa institucional para revisar, con tiempo pagado, algo que nadie revisa nunca.
Qué hacer esta semana
Si estás partiendo, tres cosas concretas y en este orden.
Primero, determina si caes en alguno de los cuatro supuestos del artículo 15 ter. Es una conversación de una hora con alguien que conozca el sistema, no un proyecto.
Segundo, corre el inventario desde el esquema antes de escribir una sola línea del documento. Es barato y va a cambiar lo que escribas: en la mayoría de los casos aparecen datos que nadie recordaba que se estaban guardando.
Tercero, haz la lista de lo que hoy no podrías acreditar. No lo que falta implementar — lo que está implementado pero no podrías demostrar que funcionó el mes pasado. Esa lista suele ser la más corta de escribir y la más incómoda de leer, y es la que más te va a servir el día que alguien pregunte.
La fecha de entrada en vigencia sigue siendo el 1 de diciembre de 2026. Hay un proyecto de prórroga que ingresó al Senado el 1 de septiembre y que a la fecha de este artículo no se ha votado. Es una mala idea planificar sobre él — lo desarrollamos en qué hacer antes de diciembre y por qué la prórroga no te salva.
En id3a construimos software vertical para mercados donde la normativa es parte del producto, no un anexo. Si estás evaluando un sistema y quieres una segunda opinión técnica sobre su exposición, conversemos.
Este artículo describe exigencias técnicas derivadas de la Ley 21.719 desde una perspectiva de ingeniería. No es asesoría legal; para la calificación jurídica de un tratamiento específico, consulta con un abogado especializado.
Fuentes: Ley 21.719, artículos 14 ter, 14 quáter, 14 quinquies, 14 sexies, 15 ter, 49 y 50, según el texto vigente publicado por la Biblioteca del Congreso Nacional (bcn.cl).
¿Te gustó este artículo?
Descubre cómo podemos ayudarte a implementar estas soluciones en tu negocio.