DEV Community: Luis Torres

Ley 21.719: el problema no es solo legal, también es arquitectónico

Luis Torres — Wed, 03 Jun 2026 21:30:17 +0000

La Ley 21.719, que moderniza la regulación chilena sobre protección de datos personales, debería abrir una conversación técnica importante en Chile: dejar de tratar los datos personales como si fueran simples campos de formulario.

Durante años muchas organizaciones usaron el RUT, el email o el teléfono como llaves primarias, identificadores de integración o campos cómodos para cruzar información entre sistemas.

Era práctico.

Pero también creó arquitecturas donde el dato personal está demasiado distribuido, demasiado expuesto y demasiado difícil de gobernar.

Mi tesis es simple: la Ley 21.719 no solo exige actualizar políticas de privacidad. En la práctica, también empuja a revisar cómo diseñamos identidad, integraciones, analítica, reportes, consentimiento y retención.

Del RUT como llave al RUT como dato gobernado

En una arquitectura moderna, una persona no debería ser "el RUT" dentro de un sistema.

Debería existir como una entidad interna representada por un identificador técnico no significativo:

person_id
customer_id
subject_id

El RUT, el email, el teléfono, la dirección o el nombre deberían ser atributos personales gobernados, no la identidad estructural del sistema.

Esto cambia la pregunta de diseño.

Antes:

¿Cuál es el RUT del cliente?

Después:

¿Qué dato personal necesito, para qué finalidad, bajo qué base legal,
durante cuánto tiempo y con qué evidencia de cumplimiento?

Tokenización: operar sin exponer de más

La tokenización puede ser una herramienta muy útil en este cambio.

En vez de que todos los sistemas guarden el RUT, email o teléfono real, pueden guardar tokens o identificadores internos. Solo una capa gobernada debería poder resolver esos tokens al dato real cuando exista una finalidad válida.

Ejemplo conceptual:

Sistema comercial:
cliente_id = 89231
rut_token = tok_7F92A1
email_token = tok_9CD114

Bóveda gobernada:
tok_7F92A1 -> 12.345.678-9
tok_9CD114 -> persona@correo.cl

Esto no significa que el dato deje automáticamente de estar regulado. Si la organización puede volver desde el token al dato real, sigue existiendo tratamiento de datos personales.

Pero reduce la exposición.

Y eso importa.

El RUT no debería viajar por todos los sistemas si muchos de ellos pueden operar con una referencia interna.

Tokenizar no es anonimizar

Este punto es importante.

Tokenizar reduce exposición, pero no convierte mágicamente un dato personal en dato anónimo.

Si la organización puede resolver el token y volver al RUT, email, teléfono o nombre real, entonces sigue existiendo un dato personal bajo gobierno. La diferencia es que ahora el acceso al dato real puede quedar concentrado, trazado y controlado.

La anonimización real es otra cosa: implica que no sea razonablemente posible volver a identificar a la persona.

Por eso el objetivo de tokenizar no debería ser "salirse de la ley".

El objetivo debería ser diseñar sistemas que operen con menos exposición, menos replicación y más control.

Una bóveda central de datos personales

En empresas con muchos sistemas, el problema no es solo proteger una base de datos.

El problema es saber:

dónde están los datos personales,
quién los consulta,
para qué finalidad,
bajo qué base legal,
por cuánto tiempo se conservan,
a qué proveedores se entregan,
cómo se eliminan, bloquean o anonimizan.

Por eso tiene sentido pensar en una bóveda central de datos personales o, más ampliamente, una capa central de gobierno de identidad y datos personales.

Modelo conceptual:

CRM / ERP / BI / Soporte / Documentos
        |
        | usan person_id o tokens
        v
Capa de gobierno de datos personales
        |
        | valida finalidad, permisos, auditoría, retención
        v
Bóveda de datos personales
        |
        | contiene RUT, email, teléfono, dirección, datos sensibles
        v
Dato real solo cuando corresponde

La bóveda no debería ser una base de datos más.

Debería ser el punto donde se decide qué sistema puede acceder a qué dato, bajo qué contexto, con qué finalidad y dejando qué evidencia.

También debería tener controles fuertes: cifrado, segregación de permisos, auditoría, monitoreo, gestión de llaves y reglas claras para resolver tokens.

Centralizar sin gobierno solo mueve el riesgo a un lugar más crítico.

El consentimiento no es un checkbox

Otra consecuencia técnica: el consentimiento no debería modelarse como una simple columna booleana.

accepted_terms = true

Eso dice muy poco.

Un consentimiento útil para gobierno debería registrar al menos:

quién consintió,
cuándo,
para qué finalidad,
bajo qué versión del texto,
por qué canal,
cómo puede revocarlo,
qué sistemas usan esa autorización.

El consentimiento debería ser un evento auditable, no solo un checkbox.

Los derechos de las personas son capacidades de plataforma

Acceso, rectificación, supresión, oposición, bloqueo, portabilidad y revocación del consentimiento no son solo temas de atención al cliente.

Son capacidades que la arquitectura debería soportar.

Si una organización tiene CRM, ERP, mesa de ayuda, analítica, almacenamiento documental, email, OCR, reportes, integraciones y planillas, responder correctamente a una solicitud de una persona titular no es trivial.

Se necesita poder localizar datos, corregirlos, bloquearlos, exportarlos o eliminarlos en todos los sistemas relevantes.

Si no existe trazabilidad, inventario y gobierno transversal, estos derechos terminan dependiendo de procesos manuales frágiles.

Retención por diseño

Muchas organizaciones guardan datos "por si acaso".

La nueva lógica de protección de datos empuja a justificar la conservación.

Cada dato debería tener una política asociada:

dato: email
finalidad: contacto operacional
base legal: según el caso aplicable
retención: mientras exista la relación y por el plazo definido
acción final: eliminar, anonimizar o bloquear

La retención indefinida es una deuda técnica con forma legal.

La planilla Excel también es tratamiento

Este punto suele olvidarse.

No basta proteger el sistema principal si después los datos terminan en exportaciones, reportes, correos, planillas, carpetas compartidas, dashboards, logs o respaldos sin control.

La fuga muchas veces no ocurre en el core transaccional.

Ocurre en la planilla exportada "temporalmente" que nadie gobierna.

Los proveedores también son parte de la arquitectura

Cloud, email, OCR, analítica, CRM externo, storage, herramientas de IA, mesa de ayuda y marketing automation pueden tratar datos personales.

Por eso el perímetro real de protección de datos incluye proveedores, contratos, instrucciones de tratamiento, subencargados, transferencias internacionales y medidas de seguridad.

En protección de datos, la arquitectura también incluye a tus proveedores.

Seguridad de la información no es lo mismo que protección de datos

Este punto también suele confundirse.

ISO 27001, cifrado, backups, monitoreo, control de acceso, tokenización o anonimización ayudan mucho. Son controles relevantes para reducir riesgo.

Pero no reemplazan el cumplimiento de protección de datos personales.

La seguridad de la información pregunta principalmente:

¿Cómo protegemos la confidencialidad, integridad y disponibilidad de la información?

La protección de datos personales agrega otras preguntas:

¿Por qué tratamos este dato personal?
¿Cuál es la base legal?
¿La finalidad es legítima y específica?
¿El dato es proporcional o estamos pidiendo de más?
¿Cuánto tiempo lo conservamos?
¿Cómo ejerce sus derechos la persona titular?
¿Qué evidencia tenemos de cumplimiento?

Una empresa puede tener buenos controles de seguridad y aun así tratar datos personales sin finalidad clara, conservarlos indefinidamente o no poder responder una solicitud de supresión, acceso o rectificación.

Por eso anonimizar, seudonimizar, tokenizar o cifrar son medios.

No son el cumplimiento completo.

La finalidad es que el tratamiento sea lícito, proporcional, transparente, seguro y demostrable.

El cumplimiento se demuestra

Una de las ideas más relevantes de la Ley 21.719 es la responsabilidad.

No basta decir que se cumple.

Hay que poder demostrarlo.

Eso implica logs, políticas, controles, contratos, inventarios, registros de consentimiento, trazabilidad de accesos, gestión de incidentes, retención, bloqueo, eliminación y decisiones documentadas.

La protección de datos no se resuelve solo con políticas en PDF.

Se resuelve con arquitectura, gobierno y evidencia.

Una ruta práctica

Si tuviera que ordenar este cambio en pasos técnicos, partiría por algo así:

Inventariar tratamientos y sistemas que almacenan o procesan datos personales.
Identificar dónde se usa RUT, email o teléfono como llave técnica.
Separar identidad interna de atributos personales.
Definir políticas de finalidad, base legal, acceso y retención por tipo de dato.
Tokenizar o seudonimizar donde el dato real no sea necesario.
Crear una capa gobernada para resolver datos reales solo cuando corresponda.
Registrar consentimiento, accesos, exportaciones, eliminaciones y bloqueos como eventos auditables.
Revisar proveedores, integraciones, reportes, BI, logs y planillas.

No todo esto se implementa de una vez.

Pero sí se puede comenzar dejando de diseñar nuevos sistemas alrededor del RUT como identificador principal.

Cierre

La Ley 21.719 no debería leerse solo como una obligación legal.

También es una señal de madurez arquitectónica.

En Chile deberíamos dejar atrás sistemas donde el RUT, email o teléfono viajan por todas partes como llaves técnicas.

El futuro debería ser otro: identificadores internos, tokenización, bóvedas de datos personales, trazabilidad, retención, derechos automatizables y gobierno centralizado.

El desafío no es llenar formularios de cumplimiento.

Es rediseñar cómo las organizaciones capturan, usan, comparten, protegen y eliminan datos personales.

Si todos los sistemas necesitan el RUT para funcionar, probablemente el problema no es solo legal.

Es de diseño.

Fuentes y alcance

La ley no dice literalmente "use una bóveda central" ni "tokenice el RUT".

Eso sería una decisión de arquitectura.

Lo que sí establece son principios y obligaciones que hacen razonables estas soluciones: licitud, finalidad, proporcionalidad, calidad, responsabilidad, seguridad, transparencia, confidencialidad, derechos de las personas titulares, reglas de conservación, supresión o anonimización, y deberes del responsable y de quienes tratan datos bajo su responsabilidad.

Desde esa base, identificadores internos, seudonimización, tokenización, bóvedas de datos personales, trazabilidad y retención por diseño son formas técnicas de implementar mejor esos principios.

Fuentes:

Nota: esta publicación es una reflexión técnica y arquitectónica sobre protección de datos personales. No constituye asesoría legal.

Los agentes de código necesitan memoria durable, no solo contexto

Luis Torres — Sat, 30 May 2026 17:02:47 +0000

Este texto nace de una práctica concreta usando agentes de código en repos reales.
El problema no fue que faltara contexto, sino que algunas decisiones importantes
quedaban en lugares donde el repositorio no podía recordarlas.

Cuando trabajamos con agentes de código, es normal pensar primero en contexto:
archivos relevantes, instrucciones del proyecto, historial de la conversación,
errores recientes, logs, planes y pruebas.

Todo eso ayuda al agente a resolver la tarea actual.

Pero hay un problema distinto que aparece rápido en repos reales: algunas decisiones
técnicas no deberían vivir solo en el chat.

Si una decisión cambia una frontera de servicio, define qué sistema es fuente de
verdad, fija un contrato de API, decide un runtime productivo o establece una
política técnica como "no usar fallbacks silenciosos", esa decisión afecta el trabajo
futuro. No basta con que el agente actual la entienda. El repositorio también debe
recordarla.

Ahí entra la idea de memoria durable del repo.

El problema

Un agente puede recordar contexto durante una sesión. Incluso puede tener memoria
privada entre sesiones, dependiendo de la herramienta. Pero esa memoria no siempre es:

visible para el equipo;
revisable en pull requests;
versionada junto al código;
portable entre herramientas;
explícita sobre qué decisiones están aceptadas y cuáles siguen en evaluación.

Eso importa porque muchas decisiones técnicas condicionan cambios futuros.

Por ejemplo:

"Este servicio es la fuente de verdad del workflow".
"Esta API es la única frontera válida para herramientas de agentes".
"Si falta configuración obligatoria, el sistema debe fallar claro".
"El entorno local debe activarse con un perfil explícito".
"Esta integración es candidata, pero todavía no está aceptada".

Si esas reglas quedan solo en una conversación, el próximo desarrollador o agente puede
volver a discutirlas, duplicarlas o romperlas sin saberlo.

ADRs como memoria del repositorio

Una forma simple de resolverlo es usar ADRs: Architecture Decision Records.

Un ADR no tiene que ser largo. De hecho, mientras más corto y concreto, mejor. Su valor
está en registrar:

qué decisión se tomó;
por qué era necesaria;
qué consecuencias debe respetar el trabajo futuro;
si está aceptada, propuesta, pendiente o reemplazada.

La pregunta de corte que uso es esta:

Si otro agente o desarrollador toca esta parte en dos meses, ¿necesita conocer esta
decisión para no romper la arquitectura?

Si la respuesta es sí, probablemente debe vivir como ADR, actualización de ADR o
candidato pendiente.

Si la respuesta es no, probablemente basta con código, tests o documentación de
implementación.

No todo merece un ADR

El objetivo no es documentar todo.

Cambiar el texto de un botón, refactorizar una función local o ajustar un detalle visual
normalmente no necesita un ADR. Son cambios importantes para el producto, pero no
necesariamente gobiernan decisiones futuras de arquitectura.

En cambio, mover la fuente de verdad de un workflow desde un servicio backend hacia
constantes del frontend sí debería encender una alerta. Eso cambia ownership, contratos
y expectativas futuras. Si ya existía una decisión previa, no basta con editar código:
hay que actualizarla o reemplazarla explícitamente.

La memoria durable no busca generar burocracia. Busca evitar que decisiones importantes
queden invisibles.

Qué hace Decision Memory

Decision Memory es un skill open source para agentes de código. Su trabajo es ayudar al
agente a decidir si una decisión técnica debe:

crear un ADR;
actualizar un ADR existente;
reemplazar una decisión previa;
quedar como candidata pendiente;
o mantenerse como documentación de implementación.

La idea no es que el agente escriba más documentación por defecto. La idea es que, cuando
detecte una decisión durable, ayude a moverla desde memoria temporal hacia memoria
versionada del repositorio.

También ayuda a detectar señales de deuda técnica oculta:

fallbacks silenciosos;
configuración inventada por defecto;
mocks o no-ops en runtime productivo;
decisiones temporales sin criterio de salida;
duplicación de reglas de dominio entre frontend y backend.

Memoria de agente vs memoria de repo

La memoria del agente sigue siendo útil. Sirve para preferencias, patrones recurrentes,
comandos habituales y contexto operativo.

Pero las decisiones arquitectónicas deberían estar donde el equipo pueda revisarlas:
en el repositorio.

Una división práctica es:

memoria del agente para preferencias y hábitos de trabajo;
instrucciones del repo para reglas operativas del agente;
ADRs para decisiones técnicas que condicionan arquitectura futura;
documentación de implementación para detalles locales;
candidatos pendientes para ideas relevantes que todavía no están validadas.

Esa separación reduce ambigüedad. También permite que distintas herramientas lean el
mismo repositorio sin depender de la memoria privada de una sesión o de un proveedor.

Ejemplo de uso

Una pregunta útil para un agente sería:

Usa decision-memory para evaluar esta decisión:
mover la fuente de verdad del workflow desde el backend hacia constantes del frontend.

No edites archivos. Clasifica si requiere un nuevo ADR, actualizar un ADR existente,
reemplazar una decisión previa o quedar como documentación de implementación.

Una respuesta esperada sería:

Clasificación: requiere ADR o actualización de ADR existente.

Razón: cambia la fuente de verdad, el ownership del dominio y el contrato entre backend
y frontend. Futuros cambios necesitarán conocer esta decisión para no reconstruir estados
paralelos ni romper la arquitectura.

Proyecto

El skill está publicado como open source:

GitHub: https://github.com/ltorresu82/skills
skills.sh: https://www.skills.sh/ltorresu82/skills/decision-memory

Instalación:

npx skills add ltorresu82/skills --skill decision-memory

La tesis es simple: los agentes de código no necesitan solo más contexto. Necesitan mejor
memoria. Y las decisiones que gobiernan el futuro de un sistema deberían vivir cerca del
código, versionadas y visibles para humanos y agentes.