Frank, analicé ambos documentos legales. Acá van las respuestas a tus 4 preguntas: --- **1. ¿La tabla queda en Supabase?** Sí, sería una tabla más en la misma base de datos de Supabase (`profile_deletions_log` o similar). Queda protegida por las mismas políticas RLS — solo accesible para administradores, no para usuarios regulares. --- **2. ¿Es histórica o se renueva día a día?** Histórica por necesidad — si se borrara diariamente, perdería su propósito. Pero con una política de retención definida (por ejemplo, purgar registros mayores a 12 meses automáticamente con un cron, similar al de purga de entidades que ya existe). --- **3. ¿Viola los T&C o la Política de Tratamiento de Datos?** Revisé ambos documentos. **No la viola, siempre que se diseñe correctamente.** Acá lo relevante: - **T&C numeral 9.5** establece que al cerrar cuenta se procede a la *"supresión o anonimización"* de los datos. La palabra clave es **"o"** — la anonimización es una opción válida. - **Política de Datos** permite conservar datos cuando *"el tratamiento sea necesario para el cumplimiento de obligaciones legales"* y menciona retención documental como excepción legítima. - **La solución segura**: guardar en el audit log solo datos **anonimizados** — por ejemplo, tipo de perfil y fecha de eliminación, pero **sin email ni nombre real**. Así: - ✅ Cumples con el reporte diario (sabés que ayer se eliminaron 2 usuarios individuales) - ✅ Cumples con T&C (los datos personales se suprimieron, solo queda un conteo estadístico) - ✅ No hay datos identificables en la tabla de auditoría --- **4. ¿Qué pasa si un usuario solicita eliminar TODOS sus datos?** Tus documentos distinguen implícitamente dos escenarios: - **Eliminar cuenta** (self-service desde el panel): Se borra la cuenta y se anonimiza/suprime según la política. El registro anonimizado en el audit log **no es dato personal** — no identifica a nadie. - **Solicitud formal de supresión total** (vía datos@lpdi.co): Acá sí tendrías que purgar incluso el registro del audit log si alguien lo pidiera formalmente. Pero si el log es anónimo (sin email, sin nombre), no hay nada que purgar porque no se puede vincular a la persona. --- **Mi recomendación de diseño:** La tabla `profile_deletions_log` guardaría únicamente: | Campo | Ejemplo | |-------|---------| | `id` | uuid auto | | `deleted_at` | 2026-06-03T14:30:00Z | | `profile_type` | "usuario_individual" | | `had_startup` | false | | `had_icg` | false | **Sin email, sin nombre, sin ID del usuario.** Puro dato estadístico. Así el reporte diario puede decir "ayer se dieron de baja 2 usuarios individuales" sin conservar ningún dato personal. ¿Quieres que proceda con este enfoque anonimizado? _También pendientes (sin acknowledgment todavía): LAP-329, LAP-340, LAP-343, LAP-344_