Como operativizar los requisitos de retencion y eliminacion entre sistemas

Muchas empresas pueden describir sus reglas de retencion en una politica mucho antes de poder ejecutarlas bien en la practica.

La politica puede decir que los tickets de soporte se conservan durante un periodo definido, que los datos de candidatos se eliminan despues de cierto tiempo, que los datos del cliente se borran tras terminar el contrato y que las copias de seguridad siguen un calendario separado. Sobre el papel, eso parece controlado.

En operaciones, sin embargo, el trabajo rara vez es tan limpio.

Los mismos datos suelen vivir en bases de datos de produccion, plataformas de analitica, herramientas de tickets, almacenamiento de archivos, sistemas de soporte, registros de CRM, herramientas de RR. HH. y backups. Distintos equipos son dueños de esos sistemas. Distintos eventos inician el plazo de retencion. Algunos registros deben guardarse mas tiempo por razones legales, contractuales o de investigacion. Otros deberian desaparecer mucho antes.

Por eso la retencion y la eliminacion se vuelven dificiles. El problema normalmente no es si la empresa tiene una regla. El problema es si tiene un modelo operativo.

Que significa realmente operativizar la retencion

Operativizar la retencion y la eliminacion significa convertir una afirmacion de politica en trabajo repetible.

Para la mayoria de los equipos SaaS, eso implica poder responder con claridad a cinco preguntas basicas:

• a que tipo de dato o registro se aplica la regla
• en que sistemas vive ese dato
• que evento inicia el periodo de retencion
• quien es responsable del borrado, archivado o manejo de excepciones
• que evidencia demuestra que la accion ocurrio

Si falta alguno de esos enlaces, la regla se vuelve dificil de ejecutar de forma consistente.

Por que las empresas tropiezan entre sistemas

Las reglas de retencion fallan en entornos con multiples sistemas porque la politica suele escribirse alrededor de categorias de registros, mientras que el negocio real funciona con sistemas, workflows y flujos de datos desordenados.

Una empresa puede definir una sola regla para la informacion de cuentas de clientes, pero la huella real de esa informacion abarca:

• la aplicacion de produccion
• herramientas de facturacion
• tickets de soporte
• analitica de producto
• almacenamiento en la nube
• exportaciones internas
• tablas del data warehouse
• entornos de backup

Borrar un registro visible en el sistema principal no significa que el requisito ya se haya cumplido en todas partes.

Cinco puntos de ruptura que generan deriva

1. La regla no esta mapeada a sistemas reales

El primer fallo es simple. La politica nombra el tipo de registro, pero nadie ha mapeado donde existe realmente.

Los equipos creen que ya tienen un proceso de borrado porque la aplicacion puede desactivar una cuenta o eliminar un documento. En realidad, las copias siguen viviendo en logs, herramientas de sincronizacion, espacios internos o plataformas posteriores.

La retencion solo se vuelve operativa cuando la regla se conecta con el inventario real de sistemas.

2. El disparador de la retencion es ambiguo

Muchos equipos definen una duracion sin definir el evento que inicia el reloj.

Por ejemplo:

• El plazo empieza cuando el cliente se da de baja o cuando termina la ultima obligacion de servicio?
• Los datos de candidatos caducan tras el rechazo, tras cerrar la vacante o tras la ultima comunicacion?
• Un registro de soporte sigue la fecha de cierre del ticket, el contrato del cliente o un calendario legal independiente?

Si el disparador es ambiguo, distintos equipos calcularan la misma regla de forma distinta.

3. Los backups y archivos se tratan como un detalle tardio

Muchos programas se rompen cuando se ignora el comportamiento de los backups y archivos.

No todos los sistemas permiten un borrado inmediato de cada copia historica. Eso no siempre significa incumplimiento, pero si significa que el modelo de retencion debe explicar que se elimina de los sistemas vivos, que caduca por rotacion de backups y que controles limitan la restauracion o la reutilizacion.

Si esa distincion nunca se documenta, la empresa puede prometer un borrado que en realidad no puede ejecutar.

4. Las excepciones se manejan de forma informal

Las reglas de retencion rara vez son absolutas. Legal holds, disputas, revisiones de fraude, investigaciones de incidentes, registros fiscales y obligaciones contractuales pueden justificar conservar datos mas tiempo que el calendario por defecto.

Eso es normal. El riesgo aparece cuando las excepciones solo viven en correos o en la memoria de alguien.

Sin una via documentada para excepciones, los equipos o bien borran demasiado y crean riesgo, o bien conservan todo para siempre porque nadie quiere tomar la decision equivocada.

5. No existe una huella clara de evidencia

Muchas empresas hacen parte del trabajo de borrado, pero luego no pueden demostrarlo.

Un engineer ejecuta un script. Un responsable de soporte cierra una solicitud. Un proveedor confirma una purga. Un ciclo de backup expira. La accion ocurrio, pero nada la vincula con la politica, el sistema, la solicitud, la aprobacion o la fecha de cierre.

Ese modelo de evidencia debil se vuelve doloroso durante auditorias, diligencia de clientes e investigaciones internas.

Como se ve un modelo operativo util

Un programa practico de retencion y eliminacion no necesita empezar como una iniciativa gigantesca. Si necesita algunos elementos estructurales.

Empiece con un calendario canonico

Mantenga una unica fuente de verdad para el conjunto principal de reglas. Debe definir tipo de registro, duracion, disparador, owner y excepciones permitidas. Si cada area conserva su propia interpretacion, la deriva empieza enseguida.

Mapee el calendario a sistemas y no solo a categorias de politica

Para cada tipo de dato importante, identifique los sistemas donde ese dato se crea, almacena, copia, exporta o archiva. Aqui es donde muchos equipos descubren el alcance real del trabajo.

Defina el workflow de borrado y no borrado

El workflow deberia mostrar:

• que evento inicia el temporizador
• que accion ocurre cuando termina el plazo
• si se espera borrado, anonimizado o archivado
• quien aprueba excepciones o legal holds
• donde se registra la finalizacion

Separe el borrado vivo del ciclo de vida del backup

No lo convierta todo en una promesa vaga. Sea claro sobre que se elimina de inmediato de los sistemas operativos y que desaparece mediante la expiracion normal del backup.

Mantenga evidencia ligera

La evidencia no tiene que ser complicada. Si tiene que ser consistente. Registros de tickets, logs del sistema, confirmaciones de proveedores, aprobaciones y salidas de revisiones periodicas suelen ser suficientes si estan conectados al workflow.

Como empezar sin intentar modelarlo todo

La mayoria de los equipos no deberia empezar intentando cubrir cada clase de dato de la empresa.

Un mejor punto de partida es concentrarse primero en las areas que generan mas presion de negocio y regulatoria:

• datos de cuentas y producto de clientes
• registros de soporte y solicitudes de confianza
• datos de empleados y candidatos
• documentacion de proveedores y procesadores

Elija uno o dos workflows donde hoy las solicitudes de borrado, las promesas contractuales o las preguntas de auditoria ya generan friccion. Mapee los sistemas. Defina el disparador. Identifique al owner. Documente la ruta de excepciones. Capture evidencia. Luego amplie desde ahi.

Eso suele ser mucho mas efectivo que volver a reescribir la politica.

Conclusion practica

Los requisitos de retencion y eliminacion no se vuelven reales porque aparezcan en una politica. Se vuelven reales cuando la empresa puede conectar cada regla con sistemas, disparadores, responsables, excepciones y evidencia.

Si su equipo todavia describe el borrado con frases generales como "ingenieria se encarga" o "el proveedor deberia quitarlo", el siguiente paso util no es una politica mas pulida. Es construir un pequeno modelo operativo y comprobable alrededor de los workflows que mas importan.