Skip to main content
Traducción. Autoritativo: fs-core-0014-erasure-portability.md.

​
Contexto

La Ley 21.719 entra en plena vigencia el 2026-12-01, y la supresión es el derecho que más directamente choca con cómo está construido el resto del sistema. Los libros de puntos son append-only por integridad contable; los registros de auditoría existen precisamente para que nada desaparezca. DEC-J3 resuelve el conflicto sin fingir que no existe: el perfil y los eventos se borran; las filas del libro se anonimizan a un tombstone. La anonimización satisface el derecho —el dato deja de ser atribuible a una persona— mientras la contabilidad queda entera. El plazo comprometido es ≤30 días y el proceso es automatizado, porque un proceso manual es un proceso que llega tarde justo el mes en que todos están ocupados. La orquestación vive en core y no en cada módulo. Un solo lugar decide qué significa suprimir, y los módulos obedecen.

​
Alcance (normativo)

  • core.subject_requests: solicitudes de supresión y portabilidad con su ciclo de vida.
  • Orquestación de la supresión entre todos los módulos, con acuse por módulo.
  • Borrado de contacto y eventos; anonimización del libro instruida a fidelización.
  • Exportación de portabilidad: todo sobre el titular en un formato estructurado y de uso común.
  • Prueba de ejecución retenida después de que el dato ya no está.
  • El SLA de 30 días con escalamiento antes de incumplirlo.

​
Fuera de alcance (normativo)

  • Verificar la identidad del solicitante. Esa es la obligación del tenant como responsable (DEC-J1); nosotros ejecutamos una instrucción de un tenant autenticado.
  • El formulario de solicitud para el member — frontend/portal.
  • Borrar un tenant. Eso es offboarding, otro runbook.

​
Comportamiento (normativo)

  1. Una solicitud tiene ciclo de vida: received → validated → executing → completed, con timestamp en cada paso. La línea de tiempo es la evidencia.
  2. El SLA es ≤30 días y escala en el día 21. Descubrir un incumplimiento el día 31 es descubrirlo demasiado tarde.
  3. La supresión se orquesta: core instruye a cada módulo y espera su acuse. Un módulo que no acusa bloquea la finalización — una supresión parcial reportada como completa es el peor resultado posible.
  4. Por módulo: core borra perfil, identidades, consentimientos y eventos. loyalty anonimiza las filas del libro a un tombstone y no borra nada. messaging borra el contenido de los envíos y conserva los conteos agregados. crm borra notas y actividades.
  5. Las supresiones (de envío) sobreviven a la supresión (de datos), como identificador hasheado sin perfil asociado. Borrarlas permitiría volver a escribirle a esa dirección, que es lo contrario de lo que la persona pidió.
  6. La prueba de ejecución sobrevive: una fila de auditoría registra que la supresión ocurrió, para quién (como referencia opaca), cuándo, y qué módulos acusaron. La prueba es lo único que debe sobrevivir al dato.
  7. La portabilidad exporta todo sobre el titular en formato estructurado y de uso común, entregado por un enlace firmado que expira.
  8. Una supresión es irreversible y se confirma antes de ejecutar. No hay deshacer, y la API lo dice.
  9. Los respaldos vencen por su propia retención; la solicitud lo deja registrado y no afirma otra cosa. Prometer borrado instantáneo de los respaldos sería una promesa que no podemos sostener.

​
Datos (normativo)

​
API (normativo)

​
Eventos (normativo)

core.contact.erased en el outbox, para que todo consumidor —incluido el webhook del propio tenant— descarte su copia. Un tenant que espejó nuestros contactos debe enterarse.

​
Criterios de aceptación (normativo)

  1. La supresión borra perfil, identidades, consentimientos y eventos, y deja las filas del libro anonimizadas con el total de puntos pendientes del programa sin cambios.
  2. Un módulo que no acusa bloquea la finalización, y la solicitud queda en executing.
  3. La fila de auditoría de prueba de ejecución sobrevive y nombra los módulos que acusaron.
  4. Una supresión de envío sobrevive como identificador hasheado y sigue bloqueando un envío a esa dirección.
  5. La exportación de portabilidad contiene todas las categorías listadas en el RAT y es JSON válido.
  6. El enlace de exportación expira y se rechaza después.
  7. El escalamiento del día 21 se dispara para una solicitud aún incompleta.
  8. Negativo: ningún camino de supresión borra una fila del libro, y ninguna finalización se reporta sin el acuse de todos los módulos.

​
Ejecución

Pipeline asíncrono. Orquestador en backend/workers, monitoreo del SLA en backend/scheduler. Cada módulo expone un handler interno de supresión; core nunca entra a las tablas de otro módulo.

​
Preguntas abiertas

​
Changelog

​
Registro de entrega

Aún no implementado.