Primer commit - Sprint 1
This commit is contained in:
54
ADR-003-consentimiento-versionado.md
Normal file
54
ADR-003-consentimiento-versionado.md
Normal file
@@ -0,0 +1,54 @@
|
||||
# ADR-003 — Consentimiento granular, versionado e inmutable
|
||||
|
||||
- **Estado:** Aceptado
|
||||
- **Fecha:** (completar con fecha de commit)
|
||||
|
||||
---
|
||||
|
||||
## Contexto
|
||||
|
||||
Bajo lógica RGPD / Ley 7593, el consentimiento para datos sensibles debe ser específico, informado y
|
||||
**demostrable**: hay que poder probar qué consintió cada persona, cuándo, y contra qué texto. Además,
|
||||
el director planteó dos caminos de consentimiento que pueden coexistir y divergir: documentos
|
||||
firmados (empresa/encuestado) y checkboxes in-app.
|
||||
|
||||
## Decisión
|
||||
|
||||
### 1. El consentimiento es evidencia, no solo UI
|
||||
Mostrar el checkbox no alcanza. Cada respuesta guarda un **registro de consentimiento** con: versión
|
||||
del texto, scopes efectivamente aceptados, timestamp. Es **inmutable** (solo INSERT/SELECT; sin
|
||||
UPDATE/DELETE).
|
||||
|
||||
### 2. Versionado del texto
|
||||
El texto de consentimiento vive en `consent_versions`. Si cambia el wording en el futuro, las
|
||||
respuestas viejas **conservan su versión vieja**. Nunca se reescribe retroactivamente lo que alguien
|
||||
aceptó.
|
||||
|
||||
### 3. Granular por capas
|
||||
Scopes separados por propósito, aceptables independientemente:
|
||||
`operativo` (dashboard de su empresa), `macro_n1` (agregados anónimos del estudio país), y a futuro
|
||||
`macro_n2` / `macro_n3`. **v1 ofrece solo `operativo` + `macro_n1`** (las encuestas son anónimas y
|
||||
Modo A sin Nivel 3). Un titular puede aceptar operativo y rechazar macro.
|
||||
|
||||
### 4. La elección del titular gana sobre la firma de la empresa
|
||||
Si la empresa firmó "todos los datos van al macro" pero el empleado destildó macro en la app, la
|
||||
respuesta NO entra al macro. El registro in-app del titular es la fuente de verdad sobre su propio dato.
|
||||
|
||||
### 5. Honestidad sobre derechos en encuestas anónimas
|
||||
En encuesta anónima:
|
||||
- No se puede hacer firmar al encuestado nada identificable (destruiría el anonimato) → el registro
|
||||
in-app es el **único** registro de consentimiento posible; no se complementa con firma del titular.
|
||||
- No se puede **revocar** después (no se puede ubicar la respuesta). El texto debe declararlo
|
||||
explícitamente **antes** de responder: "esta encuesta es anónima; no vas a poder revocar luego".
|
||||
- El wizard, al togglear anonimato, cambia qué derechos se pueden ofrecer y ajusta el texto.
|
||||
|
||||
## Consecuencias
|
||||
- (+) Demostrabilidad ante la ANPDP; trazabilidad por versión.
|
||||
- (+) Respeta la autonomía del titular sobre su dato sensible.
|
||||
- (−) Un mismo dato puede estar en el dashboard de la empresa pero excluido del macro (lógica de
|
||||
reportes debe respetar `granted_scopes` por fila — no es opcional).
|
||||
- (−) Encuestas anónimas pierden el derecho de revocación; debe comunicarse con transparencia.
|
||||
|
||||
## Relación con otros ADR
|
||||
Implementa el componente de consentimiento de ADR-001. El esquema está en `DATA_MODEL.md`
|
||||
(`consent_versions`, `consent_records`).
|
||||
Reference in New Issue
Block a user