RGPD y protección de datos en la IA
Anonimización vs. seudonimización: guía RGPD
Actualizado
Sustituir un nombre es útil, pero rara vez convierte un prompt en anónimo. Esta guía ayuda a elegir la protección adecuada y a describirla correctamente.
La anonimización y la seudonimización reducen riesgos de privacidad, pero tienen consecuencias jurídicas diferentes. Esto importa cuando los empleados copian correos de clientes, casos de RR. HH., contratos o tickets de soporte en una IA generativa: ocultar identificadores evidentes puede hacer que el texto sea más seguro sin dejar necesariamente de estar sujeto al RGPD.
La respuesta breve: la información anónima no se refiere a una persona identificada o identificable y queda fuera del RGPD. Los datos seudonimizados no pueden atribuirse a una persona sin información adicional guardada por separado y protegida, pero por regla general siguen siendo datos personales para el responsable que puede restablecer la conexión. Por tanto, la seudonimización es una garantía, no una forma de eludir las obligaciones del RGPD.
Comparación conceptual — finalidad: la anonimización pretende impedir la identificación para las partes relevantes; la seudonimización pretende impedir la atribución dentro de un ámbito definido salvo que se use información adicional autorizada. Reversibilidad: una anonimización real debe resistir los medios que razonablemente puedan utilizarse; la seudonimización puede conservar deliberadamente una vía controlada para volver a la persona. Situación jurídica: la información anónima queda fuera del RGPD; los datos personales seudonimizados siguen sujetos a base jurídica, transparencia, minimización, conservación, seguridad y derechos cuando la persona continúa siendo identificable.
Un ejemplo de prompt muestra la diferencia. “Resume la reclamación de María López sobre su enfermedad rara en la única clínica del pueblo” contiene claramente datos personales. Cambiar el nombre por “[CLIENTE_01]” es seudonimización si el CRM o un compañero permiten reconectar el token. Incluso sin tabla de equivalencias, la enfermedad, la clínica y las circunstancias detalladas pueden singularizar a María. Una versión más segura elimina detalles innecesarios, generaliza el lugar y la enfermedad y pide solo el análisis imprescindible, pero determinar si el resultado es anónimo sigue exigiendo una evaluación contextual.
Lo mismo ocurre con los documentos. Una hoja de RR. HH. donde “Ana García” pasa a ser “EMP-4827” sigue seudonimizada si RR. HH. conserva la equivalencia. Un contrato con los nombres ocultos puede identificar a una parte mediante una dirección, número de expediente, firma, metadatos o una secuencia singular de hechos. Un ticket de soporte puede seguir conteniendo datos personales por un email citado en un adjunto o por la combinación de fechas, detalles del producto y ubicación.
Las Directrices 02/2026 del EDPB proponen un test práctico con tres criterios: No Record Isolation, No Linkage y No Inference —sin aislamiento de registros, sin vinculación y sin inferencia—. A 23 de agosto de 2026, habían sido adoptadas para consulta pública, abierta hasta el 30 de octubre de 2026; no eran directrices finales. Ofrecen un marco actual útil, pero las organizaciones deben seguir el texto definitivo y la jurisprudencia aplicable.
“Sin aislamiento” pregunta si una combinación única de atributos permite aislar el registro de una persona: el riesgo práctico de singularización. “Sin vinculación” pregunta si los registros pueden conectarse con otros datos de la misma persona, incluidas fuentes públicas o internas. “Sin inferencia” pregunta si es posible deducir información específica y significativa sobre una persona identificable. Superar los tres criterios respalda la conclusión de anonimato; incumplir uno exige seguir analizando y no determina automáticamente el resultado.
El contexto es decisivo. El borrador del EDPB de 2026 refleja jurisprudencia reciente de la UE y evalúa los medios que razonablemente podrían usarse desde la perspectiva de cada entidad relevante. Un conjunto puede ser anónimo para un destinatario independiente que no puede obtener legal ni materialmente la clave, pero seguir siendo dato personal para la organización que conserva el original. Si un proveedor trata el material siguiendo instrucciones del responsable, sigue importando la perspectiva del responsable: externalizar no evita el RGPD.
La anonimización también tiene límites. El texto libre tiene muchas dimensiones y puede contener hechos raros, estilo de escritura, cronología e identificadores ocultos. Aplicar un hash a identificadores previsibles sin un secreto fuerte puede permitir ataques por diccionario. Los resultados sintéticos o agregados pueden filtrar pertenencia o permitir inferencias. Las técnicas de reidentificación y las fuentes externas cambian, por lo que hay que revisar la evaluación, las pruebas y la documentación. Anonimizar datos personales es en sí mismo un tratamiento que necesita un diseño lícito, seguro y transparente.
Aplica el test del EDPB de 2026 antes de llamar anónimos a los datos
- Sin aislamiento / singularización: ¿un puesto único, una fecha exacta, un código postal o una combinación de hechos permite aislar a una persona, aunque no aparezca su nombre? Fuente
- Sin vinculación: ¿el prompt o documento puede cruzarse con el CRM, perfiles públicos, otro conjunto de datos, una tabla de tokens o información de un tercero? Fuente
- Sin inferencia: ¿un lector o sistema de IA puede deducir un dato específico y significativo —como diagnóstico, salario o reclamación— sobre una persona identificable? Fuente
Lista de comprobación antes de enviar datos personales a una IA
- Define la finalidad mínima: pide solo la transformación, el resumen o el análisis que realmente necesitas.
- Localiza identificadores directos e indirectos en el prompt, cuerpo del documento, tablas, nombres de archivo, metadatos y adjuntos.
- Elimina o enmascara nombres, emails, teléfonos, números de cuenta y otros identificadores directos antes del envío.
- Generaliza fechas exactas, ubicaciones detalladas, funciones poco comunes y sucesos singulares cuando no sea necesaria esa precisión.
- Decide si necesitas tokens persistentes como [CLIENTE_01]; si permiten vincular registros, clasifica el material como datos personales seudonimizados.
- Conserva por separado la tabla de equivalencias, el documento original y los secretos, limita su acceso y protégelos con medidas técnicas y organizativas.
- Prueba la singularización, vinculación e inferencia frente a conocimiento interno, fuentes públicas y futuros destinatarios razonables.
- Revisa proveedor, plan, conservación, entrenamiento, subencargados, transferencias y contrato de la IA; el enmascarado no sustituye la diligencia sobre el proveedor.
- Documenta la evaluación, el responsable, los destinatarios previstos y la fecha de revisión; repítela cuando cambien el contexto, los datos o la tecnología.
- Si persisten dudas, trata el contenido como datos personales y consulta al delegado de protección de datos o asesor de privacidad.
¿Cuándo sigue siendo dato personal el contenido enmascarado?
Presume que sigue siendo dato personal si tu organización conserva el original o la clave de los tokens, si el contexto identifica a alguien, si un token común permite cruzar registros o si un destinatario puede obtener razonablemente información adicional. Quitar nombres es desidentificación, no prueba de anonimato. La conclusión depende de los datos, finalidad, destinatarios, medios disponibles y tecnología actual, y debe documentarse en vez de deducirse del nombre comercial de una función.
Usa AIamigo como protección previa al envío
AIamigo detecta información sensible y permite enmascararla antes de enviarla a herramientas de IA compatibles. Puede reducir la exposición innecesaria y apoyar la minimización en los prompts diarios. No demuestra por sí solo que todo prompt enmascarado o respuesta de IA sea anónimo: el contexto restante, los tokens persistentes, documentos originales e información disponible en otros lugares todavía pueden identificar a una persona. Trata el resultado según tu evaluación documentada y los demás controles del RGPD.
Recursos relacionados
Preguntas frecuentes
¿Cuál es la diferencia entre anonimización y seudonimización?
La anonimización hace que las personas dejen de estar identificadas o ser identificables para las partes relevantes mediante medios que razonablemente puedan utilizarse. La seudonimización impide atribuir los datos sin información adicional protegida por separado, pero normalmente siguen siendo datos personales para el responsable que puede restablecer la conexión.
¿Los datos seudonimizados siguen siendo datos personales según el RGPD?
Por regla general, sí, especialmente para el responsable que conserva el original, la clave u otros medios de atribución. La situación de un destinatario puede requerir un análisis más matizado, pero sustituir un nombre por un código no elimina automáticamente las obligaciones del RGPD.
¿Quitar los nombres hace anónimo un prompt de IA?
No necesariamente. Fechas, ubicaciones, hechos poco comunes, cargos, texto citado y otros detalles pueden singularizar a alguien, vincular el prompt a otra fuente o revelar información significativa sobre una persona identificable.
¿Cuáles son los criterios de anonimización del EDPB en 2026?
La versión en consulta de las Directrices 02/2026 utiliza los criterios sin aislamiento de registros, sin vinculación y sin inferencia. Superar los tres respalda el anonimato; si uno falla, se requiere más análisis. A 23 de agosto de 2026, las directrices no eran finales.
¿Puede AIamigo garantizar la anonimización según el RGPD?
No se puede alcanzar esa conclusión jurídica solo por enmascarar identificadores. AIamigo detecta y enmascara contenido sensible antes de enviarlo, lo que reduce la exposición, pero el contexto o la información disponible en otros lugares aún pueden convertirlo en dato personal.