Revisar datos personales (Ley 21.719)

Revisar datos personales (Ley 21.719)

Auditoría de cumplimiento sobre un repositorio real. No es asesoría legal: es un inventario técnico con evidencia, para que una persona sepa qué preguntarle a su abogado.

La regla que manda sobre todas las demás

Nunca afirmes que algo cumple. Este trabajo se entrega en tres estados y solo tres:

Una afirmación sin archivo:línea no entra al reporte. Si la evidencia está fuera del código —en un panel de Supabase, en un contrato con un proveedor, en la configuración de un servicio— eso es NO VERIFICABLE, y se dice así.

NO VERIFICABLE no es un fracaso: es el resultado honesto y es la parte más útil del reporte, porque es la lista de lo que la persona tiene que ir a mirar con sus propios ojos.

Procedimiento

Paso 1 — Inventario antes que juicio

Antes de evaluar nada, levanta qué datos personales trata el sistema. Busca en este orden:

1. Migraciones y definiciones de esquema (*.sql, schema.prisma, models.py, migrations/, CREATE TABLE).
2. Formularios y validadores del frontend.
3. Tipos e interfaces que crucen la frontera de la red.
4. Payloads que se envían a terceros.

Para cada campo que identifique o haga identificable a una persona natural, llena una fila:

tabla.campo | qué es | finalidad declarada | base de licitud | retención | quién más lo ve

Si no puedes deducir la finalidad de un campo leyendo el código, escribe finalidad no evidente en el código. Esa frase es el hallazgo más valioso de todo el paso: un campo cuya razón de existir nadie puede explicar es exactamente lo que el principio de proporcionalidad prohíbe.

Marca aparte los datos sensibles: salud, origen racial, afiliación política, convicciones religiosas, vida sexual, identidad de género, biométricos y perfil biológico. Ojo con los que se disfrazan: un campo notas u observaciones de texto libre suele contener datos de salud. Revisa los datos reales si tienes acceso, no solo el nombre de la columna.

Paso 2 — Los diez puntos

Recorre references/checklist-21719.md. Cada punto trae qué buscar, los patrones que delatan el problema y el artículo que lo respalda.

Paso 3 — Verificación contra datos, no contra código

Leer el código no prueba que el sistema se comporte como el código sugiere. Cuando tengas acceso a un entorno de desarrollo, propón —y ejecuta si te autorizan— al menos esta comprobación:

1. Crea un registro de prueba con un valor único y rastreable.
2. Ejerce el borrado por el camino que usa una persona real.
3. Busca ese valor único en todas partes: tablas, tablas de auditoría, logs, colas de trabajos, caché, exports, sistemas de terceros.

Si el valor sobrevive en algún lado, el borrado no borra. Repórtalo como ENCONTRADO aunque el código diga DELETE.

Cuando no tengas ese acceso, dilo: "la lógica de borrado se ve correcta en ruta:línea, pero no se verificó contra una base real". No lo des por bueno.

Paso 4 — El reporte

Entrega en este orden:

1. Resumen — cuántos puntos en cada estado. Sin adjetivos.
2. Inventario de datos — la tabla del paso 1.
3. Hallazgos — ordenados por gravedad, cada uno con: qué encontraste, archivo:línea, por qué importa, el artículo, y el arreglo concreto.
4. No verificable — qué falta mirar y dónde.
5. Fuera de alcance — lo que necesita un abogado: redacción de la política de privacidad, contratos con proveedores, evaluación de impacto, decisión sobre la base de licitud aplicable.

Cierra siempre con el recordatorio de que esto no es asesoría legal.

Cómo no fallar

No inventes la política de privacidad. Si te piden generar el texto del artículo 14 ter, constrúyelo desde el inventario real del paso 1. Redactar una política que promete algo que el sistema no hace es publicar una afirmación falsa sobre el propio sistema, y eso es peor que no tenerla.

No confundas ausencia de evidencia con cumplimiento. No encontrar un endpoint de exportación significa que no lo encontraste, no que la portabilidad esté resuelta en otro lado.

Pide la segunda opinión. Al terminar, sugiere que otro modelo audite el mismo repo. Un modelo no encuentra sus propios puntos ciegos.

Sé específico con el arreglo. "Mejorar el manejo del consentimiento" no sirve. "Reemplazar la columna acepto_todo por una tabla consentimientos con finalidad, version_texto, otorgado_en y revocado_en" sí.

Alcance territorial

Antes de empezar, verifica si la ley aplica: alcanza a quien esté establecido en Chile, y también a quien —desde donde sea— ofrezca bienes o servicios a personas que están en Chile, aunque sean gratis, o monitoree su comportamiento. Un SaaS gratuito con usuarios chilenos entra.

Si el proyecto no toca usuarios chilenos, la auditoría sigue sirviendo: casi todo esto es común al RGPD europeo y a las leyes que vienen en el resto de la región. Dilo así en el reporte.

Archivos de apoyo

• references/checklist-21719.md — los diez puntos en detalle.
• references/plantillas/registro-tratamiento.md — inventario para llenar.
• references/plantillas/runbook-brecha.md — qué hacer las primeras horas.
• references/plantillas/evaluacion-proveedores.md — antes de conectar un tercero.

---

Esta skill no da asesoría legal. Produce un inventario técnico y una lista de preguntas. La revisión legal la hace un abogado.