¿Sabés por qué existe cada campo que tu producto recolecta hoy? Si la respuesta es dudosa, el problema no es técnico: es de diseño. El mayor riesgo en protección de datos no viene de un ataque externo, sino de equipos que acumulan información sin propósito claro, sin fecha de vencimiento y con avisos vagos como "mejoramos tu experiencia". Estos cinco principios, extraídos de marcos regulatorios reales como el GDPR europeo, la Ley 25.326 de Argentina y la LGPD de Brasil, no son teoría legal: son guías prácticas para tomar mejores decisiones de producto.
¿Por qué cada dato necesita un propósito explícito?
El principio de propósito establece que cada dato recolectado debe tener una razón clara para existir [0:52]. Pensá en un recepcionista de hospital que pide tu teléfono para avisarte si cambia la cita. Si después usan ese número para enviarte publicidad, el propósito fue violado.
Para aplicarlo, respondé tres preguntas antes de incorporar cualquier campo:
- ¿Por qué necesitamos este dato?
- ¿Qué decisión habilita?
- ¿Qué pasa con él después?
Una declaración de propósito bien escrita se ve así: "recolectamos la ubicación del usuario para mostrar puntos de servicio cercanos; se usa solo durante la sesión activa y no se almacena" [1:24]. Esa claridad cambia por completo cómo se diseña un flujo.
¿Qué significa recolectar solo lo necesario?
El principio de minimización dice que cada campo extra tiene costo y riesgo [1:38]. La regla es directa: si no podés explicar qué decisión habilita un dato, ese dato no debería existir.
Un caso real lo ilustra bien: un sistema de reconocimiento facial recolectaba rostro, hora de entrada, edad estimada y etnicidad [1:55]. Rostro y hora pueden justificarse por seguridad. Edad y etnicidad no aportan valor y además abren la puerta a discriminación. El resultado fue un sistema suspendido.
¿Cuánto tiempo deberías guardar cada dato?
El principio de retención compara guardar datos con guardar recibos: algunos sirven, pero nadie conserva todos durante diez años [2:18]. Tres reglas claras lo resuelven:
- El tiempo de retención debe coincidir con el propósito original.
- Cuanto más sensible el dato, más corto el plazo: biométricos unos días, datos de salud y finanzas lo mínimo legal, datos de contacto mientras haya relación activa.
- Revisión periódica cada seis o doce meses preguntándote si el dato se está usando, si el sistema que lo generó sigue activo y si hay duplicados sin dueño [2:52].
Si la respuesta es no, ese dato sobra.
¿Cómo se aplica la seguridad sin frenar al equipo?
El principio de seguridad funciona como un hospital: todos trabajan ahí, pero no todos ven lo mismo [3:07]. Hay tres controles esenciales.
El acceso por rol implica que los devs ven logs técnicos sin datos personales crudos, los analistas ven agregados sin registros individuales y los auditores tienen acceso limitado y temporal [3:16]. La minimización en logs significa guardar timestamp e ID de sesión, pero no texto completo por defecto, y eliminar logs crudos después de un plazo definido [3:31]. Y la auditoría exige que todo acceso quede registrado, con una regla clave: quien audita no puede modificar los logs [3:44].
¿Qué hace que un aviso de privacidad realmente sirva?
El principio de transparencia pide que el aviso al usuario sirva, no solo cumpla [3:52]. Cinco reglas lo definen:
- Decí exactamente qué datos recolectás.
- Explicá para qué.
- Decí quién más los ve.
- Dales control real al usuario.
- Decí cuánto tiempo se guardan.
Un ejemplo claro sería "usamos tu ubicación para mostrar noticias locales". Un ejemplo vacío: "mejoramos tu experiencia" [4:12].
¿Qué pasa cuando usás un proveedor externo de IA?
Cuando trabajás con un proveedor externo, tu empresa es el controlador y el proveedor es el procesador [4:28]. Si enviás datos personales sin contrato, la responsabilidad legal es tuya, no del proveedor.
Un caso práctico lo pone en perspectiva: imaginá un sistema de recomendación para un e-commerce en Latinoamérica que recolecta clics, tiempo de lectura, búsquedas, ubicación, modelo de dispositivo, historial de doce meses y mail [4:46]. Cada dato debe pasar por un filtro: ¿mejora realmente la métrica?, ¿genera riesgo innecesario?, ¿vale la pena el costo de guardarlo?
- Ubicación: si no cambia la recomendación entre Buenos Aires y Guayaquil, eliminala [5:10].
- Mail: no lo guardes en texto plano, reemplazalo por un token [5:20].
- Historial: probá con 30 días en lugar de un año; si la diferencia en la métrica es mínima, quedate con lo menos riesgoso [5:25].
Dejá en los comentarios tu análisis o algún caso real en el que hayas aplicado estos principios.
