US-063 — Consentimiento informado

Detalle de la historia¶

Historia¶

Como cliente que se registra en FleteChat por primera vez, quiero recibir información clara sobre qué datos se van a tratar y para qué, y dar mi aceptación explícita antes de que mis datos queden persistidos, para tener control informado sobre el uso de mi información personal conforme a la Ley 81 de Panamá.

Persona de usuario¶

Aplica a todo cliente nuevo en el momento del registro por WhatsApp (ver US-001) o desde el backoffice (ver US-005). En el alta desde backoffice, el operador registra el consentimiento obtenido por el canal por el que se captó al cliente (teléfono, presencial, correo) y queda auditado de la misma forma.

Contexto de negocio¶

La Ley 81 de la República de Panamá establece que el consentimiento del titular para el tratamiento de sus datos personales debe ser libre, específico, informado e inequívoco. El flujo de registro actual (US-001) pide datos al cliente y los persiste sin un paso explícito de consentimiento informado. Esta historia formaliza ese paso: antes de persistir los datos, el agente informa al cliente sobre las finalidades del tratamiento, enlaza la política de privacidad (ver US-062) y pide aceptación inequívoca. El consentimiento queda registrado con timestamp y versión de la política vigente al momento de la aceptación, para trazabilidad ante auditoría o disputa.

Esta historia modifica el comportamiento de US-001 y US-005 insertando el paso de consentimiento antes del "alta efectiva". No rompe la historia original: la complementa con un paso formal de cumplimiento legal.

Diálogo de referencia¶

Registro por WhatsApp (ampliando US-001)¶

Agente: Para terminar su registro necesito su aceptación de nuestra política de privacidad.

Puede leerla aquí: https://fletechat.com/privacidad (versión vigente: v1.0).

En breve: usamos su nombre, teléfono y correo para atenderle, cotizarle envíos y mantener su operación logística con nosotros. No compartimos sus datos con terceros fuera de los estrictamente necesarios para el servicio (proveedores logísticos, autoridades aduaneras).

¿Acepta que tratemos sus datos en estos términos?

Cliente: Sí, acepto.

Agente: Perfecto. Quedó registrado su consentimiento con fecha de hoy. Cuando quiera ejercer sus derechos (copia de sus datos, eliminación, consulta de la política) pídamelo por aquí. Ya puede empezar a usar el servicio.

Cliente no acepta¶

Cliente: No, no acepto.

Agente: Entendido. Respeto su decisión. Sin su aceptación no podemos crear su cuenta ni tratar sus datos; no quedará registrado en nuestro sistema.

Si quiere revisarla antes de decidir, la política está en https://fletechat.com/privacidad. Si cambia de opinión o tiene alguna duda, escríbame por aquí.

Criterios de aceptación¶

Momento y contenido del consentimiento¶

1. Durante el registro por WhatsApp (US-001), inmediatamente antes de persistir el primer dato personal del cliente en el sistema, el agente entrega un mensaje de consentimiento que incluye siempre: (a) enlace visible y prominente a la política de privacidad completa (URL oficial configurada en PR-206 de US-062, con indicación de la versión vigente), (b) resumen legible de finalidades del tratamiento (reconocer al cliente, cotizar, operar embarques, comunicaciones operativas), (c) destinatarios o categorías de destinatarios (proveedores logísticos, autoridades aduaneras), y (d) pregunta explícita de aceptación. El enlace a la política no puede omitirse ni reemplazarse por un resumen: el cliente siempre ve la URL para poder consultar la política completa antes de aceptar.
2. En el alta desde backoffice (US-005), el operador registra el consentimiento obtenido previamente por el canal off-WhatsApp (llamada, presencial, correo) con campos de: canal de captación, fecha, identificación del operador que recibió el consentimiento, observación opcional. El sistema no persiste el cliente sin estos datos completos.

Aceptación inequívoca¶

1. La aceptación debe ser explícita e inequívoca: el agente interpreta como aceptación frases claras afirmativas ("sí", "acepto", "de acuerdo", "estoy de acuerdo", "confirmado") y variantes naturales equivalentes. Respuestas ambiguas ("ok", "bueno", emoji de pulgar arriba solo) requieren reconfirmación explícita antes de considerarse aceptación válida (ver PR-207).
2. El agente no presume consentimiento por silencio ni por continuar la conversación: sin un "sí" inequívoco, los datos no se persisten.

Registro del consentimiento¶

1. El consentimiento aceptado se registra en la cuenta del cliente con: timestamp de la aceptación, versión de la política vigente al momento, canal (WhatsApp o backoffice + canal off), identificador del agente o del operador que facilitó el acto, y texto exacto enviado al cliente (snapshot del mensaje de consentimiento mostrado).
2. El registro es inmutable: no se edita ni se borra. Si FleteChat actualiza la política y necesita un nuevo consentimiento (ver AC 9), se crea un registro nuevo vinculado a la cuenta, preservando los anteriores.

Caso de rechazo¶

1. Si el cliente no acepta, el agente confirma la decisión con cortesía (US-053), no persiste los datos parciales ya capturados en el flujo de registro y limpia el contexto conversacional del registro abortado. El cliente puede intentar registrarse de nuevo cuando quiera.
2. El rechazo queda registrado en el audit log (sin datos personales del cliente) con timestamp y canal, para estadística interna y evidencia ante auditoría.

Cambios de versión de la política¶

1. Cuando FleteChat publica una versión nueva de la política con cambios sustanciales (determinado por FleteChat al publicar), el sistema puede requerir re-consentimiento de los clientes existentes (ver PR-207). El re-consentimiento se solicita por WhatsApp al próximo contacto del cliente o de forma proactiva por plantilla Meta aprobada; se registra como nuevo consentimiento sin borrar el anterior. Cambios no sustanciales no requieren re-consentimiento.

Visibilidad al cliente¶

1. El cliente puede consultar en cualquier momento su estado de consentimiento preguntando al agente ("¿cuándo di consentimiento?", "¿qué acepté?"). El agente responde con la fecha, la versión de la política aceptada y el enlace a esa versión en el histórico.

Edge cases¶

• Cliente acepta con un emoji o abreviatura ambigua. El agente pide reconfirmación: "Para dejar constancia, ¿me confirma con un 'sí acepto' o 'no acepto'?".
• Cliente empieza a dar datos personales antes de aceptar (por ejemplo, mensaje espontáneo "soy María Pérez, cel 6xxx"). El agente no persiste esos datos; informa que necesita su consentimiento primero y una vez aceptado, reconfirma los datos que el cliente ya dio.
• Cliente acepta, el sistema registra, y el cliente cambia de opinión minutos después. El cliente puede ejercer el derecho de eliminación (ver US-061). El consentimiento original se conserva como evidencia histórica; la eliminación posterior cierra el ciclo.
• Actualización de política con cambios sustanciales mientras el cliente está a mitad de un flujo. El sistema no interrumpe al cliente en un paso crítico; solicita re-consentimiento al próximo contacto conversacional no crítico.
• Cliente corporativo que lo registró un operador desde el backoffice sin constancia clara de consentimiento. El sistema rechaza el alta: US-005 exige los campos de consentimiento (canal, fecha, operador) como obligatorios. Sin ellos, no hay persistencia.
• Verificación de que el consentimiento fue realmente de quien dice ser. La verificación de identidad adicional (por ejemplo, enlace al correo, ver US-004) aplica cuando corresponde; no todo consentimiento requiere verificación de correo, pero la captura por canal verificable es preferible.

Tamaño, prioridad y tipo¶

• Tamaño: S
• Prioridad: P0 — requisito legal bajo Ley 81 de Panamá; sin consentimiento inequívoco e informado el tratamiento de datos es susceptible de 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-207 — Consentimiento inequívoco y trazable. El consentimiento para el tratamiento de datos personales debe ser libre, específico, informado e inequívoco (Ley 81). El sistema registra cada consentimiento con timestamp, versión de la política, canal, identificador del agente/operador y texto del mensaje mostrado. Respuestas ambiguas requieren reconfirmación explícita. Sin consentimiento válido no se persisten datos personales. Cambios sustanciales de la política pueden requerir re-consentimiento de los clientes existentes.
• PR-223 — El consentimiento persiste ante cambios de datos de contacto. El consentimiento registrado se vincula al titular (no a su correo o número específico) y persiste cuando el titular modifica su correo verificado, su nombre o agrega/remueve números (ver historias de edición de datos y de múltiples números). El cambio de correo o número no invalida el consentimiento; el nuevo canal hereda el consentimiento existente. La modificación del canal queda registrada en audit log como evento aparte. La única situación que puede exigir re-consentimiento es la publicación de una versión nueva de la política con cambios sustanciales (AC 9).

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-207 y PR-223 confirmadas por el cliente
• ⬜ Reglas de negocio aplicables aprobadas
• ⬜ Requerimientos funcionales aplicables aprobados
• ⬜ Historia aprobada formalmente por el cliente