Más allá de los SSN: anonimizar los identificadores internos de su organización
Su herramienta RGPD elimina direcciones de correo. Elimina números de teléfono. Elimina nombres. Usted pasa las exportaciones de tickets de soporte por ella. Luego comparte el resultado con su equipo de análisis.
Sus números de cuenta de cliente siguen en cada ticket. Sus ID de pedido también. Sus ID de usuario internos también.
Estos ID parecen inofensivos por sí solos. Sin una tabla de referencia, no identifican a nadie. Pero su equipo de análisis tiene esa tabla. Su CRM también. Su base de datos de soporte también. Cualquiera con acceso puede encontrar a la persona en segundos.
Esto es un fallo de seudonimización bajo el RGPD. La herramienta no falló. Nunca se le dijo que buscara sus ID.
Qué detectan las herramientas PII estándar
Las herramientas PII estándar cubren formatos universales. Capturan lo que usa cualquier organización.
Las herramientas estándar detectan:
- Números de seguridad social (SSNs de EE. UU., NINOs del Reino Unido, formatos nacionales de la UE)
- Direcciones de correo electrónico
- Números de teléfono
- Números de tarjeta de crédito
- Nombres
- Números de pasaporte y carnet de conducir
Las herramientas estándar no detectan:
- ID de empleado en su formato EMP-XXXXX
- Números de cuenta de cliente en su formato ACC-XXXXXXXX-XX
- ID de pedido en su formato ORD-XXXXXXX
- ID de usuario interno en formatos UUID o personalizados
- Códigos de referencia específicos de socios
Las herramientas estándar encuentran patrones universales. Sus ID internos no son universales. Necesitan configuración personalizada para ser detectados.
El riesgo de reidentificación
Una empresa exporta tickets de soporte para revisión de calidad. La eliminación PII estándar suprime nombres, correos y teléfonos. Los números de cuenta en formato ACC-XXXXXXXX-XX no se tocan.
La exportación va al equipo de análisis. Un analista hace una unión entre la tabla de tickets y la base de datos de clientes usando el número de cuenta. La persona se encuentra al instante. No se necesita ninguna técnica especial. Es una consulta SQL de rutina.
El Artículo 4(5) del RGPD define la seudonimización como el tratamiento en que los datos «ya no puedan atribuirse a un interesado específico sin utilizar información adicional». Los números de cuenta no superan esa prueba. La información adicional — su base de datos de clientes — está ahí mismo en su organización.
La exportación «anonimizada» no lo era.
Crear patrones de entidades personalizados
La configuración de entidades personalizadas es rápida. Los equipos de cumplimiento pueden hacerlo sin ayuda técnica.
Paso 1: Listar sus formatos de ID.
Anote cada uno. Por ejemplo: cuenta ACC-XXXXXXXX-XX, pedido ORD-XXXXXXX, empleado EMP-XXXXX.
Paso 2: Describir el formato en lenguaje sencillo.
«Los números de cuenta empiezan con ACC, luego un guión, luego 8 dígitos, luego un guión, luego 2 letras mayúsculas.»
La generación de patrones asistida por IA devuelve: ACC-\d{8}-[A-Z]{2}
Paso 3: Probar con datos de muestra.
Cargue 20 a 30 documentos. Confirme que se encuentran todas las ocurrencias. Confirme que no aparecen falsos positivos.
Paso 4: Elegir un método.
Para ID usados como claves de unión, donde el análisis necesita vincular registros:
- Seudonimizar. Reemplazar ACC-00123456-AB por ACC-99876543-XY cada vez. La misma entrada siempre da la misma salida. Las uniones siguen funcionando. El valor original no puede recuperarse sin la clave.
Para ID que no se necesitan en el análisis:
- Redactar. Reemplazar con [REDACTED]. Simple. Permanente.
Paso 5: Guardar como preset compartido.
Guarde la entidad personalizada — o un conjunto de ellas — como un preset compartido. La configuración se aplica a todos los usos: cargas masivas, llamadas API, interfaz de navegador. Los nuevos miembros del equipo obtienen la configuración completa de inmediato.
Caso práctico: 180.000 tickets de soporte
Una empresa encontró 180.000 tickets de soporte en su almacén de análisis. Los nombres y correos habían sido eliminados. Los números de cuenta no. Cada ticket seguía teniendo un valor ACC-XXXXXXXX-XX activo.
Calendario de resolución:
- El responsable de cumplimiento define el patrón ACC — 15 minutos
- Lo prueba en 30 tickets de muestra — 20 minutos
- Confirma la precisión — 10 minutos
- Procesa 180.000 tickets en un lote nocturno
- Reemplaza las tablas del almacén con las versiones limpias
Tiempo total del responsable de cumplimiento: 45 minutos. Sin detección de entidades personalizadas, la solución habría requerido un ticket de ingeniería, revisión de código y un despliegue. Eso lleva semanas, no horas.
Para ver cómo los ID personalizados crean riesgos en las herramientas de IA de soporte, consulte la guía RGPD para soporte con IA.
Dónde se propagan los ID internos
Los ID internos aparecen en más lugares de los que la mayoría de los equipos esperan.
Documentos internos:
- Notas de reuniones con referencias a cuentas o pedidos
- Hilos de correo sobre casos de clientes
- Presentaciones con datos de casos reales
Compartidos con terceros:
- Informes a reguladores con números de referencia
- Documentos de auditoría con referencias de clientes
- Archivos de proveedores con ID de clientes
Investigación y análisis:
- Conjuntos de datos de recorrido del cliente
- Exportaciones de revisión de calidad del soporte
- Datos de entrenamiento para modelos ML internos
Cada contexto necesita la misma configuración de entidades personalizadas para producir resultados verdaderamente anónimos.
Seudonimización vs. anonimización
El RGPD traza una línea clara.
La seudonimización reemplaza los ID por sustitutos. La persona original puede encontrarse de nuevo si alguien tiene la tabla de referencia. Estos datos siguen siendo datos personales. El riesgo disminuye. Sus obligaciones bajo el RGPD no desaparecen.
La anonimización elimina la capacidad de reidentificar. Los datos anónimos no son datos personales. El RGPD no se aplica a ellos.
Los números de cuenta y de pedido son seudónimos cuando existen tablas de referencia. Reemplazarlos con sustitutos fijos reduce el riesgo, pero el RGPD sigue aplicando. Reemplazarlos con tokens aleatorios — y eliminar la clave — suprime la obligación RGPD, pero impide el análisis con uniones.
Para compartir con terceros que no tienen sus tablas de referencia: la seudonimización puede ser suficiente. Para análisis internos, se necesita anonimización completa o controles de acceso estrictos. La guía de cumplimiento legal explica cómo documentar cada enfoque para su registro de actividades de tratamiento.
Conclusión
La brecha no es un fallo de la herramienta. Es una brecha de configuración. Ninguna herramienta puede conocer el formato de su número de cuenta si no se lo indica.
La configuración de entidades personalizadas cierra la brecha en horas. Los equipos de cumplimiento definen los formatos, los prueban con datos de muestra y los aplican en todos los modos de uso. No se necesita ayuda técnica.
Los 180.000 números de cuenta sin redactar no estaban ahí porque la herramienta falló. Estaban ahí porque nunca se le dijo a la herramienta que los buscara.