US-061 — Derechos del titular (Ley 81)

Detalle de la historia¶

Historia¶

Como cliente de FleteChat, quiero poder solicitar por WhatsApp (a) una copia descargable de mis datos personales y (b) la eliminación de esos datos dentro de los límites legales, con procesamiento controlado por un operador, para ejercer mis derechos de acceso, portabilidad y eliminación conforme a la Ley 81 de Panamá y equivalentes, respetando las obligaciones contables y legales de retención que aplican al negocio logístico.

Persona de usuario¶

Aplica a todo cliente (titular de cuenta o colaborador) que ejerce derechos sobre sus datos (acceso/portabilidad o eliminación). Aplica también al operador que procesa manualmente la solicitud en el backoffice (rol admin u operator con permiso específico) y al admin que gestiona los casos que requieren decisión excepcional.

Contexto de negocio¶

La Ley 81 de la República de Panamá sobre protección de datos personales (y equivalentes en otras jurisdicciones) reconoce al titular varios derechos: acceso a sus datos, portabilidad (recibirlos en formato estructurado y legible por máquina para llevarlos a otro proveedor), rectificación, oposición y eliminación (con los matices que la propia ley contempla).

Esta historia cubre dos de esos derechos en v1.0: acceso + portabilidad (el cliente pide una copia descargable de sus datos) y eliminación (el cliente pide que sus datos se borren). Rectificación se cubre operativamente con la edición de perfil en US-006; oposición no aplica al alcance del servicio en v1.0. Otros derechos quedan para versiones posteriores si la operación lo requiere.

Al mismo tiempo, un operador logístico tiene obligaciones de retención por normas contables y regulatorias (facturación, aduanas, antifraude) que impiden borrar ciertas categorías de datos antes de plazos definidos. La Ley 81 contempla esta tensión: el derecho del titular se respeta en la medida en que no colisione con obligaciones legales explícitas. Esto aplica tanto a la eliminación (hay datos que no se borran antes del plazo) como a la portabilidad (el paquete incluye la totalidad de los datos del titular en el sistema, incluyendo los sujetos a retención).

En v1.0 el procesamiento es manual (ver PR-200): el cliente solicita por WhatsApp, el agente registra la solicitud y la encola para un operador humano; el operador revisa el caso, genera el paquete de datos (para solicitudes de acceso/portabilidad) o ejecuta la eliminación parcial (para solicitudes de eliminación), y responde al cliente dentro del plazo legal (ver PR-202). La automatización completa queda para versiones posteriores.

Diálogo de referencia¶

Cliente solicita una copia de sus datos (acceso/portabilidad)¶

Cliente: Quisiera que me envíen una copia de todos mis datos que tienen.

Agente: Claro. Para procesar su solicitud de acceso y portabilidad conforme a la Ley 81 de Panamá, le preparo un paquete descargable con sus datos personales, historial conversacional y operaciones asociadas (cotizaciones, embarques, documentos). ¿Confirma la solicitud?

Cliente: Sí.

Agente: Registré su solicitud con el código SOL-20260420-002. Un asesor prepara el paquete y le enviará por correo un enlace seguro para descargarlo, dentro del plazo legal aplicable. Por seguridad usamos dos canales: el enlace llega a su correo registrado y el código para abrirlo le llega por este WhatsApp.

Cliente solicita eliminación¶

Cliente: Quiero que eliminen mis datos personales.

Agente: Entendido. Para procesar su solicitud de eliminación de datos personales conforme a la Ley 81 de Panamá, necesito que confirme: está solicitando que FleteChat elimine sus datos personales de contacto (nombre, teléfono, correo, historial de conversación). Parte de la información asociada a sus operaciones (facturas, embarques) debe conservarse por obligaciones contables y legales durante los plazos que la ley exige. ¿Confirma la solicitud?

Cliente: Sí, confirmo.

Agente: Registré su solicitud con el código SOL-20260420-001. Un asesor la va a procesar y le responderá dentro del plazo legal aplicable. Si tiene alguna consulta puntual mientras tanto, dígame y lo paso con un asesor.

Cliente pregunta por estado de la solicitud¶

Cliente: ¿Cómo va mi solicitud?

Agente: Su solicitud SOL-20260420-001 está en procesamiento. Un asesor le responderá dentro del plazo legal aplicable. Si prefiere, le paso con un asesor ahora para que le dé el estado con detalle.

Criterios de aceptación¶

Detección y registro de la solicitud¶

1. FleteChat detecta dos tipos de intenciones del titular: a. Acceso / portabilidad: "copia de mis datos", "quiero mis datos", "exportar mis datos", "portabilidad", y variantes naturales equivalentes. b. Eliminación: "eliminen mis datos", "quiero que borren mis datos", "baja de datos", "eliminación bajo Ley 81", y variantes naturales equivalentes.
2. Ante la detección, el agente confirma explícitamente con el cliente el alcance según el tipo de solicitud (paquete descargable para acceso/portabilidad; datos eliminables vs. datos con retención obligatoria para eliminación) y pide confirmación.
3. Tras la confirmación, FleteChat crea una solicitud formal con: código único (ej. SOL-YYYYMMDD-NNN), cliente, tipo (acceso_portabilidad | eliminacion), canal de entrada, timestamp, fragmento de conversación que contiene la solicitud, estado (inicialmente "registrada").

Explicación transparente al cliente¶

1. Para eliminación, el agente le explica al cliente que hay datos con retención obligatoria por norma contable y legal (facturas, embarques, documentación regulatoria) que no se pueden eliminar antes del plazo normativo, y que la eliminación se ejecutará sobre datos personales de contacto e historial conversacional en la medida que la ley lo permite (ver PR-201).
2. Para acceso/portabilidad, el agente le explica al cliente qué contiene el paquete descargable (ver AC 8 y PR-204): datos de perfil, historial conversacional, operaciones asociadas y documentos relacionados.
3. En ambos tipos, el agente informa al cliente el plazo legal de respuesta definido en PR-202.

Procesamiento por operador¶

1. La solicitud aparece en el backoffice en una bandeja dedicada accesible a admin y a operator con permiso específico. Cada solicitud muestra el contexto completo (fragmento conversacional, datos del cliente, operaciones asociadas) y el tipo de solicitud.
2. Para eliminación, el operador revisa manualmente, identifica qué datos puede eliminar y cuáles debe retener por obligación legal, ejecuta la eliminación parcial en el sistema y redacta una respuesta formal al cliente.
3. Para acceso/portabilidad, el operador dispara desde el backoffice la generación del paquete de datos (ver PR-204): el sistema arma el paquete con el contenido estandarizado y el operador valida antes de enviar el enlace de descarga al cliente.

Paquete de datos descargable (acceso y portabilidad)¶

1. La entrega del paquete usa dos canales separados (ver PR-205) para reducir el riesgo de intercepción de un solo canal: a. El enlace firmado al recurso de descarga se envía por correo electrónico al correo verificado del titular. b. El código de verificación (OTP) que autoriza la descarga se envía por WhatsApp al número verificado del titular, al momento en que el titular abre el enlace desde el correo.
2. Al abrir el enlace desde el correo, la página pide el código de verificación; FleteChat dispara el envío del OTP por WhatsApp al titular en ese momento. Ingresado el código correcto, la página inicia la descarga del paquete. Reutiliza la mecánica OTP de sesión de US-030 con la diferencia de que el enlace no viaja por WhatsApp sino por correo.
3. El paquete tiene formato ZIP y contiene: (a) un archivo JSON estructurado con todos los datos personales del titular (perfil, contactos, preferencias, historial conversacional, operaciones completas con cotizaciones y embarques), (b) PDFs de los documentos operativos emitidos para el titular (instructivos de US-019/020/021, cotizaciones, facturas en la medida que sean entregables al titular), y (c) un archivo README legible por humano que describe el contenido, la fecha de generación y el alcance legal.
4. El enlace expira en una ventana corta configurable (valor por defecto: 24 horas, alineado con la urgencia del trámite legal pero más amplio que el enlace de reportes de US-030 por el uso esperado). El enlace es de un solo uso para la descarga; tras descargarse, se invalida. El código OTP tiene vida útil propia (vida útil corta, reintentos limitados; reutiliza parámetros de US-030 PR-149).
5. El paquete incluye los datos sujetos a retención legal: el derecho de acceso/portabilidad cubre la totalidad de los datos del titular; la restricción legal de retención aplica a la eliminación, no al acceso.
6. Requisito de correo verificado: la entrega por correo requiere que el titular tenga un correo verificado (ver US-004) en el sistema. Si no lo tiene, el operador debe disparar verificación de correo antes de enviar el paquete; esto queda documentado en la solicitud.

Respuesta al cliente¶

1. La respuesta formal del operador se envía por WhatsApp (dentro de ventana de 24h) o por plantilla Meta aprobada específica según el tipo de solicitud (fuera de ventana). Incluye, según el tipo: a. Eliminación: qué se eliminó, qué se retuvo, por qué, y plazos de retención aplicables. b. Acceso/portabilidad: confirmación de que el correo con el enlace fue enviado a su dirección registrada, recordatorio de que el código OTP llegará por WhatsApp al abrir el enlace, y vigencia del enlace.

Estados y cierre¶

1. Los estados de la solicitud son: registrada, en procesamiento, paquete listo (sólo para acceso/portabilidad), entregada / completada, rechazada (caso excepcional con justificación). Los cambios de estado quedan en el audit log.
2. Una solicitud completada cierra el ciclo. Para eliminación, los datos eliminados se borran efectivamente y el audit log conserva el hecho de la eliminación (no los datos eliminados). Para acceso/portabilidad, el paquete descargado se mantiene disponible durante la ventana de expiración y luego se purga.

Consulta de estado¶

1. El cliente puede consultar el estado de su solicitud por WhatsApp ("¿cómo va mi solicitud?" con o sin código). El agente responde con el estado actual y el plazo de respuesta pendiente.

Audit log¶

1. Cada solicitud, confirmación, cambio de estado, generación del paquete, envío del correo con el enlace (destinatario, timestamp), solicitud del OTP por WhatsApp (timestamp), intentos de ingreso del OTP (válidos/inválidos), descarga efectiva, eliminación efectiva y respuesta al cliente queda registrada en el audit log con actor, timestamp y diff de datos afectados (sin exponer los datos eliminados ni el contenido del paquete).

Edge cases¶

• Cliente solicita eliminación pero tiene embarques en curso. El operador contacta al cliente (con el consentimiento previo) para aclarar si desea esperar a que termine el embarque o procesar la eliminación parcial dejando los datos del embarque hasta el cierre legal. La decisión se documenta en la solicitud.
• Cliente solicita eliminación y al día siguiente pide cotizar otra vez. El operador define en su respuesta si la eliminación se ejecuta igual (el cliente debe re-registrarse) o si el cliente desea cancelar la solicitud. Si cancela, la solicitud pasa a estado "cancelada por el cliente".
• Cliente pide acceso/portabilidad o eliminación en nombre de otra persona sin ser titular autorizado. El agente solicita verificación de identidad; si no la provee, la solicitud queda en pausa hasta confirmación. Este filtro previene abusos (especialmente crítico para acceso: entregar un paquete de datos a la persona equivocada es una fuga de datos).
• Solicitud vence el plazo legal sin haber sido procesada. El sistema alerta al admin antes del vencimiento (misma lógica que US-040) para escalar la atención y cumplir el plazo.
• Cliente solicita acceso/portabilidad o eliminación pero su cuenta no existe en FleteChat. El agente lo informa amablemente, registra la consulta como "no aplicable" y orienta al cliente.
• Cliente solicita acceso/portabilidad y eliminación en la misma conversación ("denme una copia antes de borrarme"). Se crean dos solicitudes separadas vinculadas entre sí; la de acceso se procesa primero y, tras la confirmación de descarga o el vencimiento del enlace, se procesa la de eliminación.
• Cliente no ingresa el código OTP y el enlace del paquete expira. El cliente puede pedir un nuevo enlace por WhatsApp dentro del plazo de conservación del paquete; el operador regenera el enlace y el paquete (o reutiliza el paquete existente) y envía uno nuevo al mismo correo verificado.
• Cliente intenta descargar el paquete varias veces. El enlace es de un solo uso para la descarga efectiva (PR-205 / alineado con US-030): una vez descargado, se invalida. Para una nueva descarga el cliente solicita un enlace nuevo al operador; el enlace nuevo se envía al correo.
• Cliente sin correo verificado en el sistema. El operador no puede enviar el paquete hasta disparar verificación de correo (ver US-004). La solicitud queda en estado "en procesamiento — pendiente verificación correo" y el agente avisa al cliente que antes de recibir el paquete debe verificar su correo.
• Correo del cliente termina en spam o no llega. El cliente puede pedir reenvío desde WhatsApp ("no me llegó el correo"); el operador reenvía desde el backoffice y queda auditado. Si el correo rebota (buzón lleno, dirección inválida), el operador es notificado en el backoffice y contacta al cliente para actualizar su correo verificado antes de reenviar.
• Cliente cambia de correo entre la solicitud y la entrega. Si el cliente actualiza su correo verificado (ver US-006), el enlace viaja al correo vigente al momento del envío. Si pidió reenvío, también va al correo vigente.
• Paquete grande por historial extenso. El sistema lo arma sin bloquear la UI del backoffice (procesamiento en segundo plano); la solicitud pasa a estado "paquete listo" cuando termina.
• Dato de un cliente que es también colaborador en otra cuenta. El paquete incluye únicamente los datos propios del titular solicitante; referencias a otras cuentas se incluyen con los datos mínimos necesarios para que el paquete sea coherente, pero no exponen datos ajenos.
• Cliente pide rectificación de sus datos en lugar de eliminación o acceso. La rectificación es un derecho independiente del paquete de Ley 81 y se ejerce mediante la historia de edición de datos de cliente (el cliente lo solicita al agente y el operador lo aplica en el backoffice, o el cliente usa el autoservicio si está habilitado). El operador confirma el cambio al titular; la modificación queda en audit log como cualquier edición de datos. El agente debe reconocer la intención ("actualicen mi correo", "corrijan mi número") y orientar al cliente al flujo correspondiente, no tratarlo como una solicitud de Ley 81 distinta.

Tamaño, prioridad y tipo¶

• Tamaño: M
• Prioridad: P1 — requisito legal en Panamá y equivalentes; no implementarlo expone a FleteChat a sanciones.
• Tipo: feature

Premisas¶

La historia está redactada bajo las siguientes premisas. Si alguna cambia, la historia debe revisarse y ajustarse en consecuencia. Todas deben ser confirmadas por el cliente antes de cerrar la historia.

• PR-200 — Procesamiento manual por operador en v1.0. Las solicitudes de acceso/portabilidad y de eliminación se procesan manualmente por un operador de FleteChat desde el backoffice (el operador valida identidad, dispara la generación del paquete o ejecuta la eliminación, y aprueba el envío al cliente). La automatización completa queda para versiones posteriores.
• PR-201 — Retención obligatoria por ley contable y regulatoria. Datos con obligación legal de retención (facturas, documentación aduanera, embarques cerrados bajo normativa contable) no se eliminan antes del plazo normativo aplicable. La Ley 81 de Panamá contempla esta excepción; el cliente recibe explicación clara del alcance real de la eliminación. El derecho de acceso/portabilidad no queda limitado por esta retención: el paquete incluye la totalidad de los datos del titular.
• PR-202 — Plazo legal de respuesta. FleteChat responde formalmente a cada solicitud dentro del plazo legal aplicable, que en Panamá es de 15 días hábiles desde la recepción (valor configurable por jurisdicción desde parámetros globales, ver US-046).
• PR-204 — Paquete de datos descargable. Para solicitudes de acceso/portabilidad, FleteChat genera un paquete ZIP con: JSON estructurado (perfil, contactos, historial conversacional, operaciones), PDFs de documentos operativos entregables al titular y un README explicativo. El contenido del paquete es estandarizado (no discrecional); el operador dispara la generación y valida antes de enviar el enlace al cliente.
• PR-205 — Entrega multicanal del paquete (enlace por correo, OTP por WhatsApp). La entrega del paquete separa los dos factores de autenticación en dos canales distintos para reducir el riesgo frente al compromiso de uno solo: el enlace firmado se envía por correo electrónico al correo verificado del titular (ver US-004 para la verificación); el código OTP que autoriza la descarga se envía por WhatsApp al número verificado al momento en que el titular abre el enlace desde el correo. El enlace expira en una ventana configurable (24 horas por defecto) y la descarga efectiva es de un solo uso: tras descargarse se invalida. El OTP reutiliza los parámetros de vida útil y reintentos de US-030 PR-149. Si el titular no tiene correo verificado, la entrega no procede hasta completar la verificación.
• PR-222 — Contactabilidad durante la solicitud en curso. Mientras una solicitud de eliminación está en trámite (entre la recepción y la ejecución efectiva), el número de WhatsApp y el correo verificado del titular permanecen operables para el intercambio estrictamente vinculado a esa solicitud: aclaraciones del operador, consentimientos intermedios, entrega de la respuesta formal. La eliminación se ejecuta recién en el momento final del trámite; hasta entonces no se borran ni se desactivan los canales del titular. Esta garantía aplica también si el titular tiene operaciones en curso (embarques activos) — la eliminación se coordina con el cierre legal de esas operaciones según PR-201.

Refinamiento y Definition of Ready¶

Notas¶

Checklist¶

• ✅ Historia escrita en formato Como / Quiero / Para
• ✅ Persona de usuario identificada
• ✅ Contexto de negocio documentado
• ✅ Criterios de aceptación observables y pass/fail
• ✅ Edge cases relevantes listados
• ✅ Tamaño y prioridad asignados
• ⬜ Premisas PR-200 a PR-202, PR-204 a PR-205 y PR-222 confirmadas por el cliente
• ⬜ Reglas de negocio aplicables aprobadas
• ⬜ Requerimientos funcionales aplicables aprobados
• ⬜ Historia aprobada formalmente por el cliente