Casi todo lo que se escribe sobre protección de datos está dirigido a empresas con departamento jurídico. Para quien tiene un producto pequeño con usuarios reales, el resultado práctico suele ser uno de dos extremos: pegar una política de privacidad copiada de otro sitio, o no hacer nada y confiar en pasar desapercibido.
Hay un punto intermedio que cubre la mayor parte del riesgo y que se puede implementar en unos días. No es cumplimiento completo ni sustituye a un especialista, pero es la diferencia entre un incidente manejable y uno que no lo es.
Esto tampoco es asesoramiento legal, y el reglamento europeo se usa aquí como referencia porque es el más exigente y el que más lejos alcanza territorialmente.
Qué cuenta como dato personal
El primer error habitual es creer que solo lo son el nombre y el correo. La definición es mucho más amplia: cualquier información que permita identificar a una persona, directamente o combinándola con otra.
Eso incluye cosas que en un sistema no parecen datos personales en absoluto. La dirección IP lo es. Un identificador de dispositivo lo es. Un registro de actividad con un identificador de usuario, aunque el nombre esté en otra tabla, lo es.
La prueba práctica que funciona: si con ese dato y lo que tienes a mano puedes llegar a saber de quién se trata, es dato personal. Y si el dato revela salud, ideología, religión, orientación sexual, origen étnico o datos biométricos, entra en una categoría especial con requisitos más estrictos.
Esa amplitud tiene una consecuencia directa: los registros de actividad, que casi nadie considera al pensar en privacidad, suelen ser el mayor depósito de datos personales de un sistema pequeño.
El principio que ahorra más trabajo que ningún otro
De todo el reglamento, hay una idea que reduce el esfuerzo de cumplimiento más que cualquier otra medida técnica.
La minimización dice que solo debes recoger los datos que necesitas para la finalidad concreta que has declarado. No los que podrían venir bien algún día.
Aplicado a un formulario de registro, la pregunta por cada campo es qué pasa si no lo pides. Si la respuesta es que no pasa nada, ese campo sobra, y con él desaparecen las obligaciones de protegerlo, exportarlo, borrarlo y responder por él si hay una filtración.
Lo mismo con los registros de actividad: guardar la petición completa con todas sus cabeceras es cómodo para depurar y convierte tus archivos de log en una base de datos personal sin control.
La versión corta de este principio es que el dato que no tienes no se puede filtrar, y es el único consejo de esta lista que ahorra trabajo en lugar de añadirlo.
Por qué tratas cada dato: la base legal
Todo tratamiento de datos necesita una justificación de las que el reglamento enumera, y elegir la equivocada es un error frecuente.
La ejecución de un contrato cubre lo necesario para prestar el servicio: el correo para la cuenta, la dirección para el envío. No necesitas consentimiento para esto, y pedirlo confunde.
El interés legítimo cubre cosas como la seguridad del sistema o la prevención del fraude, siempre que hayas valorado que no pesa más el derecho del usuario.
La obligación legal cubre lo que otra norma te exige guardar, típicamente las facturas durante varios años.
El consentimiento es para el resto: analítica no esencial, publicidad, comunicaciones comerciales. Y tiene requisitos duros: debe ser libre, específico, informado, dado por una acción afirmativa, y debe poder retirarse tan fácilmente como se dio.
La consecuencia técnica más visible de esto es que las casillas premarcadas no valen como consentimiento, y que un banner de cookies donde aceptar es un botón grande y rechazar está escondido tras dos clics no cumple el requisito de libertad.
Los derechos que tienen que funcionar de verdad
El usuario puede pedir cosas concretas, y el sistema tiene que poder responderlas en un plazo de un mes. Hay tres que exigen trabajo técnico previo.
Acceso y portabilidad: entregar todo lo que tienes de esa persona, en un formato legible por máquina. Si los datos están repartidos en cinco tablas y dos servicios externos, esto es un problema a resolver antes de que alguien lo pida.
Supresión: borrar sus datos cuando ya no hay base para conservarlos. Esto choca de frente con el borrado lógico, que es lo que casi todo sistema implementa por comodidad, y con las copias de seguridad.
Rectificación: corregir lo que esté mal, incluido lo que ya hayas enviado a terceros.
La forma sensata de prepararlo es escribir dos rutinas de administración, una de exportación y otra de borrado, antes de necesitarlas. Hacerlo a mano contra la base de datos el día de la petición es cuando se olvida la mitad.
# Localizar todas las tablas que referencian al usuario antes de escribir nada
psql -d mi_base -c "\d+ usuarios"
psql -d mi_base -c "
SELECT tc.table_name, kcu.column_name
FROM information_schema.table_constraints tc
JOIN information_schema.key_column_usage kcu ON tc.constraint_name = kcu.constraint_name
JOIN information_schema.constraint_column_usage ccu ON tc.constraint_name = ccu.constraint_name
WHERE tc.constraint_type = 'FOREIGN KEY' AND ccu.table_name = 'usuarios';"Esa consulta devuelve el mapa real de dónde vive el rastro de una persona, que casi nunca coincide con el que uno tiene en la cabeza.
Borrar de verdad, con las copias de seguridad de por medio
El borrado es donde la teoría y la práctica chocan más fuerte, y conviene saber cuál es la salida aceptada.
Si borras al usuario de la base pero conservas una copia de seguridad de hace una semana, sus datos siguen existiendo. Restaurar esa copia lo resucitaría.
La solución que se considera razonable no es reescribir las copias, que a menudo es inviable, sino tener un ciclo de rotación acotado y documentado, y un registro de borrados que se vuelva a aplicar si alguna vez se restaura una copia antigua.
Para los datos que necesitas conservar por otra obligación, como las facturas, la salida es la disociación: conservar el registro contable sin los datos que lo vinculan a una persona identificable, cuando la norma fiscal lo permita.
Y el borrado lógico con una marca de borrado, tan cómodo para el desarrollo, no es borrado a efectos del reglamento. Puede servir durante un plazo corto y documentado, pero al final del plazo los datos tienen que irse de verdad.
Los proveedores que ven tus datos
Un producto pequeño reparte datos personales entre más servicios de los que su equipo suele recordar.
El correo transaccional ve las direcciones. La pasarela de pago ve los datos de facturación. El servicio de errores ve lo que venga en la traza, que puede incluir cuerpos de petición completos. La analítica ve identificadores y comportamiento. El alojamiento ve todo.
Cada uno de esos es un encargado del tratamiento y requiere un contrato específico, que las plataformas serias ofrecen como documento estándar. Y si el proveedor está fuera del espacio europeo, hay que comprobar qué mecanismo de transferencia internacional aplica.
El error más común con diferencia está en el servicio de errores: por omisión captura variables locales y cuerpos de petición, y acaba almacenando contraseñas, tokens y datos personales en un sistema de terceros. Eso se configura.
# Comprobar que no se estan enviando datos sensibles en las trazas de error
grep -rn "password\|token\|dni\|tarjeta" --include="*.log" storage/logs/ | head
# Y que no viajan en las URL, donde quedan registradas en todas partes
grep -rn "?email=\|&dni=\|?token=" src/ | headEl segundo comando busca un problema específico y muy extendido: los datos personales en la cadena de consulta acaban en los registros del servidor, en el historial del navegador y en la cabecera de referencia enviada a terceros.
Cuánto tiempo guardar cada cosa
La conservación indefinida es el estado por omisión de casi todos los sistemas, y no es defendible. Cada categoría de dato necesita un plazo y un motivo.
Lo que funciona es escribir una tabla corta, de diez líneas, con qué se guarda, por qué y durante cuánto. Ese documento resuelve a la vez la obligación de documentar y la pregunta técnica de qué debe borrar la tarea programada.
| Dato | Motivo | Plazo |
|-----------------------------|-------------------------|------------|
| Cuenta y perfil | Prestar el servicio | Mientras exista la cuenta |
| Registros de acceso con IP | Seguridad | 90 dias |
| Carritos abandonados | Recuperar la compra | 30 dias |
| Facturas | Obligacion fiscal | Segun norma aplicable |
| Trazas de error | Depuracion | 30 dias |# Una tarea programada que aplique los plazos de verdad
0 4 * * * /usr/bin/php /ruta/artisan privacidad:purgar >> /var/log/purga.log 2>&1Sin esa tarea, la tabla es un documento que describe algo que no ocurre, que es peor que no tenerla.
Qué hacer si hay una filtración
Este es el punto donde la falta de preparación se paga más caro, porque el plazo es corto y empieza a contar en cuanto te enteras.
Cuando hay una brecha con riesgo para los afectados, hay que notificar a la autoridad de control en setenta y dos horas. Si el riesgo es alto, también hay que avisar a las personas afectadas.
Setenta y dos horas es poco tiempo para averiguar qué datos se vieron, de cuántas personas y durante cuánto. Si no hay registros de acceso que lo permitan reconstruir, la respuesta a la autoridad es un encogimiento de hombros, y eso agrava la situación.
Lo mínimo preparable de antemano son tres cosas: registros que permitan reconstruir accesos, saber a qué autoridad hay que notificar, y tener escrito quién decide y quién escribe la comunicación.
Conviene además distinguir entre notificar y esperar a tenerlo todo claro: el reglamento permite una notificación inicial incompleta y completarla después.
El mínimo razonable para un producto pequeño
Resumiendo en lo que de verdad cabe hacer en unos días y cubre la mayor parte del riesgo:
Recoger menos campos. Escribir la tabla de plazos y la tarea que los aplica. Tener las rutinas de exportación y borrado antes de que alguien las pida. Configurar el servicio de errores para que no capture datos sensibles. Revisar que ningún dato personal viaje en las URL. Cifrar el tránsito y la base en reposo. Y tener una política de privacidad que describa lo que el sistema hace de verdad, no lo que decía la plantilla.
Ese último punto es más importante de lo que parece: una política copiada que promete cosas que tu sistema no hace es una declaración falsa, y es peor que una breve y exacta.
Qué se le escapa a una IA con esto
Pedirle a un asistente que resuelva la parte de privacidad produce resultados de calidad muy desigual según lo que se le pida.
Lo hace bien en lo técnico concreto: escribir la rutina de exportación, la tarea de purga, la configuración para excluir campos sensibles de las trazas. Ahí el criterio de éxito es verificable y el trabajo es mecánico.
Lo hace mal en las políticas de privacidad. Genera un documento completo y de aspecto profesional que describe un sistema genérico, no el tuyo. Menciona tratamientos que no haces y omite los que sí. Como es un documento que declara lo que haces con datos ajenos, la inexactitud tiene consecuencias.
Tampoco puede decidir la base legal de cada tratamiento, porque depende de cómo funciona tu negocio y de qué le prometiste al usuario. Elegirá consentimiento por omisión, que suele ser la peor opción porque obliga a gestionar retiradas para cosas que no lo necesitaban.
Y confunde con frecuencia jurisdicciones, mezclando requisitos europeos con californianos en una misma respuesta. La forma de usarlo bien es al revés de lo habitual: dile lo que tu sistema hace y pídele que enumere qué obligaciones se activan y qué preguntas llevarías a un especialista.