Seudonimización de texto clínico antes de pasarlo por la IA

1. Qué es la seudonimización, en una frase

La seudonimización es el tratamiento por el cual los datos de un paciente ya no pueden atribuirse a esa persona sin usar información adicional, siempre que esa información adicional se guarde por separado y con medidas técnicas y organizativas que impidan volver a atribuir la identidad. Es la definición que da el artículo 4.5 del RGPD, y no es un capricho: es exactamente el mecanismo pensado para que un dato clínico pueda circular fuera del sistema del centro sin llevar el nombre pegado.

1.1. Un truco simple con un requisito duro

En la práctica, seudonimizar es cambiar «María González, 78 años, DNI 12345678A» por «paciente PA-8f3c2, 78 años» dentro del texto que sale del centro. El truco es simple; el requisito es duro: el diccionario que relaciona PA-8f3c2 con María González tiene que vivir dentro del centro y no salir con el texto. Sin ese diccionario, la seudonimización pierde su sentido y se convierte en una anonimización defectuosa.

1.2. Por qué se hace antes de mandar la nota al modelo

Un modelo de IA es un servicio externo casi siempre: aunque esté alojado en Europa, pertenece a otra organización y procesa el texto en máquinas que no son las del centro. Mandarle un dato clínico sin quitar antes lo que identifica al paciente es exponer información sensible a un tercero sin base jurídica suficiente, y sin control sobre lo que ese tercero hace con los tokens que recibe. La seudonimización es el filtro que baja el riesgo a algo manejable.

2. Por qué es obligatoria antes de la IA

No es una recomendación de buenas prácticas: es una condición que se aplica caso por caso según el proveedor del modelo, pero que, en el estado actual del sector, hay que dar por defecto en cualquier flujo que mande texto clínico fuera del sistema del centro.

2.1. Por el RGPD

El RGPD no prohíbe la IA, pero exige minimización de datos: no se envía más información personal de la que hace falta para el fin declarado. Un modelo que redacta un borrador de informe no necesita saber cómo se llama el paciente; necesita el motivo, la exploración y el diagnóstico. Enviar el nombre además es exceso de tratamiento, y ese exceso se sanciona.

2.2. Por el contrato con el proveedor del modelo

Los proveedores serios de modelos declaran que no reentrenan con las llamadas API, pero rara vez se comprometen a no registrarlas para depuración, para métricas de calidad o para responder a una petición legal. Cada dato identificable que sale del sistema del centro entra en ese registro de terceros, y el centro deja de tener control sobre él. Seudonimizar antes es lo que hace ese registro inofensivo.

2.3. Por decisión firme del ecosistema

La regla dentro de obeliOmed es explícita y aplica a todos los flujos de IA del producto: el texto clínico va seudonimizado antes de salir hacia el modelo, y si esa capa no está disponible, no se llama al modelo. Es más restrictiva que la norma —hay excepciones que el RGPD permitiría—, y la razón es sencilla: preferimos no sugerir a filtrar información que después no se puede recuperar.

3. Seudonimización no es anonimización

El diccionario que reidentifica se queda dentro del centro, con acceso propio.

Los dos términos suenan parecidos, y en la práctica clínica se usan como sinónimos casi a diario. No lo son. La confusión no es académica: cada uno abre y cierra puertas legales distintas.

3.1. La anonimización es irreversible

Un dato está anonimizado cuando ya no se puede reidentificar al paciente ni siquiera con toda la información adicional del centro. Un dataset anonimizado sale del ámbito del RGPD porque ya no es dato personal, y por eso las técnicas de anonimización son más agresivas: se agregan valores, se redondean fechas, se agrupan diagnósticos en categorías amplias. La contrapartida es que la utilidad clínica del dato baja mucho, y a veces se rompe.

3.2. La seudonimización es reversible pero controlada

Un dato seudonimizado sigue siendo dato personal a efectos del RGPD, pero su procesamiento tiene menos exposición: quien lo recibe fuera del centro no puede reidentificar al paciente por sí solo. El diccionario que reconstruye la identidad se guarda dentro del sistema del centro con controles de acceso, y esa asimetría es lo que hace posible que un modelo de IA proponga un borrador de informe que después el clínico completa con los datos identificativos del paciente correcto.

3.3. Cuál corresponde en cada caso

Para llamar a un modelo de IA que devuelve un texto que se va a asociar al mismo paciente después, seudonimización. Para publicar cifras agregadas en un informe estadístico, anonimización — que es un tema propio y se trata en la nota sobre datos clínicos para estadística. Para montar una demo, anonimización agresiva, sin excepción.

4. Qué se sustituye y qué se conserva

La seudonimización no es un borrado a ciegas de todo lo que suene a personal: es una sustitución selectiva que conserva lo clínicamente útil y sustituye lo que identifica.

4.1. Los identificadores directos

Nombre, apellidos, DNI, tarjeta sanitaria, número de historia, número de teléfono, dirección postal, correo electrónico, matrícula de vehículo si aparece. Todo eso se sustituye por un identificador opaco propio del sistema —«PA-8f3c2»— que no da pistas sobre la persona real. La sustitución es determinista dentro de la misma sesión: el mismo paciente recibe siempre el mismo identificador en el texto de esa llamada, para que el modelo entienda las referencias internas.

4.2. Los cuasi-identificadores

La fecha de nacimiento exacta, el código postal completo, el nombre del centro de trabajo, la profesión concreta si es rara. Combinados, permiten reidentificar aunque no salga el nombre. La convención razonable es dejar la edad en años y el código postal a tres dígitos, cambiar la fecha exacta por «hace X meses» cuando el contexto clínico lo permite, y mantener la profesión solo cuando aporta al motivo del texto.

4.3. Lo que se conserva íntegro

Los signos clínicos, los valores de las pruebas, la evolución, la medicación con sus dosis, los diagnósticos. Todo eso es lo que el modelo necesita para hacer su trabajo, y quitarlo no reduce el riesgo de identificación —no es identificativo por sí solo—; lo único que hace es dejar al modelo sin la información que se le está pidiendo procesar.

5. El vínculo, la pieza que decide todo

El diccionario que relaciona los identificadores opacos con los pacientes reales es la pieza crítica de la seudonimización. Si el vínculo se protege bien, la seudonimización funciona; si no, tenemos anonimización defectuosa.

5.1. Vive dentro del sistema del centro, siempre

El diccionario nunca sale del centro. No se manda al modelo, no se guarda en el proveedor de IA, no aparece en logs remotos. Su almacenamiento es interno al sistema clínico, con cifrado en reposo y con control de acceso a nivel de servicio: solo el servicio que sustituye los identificadores puede leerlo, no los usuarios finales.

5.2. Tiene su propio ciclo de vida

Un identificador opaco de una llamada puntual no tiene por qué vivir para siempre. Cuando la respuesta del modelo ya se ha incorporado al expediente correspondiente, el vínculo de esa sesión puede descartarse. Mantener un mapa histórico completo de todas las seudonimizaciones eleva el impacto de una brecha sin aportar valor operativo — y una brecha en ese mapa reidentifica meses de historial de IA de golpe.

5.3. Se audita como se auditan los accesos a la historia

Cada consulta al diccionario para reidentificar deja registro con quién, cuándo y por qué. Esa auditoría de acceso es lo que después permite responder a un derecho de acceso del paciente sobre qué ha pasado con sus datos en flujos de IA, sin depender de la memoria del equipo.

6. Qué exigen el RGPD y la AEPD

La normativa aplicable no es solo el Reglamento General de Protección de Datos: la AEPD ha publicado orientaciones específicas sobre IA aplicable a datos personales que precisan los requisitos.

6.1. Base jurídica del tratamiento

Antes de seudonimizar y mandar el texto al modelo, hay que tener claro qué base jurídica sostiene el tratamiento. En un centro sanitario suele apoyarse en el interés legítimo o en la ejecución de un contrato con el paciente, pero en cualquier caso el proceso debe estar recogido en el registro de actividades de tratamiento del centro. Un flujo de IA que no aparece ahí es un flujo sin cobertura documental.

6.2. Encargado de tratamiento

El proveedor del modelo actúa como encargado de tratamiento del centro y debe firmar un contrato en los términos del artículo 28 del RGPD: qué datos trata, para qué, con qué medidas de seguridad, qué pasa al terminar el contrato. Un modelo de IA usado sin contrato de encargado es un incumplimiento formal, aunque la información esté seudonimizada.

6.3. Evaluación de impacto

La AEPD ha señalado que los tratamientos que usan IA sobre datos de salud generalmente requieren evaluación de impacto en protección de datos previa. Es un documento formal del centro que analiza qué se va a tratar, qué riesgos hay y qué medidas se toman para reducirlos. Sin ese documento, la decisión de arrancar un flujo de IA sobre historia clínica es una decisión sin trazabilidad de responsabilidad.

7. Qué debe hacer tu software antes de llamar al modelo

La llamada al modelo no sale del cliente directo: pasa por una capa intermedia auditada.

La disciplina de la seudonimización no es un ejercicio manual del clínico: es una capa que el software del centro tiene que garantizar antes de que salga la primera petición. Tres criterios verificables.

7.1. Interceptar el texto antes del envío

La llamada al modelo no se hace directamente desde el cliente que redacta la nota: pasa por un servicio interno que sustituye los identificadores por marcadores opacos y solo entonces la envía. Un sistema que hace la llamada directa desde el navegador o desde la aplicación del clínico, sin capa intermedia, no puede garantizar la seudonimización porque depende del comportamiento del usuario final.

7.2. Reidentificar la respuesta con el vínculo correcto

Cuando el modelo devuelve el borrador con los marcadores opacos —«PA-8f3c2 acude por…»— el sistema los sustituye por los datos reales del paciente correspondiente antes de mostrar la respuesta al clínico. La sustitución usa el vínculo de esa sesión, no un mapa global. Un fallo aquí es peor que un fallo al ocultar: mezclaría datos de un paciente en la respuesta de otro.

7.3. Registrar la llamada como acceso al dato del paciente

Cada llamada al modelo con texto de un paciente cuenta como un tratamiento de sus datos, y queda registrado en el mismo log de accesos que la lectura de la historia. Así, si más adelante el paciente ejerce el derecho de acceso sobre lo que se ha hecho con sus datos, la información existe y se puede entregar.

Y un cuarto criterio, más de arquitectura que técnico. Si la capa de seudonimización no está activa por cualquier motivo —fallo del servicio, actualización, mantenimiento—, la llamada al modelo debe cancelarse, no continuar sin seudonimizar. Es la regla firme del producto y evita justamente los incidentes que este documento existe para prevenir.

8. Errores frecuentes al seudonimizar

• Sustituir solo el nombre y dejar el DNI. Un DNI en el texto reidentifica al paciente en un cruce trivial.
• Cambiar el nombre por otro nombre real. «Juan Pérez» por «María González» produce texto que confunde al modelo y filtra un patrón que después nadie recuerda.
• Enviar los adjuntos originales —el PDF de la analítica, la imagen escaneada del informe— cuando el modelo solo pedía el texto. Los adjuntos suelen llevar cabecera con nombre y número de historia.
• Guardar el diccionario en el mismo sitio donde vive el texto seudonimizado, sin cifrado adicional. Una brecha del almacén revela todo el vínculo de golpe.

8.1. El error que más caro sale: la excepción «solo por esta vez»

Un clínico con prisa pide al sistema mandar el texto tal cual, sin seudonimizar, «solo por esta vez» porque la capa está lenta. Cuando ese atajo existe, en pocos meses se usa a diario y la disciplina se ha perdido. La regla del producto —si la capa no está, no se llama— es antipática pero es la única que sostiene la política a largo plazo. Un incidente aislado explicable pesa menos que un patrón de excepciones documentado en auditoría.

8.2. Confundir cifrado con seudonimización

Cifrar el texto antes de mandarlo al modelo no equivale a seudonimizar: el modelo necesita el texto en claro para procesarlo, así que en algún punto se descifra y ahí aparecen los datos identificativos si no se han sustituido antes. Cifrado y seudonimización son dos capas complementarias y ninguna sustituye a la otra: cifrado protege el transporte y el almacenamiento; seudonimización protege el contenido cuando otro lo procesa.

8.3. Seudonimizar el texto y no seudonimizar el asunto o el metadato

El texto del cuerpo de la petición se seudonimiza y el asunto de la petición lleva «Informe de María González – 2026-08-28» a la vista. El metadato es más pequeño pero identifica igual, y muchas capas de logs y monitorización solo guardan el asunto, no el cuerpo. La seudonimización tiene que ser consistente en todos los campos que salen del sistema.

9. Qué aporta obeliOmed con esto

9.1. La capa está siempre delante del modelo

obeliOmed no permite que una llamada de IA sobre texto clínico salte la capa de seudonimización. Cuando el clínico pide un borrador de informe con ayuda del modelo, el texto del paciente pasa primero por el servicio que sustituye los identificadores, y solo entonces se envía. La respuesta del modelo se reidentifica dentro del sistema antes de mostrarse. Si la capa no está disponible por cualquier motivo, la llamada no se hace — es la regla firme del producto.

9.2. La IA propone, la persona confirma

El borrador que devuelve el modelo nunca se guarda directamente en la historia clínica: aparece como propuesta para que el profesional lo revise, lo corrija y lo apruebe. Ese confirmación humana está en el mismo circuito que la firma electrónica del clínico, y sin ella el borrador no cuenta como acto asistencial. Ningún documento clínico, fiscal ni legal se crea o modifica sin esa confirmación.

9.3. Lo que no hace, dicho antes de que lo preguntes

obeliOmed no reentrena modelos con los datos del centro, no comparte los datos seudonimizados con terceros distintos del proveedor del modelo declarado, y no guarda historial de las respuestas del modelo fuera del expediente correspondiente. La documentación completa del flujo —qué proveedor, qué modelo, qué campos se envían, qué contrato de encargado— está disponible para el centro sin necesidad de pedirla como favor.