Anonimización de datos personales según el RGPD: requisitos, técnicas y ejemplos

¿Qué es la anonimización RGPD?

La anonimización RGPD consiste en transformar datos personales de modo que las personas dejen de ser identificables, teniendo en cuenta los medios que razonablemente podrían utilizarse para identificarlas. El considerando 26 distingue este resultado de la mera ocultación de identificadores evidentes. La información verdaderamente anónima queda fuera del RGPD; sustituir solo los nombres no basta para demostrar que se ha alcanzado ese umbral. [1]

La anonimización describe un resultado, no una función concreta del software. Para un equipo que prepara documentos para otro público, la tarea consiste en conservar la información útil y, a la vez, evaluar si los detalles restantes siguen señalando a una persona.

Esa distinción importa en el trabajo cotidiano. Un proveedor de pagos puede necesitar un número de cuenta para resolver una transacción. Una compañera que prepara una guía general de resolución de incidencias probablemente no lo necesita. El mismo documento de origen puede requerir un tratamiento distinto para esos dos fines.

¿Qué exige el RGPD antes de compartir o reutilizar datos?

El artículo 5, apartado 1, letra c), establece la minimización de datos: los datos personales deben limitarse a lo que exige la finalidad del tratamiento. El artículo 25 conecta ese principio con la forma en que se diseñan los sistemas y los flujos de trabajo. La anonimización puede respaldar esos objetivos, pero el RGPD no exige que toda organización anonimice todos sus registros. [1][2][3]

En un flujo de trabajo documental, empiece por nombrar la finalidad y el destinatario. Escribir «preparar un ejemplo de resolución de incidencias para el soporte del proveedor» es más útil que escribir «usar estos datos internamente». Permite a quien revisa decidir si el nombre de un cliente, una marca de tiempo precisa o una referencia de transacción aportan algo a la tarea.

El propio acto de anonimizar datos personales es un tratamiento, de modo que las obligaciones se aplican mientras maneja la información original. Sigue necesitando una base jurídica adecuada y las salvaguardas correspondientes. Un resultado anónimo no convierte retroactivamente en lícita una recogida que no lo era. [1]

Trate la fuente y la copia propuesta para compartir por separado. Redactar un extracto no elimina los identificadores del ticket original, de los archivos adjuntos ni de exportaciones anteriores. Sus disposiciones de conservación y acceso también deben cubrir esos registros. [2]

Anonimización, seudonimización y enmascaramiento: las diferencias

La anonimización busca eliminar la identificabilidad. La seudonimización reduce el vínculo con una persona, mientras que información adicional puede restablecer ese vínculo; es una salvaguarda, no el mismo resultado. El Comité Europeo de Protección de Datos (CEPD) explica esta distinción porque los términos tienen implicaciones distintas para la protección de datos. [4]

Por ejemplo, sustituir los nombres de empleados por códigos y mantener una tabla de correspondencia aparte es un flujo de seudonimización. Puede permitir análisis útiles sin mostrar los nombres a cada analista. Mientras los registros sigan siendo atribuibles mediante información adicional, siguen siendo datos personales. [4]

El enmascaramiento y la redacción describen operaciones. El enmascaramiento puede ocultar parte de un número de cuenta mostrado; la redacción puede eliminar un nombre o sustituirlo por un marcador. Ninguno de los dos términos indica por sí solo si una persona sigue siendo identificable. Una pregunta útil de revisión es: ¿qué podría deducir alguien a partir del resultado y de la demás información de que dispone? [5]

No base una decisión de anonimato únicamente en eliminar una tabla de correspondencia. El registro original o detalles distintivos del texto pueden seguir ofreciendo una vía de vuelta hasta una persona. Evalúe el resultado en su contexto, incluida la información disponible para el público destinatario. [5]

Dato personal relativo: qué aclara la sentencia del Tribunal de Justicia de 2025

El 4 de septiembre de 2025, en el asunto C-413/23 P, el Tribunal de Justicia de la UE declaró que los datos seudonimizados no son automáticamente datos personales para todo destinatario. Si un destinatario no puede revertir la seudonimización y esta impide efectivamente la atribución, los datos no son personales desde su punto de vista. Para el responsable, que dispone de la correspondencia, siguen siéndolo. [9]

El asunto se refería al reglamento 2018/1725 aplicable a las instituciones de la UE; la doctrina extrae de él criterios también para el RGPD. En la práctica, que una copia compartida sea anónima para el destinatario depende de los medios de identificación de que disponga razonablemente, incluido el contexto del propio texto. El Tribunal aclaró además que los destinatarios deben indicarse ya en el momento de la recogida, aunque el vínculo personal se elimine antes de la transmisión. [9]

Técnicas habituales de anonimización y sus límites

La supresión elimina información, como un campo de contacto o una frase innecesaria. La generalización reduce la precisión, por ejemplo sustituyendo una ubicación detallada por un área más amplia. Ambas requieren decidir cuánto detalle necesita la tarea. La CNIL recomienda tener en cuenta la información útil, los valores poco frecuentes y el nivel de detalle adecuado al diseñar un proceso de anonimización. [3]

Para conjuntos de datos estructurados existen técnicas formales. La AEPD dedica una nota técnica a la k-anonimidad: un individuo es k-anónimo si, para cualquier combinación de sus atributos cuasi-identificadores, existen al menos otros k-1 individuos con los mismos valores. La privacidad diferencial y los datos sintéticos persiguen objetivos parecidos. Sirven sobre todo para bases de datos y estadísticas, menos para textos libres como correos o tickets. [8]

La agregación presenta información sobre grupos en lugar de registros individuales. La aleatorización modifica valores, a menudo para conservar patrones estadísticos útiles reduciendo la divulgación. Estos métodos exigen un diseño cuidadoso: un grupo pequeño o una combinación inusual de atributos puede seguir revelando información sobre una persona concreta. El glosario de la ICO explica estos enfoques en el contexto del RGPD del Reino Unido. [6]

En un extracto de soporte al cliente, eliminar los datos de contacto puede conservar toda la historia de la incidencia. En un informe de plantilla, un recuento por departamento puede ser más útil que relatos individuales de cada empleado. En un conjunto de datos de investigación pública, pueden hacer falta métodos estadísticos especializados y una evaluación de divulgación aparte.

Elija la técnica en función del uso previsto. Un método adecuado para un panel de control no sirve automáticamente para texto libre. Agregar quejas puede mostrar la frecuencia de un error, pero no puede conservar la formulación exacta que un ingeniero necesita para entender un mensaje de error ambiguo.

DataAnonymiser se centra en detectar detalles identificativos y sustituirlos por marcadores en el texto. No convierte automáticamente los documentos en agregados estadísticos ni aplica todas las técnicas descritas aquí. Generalizar un relato o producir un resumen a nivel de grupo es un paso editorial o analítico distinto.

Ejemplo 1: redactar un ticket de soporte antes de escalarlo a un proveedor

Los siguientes ejemplos son ficticios e ilustrativos, no resultados medidos del producto ni prueba de anonimato legal. Cada uno parte de una tarea útil y examina después la información que esa tarea no necesita.

Original: «Por favor, contacte con Alex Morgan en alex.morgan@example.com. El pago falló dos veces después de actualizar mis datos de facturación».

Versión redactada ilustrativa: «Por favor, contacte con [full_name] en [email]. El pago falló dos veces después de actualizar mis datos de facturación».

Un ingeniero que investigue la secuencia puede seguir entendiendo el síntoma. Los datos de contacto del cliente no aportan nada a esa investigación. La persona que analiza el caso también puede eliminar toda la frase de contacto de la copia para compartir si el proveedor no necesita responder al cliente.

Antes de reenviarlo, revise el ticket completo. Un asunto, una respuesta citada, una captura de pantalla o una referencia de transacción pueden contener información que el extracto ya no muestra. Si el proveedor necesita una referencia para localizar la transacción, reconozca esa necesidad y utilice el proceso aprobado para compartir datos personales, en lugar de describir el paquete como anónimo.

Ejemplo 2: preparar un escenario de RR. HH. sin identificar a una empleada

Original: «Maya, la única supervisora del turno de noche en nuestra sucursal del puerto, pidió un cambio de horario al volver de su permiso parental».

Al eliminar el nombre queda: «[first_name], la única supervisora del turno de noche en nuestra sucursal del puerto, pidió un cambio de horario al volver de su permiso parental».

Una compañera familiarizada con esa sucursal puede seguir sabiendo exactamente a quién se refiere la frase. La palabra «única» señala un puesto distintivo; la ubicación y el suceso reciente añaden contexto. Por eso revisar un documento significa leer la historia, no solo comprobar que todos los nombres han desaparecido.

Para un ejercicio de formación de mandos, una persona editora podría escribir en su lugar: «Un empleado pidió un cambio de horario tras un periodo de permiso». Esa versión elimina varios detalles y conserva el debate sobre cómo gestionar la solicitud. Es una reescritura manual independiente, no una afirmación de que la aplicación generaliza el escenario automáticamente.

La persona responsable de la formación debe decidir si las circunstancias restantes resultan distintivas para el público. Cuando el incidente real ya es ampliamente conocido, construir un escenario totalmente ficticio puede servir mejor al objetivo formativo que adaptar el caso real.

Ejemplo 3: reducir los datos personales en un prompt de IA

Original: «Redacta una respuesta a Sam Rivera en sam.rivera@example.com sobre una factura duplicada. Sam es nuestro primer cliente en el proyecto piloto de la isla, anunciado ayer en la nota de prensa».

Sustituir el nombre y el correo elimina los datos de contacto directos. Queda, sin embargo, una descripción que podría vincular al cliente con un anuncio público. Si la tarea consiste simplemente en redactar una respuesta educada sobre la factura, ese contexto es innecesario.

Un prompt preparado por una persona podría decir: «Redacta una respuesta educada a un cliente que recibió una factura duplicada. Explica que estamos revisando los registros de facturación y que le contactaremos de nuevo». Las instrucciones útiles se mantienen y se omite la historia distintiva del cliente.

Revise el prompt completo, incluidos los ejemplos y el texto de conversaciones anteriores. Use el servicio de IA aprobado para la información que permanece. La redacción no es un permiso automático para divulgar un documento, y el lugar de procesamiento de la herramienta de redacción no determina lo que ocurre después de pegar su salida en otro servicio.

Cómo evaluar el riesgo de reidentificación

La CNIL describe tres comprobaciones importantes: si una persona puede singularizarse, si los registros pueden vincularse y si puede inferirse información sobre alguien. Ofrecen a quien revisa una forma de mirar más allá de los nombres y correos evidentes. [3]

Convierta esas comprobaciones en preguntas sobre su propio documento. ¿Describe el texto un puesto único? ¿Podría coincidir una fecha de un suceso con un anuncio público? ¿Hace un grupo reducido una afirmación reveladora sobre un miembro no identificado? Los ejemplos anteriores muestran cómo una frase corriente puede portar más información identificativa de la que su autora pretendía.

Considere tanto la información como las personas que puedan acceder a ella. La guía de la ICO del Reino Unido recomienda evaluar métodos de identificación realistas y distingue la difusión controlada de la publicación abierta. Su guía está actualmente en revisión tras cambios legislativos en el Reino Unido, así que utilícela como contexto práctico específico del Reino Unido junto con las fuentes de la UE aplicables. [5]

Un informe de riesgo del software puede señalar identificadores detectados o una detección incompleta. No puede determinar todo lo que ya sabe un destinatario. Utilícelo para orientar la revisión, registre después los supuestos que sustentan la decisión de compartir y revíselos cuando cambien el público o la información disponible.

Un flujo de trabajo práctico para la minimización de datos del RGPD

1. Defina la tarea. Anote por qué se necesita la información, quién la recibirá y si bastaría un extracto más corto o un ejemplo ficticio. Decida qué partes deben seguir siendo exactas para que la tarea tenga éxito.

2. Identifique el detalle innecesario. Revise los identificadores directos y el contexto distintivo. Compruebe el material que va a compartir, incluidas las conversaciones citadas y los adjuntos, en lugar de asumir que el párrafo principal representa todo el paquete.

3. Redacte y revise. Pase el texto relevante por DataAnonymiser, revise las sustituciones y atienda las advertencias de riesgo residual. Si su plan lo permite, añada términos personalizados para nombres sensibles o referencias internas propias del trabajo.

4. Revise la historia restante. Decida si hace falta eliminar o generalizar manualmente algo más. Pida a alguien familiarizado con el contexto del negocio que cuestione la copia propuesta para compartir, sobre todo en asuntos de empleados, salud o clientes.

5. Registre y controle la entrega. Documente la finalidad, el destinatario, el resultado de la revisión y las dudas sin resolver en el proceso aprobado por su organización. No reproduzca en ese registro detalles personales innecesarios. Si la anonimidad es dudosa, trate el resultado como datos personales y obtenga la revisión adecuada antes de compartirlo.

Dónde encaja DataAnonymiser: procesamiento bajo su control

DataAnonymiser ofrece un paso repetible entre el material de origen y su siguiente uso. Detecta detalles identificativos, los sustituye por marcadores y presenta el resultado con información de revisión. El objetivo es conservar texto útil reduciendo la exposición innecesaria.

En la edición Individual, el contenido se procesa en el dispositivo. Enterprise utiliza un servidor que su organización instala y opera dentro de su propia red, activado mediante una configuración explícita del administrador. Ninguna de las dos ediciones envía el contenido de los documentos a infraestructura operada por DataAnonymiser para su procesamiento.

Eso le da a su equipo el control sobre dónde ocurre el paso de redacción. No elimina la necesidad de revisar el resultado ni de evaluar el siguiente destino. La persona que copia un resultado en una herramienta externa toma una decisión de compartición independiente.

Empiece con un flujo de trabajo recurrente, como las escaladas a proveedores o el material de formación interno. Acuerde qué información es necesaria, asigne la responsabilidad de la revisión y pruebe ejemplos ficticios representativos antes de introducir documentos reales. Hable con nosotros sobre un despliegue Enterprise adaptado a la infraestructura y al proceso de revisión de su organización.