¿Por qué es tan difícil borrar en entornos que han crecido con los años?
Una clienta figura en el sistema central, en el sistema de siniestros o de expedientes, en la contabilidad, en el CRM y en el archivo. Los sistemas son de distintos fabricantes, algunos tienen décadas y los datos dependen unos de otros: un contrato remite a una persona, un pago a un contrato.
Si cada sistema borra por su cuenta, surgen lagunas y contradicciones. Algunos sistemas tienen sus propios motivos para conservar los datos más tiempo. Y sin respuesta, al final nadie sabe si los datos han desaparecido realmente en todas partes. Un borrado manual por sistema es caro y difícil de demostrar.
¿Qué debe ofrecer un control del borrado?
| Requisito | Por qué |
|---|---|
| Orden correcto | Los datos dependientes se borran primero; en ningún lugar queda una referencia a datos ya borrados. |
| Objeciones | Una aplicación puede oponerse porque todavía necesita los datos. |
| Bloqueos de borrado | Un legal hold detiene los borrados en casos concretos, por ejemplo en un litigio. |
| Aprobaciones | Cuando el riesgo lo exige, una persona autorizada aprueba el borrado antes de que se ejecute. |
| Respuesta | Cada aplicación confirma lo que ha borrado. |
| Supervisión | Si falta una respuesta, se emite un aviso. |
| Registro | Una prueba por ciclo de borrado para la auditoría y la autoridad de supervisión. |
Control central, borrado descentralizado
Cada aplicación es la que mejor conoce su estructura de datos y su lógica de negocio. Por eso debería borrar ella misma, con sus funciones de borrado existentes. El control central no interviene en las bases de datos: establece qué se borra y cuándo, comprueba y reúne las respuestas.
Las aplicaciones se conectan mediante una interfaz abierta, por ejemplo REST, o mediante mensajes, por ejemplo con Azure Service Bus. Así, las aplicaciones pueden conectarse paso a paso, sin cambiarlo todo de golpe.
¿Borrar, anonimizar o archivar?
No todas las aplicaciones deben reaccionar igual. Según el tipo de datos y la obligación, se borra, se anonimiza (por ejemplo, si los datos se necesitan para estadísticas) o se archiva, si aún está vigente una obligación de conservación. Un buen control permite definirlo por aplicación y deja constancia de lo que ha ocurrido en cada caso.
Desde la práctica
En Pax, la aseguradora suiza de previsión con sede en Basilea, Espresso Data Privacy borra desde 2024 de forma automatizada en sistemas SAP y no SAP, con cadenas de borrado que tienen en cuenta las dependencias entre aplicaciones y objetos de negocio.