Documento vigente · versión 2.2

Política y Procedimiento de Borrado de Datos — Memo (@getmemo_bot)

Última actualización: 28 de agosto de 2026 Versión: 2.2 — vigente desde el 28 de agosto de 2026

Este documento describe cómo un usuario solicita el borrado de sus datos, qué se elimina, qué se conserva y por qué, y cómo debe implementarlo el bot (corriente B). Cumple el derecho de cancelación de la Ley 19.628 y el requisito de borrado en cascada del contrato de datos.

1. Cómo lo solicita el usuario

Dos vías, ambas deben quedar disponibles:

Comando en el bot: /borrar_mis_datos. Es la vía principal y debe estar siempre operativa, incluso para cuentas vencidas o canceladas.
Correo de contacto: contacto@getmemobot.app, para quien no pueda usar el bot. La identidad se valida pidiendo que el mensaje provenga de la cuenta de Telegram registrada o confirmando el telegram_id.

2. Confirmación previa (anti-borrado accidental)

El borrado es irreversible. El comando debe pedir una confirmación explícita antes de ejecutar (por ejemplo, un botón "Sí, borrar todo" / "Cancelar"). El mensaje debe advertir que:

Se eliminan todos sus movimientos, recordatorios, fotos y documentos procesados, tarjetas, cuentas separadas con sus saldos y movimientos, pagos recurrentes, memoria de largo plazo y memoria conversacional.
La acción no se puede deshacer.
Si tiene una suscripción activa, conviene cancelarla antes (el borrado no detiene por sí solo un cobro recurrente de la pasarela).

3. Qué se elimina

Al confirmar, se borra todo lo que cuelga del usuario. Gracias a las llaves foráneas con ON DELETE CASCADE del esquema, eliminar la fila de usuarios arrastra todas las tablas dependientes:

usuarios — la cuenta (identificador, nombre, estado, plan y ciclo, consentimiento con su versión, moneda, fuente).
movimientos — todos los gastos e ingresos, incluidos los marcados con tarjeta.
tarjetas — las tarjetas de crédito del usuario (nombres/alias y estado).
categorias_usuario — la taxonomía personalizada de categorías.
recordatorios — todos los recordatorios (también deben des-agendarse del scheduler en memoria, ver sección 6).
cuentas y cuenta_movimientos — las cuentas separadas y su ledger completo, en cualquier moneda.
pagos_recurrentes y pagos_realizados — las cuentas fijas y su historial de pago por periodo.
memoria — la memoria de largo plazo (dato potencialmente sensible; su eliminación es parte esencial del borrado).
borradores — propuestas de registro pendientes de confirmar.
alertas_gasto — alertas de presupuesto.
uso — contadores de cupos.
conversacion — memoria conversacional del LLM.
pagos — ver la excepción de la sección 4 (se disocia, no se borra).
Fotos de boletas y documentos — si existiera algún archivo temporal en disco, se elimina.

Implementación esperada (corriente B): un único borrado de la fila en usuarios filtrando por usuario_id, dentro de una transacción, dejando que la cascada del esquema haga el resto. Verificar que PRAGMA foreign_keys=ON esté activo en la conexión (lo está en core/db.py), porque de lo contrario la cascada no se aplica.

4. Qué se conserva (y por qué)

Registros de pago (pagos): se conservan por obligación contable y tributaria, aun después del borrado, por el plazo legal. El esquema lo implementa con ON DELETE SET NULL: al borrar la fila de usuarios, las filas de pagos no se eliminan sino que quedan disociadas (su usuario_id pasa a NULL). Se conserva el registro de la transacción (identificador en la pasarela, monto, estado, fecha), no el detalle de en qué gastó el usuario: los datos financieros personales (montos de movimientos, glosas, boletas, cuentas, memoria) se borran con la cascada.
Respaldos (backups): los respaldos existentes se sobrescriben en su ciclo normal de rotación. Un dato borrado puede sobrevivir en un respaldo hasta que ese respaldo se rote. No se restauran datos borrados desde un respaldo.

Toda excepción de conservación se limita a lo estrictamente exigido por la ley o necesario para defensa ante reclamos. Nunca se conserva con fines comerciales.

5. Plazos

Borrado por comando: inmediato. La confirmación dispara el borrado en línea y el bot responde confirmando que se ejecutó.
Borrado por correo: dentro de un plazo razonable desde que se valida la identidad (objetivo: pocos días hábiles).

6. Efectos colaterales que el bot debe manejar

Recordatorios agendados: además de borrarlos de la tabla, hay que cancelar sus jobs en el scheduler en memoria (APScheduler) para que no se disparen contra un usuario inexistente.
Sesión/estado en memoria: limpiar cualquier caché de la conversación del usuario.
Suscripción activa: el borrado no cancela el cobro recurrente en la pasarela de pagos (dLocal). Si la cuenta está activa, el bot debe advertirlo y, si corresponde, indicar cómo cancelar antes de borrar (desde el bot o escribiendo a contacto@getmemobot.app).

7. Confirmación al usuario

Tras ejecutar, el bot informa que el borrado se completó y qué quedó conservado por obligación legal (registros de pago disociados, si aplica). El usuario puede volver a usar Memo registrándose de nuevo con /start, lo que crea una cuenta nueva desde cero (y exige aceptar la versión vigente de los términos).

8. Registro interno

Se deja constancia mínima de que ocurrió un borrado (fecha y telegram_id hasheado o el identificador de pago), sin conservar los datos borrados, para poder acreditar el cumplimiento de la solicitud si fuese requerido.