Cinco principios para proteger datos en tu producto

¿Cuántos campos recolecta el producto en el que trabajás hoy y podrías explicar por qué existe cada uno? Aplicar principios de protección de datos en decisiones de producto es lo que separa a un equipo responsable de uno que acumula riesgo sin darse cuenta. Esta guía es para quienes diseñan, programan o gestionan productos que manejan datos personales, sobre todo con IA de por medio.

El riesgo más frecuente no es un hacker sofisticado. Es un equipo que recolecta datos sin preguntarse por qué, los guarda sin fecha de vencimiento y le dice al usuario que "mejora su experiencia" sin explicar nada concreto.

¿De dónde vienen estos principios de protección de datos?

Estos cinco principios no salen de la nada. Nacen de marcos legales reales que ya se aplican en el mundo. En Europa está el GDPR, probablemente el estándar más influyente hoy. En Argentina, la Ley 25.326. En Brasil, la LGPD [00:41].

No necesitás ser abogado para trabajar con esto, pero sí entender algo clave: estos marcos no son teoría legal, son guías prácticas para tomar mejores decisiones de producto [00:57]. La idea es bajarlos a decisiones concretas, no a teoría.

¿Cómo aplico propósito y minimización a cada dato?

Los dos primeros principios responden a la misma pregunta incómoda: ¿este dato realmente necesita existir?

El principio de propósito dice que cada dato necesita una razón clara. Pensalo con el recepcionista de un hospital que te pide el teléfono: el propósito es llamarte si cambia la cita. Si después usan ese número para mandarte publicidad, ese propósito fue violado [01:26].

Podés abordarlo con tres preguntas:

• ¿Por qué necesitamos este dato?
• ¿Qué decisión habilita?
• ¿Qué pasa con él después?

Y escribí una declaración de propósito en cada campo. Por ejemplo: "recolectamos la ubicación del usuario para mostrar puntos de servicio cercanos, se usa solo durante la sesión activa y no se almacena" [01:52].

¿Qué es la minimización de datos? Es recolectar solo lo estrictamente necesario. Si no podés explicar qué decisión habilita un dato, ese dato no debería existir, porque cada campo extra suma costo y riesgo.

Un ejemplo real: un sistema de reconocimiento facial que recolecta rostro, hora de entrada, edad estimada y etnicidad. Rostro y hora tienen sentido para seguridad; edad y etnicidad no, y además abren la puerta a discriminación. Resultado: sistema suspendido [02:38].

¿Cuánto tiempo debo guardar los datos y cómo los protejo?

Acá entran retención y seguridad, los principios que definen qué pasa con el dato una vez que ya lo tenés.

¿Cuál es la regla de retención de datos?

Guardar datos es como guardar recibos: algunos sirven, pero nadie los guarda todos durante 10 años. Hay tres reglas claras de retención [03:00]:

1. El tiempo de retención debe coincidir con el propósito.
2. Cuanto más sensible el dato, más corto el tiempo: biométricos unos días o semanas, salud y finanzas lo mínimo legal, contacto mientras haya relación activa.
3. Revisión periódica cada seis o 12 meses.

En cada revisión preguntate si el dato se está usando, si el sistema que lo generó sigue activo y si hay duplicados sin dueño. Si la respuesta es no, ese dato sobra [03:41].

¿Cómo aplico seguridad por rol en un sistema de datos?

Pensalo como un hospital: todos trabajan ahí, pero no todos ven lo mismo. En un sistema de datos pasa igual [03:52]. La seguridad se apoya en tres controles:

• Acceso por rol: los devs ven logs técnicos y no datos personales crudos, los analistas ven agregados y no registros individuales, los auditores tienen acceso limitado y temporal.
• Minimización en logs: guardá timestamp e ID de sesión, pero no el texto completo por defecto, y eliminá logs crudos después de un tiempo definido.
• Auditoría: todo acceso queda registrado y quien audita no puede modificar los logs [04:40].

Estos controles funcionan juntos: el rol limita quién entra, la minimización reduce qué queda expuesto y la auditoría deja rastro de todo.

¿Cómo escribo un aviso de transparencia que sirva?

El principio de transparencia cierra la lista, y su regla es contundente: el aviso al usuario tiene que servir, no solo cumplir [04:50]. Hay cinco cosas que decir siempre:

• Qué datos recolectás.
• Para qué los usás.
• Quién más los ve.
• Qué control real le das al usuario.
• Cuánto tiempo se guardan.

Un ejemplo claro: "usamos tu ubicación para mostrar noticias locales". Un ejemplo vacío: "mejoramos tu experiencia" [05:13].

¿Quién es responsable cuando uso un proveedor externo de IA? Tu empresa es el controlador y el proveedor externo es el procesador. Si enviás datos personales sin contrato, la responsabilidad es tuya, no del proveedor.

¿Cómo filtro los datos en un caso real de recomendación?

Imaginá un sistema de recomendación para un gran e-commerce en Latinoamérica. Recolecta de todo: clics, tiempo de lectura, búsquedas, ubicación, modelo del dispositivo, un historial de 12 meses y hasta el mail [06:04].

Tu desafío es pasar cada dato por un filtro de tres preguntas:

1. ¿Mejora realmente la métrica?
2. ¿Genera un riesgo innecesario?
3. ¿Vale la pena el costo de guardarlo?

Y aquí viene lo interesante. La ubicación: ¿de verdad cambia lo que le recomendás a alguien en Buenos Aires o en Guayaquil? Si no, sacala. El mail no lo guardés en texto plano, reemplazalo por un token. Y el 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 [06:47].

Dejame en los comentarios tu análisis o algún caso real de este tipo en el que hayas trabajado.