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. 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 Martínez, 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, pero acceso no autorizado a datos de salud:
46     notificacion a la AEPD en 72h (Art. 33) por prudencia.
47   - Accion correctiva: RLS + formacion + canal formal.
48

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

545. PROXIMOS PASOS (Q2 2024)
55   - Simulacro de auditoría AEPD (externo)
56   - Consent management integrado en pipelines
57   - Revision trimestral de politicas RLS
58   - 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 312 historiales de salud mental 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. 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 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. Martin (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.