6.4 KiB
ADR-001 — Modelo de privacidad y gobierno de datos
- Estado: Aceptado
- Fecha: (completar con fecha de commit)
- Decisores: Director del proyecto + asistente de dirección técnica
- Contexto legal: Paraguay, Ley N° 7593/2025 de Protección de Datos Personales
Contexto
El producto corre la misma encuesta en N empresas con dos propósitos en tensión: operativo (dashboard por empresa para decidir acciones) y macro (estudio país de la "economía de la discapacidad"). Se tratan datos sensibles (salud/discapacidad). Resolver mal esta tensión significa o filtrar datos confidenciales entre empresas, o perder el análisis macro que es el diferencial.
Marco legal aplicable: la Ley N° 7593/2025 fue promulgada el 27/11/2025, está alineada con el RGPD europeo, crea la Agencia Nacional de Protección de Datos Personales (ANPDP) con régimen sancionatorio, y tiene vacatio legis de 24 meses (exigibilidad plena ~nov 2027). Reconoce categoría especial para datos sensibles (incluye salud) y derechos de acceso, rectificación, oposición, supresión, portabilidad y revocación del consentimiento. No es asesoría legal; validar con especialista antes de producción.
Decisión
Adoptamos un modelo de privacy by design con los siguientes componentes cerrados:
1. Anonimato como propiedad por-encuesta
El anonimato no es global de la plataforma: cada encuesta lo declara en su configuración. El wizard de creación lo togglea y eso propaga a cómo se guarda cada respuesta.
2. Dos ejes de clasificación, ortogonales
- Sensibilidad legal (
comun|sensible|anonimizado) → alimenta el consentimiento. - Seguridad (
publico|interno|confidencial) → alimenta RLS y cifrado.
"Confidencial" es seguridad, NO una categoría legal. Una encuesta puede ser confidencial en storage y no-sensible legalmente, o al revés.
3. La herramienta constriñe, no solo permite
La clasificación no es pura auto-declaración del creador. Ciertos tipos de pregunta (salud/discapacidad) se auto-marcan sensibles y elevan la encuesta, sin importar lo que elija el creador. El wizard guía y bloquea por defecto hacia la clasificación correcta. (Operacionaliza los principios de minimización y responsabilidad proactiva de la ley.)
4. El titular del consentimiento es el respondente, no la empresa
La empresa autoriza el despliegue; el individuo consiente el tratamiento de su propio dato sensible. Ante divergencia entre un documento firmado por la empresa y la elección granular del titular en la app, gana siempre la elección del titular.
5. Consentimiento granular, por capas y versionado
Checkboxes separados por propósito (operativo / macro N1 / macro N2...), no un único "acepto todo". Cada respuesta guarda un registro inmutable con timestamp contra la versión vigente del texto. (Ver ADR-003.)
6. Rol de responsable parametrizable (controller_role), con cascada
- Modo A (nosotros = responsable): macro a todos los niveles consentidos por el titular.
- Modo B (empresa = responsable, nosotros = encargado): macro solo vía Nivel 1 anonimizado irreversible. Usar dato de Modo B para Nivel 2/3 sería ejercer de responsable encubierto → ilícito.
Regla limpia: Modo A → macro a todos los niveles consentidos. Modo B → macro solo vía Nivel 1 anonimizado. El wizard debe mostrar la consecuencia al elegir el modo, no ofrecerlo como dropdown plano.
7. Anónimo a nivel respondente, conservando atribución de empresa (las 4 de v1)
- Sí se conserva
company_id+ cuasi-identificadores (edad en bucket, sector, zona) → habilita Nivel 2 (empresa A vs el resto) y comparación por segmento. - No se recolecta
respondent_id. El campo queda reservado en el esquema para encuestas futuras, pero para estos 4 estudios el dato queda permanentemente en Nivel 1/2.
8. Distinción anónimo vs pseudónimo (textual, para no re-confundir)
La comparación por segmento ("25 / sector X / zona A" vs "zona B") usa los cuasi-identificadores
de cada fila y no requiere respondent_id. La clave pseudónima solo sirve para vincular varias
respuestas a la misma persona desconocida (longitudinal, re-contacto, dedup avanzado) — nada de eso
es caso de v1. La dedup simple se hace con ip_hash.
9. Umbral de k-anonimato mandatorio en visualización
Anónimo en storage no es a prueba de re-identificación: un n=1 por cruce de cuasi-identificadores es identificable. Toda visualización compartida (incluido el dashboard de la empresa) suprime celdas con n < umbral (default 5). La comparación individuo-vs-individuo está prohibida en dashboards compartidos; la inspección fila-por-fila es solo análisis interno (Modo A).
10. Texto libre fuera del store analítico crudo
Las preguntas abiertas no se exponen crudas a reportes (vector de re-identificación). Se categorizan antes (a futuro, vía LLM — está en BACKLOG).
Alcance de esta etapa (v1)
Solo Modo A, solo encuestas anónimas, sin Nivel 3 atribuible. El esquema soporta más (controller_role, respondent_id) pero v1 no lo opera. Principio: el esquema guarda la opción, estos datos puntuales no la usan.
Alternativas consideradas
- Macro 100% anonimizado siempre (solo Nivel 1): más simple, pero mata el benchmark sectorial que el director quiere a futuro. Rechazado por cerrar opción de bajo costo.
- Pseudonimización con
respondent_iddesde v1: habilita longitudinal/re-contacto pero agrega carga legal (es dato personal) sin caso de uso inmediato. Rechazado para v1; campo reservado. - Nivel 3 atribuible desde v1: máximo poder analítico, pero requiere acuerdo de tratamiento por empresa + consentimiento explícito + vía de re-identificación. Diferido hasta tener feedback real.
Consecuencias
- (+) Cumplimiento alineado a Ley 7593 desde el diseño; soberanía; protección del empleado frente a su empleador.
- (+) Mantiene viva la opción de Nivel 2 sin recolectar datos personales adicionales.
- (−) El dato de los 4 estudios no podrá usarse jamás para análisis atribuible ni longitudinal individual (decisión consciente).
- (−) El umbral de k-anonimato puede dejar segmentos chicos sin reporte ("n insuficiente") — es el costo correcto de la privacidad.
Pendiente
Validación del flujo de consentimiento y del lenguaje legal con asesor paraguayo antes de producción.