Tomás lidera el equipo de desarrollo de una empresa de logística en Quilicura. Le piden un formulario nuevo para inscribir a los conductores externos que reparten para la empresa. El requerimiento llega con 22 campos: nombre, RUT, licencia, patente, cuenta bancaria, estado civil, número de hijos, Isapre o Fonasa, contacto de emergencia, talla de polera y una foto de la cara «por si acaso». Tomás se pregunta para qué sirve cada uno. Nadie sabe responder por el estado civil.
Esa pregunta, hecha antes de escribir la primera línea de código, es lo que la ley llama protección desde el diseño.
Lo que dice el artículo 14 quáter
El artículo tiene dos mitades.
Desde el diseño. El responsable debe aplicar medidas técnicas y organizativas adecuadas desde el diseño, antes y durante el tratamiento de los datos, para cumplir los principios y los derechos de la ley. Las medidas se eligen considerando el estado de la técnica, los costos de implementación, la naturaleza, el ámbito, el contexto y los fines del tratamiento, y sus riesgos.
Por defecto. El responsable debe aplicar medidas para garantizar que, por defecto, sólo se traten los datos personales específicos y estrictamente necesarios para cada actividad. Para eso considera cuatro cosas: el número de datos recogidos, la extensión del tratamiento, el plazo de conservación y su accesibilidad.
Las dos mitades aterrizan en sistemas concretos. Si trabajas en TI, son tuyas.
Las cuatro perillas del «por defecto»
La ley nombra cuatro variables. Sirven como lista de revisión para cualquier sistema.
1. Cuántos datos. Cada campo tiene que tener un para qué. El principio de proporcionalidad (artículo 3°, letra c) pide que los datos sean necesarios, adecuados y pertinentes para el fin. En el formulario de Tomás, el estado civil y el número de hijos no sirven para coordinar repartos. La previsión de salud tampoco. Tratar datos innecesarios es infracción grave (artículo 34 ter, letra c).
2. Cuánto se hace con ellos. Que un dato se recoja para pagar no significa que deba aparecer en el reporte de rutas. Cada módulo usa lo que necesita.
3. Cuánto tiempo. La ley dice que los datos se guardan sólo el tiempo necesario para sus fines, y después se suprimen o anonimizan (artículo 3°, letra c). Un sistema que nunca borra nada no cumple por defecto. Define el plazo al diseñar la tabla, no cuando alguien lo pida.
4. Quién los ve. La accesibilidad. Por defecto, el mínimo de personas. La cuenta bancaria del conductor la ve finanzas, no el despachador.
Ejemplo. Tomás vuelve con una propuesta: 9 campos en vez de 22, la cuenta bancaria visible sólo para finanzas, los datos de conductores que dejan de trabajar con la empresa se borran a los 12 meses, y la foto se reemplaza por la patente del vehículo. Lo que nadie supo justificar, no entra.
Seudonimizar y anonimizar no son lo mismo
La ley distingue las dos cosas (artículo 2°, letras k y l), y para TI la diferencia es práctica:
- Anonimizar es irreversible: ya no hay cómo saber de quién es el dato. Un dato anonimizado deja de ser dato personal.
- Seudonimizar es reemplazar el dato identificador por otro, guardando aparte —y protegida— la información que permite volver a asociarlo. Con esa información se puede volver a saber de quién es: el riesgo baja, pero no desaparece.
El artículo 14 quinquies menciona la seudonimización y el cifrado entre las medidas de seguridad. Un ambiente de pruebas con datos seudonimizados, o con datos ficticios, es diseño. Uno con una copia de producción no lo es. Lo desarrollamos en Datos reales de producción en un chat de IA al programar.
Al elegir un sistema que no construyes
La ley le pone el deber al responsable, no al proveedor de software. Si tu empresa compra un sistema de remuneraciones o un CRM, la pregunta es la misma. Algunas para la reunión con el proveedor:
- ¿Puedo desactivar los campos que no uso?
- ¿Puedo definir quién ve qué, por rol?
- ¿Puedo fijar un plazo de conservación y que el sistema borre solo?
- ¿Dónde se procesan los datos? Si es fuera de Chile, es una transferencia internacional.
- ¿Qué queda registrado de quién accedió a qué?
Y si un tratamiento puede significar un alto riesgo para las personas, el artículo 15 ter pide una evaluación de impacto antes de empezar. Es el momento natural para hacerse estas preguntas.
La IA, diseñada así
Un chat de IA es un sistema más, y las cuatro perillas aplican igual. El caso típico: un colaborador pega un texto con nombres y RUT. Por defecto, ¿cuántos de esos datos necesita el modelo para ayudar? Casi nunca el RUT.
Plumii se diseñó con esa pregunta. Un filtro reconoce el dato antes del modelo y lo cambia por una marca: el modelo recibe «Resume la situación de {NAME}, RUT {rut}» y responde con la marca. La plantilla de partida tapa nombres, RUT, correos, teléfonos, direcciones y patentes, y bloquea tarjetas y contraseñas; quien administra Plumii en tu empresa ajusta la regla. Las conversaciones están cifradas y son sólo de cada persona. El registro de uso guarda qué datos traía cada mensaje y qué regla se aplicó, sin la conversación, por 24 meses.
Tiene límites que conviene saber: el filtro reconoce los datos por el contexto, en español, y uno raro o mal escrito puede pasar; no reconoce datos sensibles como un diagnóstico; y tapar el nombre no basta si el resto del texto identifica a la persona. El detalle está en Privacidad por diseño.
Este artículo es información general, no asesoría legal. El texto oficial de la ley está en la Biblioteca del Congreso Nacional.