Caso ficticio
Juanito Pérez lidera el equipo de desarrollo de una empresa de logística en una ciudad de la zona central. 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». Juanito se pregunta para qué sirve cada uno. Nadie sabe responder por el estado civil.
La respuesta corta
La ley pide dos cosas, en el artículo 14 quáter:
Desde el diseño. Pensar la protección de los datos antes de tratarlos, no después. El responsable debe aplicar medidas técnicas y organizativas adecuadas desde el diseño, antes y durante el tratamiento, 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. Que el sistema trate, sin que nadie tenga que pedirlo, sólo los datos personales específicos y estrictamente necesarios para cada actividad. Para eso la ley nombra cuatro variables: el número de datos recogidos, la extensión del tratamiento, el plazo de conservación y su accesibilidad.
La pregunta de Juanito, hecha antes de escribir la primera línea de código, es exactamente lo primero. Las cuatro variables son la forma de responderla.
Las cuatro perillas, en el formulario de Juanito
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. Para inscribir a un conductor y coordinar sus repartos hacen falta su nombre, su RUT, su licencia y la patente del vehículo; para pagarle, una cuenta bancaria. El estado civil y el número de hijos no sirven para coordinar repartos. La previsión de salud tampoco. La foto de la cara «por si acaso» no tiene un para qué: para identificar el vehículo basta la patente. 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. En el sistema de Juanito, la cuenta bancaria vive en el módulo de pagos y no se copia al de despachos.
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 formulario que guarda para siempre a cada conductor que alguna vez se inscribió no cumple por defecto. El plazo se define 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. Juanito 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 sale del formulario. Lo que nadie supo justificar, no entra.
Lo que queda fuera del formulario también es diseño
El formulario es la puerta de entrada, pero el deber sigue a los datos. Dos decisiones más que le tocan a Juanito:
- Las pruebas. Un ambiente de pruebas con datos ficticios o seudonimizados es diseño; uno con una copia de los conductores reales no lo es. El artículo 14 quinquies menciona la seudonimización y el cifrado entre las medidas de seguridad. Lo desarrollamos en Datos reales o datos de prueba al programar con IA.
- Si el formulario no lo construye él. La ley le pone el deber al responsable, no al proveedor de software. Si la empresa comprara una plataforma de inscripción, las cuatro perillas serían las preguntas para el proveedor: ¿puedo desactivar los campos que no uso?, ¿puedo definir quién ve qué?, ¿puedo fijar un plazo y que el sistema borre solo? Y si procesa fuera de Chile, es una transferencia internacional.
Dónde ayuda Plumii
Un chat de IA es un sistema más, y las cuatro perillas aplican igual: si Juanito pega una lista de conductores para que la IA le ayude a ordenarla, el modelo casi nunca necesita sus RUT. Plumii se diseñó con esa pregunta. Por defecto, la plantilla de partida tapa nombres, RUT, correos, teléfonos, direcciones y patentes antes de que el mensaje llegue al modelo, 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, y el registro de uso guarda qué datos traía cada mensaje, sin la conversación, por 24 meses. El filtro reconoce los datos por el contexto, en español, y uno raro o mal escrito puede pasar. El detalle está en Privacidad por diseño.
Las personas, empresas y situaciones de este artículo son ficticias: las inventamos para explicar la ley, y cualquier parecido con un caso real es coincidencia. Este artículo es información general, no asesoría legal. El texto oficial de la ley está en la Biblioteca del Congreso Nacional.