Anonimizar una demo con datos de verdad: qué borrar y qué se rompe si borras mal

1. Por qué las demos son un caso especial

Un entorno de demo es un sistema en el que se muestra cómo funciona el software a alguien que aún no lo usa: un cliente potencial, un formador nuevo, un desarrollador que se incorpora al equipo. La demo suele necesitar datos parecidos a los reales para que las funciones se vean con sentido: una agenda vacía no muestra nada.

1.1. La tentación de la copia de producción

La vía fácil es tomar una copia de la base de datos de producción, cambiar el nombre de los pacientes y presentarla como «demo anonimizada». Es la vía que ha producido casi todos los incidentes documentados en el sector. La copia arrastra fechas exactas, códigos postales completos, patrones únicos de visitas, y —muy frecuentemente— adjuntos originales con la cabecera identificativa dentro.

1.2. La demo se enseña a gente que no está sometida a secreto

El detalle que agrava el problema: los espectadores de una demo no son necesariamente profesionales sanitarios sujetos a secreto. Un cliente potencial, un becario, un asistente comercial ven la pantalla y pueden identificar por casualidad a un paciente conocido. Basta con que uno de esos casos ocurra para tener incidente.

1.3. La demo es también un banco para pruebas de desarrollo

El entorno de demo suele usarse también para probar cambios de software antes de subirlos a producción. Cada prueba manipula datos, dispara envíos, genera facturas de mentira. Cuando los datos son reales aunque «anonimizados», cada prueba mueve información personal en flujos internos de desarrollo, sin la disciplina de la producción. Es exactamente el contexto donde una fuga es más difícil de detectar.

2. Las dos vías: copia reducida vs pacientes falsos

Hay dos maneras de preparar los datos de una demo. Una es tomar producción y limpiarla; la otra es generar pacientes falsos desde cero. Salvo excepciones muy contadas, la segunda es la única defendible.

2.1. Copia reducida y anonimizada

Se toma un subconjunto de la base de datos real, se aplican técnicas de anonimización —cambio de identificadores, agregación de cuasi-identificadores— y se usa como demo. La ventaja aparente es que el sistema muestra su funcionamiento con datos realistas. La desventaja es que la anonimización defectuosa deja rastros, y en un entorno de demo los rastros se ven en pantalla.

2.2. Pacientes falsos generados desde cero

Se generan pacientes ficticios con nombres inventados, datos coherentes pero fabricados, historias clínicas escritas a propósito. El coste inicial es mayor —hay que crear el contenido, no basta con reciclar— pero el sistema queda limpio de riesgo. Si el generador es bueno, los pacientes falsos son indistinguibles de reales en la demo y no llevan ningún vínculo con personas.

2.3. Cuál corresponde

Para demos comerciales, formación de personal externo, pruebas de desarrollo con espectadores no sanitarios: pacientes falsos, siempre. La copia reducida solo puede considerarse en pruebas internas muy acotadas de equipo sanitario propio, con acceso controlado y borrado tras la prueba, y siempre con la conciencia de que sigue siendo tratamiento de datos personales bajo el RGPD.

3. Copia reducida: por qué casi nunca funciona

El cambio del nombre no borra la cabecera del PDF, ni el codigo postal, ni la fecha exacta.

Si aun así se opta por copia reducida, merece la pena enumerar por qué la mayoría de intentos fallan. La lista no es exhaustiva pero cubre los patrones más habituales.

3.1. Los cuasi-identificadores permanecen

Se cambia el nombre pero se dejan la fecha exacta de nacimiento, el código postal completo y el sexo. La misma trampa que en datos para estadística: con esas tres columnas se reidentifica a la mayoría de los pacientes en un cruce con fuentes públicas. La demo enseña a un espectador que lo primero que hace al ver la pantalla es reconocer a alguien de su vecindario.

3.2. Los adjuntos originales aparecen

La base de datos se anonimizó, pero los archivos que cuelgan de cada paciente —el PDF del informe externo, la imagen escaneada, el archivo DICOM— tienen sus propias cabeceras con nombres reales dentro. La demo abre el visor de documentos y ahí está el nombre original tal cual. Es el fallo más frecuente porque la anonimización se piensa a nivel de campos de la base, no a nivel de contenidos de fichero.

3.3. Los eventos únicos se ven a la legua

Hay pacientes que tuvieron eventos únicos —una complicación rara, una hospitalización coincidiendo con una noticia, un tratamiento excepcional—. En una demo, esos eventos siguen ahí y quien los conozca los identifica sin más. La anonimización sistemática no puede tocarlos sin destruir el dataset.

3.4. Las relaciones entre pacientes se preservan

La copia reducida mantiene la estructura relacional: si dos pacientes están registrados como familiares, esa relación sigue en la copia. Un espectador que reconoce a uno puede deducir al otro por proximidad. Los apellidos compartidos, las direcciones cercanas, las citas en el mismo día son pistas que la anonimización a nivel de columna no elimina.

4. Pacientes falsos: cómo se genera un dataset útil

Un dataset de pacientes falsos bien construido es indistinguible de uno real en la superficie y no lleva ningún vínculo con personas. La generación tiene su propia disciplina.

4.1. Nombres verosímiles pero inventados

Los nombres se generan a partir de listas públicas de nombres y apellidos comunes, combinados aleatoriamente. Un generador serio evita combinaciones que casualmente coincidan con personas reales conocidas —futbolistas, políticos, actores—, y evita también apellidos raros que podrían identificar a familias concretas. La lista de nombres se documenta y se revisa periódicamente.

4.2. Datos demográficos consistentes

Edad, sexo, código postal, profesión coherentes entre sí —una jubilada con 87 años, no de 25—; distribuciones que representen la mezcla real de pacientes del centro sin sesgar hacia demografías concretas. Un dataset con 100 pacientes falsos debería reproducir aproximadamente la pirámide de edad y el reparto por especialidad del centro real, para que la demo se parezca al uso cotidiano.

4.3. Historia clínica creíble

La parte más costosa. No basta con generar diagnósticos al azar: la evolución tiene que tener sentido clínico. Un paciente con diabetes debería tener las revisiones esperadas para diabetes; una cirugía debería llevar consentimiento e informe de alta. La biblioteca de casos clínicos ficticios —escritos por profesional sanitario del propio centro, con revisión— es lo que permite que la demo se vea profesional.

4.4. Refresco periódico y firmas de reconocimiento

Los pacientes falsos deberían llevar alguna marca que permita identificarlos como tal —por ejemplo, todos los DNI generados empiezan por un patrón reservado, o los nombres siguen una convención—. La marca no impide la demo pero sí facilita cualquier auditoría posterior que verifique que en el entorno de demo no ha entrado nunca un paciente real.

5. Qué se rompe cuando borras mal

El error simétrico al de dejar información identificable es borrar tanto que la demo deja de servir. Merece la pena enumerar qué se rompe según qué se borra.

5.1. Si borras las fechas exactas

Los recordatorios de cita, los cálculos de plazos —diez días de recuperación, revisión al mes— dejan de funcionar. La demo no puede enseñar la funcionalidad de recordatorios porque no hay cita futura concreta. La agregación por semana es un compromiso: se mantiene la utilidad para recordatorios generales y se pierde la granularidad diaria.

5.2. Si borras las relaciones entre pacientes

La demo no puede enseñar el flujo del tutor legal de un menor, ni el familiar de un paciente incapacitado. Cuando la funcionalidad depende de las relaciones —consentimientos firmados por tutor, comunicación con familiar— hay que generar relaciones ficticias, no borrar las existentes.

5.3. Si borras los eventos únicos

La demo se queda solo con casos rutinarios y pierde la ilustración de escenarios complejos. Si la demo quiere enseñar «cómo se gestiona una queja rara», hace falta al menos un paciente con esa queja —falso, con perfil coherente— para que la funcionalidad se vea.

5.4. Si borras los adjuntos

La demo pierde la parte más visible del sistema: cómo se abren informes, cómo se ven imágenes, cómo se descargan documentos. Los adjuntos se sustituyen por versiones falsas —un PDF genérico con datos del paciente falso, una imagen tomada con permiso de una base pública— para mantener la utilidad sin arrastrar contenidos reales.

6. La demo no es una excepción del RGPD

Un error frecuente es pensar que las demos internas del centro caen fuera del RGPD porque «no son producción». No es cierto.

6.1. Tratamiento de datos personales

Preparar una copia reducida de producción, aunque se llame «demo», es un tratamiento de datos personales. Requiere base jurídica declarada, medidas de seguridad, plazo de conservación en el entorno de demo y protocolo de borrado tras la demo. La documentación del centro debería recoger este flujo en el registro de actividades de tratamiento como uno más.

6.2. Comunicación a terceros

Una demo a un cliente potencial es una comunicación de datos a un tercero. Si los datos son reales anonimizados a medias, la comunicación es de datos personales sin base jurídica —el cliente potencial no es encargado del centro ni tiene consentimiento del paciente para verlos—. La sanción por comunicación no amparada aplica igual que en cualquier otro caso, y la agravante de que fue en contexto comercial no ayuda.

6.3. Brecha de seguridad

Un incidente en el entorno de demo cuenta como brecha de seguridad si hay datos personales dentro, y activa la obligación de notificar a la AEPD en 72 horas cuando el riesgo para los derechos del paciente es probable. El protocolo de brecha aplica igual, sin descuento por «era solo la demo».

7. Qué debe hacer tu software con los entornos de demo

El entorno de demo lleva marca visible en cada pantalla para no confundirlo con produccion.

La disciplina no puede descansar solo en la buena voluntad. El software del centro tiene que sostener parte del trabajo.

7.1. Marca visible del entorno de demo

El entorno de demo se distingue del de producción con una marca visual clara en cada pantalla —banner de color, indicador en cabecera—. Es lo que impide el error clásico de confundir uno con otro: el usuario se conecta creyendo que está en demo, deja pruebas hechas, y descubre después que estaba en producción. La marca no es adorno: es una barrera de seguridad.

7.2. Aislamiento de datos entre entornos

La base de datos de demo y la de producción son independientes, con credenciales y almacenamiento propios. No hay migración manual de una a otra: el proceso de refrescar la demo, si se hace, pasa por una capa de generación/anonimización auditada, no por una copia directa.

7.3. Generador de pacientes falsos integrado

El sistema ofrece una herramienta para poblar el entorno de demo con pacientes ficticios generados a partir de plantillas, sin necesidad de tocar producción. La herramienta genera nombres, historias y adjuntos coherentes y marca cada registro con la firma que permite identificarlo como falso en cualquier auditoría posterior.

Y un cuarto criterio, más operativo. Antes de cada demo comercial, alguien del centro verifica visualmente que el entorno no contiene pacientes reales por descuido, y firma que la revisión se hizo. Es un paso de un minuto que evita el incidente más frecuente.

8. Errores frecuentes al preparar demos

• Copia de producción «cambiando el nombre». Los cuasi-identificadores reidentifican.
• Adjuntos originales con cabecera identificativa dentro, aunque la base esté limpia.
• Confundir entorno de demo con producción, dejando pruebas que después aparecen en la historia real.
• Reusar la misma demo entre clientes sin refrescar, arrastrando cambios que el anterior hizo y que el siguiente ve.

8.1. El error que más caro sale: la demo comercial con paciente reconocido

El comercial del centro enseña la demo al director de una clínica potencial cliente. En un paciente ejemplo, el nombre está cambiado pero el código postal y la edad coinciden con un paciente que el director conoce personalmente. La demo se convierte en un momento incómodo, y en incidente RGPD si el director decide reclamarlo. La consecuencia no depende de la mala fe de nadie: es la anonimización defectuosa la que falla. El caso repetido lleva a la única política que funciona: nunca copia de producción en demos comerciales.

8.2. Ejecutar pruebas contra la demo con datos que no lo son

Un desarrollador prueba una función nueva en el entorno de demo y, para comprobar un caso, importa un fichero real con datos de un paciente conocido. La demo queda contaminada con datos reales sin que el resto del equipo lo sepa, y esos datos aparecen en la siguiente demo comercial. La disciplina razonable es prohibir la importación de datos externos al entorno de demo sin pasar por el generador de datos falsos.

8.3. Compartir credenciales de la demo con proveedores externos

Se comparten credenciales del entorno de demo con un proveedor de formación o de integración para que pueda ver el sistema. Si en esa demo hay algún dato real —por el error anterior o por descuido— la comunicación pasa a ser sin contrato de encargado. El proveedor debería tener sus propios pacientes falsos en un entorno propio, no acceder al del centro.

9. Qué aporta obeliOmed con esto

9.1. Los entornos de demo salen con pacientes falsos por defecto

obeliOmed proporciona a cada nuevo centro un entorno de demo poblado con pacientes ficticios generados desde plantillas: nombres inventados, historia clínica coherente, adjuntos ficticios, agenda con citas de ejemplo. La demo se refresca cuando el centro lo pide y siempre desde generador; no hay ninguna operación soportada que copie datos de producción a la demo del centro.

9.2. La demo lleva marca visible y no es exportable

El entorno de demo se distingue del de producción por una marca en cada pantalla, y los datos de la demo no pueden exportarse como si fueran de producción —el sistema los marca en las cabeceras y en los informes como «entorno de pruebas» para que nadie los confunda—. Cualquier flujo que intente sacar un dato de la demo lleva ese marcador.

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

obeliOmed no puede impedir que el propio centro cree un entorno de demo manualmente con una copia parcial de su producción si decide hacerlo por su cuenta: el sistema desaconseja la práctica y no la ofrece como funcionalidad, pero un administrador determinado puede montarla con acceso a su base de datos. Lo que sí hace es no proporcionar ninguna herramienta que facilite ese atajo, y en la formación del cliente se explica por qué no se debe.