Una política de retención y borrado no se implementa con una única instrucción DELETE. En una aplicación PHP, la misma información puede aparecer en varias tablas, archivos, cachés, registros y servicios externos. Si el proceso sólo elimina la fila principal, puede dejar copias activas; si borra sin revisar dependencias, puede romper operaciones o eliminar datos que debían conservarse.
El objetivo práctico es convertir cada regla en un flujo que identifique los datos afectados, aplique la acción adecuada, gestione excepciones y deje evidencia verificable. La política debe acordarse con las áreas responsables de producto, tecnología y datos, y contrastarse con las obligaciones aplicables al negocio. No conviene inferir plazos legales universales: dependen del contexto y deben validarse antes de automatizarlos.
Empieza por las categorías y las reglas de conservación
Antes de diseñar el borrado, clasifica la información según su finalidad y uso. Un perfil, una dirección necesaria para una operación pendiente, un historial de actividad y un registro contable pueden tener reglas distintas, aunque estén relacionados con la misma cuenta.
Para cada categoría, documenta al menos:
- Finalidad y responsable: por qué se almacena y qué equipo decide sobre su conservación.
- Evento que inicia la regla: por ejemplo, cierre de cuenta, vencimiento de una relación o solicitud validada.
- Plazo y condición: cuándo se revisa o ejecuta la acción, incluyendo posibles suspensiones justificadas.
- Acción: borrar, anonimizar, conservar con acceso restringido o derivar a revisión manual.
- Dependencias: sistemas y procesos que deben completarse antes de declarar el caso resuelto.
“Conservar” no significa mantener indefinidamente por comodidad. Debe tener una razón, un alcance y una fecha o condición de revisión. Si una parte de la información tiene que mantenerse por una necesidad operativa, separa ese conjunto del resto y limita quién puede acceder a él.
Inventaría copias, referencias y sistemas conectados
El inventario debe seguir el recorrido real del dato, no sólo el esquema de la base de datos. Examina tablas relacionadas, campos JSON, archivos subidos, exportaciones, índices de búsqueda, cachés, colas, registros de aplicación y sistemas integrados. Incluye también los flujos que generan copias: informes, herramientas de soporte, analítica o procesos de importación.
Para cada ubicación, anota qué identificador permite encontrar el dato, quién es responsable, cómo se elimina o actualiza y qué ocurre si el sistema no está disponible. Revisa relaciones mediante claves foráneas y lógica de aplicación: una relación en la base de datos puede impedir el borrado en cascada, mientras que una eliminación en cascada puede borrar más de lo previsto.
Trata las copias de seguridad como un caso separado. Puede que no permitan borrar un elemento individual sin restaurar la copia completa. Define cómo se limita su acceso, cuánto tiempo permanecen y qué procedimiento evita que un dato eliminado vuelva a sistemas activos tras una restauración. Documenta la decisión y valídala con las personas responsables de infraestructura y cumplimiento.
Decide cuándo borrar, anonimizar o conservar
El borrado físico elimina el dato de un sistema activo, pero no siempre es la opción correcta para cada registro. La anonimización puede ser apropiada cuando se necesita conservar información estadística y se puede retirar de forma efectiva la posibilidad de vincularla con una persona. Sustituir un nombre por un identificador estable no basta si existe otra tabla que permite reconstruir la relación.
La conservación restringida puede servir para los datos que aún son necesarios para una operación o una obligación validada. Mantén esos elementos separados, con permisos específicos y una regla de revisión. Si no se puede determinar con seguridad qué acción corresponde —por ejemplo, por una disputa, una dependencia desconocida o una incoherencia de identidad—, dirige el caso a una cola de revisión en lugar de improvisar.
También hay que revisar las consecuencias funcionales: qué sucede con pedidos, suscripciones, tickets, claves de API o documentos compartidos cuando desaparece una cuenta. El comportamiento debe ser explícito y coherente entre la interfaz, la lógica PHP y los servicios conectados.
Implementa un flujo idempotente y observable
Un proceso de borrado suele ejecutarse en segundo plano, mediante una cola o una tarea programada. Modela el caso con estados explícitos, por ejemplo: solicitado, validado, en proceso, pendiente de sistemas externos, completado o requiere revisión. Define transiciones permitidas y quién puede reintentar o cerrar una excepción.
La idempotencia es esencial: repetir una etapa no debe duplicar efectos ni causar daños. Antes de borrar un archivo, comprueba que existe; al procesar una solicitud, verifica el estado actual; al llamar a un servicio externo, utiliza mecanismos de idempotencia si están disponibles. Si no puedes garantizarlo, registra la respuesta y diseña una reconciliación antes de reintentar a ciegas.
Un esquema conceptual en PHP podría separar la orquestación de las acciones por sistema:
foreach ($steps as $step) {
if ($step->isComplete($requestId)) {
continue;
}
$step->execute($subjectReference);
$step->markComplete($requestId);
}El ejemplo no resuelve transacciones distribuidas: una base de datos y un proveedor externo no comparten necesariamente una transacción. Guarda el progreso de forma fiable, maneja errores por etapa y permite retomar el trabajo. Si una operación falla a mitad, el estado debe indicar qué falta; no debe presentarse como completada.
Registra la ejecución sin crear otra copia personal
La trazabilidad permite responder quién o qué proceso actuó, cuándo, sobre qué solicitud y con qué resultado. Registra identificadores internos de operación, estados, etapas y códigos de error útiles para diagnóstico. Evita copiar nombres, correos, documentos, contenido de archivos o cargas completas de API en los logs.
Un identificador de usuario seudónimo sigue pudiendo ser sensible si permite volver a identificar a alguien. Restringe el acceso al registro, limita su conservación y separa la información operativa de la identidad cuando sea posible. Los mensajes de error deben ayudar a localizar el sistema afectado sin exponer datos personales en herramientas de monitorización.
Comprueba el resultado y prepara las excepciones
Las pruebas deben cubrir tanto el caso normal como los fallos parciales. Usa datos de prueba y verifica las ubicaciones identificadas en el inventario, no sólo la tabla principal. Incluye escenarios como una relación que impide borrar, un archivo ausente, un proveedor externo no disponible, un reintento y una excepción que exige revisión.
Una lista operativa útil pregunta: ¿se localizó cada copia conocida?, ¿se aplicó la acción prevista en cada categoría?, ¿quedó alguna etapa pendiente?, ¿los sistemas externos confirmaron el resultado?, ¿los logs contienen sólo la información necesaria?, ¿un reintento conserva la seguridad del proceso? Añade comprobaciones periódicas para detectar nuevas tablas, integraciones o rutas de datos que hayan quedado fuera del inventario.
Ejemplo hipotético: cierre de una cuenta
Supongamos que una persona solicita cerrar su cuenta en una aplicación PHP. El flujo valida la solicitud y consulta las reglas definidas para perfil, archivos, actividad e información asociada a operaciones pendientes. El perfil y los archivos elegibles se eliminan; ciertos registros se conservan de forma restringida si existe una razón aprobada; los datos destinados a análisis sólo permanecen si se han anonimizado de manera efectiva.
La aplicación registra cada etapa sin incluir el correo ni el contenido de los archivos. Si un servicio externo no responde, el caso queda como pendiente y un proceso posterior reintenta o solicita intervención según la política. Sólo se marca como completado cuando todas las acciones requeridas han sido confirmadas o cuando una excepción formal queda documentada y aprobada.
Antes de implementar, resuelve las decisiones todavía abiertas: qué sistemas contienen el dato, quién autoriza excepciones, qué significa “completado” para cada destino, cómo se tratan las copias de seguridad y quién revisa los fallos. Esa definición convierte una intención de borrado en un proceso mantenible, comprobable y seguro.
