Saltar al contenido
~/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.

⏱ 35 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. Martín, 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: 20 de septiembre 2024
4Presentado por: tú, Senior Data Engineer
5Revisado por: Rosa Martínez, DPO
6

71. SITUACIÓN INICIAL (lunes)
8   - Sin proceso automatizado de supresión GDPR
9   - Sin anonimización formal para investigación
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 16-20 septiembre)
15

16   a) Supresión automatizada (Art. 17)
17      - Proceso reproducible con certificado de evidencia
18      - Verifica excepciones legales ANTES de borrar
19      - Conserva BLOQUEADA la historia clínica que la ley obliga a
20        guardar, y la borra sola cuando vence el plazo
21      - Tiempo de ejecución: < 2 minutos por solicitud
22      - Resultado: 100% trazabilidad, 0% riesgo de borrado ilegal
23

24   b) Anonimización k-anonymity (Art. 89)
25      - k=5 verificado (supera mínimo del comité de ética)
26      - Generalización progresiva con mínimo impacto en utilidad
27      - Verificación automática antes de exportar dataset
28      - Resultado: datos útiles para investigación sin riesgo
29

30   c) Audit trail inmutable (Art. 30)
31      - Registro de CADA acceso a datos de pacientes
32      - Búsqueda en < 5 segundos (SLA AEPD: 72h)
33      - Retención 24 meses, tabla append-only
34      - Detector automático de anomalías
35      - Resultado: ya detectó incidente interno en tiempo real
36

37   d) Row-Level Security (Art. 25 - Privacy by Design)
38      - Implementado tras incidente del 18/09 (al día siguiente)
39      - Cada rol ve SOLO lo que necesita para su función
40      - Control a nivel de BD (no depende de la aplicación)
41      - Tests automatizados de políticas en CI/CD
42      - Resultado: técnicamente imposible repetir el incidente
43

443. INCIDENTE GESTIONADO (18 de septiembre)
45   - Acceso no autorizado por empleado junior (sin malicia)
46   - Detección: 2 minutos. Contención: 26 minutos.
47   - Sin exfiltración, pero acceso no autorizado a datos de salud:
48     notificación a la AEPD en 72h (Art. 33) por prudencia.
49   - Acción correctiva: RLS + formación + canal formal.
50

514. ESTADO ACTUAL: 4/4 controles operativos
52   - Incidente documentado con post-mortem
53   - Formación GDPR programada para todo el equipo
54   - Pipeline de consent management en desarrollo
55

565. PRÓXIMOS PASOS (Q4 2024)
57   - Simulacro de auditoría AEPD (externo)
58   - Consent management integrado en pipelines
59   - Revisión trimestral de políticas RLS
60   - 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, y me sale que sí. Que los datos no salieran del sistema reduce el daño, pero el Art. 4.12 considera violación el acceso no autorizado aunque el dato no se exfiltre. El Art. 33.1 obliga a notificar salvo que sea improbable que haya riesgo, y con hasta 12.847 pacientes identificados junto a sus diagnósticos, vistos por alguien sin autorización, no puedo sostener que el riesgo sea improbable. Así que notificamos, dentro del plazo de 72 horas, y documentamos el alcance y las medidas ya tomadas." Marta asiente: "Correcto. Ante datos de categoría especial, la prudencia es notificar y demostrar diligencia. Quien decide no notificar tiene que poder argumentar por escrito por qué el riesgo era improbable -- y eso, aquí, no se sostiene."

Dr. Martín 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. Martín 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. Martín debe EXCLUIRLO automáticamente del dataset."

El consent management en MediTrack funciona así: cada paciente tiene N registros de consentimiento, uno por finalidad que lo necesita (investigación, marketing, compartir con aseguradora, datos de wearable). La asistencia no está entre ellas: no necesita consentimiento (Art. 9.2.h). Cada consentimiento puede estar "otorgado" o "revocado" con fechas. Los pipelines de esas finalidades deben verificar ANTES de procesar que el paciente tiene consentimiento activo; el asistencial deja pasar sin comprobar nada, porque no hay nada que comprobar.

1-- Modelo de consentimiento por finalidad
2-- Un paciente puede tener el consentimiento de marketing concedido y el de
3-- investigacion revocado. No es un SI/NO global.
4--
5-- Los cuatro tipos que existen en consentimientos.tipo_consentimiento son:
6--   investigacion · marketing · compartir_aseguradora · wearable_data
7-- La asistencia sanitaria NO esta en esta tabla, y es a proposito: no se apoya
8-- en consentimiento, sino en el Art. 9.2.h (lee el aviso de abajo).
9

10SELECT
11    paciente_id,
12    tipo_consentimiento,
13    estado,
14    fecha_otorgamiento,
15    fecha_revocacion
16FROM consentimientos
17WHERE paciente_id = 12
18ORDER BY tipo_consentimiento, fecha_otorgamiento DESC;
19

20-- Resultado real para el paciente 12:
21-- 12 | compartir_aseguradora | granted | 2024-09-28 11:38:51 | NULL
22-- 12 | investigacion         | revoked | 2025-03-29 11:42:33 | 2026-01-21 11:42:33
23-- 12 | marketing             | granted | 2025-03-21 11:09:15 | NULL
24

25-- Esto significa:
26-- - NO podemos incluirlo en el dataset del Dr. Martín (investigacion revocado)
27-- - Podemos enviarle comunicaciones de salud (marketing concedido)
28-- - Podemos compartir datos con su aseguradora (compartir concedido)
29-- - Y podemos atenderle igual: la asistencia no depende de esta tabla
30

31-- Query para verificar consentimiento activo:
32SELECT EXISTS (
33    SELECT 1 FROM consentimientos
34    WHERE paciente_id = 12
35      AND tipo_consentimiento = 'investigacion'
36      AND estado = 'granted'
37      AND fecha_revocacion IS NULL
38) AS tiene_consentimiento_investigacion;
39-- Resultado: false

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

La asistencia sanitaria no se apoya en el consentimiento sino en una base propia del Art. 9: la letra h del 9.2 (fines de medicina preventiva, diagnóstico y asistencia), junto con el 9.3. No basta con el Art. 6 —una base del Art. 6 es necesaria, pero para un dato de salud SIEMPRE hace falta además una excepción del Art. 9.2—. En cambio, la "investigación" sí se apoya en consentimiento explícito (o en el 9.2.j con garantías), que el paciente puede revocar en cualquier momento. Por eso un pipeline de investigación DEBE verificar consentimiento activo ANTES de incluir a cada paciente; uno asistencial no depende de esa casilla.

Regístrate para guardar tu progreso.