Cuánto tiempo guardas los registros es una decisión de privacidad que ya tomaste

Pregunta a un equipo pequeño cuánto tiempo guarda los registros de peticiones y recibirás una de dos respuestas: "lo que trae la plataforma" o "para siempre, ocupan poco". Ambas son decisiones, y la segunda es la mayor recogida de datos personales no declarada que tendrá la mayoría de los proyectos.

1. Qué hay realmente en una línea

Una entrada estándar de registro contiene la IP del cliente, la marca de tiempo, el método y la ruta, el código de respuesta, los bytes, el referer y el User-Agent. Es suficiente para identificar a una persona en muchos casos, sobre todo en un sitio con pocos visitantes: una IP más una hora más una ruta pueden identificar más que un nombre.

2. Tres razones legítimas para conservarlos

• Depurar. Algo se rompió a las 14:32 y quieres ver la petición que lo causó. Eso necesita días, no años, y la parte útil suele ser el estado, la ruta y el tiempo, no la IP completa.
• Abuso y capacidad. Un pico de tráfico, una campaña de scraping, un ataque de credential stuffing. Casi siempre necesita semanas, porque los patrones solo aparecen con el tiempo.
• Obligación legal. Algunas jurisdicciones exigen retención breve de datos de conexión para fines concretos. Es la única razón que justifica un mínimo fijo, y viene con condiciones.

Ninguna de esas razones exige la IP completa para siempre. Si puedes cumplir el propósito con una dirección truncada o un hash con clave, conservar el valor en bruto es una elección, no una necesidad.

3. Minimiza al escribir, no al borrar

La mejora de privacidad más barata en cualquier pipeline de registros está en la ingesta. Elimina el último octeto de IPv4 y los últimos 80 bits de IPv6: conservas la depuración a nivel de ciudad y destruyes casi toda la identificabilidad individual. Si necesitas correlacionar sesiones, hashea la dirección con una sal que rotas cada mes: la correlación del mismo día sigue funcionando, la de un mes a otro se corta, y la sal nunca llega al almacén.

Descarta las cadenas de consulta que no necesitas. La mitad de los datos personales de un registro típico están en la query: tokens en URLs, correos en enlaces de restablecimiento, términos de búsqueda. Registrar la plantilla de ruta en lugar de la URL completa elimina la mayoría sin perder la capacidad de depurar el enrutado.

4. Borrar es más difícil de lo que parece

Una política que dice "30 días" pero deja copias de seguridad un año es una política que no existe. Si los registros caen en almacenamiento de objetos con versionado, borrar significa borrar también las versiones. Si se exportan a una hoja de cálculo para un panel, esa copia tiene su propia retención. Los agregados derivados suelen poder conservarse —conteos por hora y ruta no son datos personales—, lo que es una buena razón para construir el agregado en vez de retener las filas.

5. Qué puedes prometer honestamente

No escribas "conservamos registros 30 días" salvo que hayas visto desaparecer una fila. Elige una ventana que puedas imponer con una regla de ciclo de vida, verifícala una vez consultando una fila antigua y pon ese número en la política. Un 14 días verificado es mejor promesa que un 90 aspiracional.

La misma lógica vale para terceros: tu CDN y tu rastreador de errores también guardan copias, con sus calendarios. Anota qué proveedor ve qué y por cuánto tiempo, porque esa es la retención que tus usuarios reciben de verdad.

ipbox.one no mantiene archivo por visitante: el único valor almacenado es un contador de límite que caduca en unos noventa segundos, y la política de privacidad lo dice así porque se puede verificar.