Errores comunes de retencion y eliminacion que los equipos SaaS aun cometen

Los errores de retencion y eliminacion aparecen cuando una empresa SaaS trata el tema como una politica, no como una operacion. Bajo el GDPR, los datos personales no deben conservarse mas tiempo del necesario para el proposito, deben existir plazos de borrado o revision, y el derecho de supresion puede exigir una respuesta concreta. Lo dificil es demostrar que esa regla vive en sistemas, tickets, proveedores, backups y evidencia.

Los fallos mas comunes son triggers poco claros, reglas no mapeadas a sistemas reales, excepciones informales, promesas de borrado que ignoran backups y evidencia debil. Un flujo pequeno y repetible suele reducir mas riesgo que otra version de la politica.

Por que falla incluso en equipos capaces

En papel parece simple: datos de clientes durante un periodo, tickets de soporte durante otro, candidatos hasta terminar el proceso y backups por rotacion. En la practica, los mismos datos aparecen en la aplicacion, warehouse, CRM, helpdesk, logs, analytics, billing, exports, espacios compartidos y proveedores.

Si el mapa no existe, el borrado es parcial. Se elimina la cuenta visible, pero quedan eventos, adjuntos, exportaciones o copias en otro sistema.

Error 1: politica sin mapa de sistemas

Una retention schedule debe conectarse con sistemas y vendors reales. Para cada flujo importante, documenta donde vive el dato, quien es owner, que accion es posible y que evidencia queda. Empieza por cierre de cuentas, solicitudes de supresion, tickets de soporte, registros de empleados, offboarding de proveedores, analytics y logs.

Error 2: duracion sin trigger

Muchos equipos saben cuanto tiempo conservar datos, pero no cuando empieza el reloj. Puede ser cancelacion, factura final, desactivacion, cierre del ticket o fin de obligaciones contractuales. Si el trigger no esta escrito como evento operativo, cada equipo calcula distinto.

Error 3: asignarlo todo a engineering

Engineering ejecuta mucho del borrado, pero legal, privacy, security, support, finance, product y procurement tambien tienen piezas del proceso. El flujo debe aclarar quien decide la regla, quien detecta el trigger, quien aprueba excepciones, quien ejecuta y quien conserva evidencia.

Error 4: revisar minimizacion demasiado tarde

La eliminacion se complica cuando se han recogido demasiados datos. Formularios, analytics, adjuntos de soporte, integraciones y campos libres distribuyen datos personales rapidamente. Antes de lanzar una funcion, pregunta si el dato es necesario, si bastan datos agregados o anonimos, donde se copia y que regla de retencion aplica.

Error 5: prometer borrado absoluto sin backups

Los sistemas vivos pueden borrar rapido, mientras que backups y archivos expiran por rotacion. Algunas copias son inmutables o no permiten borrar un registro aislado. El modelo debe distinguir borrado en sistemas activos, anonimizacion, ciclo de backups, controles de restauracion y legal holds. El EDPB destaco en 2026 que backups y periodos de retencion siguen siendo retos practicos.

Error 6: tratar todas las solicitudes igual

El derecho de supresion no es absoluto. Pueden existir obligaciones legales, interes publico o defensa de reclamaciones. Usa un arbol de decision: confirmar identidad y scope, localizar sistemas y vendors, verificar base de supresion, revisar excepciones, ejecutar borrado, anonimizar, restringir o retener con razon documentada.

Error 7: perder la evidencia

El trabajo puede haberse hecho y aun asi no estar audit-ready. Un script, un email del vendor y un ticket cerrado no bastan si no estan conectados. La evidencia debe unir regla, trigger, decision, owner, accion, fecha y excepcion.

Error 8: no actualizar tras cambios de producto

Nuevas integraciones, tablas de analytics, logs de AI, screenshots de soporte o migraciones de billing cambian el alcance de retencion. Los lanzamientos de alto riesgo deben revisar datos personales, copias, owners, borrado y evidencia antes de salir.

Checklist practico

• Cada regla esta conectada a sistemas y vendors.
• El trigger es un evento claro.
• Hay owners de decision, ejecucion y evidencia.
• Backups, archivos y exports estan tratados por separado.
• Las excepciones y legal holds estan documentados.
• Las promesas a clientes coinciden con la realidad tecnica.

Si varias respuestas son negativas, empieza con un flujo de alto riesgo: cierre de cuenta, solicitud de supresion o retencion de tickets de soporte.