~/bigdatastack

lección 7

Día 5 -- Presentación al compliance board y consent management

Viernes: presentas la arquitectura de gobernanza al board (CEO, DPO, abogada externa, Director Médico). Además implementas un pipeline consent-aware que respeta automáticamente las preferencias de cada paciente.

⏱ 40 min

### Viernes, 9:00 AM -- Preparando la presentación

Datasets de esta lección (en tu carpeta datos/): datos/consentimientos.csv (columnas id, paciente_id, tipo_consentimiento, estado, fecha_otorgamiento, fecha_revocacion, version_politica, canal — la base del pipeline consent-aware) y datos/pacientes.csv (columnas consent_investigacion y consent_marketing). Con ellos diseñas el pipeline que excluye automáticamente a quien haya revocado el consentimiento para la finalidad concreta del procesamiento.

Rosa te avisó el miércoles: "El viernes hay reunión trimestral del compliance board. Quiero que presentes lo que hemos implementado esta semana. Van a estar: yo, el Dr. Martin, el CEO (Andrés Molina) y nuestra abogada externa (Marta Serrano, del despacho Garrigues). Necesito que lo expliques de forma que Andrés lo entienda -- él no es técnico pero es el responsable último ante la AEPD."

Laura te ayuda a preparar: "El truco con un board no técnico es: no hables de PostgreSQL, triggers ni Python. Habla de RIESGOS que hemos mitigado, CONTROLES que hemos implementado y EVIDENCIA que podemos mostrar si viene la AEPD. Andrés piensa en riesgo de negocio y probabilidad de multa, no en líneas de código."

### La estructura de tu presentación

1RESUMEN EJECUTIVO -- GOBERNANZA DE DATOS MEDITRACK
2====================================================
3Fecha: 8 de marzo 2024
4Presentado por: tú, Senior Data Engineer
5Revisado por: Rosa Martinez, DPO
6

71. SITUACION INICIAL (lunes)
8   - Sin proceso automatizado de supresión GDPR
9   - Sin anonimización formal para investigacion
10   - Sin audit trail de accesos granular
11   - Sin control técnico de acceso a nivel de fila (RLS)
12   - Riesgo: multa potencial hasta 20M EUR (Art. 83.5 GDPR)
13

142. CONTROLES IMPLEMENTADOS (semana 4-8 marzo)
15

16   a) Supresion automatizada (Art. 17)
17      - Proceso reproducible con certificado de evidencia
18      - Verifica excepciones legales ANTES de borrar
19      - Tiempo de ejecucion: < 2 minutos por solicitud
20      - Resultado: 100% trazabilidad, 0% riesgo de borrado ilegal
21

22   b) Anonimizacion k-anonymity (Art. 89)
23      - k=5 verificado (supera mínimo del comite de etica)
24      - Generalizacion progresiva con mínimo impacto en utilidad
25      - Verificacion automática antes de exportar dataset
26      - Resultado: datos útiles para investigacion sin riesgo
27

28   c) Audit trail inmutable (Art. 30)
29      - Registro de CADA acceso a datos de pacientes
30      - Busqueda en < 5 segundos (SLA AEPD: 72h)
31      - Retencion 24 meses, tabla append-only
32      - Detector automático de anomalias
33      - Resultado: ya detecto incidente interno en tiempo real
34

35   d) Row-Level Security (Art. 25 - Privacy by Design)
36      - Implementado tras incidente del 6/03 (mismo día)
37      - Cada rol ve SOLO lo que necesita para su función
38      - Control a nivel de BD (no depende de la aplicacion)
39      - Tests automatizados de politicas en CI/CD
40      - Resultado: tecnicamente imposible repetir el incidente
41

423. INCIDENTE GESTIONADO (6 de marzo)
43   - Acceso no autorizado por empleado junior (sin malicia)
44   - Deteccion: 2 minutos. Contencion: 26 minutos.
45   - Sin exfiltracion de datos. Sin notificación AEPD requerida.
46   - Accion correctiva: RLS + formacion + canal formal.
47

484. ESTADO ACTUAL: 4/4 controles operativos
49   - Incidente documentado con post-mortem
50   - Formacion GDPR programada para todo el equipo
51   - Pipeline de consent management en desarrollo
52

535. PROXIMOS PASOS (Q2 2024)
54   - Simulacro de auditoría AEPD (externo)
55   - Consent management integrado en pipelines
56   - Revision trimestral de politicas RLS
57   - Automatizar borrado diferido (prescripciones que expiran)

El resumen ejecutivo -- lenguaje de riesgo y controles, no de tecnología

### Las preguntas del board

Andrés (CEO) pregunta primero: "Si mañana viene la AEPD y nos pide demostrar quién accedió a los datos de un paciente concreto hace 6 meses, cuánto tardamos?" Tu respuesta: "Menos de 5 segundos. La query está indexada y probada." Andrés asiente satisfecho.

Marta Serrano (abogada) pregunta: "El incidente de esta semana -- tenemos obligación de notificar a la AEPD bajo el Art. 33?" Rosa responde: "Lo he evaluado. Los datos no salieron del sistema -- solo fueron SELECTs en un cliente SQL local, sin exportación, sin envío a terceros. Según el Art. 33.1, la obligación de notificar existe si hay riesgo para los derechos de los interesados. Sin exfiltración, no hay riesgo real. Pero he documentado la decisión y la justificación por si la AEPD pregunta." Marta asiente: "Correcto. La documentación de la decisión es clave -- demuestra diligencia."

Dr. Martin pregunta: "Y mi dataset de investigación, puedo usarlo ya?" Tu respuesta: "Sí, está listo. k=5 verificado automáticamente, aprobado por el comité de ética, sin posibilidad de reidentificación. Te lo envío esta tarde al repositorio seguro." El Dr. Martin sonríe -- es la primera vez que le ves sonreír en toda la semana.

Andrés cierra: "Buen trabajo. Rosa, quiero un simulacro de auditoría el mes que viene. Que venga alguien externo a intentar encontrar agujeros. Si los hay, mejor que los encontremos nosotros antes que la AEPD." Rosa mira hacia ti y asiente con aprobación discreta. Viniendo de ella, es casi un abrazo.

Consejo de senior: Cuando presentas a un board no técnico, la estructura es: 1) cuál era el riesgo (en euros y probabilidad), 2) qué hiciste para mitigarlo, 3) cómo puedes DEMOSTRAR que funciona. Si el CEO puede responder "estamos cubiertos si viene la AEPD" con confianza, tu presentación fue un éxito. Los detalles técnicos se quedan para el 1:1 con Laura.

### Consent management -- el último pilar

Después de la reunión del board, Laura te pide una última cosa: "Rosa quiere que antes de cerrar la semana dejemos diseñado el consent management para pipelines. La idea es que NINGUN pipeline pueda procesar datos de un paciente si ese paciente ha revocado su consentimiento para esa finalidad concreta. Ejemplo: si un paciente revocó consentimiento para investigación, el pipeline del Dr. Martin debe EXCLUIRLO automáticamente del dataset."

El consent management en MediTrack funciona así: cada paciente tiene N registros de consentimiento, uno por finalidad (asistencial, investigación, marketing, compartir con aseguradora). Cada consentimiento puede estar "otorgado" o "revocado" con fechas. Los pipelines deben verificar ANTES de procesar que el paciente tiene consentimiento activo para la finalidad del pipeline.

1-- Modelo de consentimiento por finalidad
2-- Un paciente puede tener consentimiento para asistencial pero NO para investigacion
3

4SELECT 
5    paciente_id,
6    finalidad,
7    estado,
8    fecha_otorgado,
9    fecha_revocado
10FROM consentimientos
11WHERE paciente_id = 'PAC-001234'
12ORDER BY finalidad, fecha_otorgado DESC;
13

14-- Resultado ejemplo:
15-- PAC-001234 | asistencial     | otorgado | 2022-01-15 | NULL        (activo)
16-- PAC-001234 | investigacion   | revocado | 2022-01-15 | 2023-11-03 (revocado)
17-- PAC-001234 | marketing       | otorgado | 2022-01-15 | NULL        (activo)
18-- PAC-001234 | compartir_aseg  | revocado | 2022-06-01 | 2023-08-20 (revocado)
19

20-- Esto significa:
21-- - Podemos usar sus datos para atención medica (asistencial)
22-- - NO podemos incluirlo en el dataset del Dr. Martin (investigacion revocado)
23-- - Podemos enviarle comunicaciones de salud (marketing)
24-- - NO podemos compartir datos con su aseguradora (compartir revocado)
25

26-- Query para verificar consentimiento activo:
27SELECT EXISTS (
28    SELECT 1 FROM consentimientos
29    WHERE paciente_id = 'PAC-001234'
30      AND finalidad = 'investigacion'
31      AND estado = 'otorgado'
32      AND fecha_revocado IS NULL
33) AS tiene_consentimiento_investigacion;
34-- Resultado: false

El consentimiento es granular por finalidad -- no es un SI/NO global

El consentimiento para "asistencial" es casi implícito en la relación médico-paciente (Art. 6.1.b GDPR -- ejecución de contrato). Pero el consentimiento para "investigación" requiere aceptación EXPLICITA y puede revocarse en cualquier momento. Un pipeline de investigación DEBE verificar consentimiento activo ANTES de incluir cada paciente.

## ejercicios

[01]

Informe de salud de controles para auditoría

Escribe una query SQL que genere el "informe mensual de salud" de todos los controles implementados. Es lo que Rosa presenta cada mes al board: supresiones ejecutadas, datasets anonimizados, accesos auditados, anomalias detectadas y accesos bloqueados por RLS.

Cargando editor...
[02]

Pipeline consent-aware para investigacion

Implementa una clase ConsentAwarePipeline que verifica automaticamente el consentimiento de cada paciente ANTES de procesar sus datos. Si un paciente ha revocado consentimiento para la finalidad del pipeline, se excluye automaticamente y se registra la exclusion.

Cargando editor...

Regístrate para guardar tu progreso.

## comentarios

Reporta erratas, ayuda a otros o comparte tu opinión. Sé constructivo.

Inicia sesión para comentar y responder.

cargando comentarios...