Capítulo 3 de la serie Sprint DGX (desde el Capítulo 1). El arco de 26 días en el que la fricción legal fue más difícil que el machine learning.
La conversación que el pitch técnico no incluye nunca
Cuando pitcheas un proyecto de IA clínica a un sponsor del tamaño de NVIDIA, hay una parte que nunca se firma en el mail de aplicación: cómo viajan físicamente tus datos sanitarios desde tu disco local hasta un servidor multi-tenant del que vas a salir en 60 días.
El RGPD tiene mucho que decir sobre eso. Y no son sugerencias.
Este capítulo cuenta cómo lo gestionamos durante 26 días del sprint, qué nos encontramos por el camino, y cuál fue el momento más incómodo de todo el proyecto. Spoiler: no fue una respuesta del vendor que tardó, ni un wipe que no se hizo. Fue algo que descubrimos nosotros mismos, sin que nadie nos obligara a buscarlo.
Anonimizar un DICOM no es lo mismo que «ya está, ya es público»
El malentendido más común en proyectos de IA sanitaria es asumir que vaciar los campos de paciente en una imagen DICOM la convierte en un dato sin restricciones. No es así.
Bajo el Artículo 9 del RGPD, la categoría especial de datos de salud, , lo que muchos llaman «anonimización» es en realidad pseudonimización (Art.4.5). La diferencia es jurídicamente enorme: la pseudonimización es reversible si alguien vuelve a tener acceso a la tabla de mapeo que conecta un identificador opaco con el paciente real. Y mientras el dato sea reversible, sigue siendo dato de salud.
Eso significa que aunque hayas vaciado todos los campos PII de las cabeceras DICOM y reemplazado los identificadores por hashes, esos GB que quieres subir al cloud siguen estando en el régimen reforzado del Art.9. El RGPD te pide entonces documentar cuatro cosas concretas:
- Quién es quién: controller, processor, sub-processor. Los roles tienen que estar claros.
- Qué pasa con los bloques físicos del disco cuando termina el procesamiento.
- Si existe un Data Processing Agreement (DPA) que cubra explícitamente el Art.9.
- Si puedes obtener un Certificate of Destruction que documente el método de borrado y la fecha, idealmente bajo un estándar reconocido como NIST SP 800-88 Rev.1.
Sin esas cuatro respuestas por escrito, subir los datos al instance es asumir riesgo legal no documentado. Y el sprint no podía arrancar el upload sin esto.
Día 10: dos mails al mismo tiempo, no uno
Mandamos dos mails simultáneos. No uno. La diferencia importa.
Uno fue al orquestador del grant, que es quien gestiona el provisioning y el borrado del nodo. El otro fue al proveedor de infraestructura física subyacente, que es quien tiene la custodia real de los discos donde aterrizarían las imágenes.
La razón de mandar los dos en paralelo es operativa. Si solo escribes al orquestador, lo más probable es que después de unos días te conteste «ese tema lo lleva el proveedor de hardware, contacta con ellos». Dos mails en paralelo cubren toda la cadena desde el primer momento, y cada parte responde lo que sí gestiona.
Las cuatro preguntas iban más o menos así:
- Cuando se elimina un instance, ¿qué pasa con los bloques físicos del disco subyacente? ¿Se sobrescriben, se cero-rellenan, se crypto-erase antes de devolverse al pool, o el borrado es solo lógico?
- ¿Hay algún mecanismo documentado para lanzar un wipe seguro del volumen de trabajo desde dentro del instance, antes de eliminarlo?
- ¿Qué entidad es el contacto formal para obtener un Certificate of Destruction una vez completado el borrado?
- ¿Existe un Data Processing Agreement que cubra explícitamente el procesamiento de datos de salud bajo Art.9 del RGPD?
El cierre de ambos mails era casi más importante que las preguntas: «Esto no bloquea el provisioning del instance. Vamos a empezar con benchmarks sobre datasets públicos. El upload de datos clínicos queda condicionado a recibir estas respuestas por escrito.»
Esa última frase es la que mantiene el sprint en movimiento mientras la conversación legal avanza. No paralizamos todo: paralizamos solo el upload de los datos propios. El nodo se provisiona, los benchmarks sobre datasets públicos arrancan, las primeras fases metodológicas corren.
El plan B que documentamos el mismo día
Mandar los mails sin plan B sería depender ciegamente del vendor. Si las respuestas tardan o llegan negativas, ¿qué hacemos?
Tres opciones, archivadas el mismo día:
- Cifrado AES en reposo del directorio de datos clínicos dentro del instance, con una clave que nunca toca el disco persistente del propio servidor. El coste de cómputo es trivial sobre 8 H100.
- Wipe manual seguro antes del delete: lanzar un borrado seguro con varias pasadas sobre el path de los datos antes de eliminar el instance. No es perfecto —el borrado a nivel de bloque del host no está garantizado por esta vía— pero es defensa en profundidad real.
- Solo subir blobs ya cifrados: la clave vive en una máquina local, se descifra en memoria al cargar al modelo, y los datos en claro nunca tocan el disco persistente del instance.
Con el plan B sobre la mesa teníamos margen. Si todo iba mal, el upload se hacía cifrado y el sprint seguía. La conversación legal podía durar lo que tuviera que durar.
Plot twist número uno: la cadena de proveedores no era exactamente la que asumíamos
Al provisionarse el instance descubrimos que la arquitectura real del backend tenía una capa más de la que asumimos al redactar los mails. Sin entrar en nombres comerciales —porque la cadena exacta de sub-processors es información contractual del partner, no nuestra para hacer pública—, lo relevante es esto:
- El régimen RGPD aplicable acabó siendo más favorable de lo previsto, no menos. El sub-processor real publica DPA estándar, tiene certificaciones internacionales reconocidas (incluyendo equivalencias HIPAA en regiones específicas), y los términos son auditables.
- El destinatario «técnicamente correcto» del segundo mail era ligeramente distinto al que habíamos escrito. Daño cero: las preguntas que importaban habían ido también al orquestador, que sí es la contraparte correcta del proyecto.
Hubo además un detalle operativo que simplificó la cadena de custodia más de lo que esperábamos: el tipo de instance era non-stoppable por diseño. No se puede pausar. El nodo arranca el Día 1 y solo se apaga al final del sprint, con un único evento de borrado. Eso suena a limitación, pero desde el punto de vista de protección de datos es una ventaja: hay un único punto de extinción, en lugar de múltiples ciclos de stop/start con persistencia entre sesiones.
Plot twist número dos: el problema serio era otro
Aquí viene el momento incómodo.
Bien entrados en el sprint, lanzamos una auditoría forense interna sobre el filesystem del instance. No la lanzamos porque nada chirriara: la lanzamos porque nuestros workflows internos incluyen una revisión periódica de PII en el árbol de archivos como práctica preventiva. Nadie nos obligó a hacerla. Si no hubiera estado en el calendario, no habríamos encontrado lo que encontramos.
Dentro del directorio del export DICOM había un subdirectorio que se había quedado del primer pase del pipeline, antes del strip de cabeceras. Decenas de gigas. Cientos de miles de ficheros. Más de mil carpetas con paths que seguían el patrón <APELLIDO>_UUID/...
El DICOM final, el que estaba en producción del sprint, estaba correctamente anonimizado: cabeceras vacías, identificadores opacos. Pero ese directorio intermedio, olvidado del primer pase, tenía nombres de pacientes en los propios paths del filesystem. Pseudonimización rota a nivel de árbol de archivos.
La lección operativa es brutalmente simple: el strip de cabeceras DICOM cubre el contenido del archivo, no la ruta donde el archivo vive. Si tu pipeline genera estructuras de carpetas con identificadores reales antes de un rename posterior, esos paths son PII en filesystem-scope, exactamente igual de regulada que la PII en cabeceras.
El fix de fondo se hizo en una nueva versión del pipeline de anonimización, que genera identificadores opacos desde el primer pase y no hace renames a posteriori. Pero antes de borrar nada, tocaba construir cadena de custodia.
Cadena de custodia antes que prisa
La tentación de borrar inmediatamente lo que no debería estar ahí es enorme. Es exactamente la tentación que hay que aguantar.
Durante una semana construimos el rastro documental completo: hashes SHA256 sobre la totalidad del contenido, snapshot del estado del filesystem, registro temporal de cada paso, copia íntegra verificada de los DICOM ya anonimizados sobre nuestro NAS local.
La cadena de custodia es lo que permite que, si alguien pregunta dentro de tres años qué pasó con esos datos, exista una respuesta documentada con timestamps y hashes que cuadran. No es ceremonia: es lo que te permite responder «sí, lo gestionamos, aquí está la prueba» en lugar de «creemos que…».
El día del borrado: siete segundos
Una vez la cadena de custodia estaba completa y verificada, ejecutamos el borrado. Sobre NVMe, el sistema operativo tardó poco más de siete segundos en eliminar el directorio entero.
Comprobación posterior:
- El DICOM anonimizado correctamente no se vio afectado.
- Muestra aleatoria de ficheros del NAS local: todos los hashes verificados contra los pre-calculados.
- Verificación canónica final completa.
Siete segundos para borrar el problema. Y unos días de trabajo previo para asegurarnos de que esos siete segundos se podían defender ante cualquier auditor que llamara a la puerta.
El evento contractual de destrucción de datos —el borrado del instance completo al final del sprint— sigue agendado para su día. Pero el riesgo concreto del audit forense ya estaba cerrado.
Estado al cerrar el arco RGPD
- DICOM verificado limpio: cero PII residual ni en contenido ni en paths.
- Cadena de custodia documental completa: mails iniciales, auditoría forense, limpieza destructiva y backup íntegro en NAS local.
- Régimen legal cubierto: DPA del sub-processor, orquestador como processor formal, sponsor del grant sin participación en el data path.
- Plan B documentado y disponible para escenarios futuros, aunque no hizo falta ejecutarlo.
La lección, sin barniz
Hay dos formas de gestionar el cumplimiento del Art.9 en un proyecto de IA clínica sobre cloud GPU. La primera es ir cumpliendo lo mínimo, esperar que nadie pregunte, y rezar para que ningún paciente decida ejercer derechos. La segunda es asumir desde el Día 1 que la fricción legal es parte del proyecto, planificarla en paralelo al ML, y dedicarle el tiempo que pide.
Nosotros vamos por la segunda, y lo recomendamos. No porque la primera no funcione muchas veces —funciona—, sino porque cuando deja de funcionar, ya es tarde para improvisar.
Y sobre el directorio fantasma: lo encontramos nosotros, sin que nadie nos vigilara. Esa es la diferencia entre cumplir y hacer las cosas bien.
Próximo capítulo
Con los datos limpios y el legal cubierto, empezamos a entrenar de verdad. Tres fases consecutivas sobre el modelo base, un primer salto significativo sobre la accuracy de partida en el benchmark dental, y la sensación —por primera vez en el sprint— de que el modelo empezaba a «hablar dental». El día que dejó de ser un VLM genérico.
Preguntas frecuentes
¿Anonimizar un DICOM lo saca del régimen del Art.9 del RGPD?
No, salvo que la anonimización sea irreversible en sentido estricto. Lo que en la práctica clínica se llama «anonimización» suele ser pseudonimización: existe una tabla de mapeo que permite re-identificar al paciente. Mientras esa reversibilidad sea posible, el dato sigue siendo dato de salud y se le aplica el régimen reforzado del Art.9.
¿Qué es un Certificate of Destruction y por qué importa?
Es un documento formal que acredita que un conjunto de datos ha sido destruido siguiendo un estándar reconocido (típicamente NIST SP 800-88 Rev.1 para destrucción digital), con método, fecha y responsable. Importa porque te permite responder con evidencia ante una auditoría, una solicitud de derechos del paciente o una inspección regulatoria. Sin certificado, tu palabra es la única prueba.
¿Por qué mandar dos mails simultáneos en lugar de uno y esperar?
Porque cuando una pregunta cruza dos vendors, el riesgo no es que te digan que no: es que cada uno te diga «eso lo lleva el otro» y pierdas semanas. Mandar a ambos a la vez fuerza que cada uno responda lo que sí gestiona, y deja claro desde el primer mail que no hay ambigüedad sobre quién es el interlocutor adecuado para cada parte de la cadena.
¿Por qué el «directorio fantasma» era un problema si el contenido ya estaba anonimizado?
Porque el strip de cabeceras DICOM elimina la PII del contenido del archivo, pero no toca la ruta donde el archivo se guarda. Si tu pipeline genera carpetas con apellidos o identificadores reales y luego renombra solo el contenido, los nombres de carpeta siguen siendo datos personales. En filesystem-scope, los paths son PII regulada exactamente igual que las cabeceras.
¿Por qué no se borró el directorio en cuanto se descubrió?
Porque borrarlo sin construir antes la cadena de custodia equivale a destruir evidencia. Si alguien pregunta dentro de dos años qué había exactamente ahí, qué pasos se siguieron y cuándo, la única respuesta defendible es una documentada con hashes y timestamps. La semana de trabajo previo al borrado es lo que separa «lo gestionamos» de «creemos que lo gestionamos».
¿Es viable procesar datos clínicos bajo RGPD Art.9 sobre cloud GPU?
Sí, siempre que el proveedor publique DPA con cláusulas estándar contractuales para datos de salud, opere en regiones europeas y exista un mecanismo formal de borrado documentado al final del procesamiento. La elección del sub-processor importa: hay clouds donde esta conversación es trivial y otros donde es imposible. Y para uso continuado, no para un sprint puntual, nuestra opinión es clara: on-premise sigue siendo el camino más limpio.
