Más allá de los números de seguro social y las direcciones de correo electrónico: Anonimizando los identificadores personalizados de su organización
Su herramienta de anonimización GDPR detecta direcciones de correo electrónico. Detecta números de teléfono. Detecta nombres y números de seguro social. Ejecuta sus exportaciones de tickets de soporte a través de ella, descarga la salida anonimizada y la comparte con su equipo de análisis.
Sus números de cuenta de cliente (formato ACC-XXXXXXXX-XX) todavía están en cada ticket. Sus ID de pedidos (ORD-XXXXXXX) todavía están presentes. Sus ID de usuario internos todavía están allí.
Estos identificadores son seudónimos en aislamiento — no identifican directamente a una persona sin acceso a una tabla de búsqueda. Pero su equipo de análisis tiene acceso a esa tabla de búsqueda. Su base de datos de soporte la tiene. Su CRM la tiene. La exportación anonimizada puede ser re-identificada en segundos por cualquier persona con acceso a cualquiera de estos sistemas.
Este es un fallo de seudonimización de GDPR — no porque la herramienta pasara por alto el PII estándar, sino porque no podía conocer los identificadores específicos de su organización.
Lo que detectan las herramientas estándar de PII
Las herramientas estándar de detección de PII — incluidas las configuraciones base de Microsoft Presidio — están construidas alrededor de formatos de identificadores universales:
Lo que se cubre:
- Números de seguro social (SSNs de EE. UU., NINOs del Reino Unido, formatos de ID nacional de la UE)
- Direcciones de correo electrónico (formato RFC 5322)
- Números de teléfono (formatos E.164 y nacionales)
- Números de tarjetas de crédito (validación del algoritmo de Luhn)
- Nombres (detección basada en modelos NER)
- Números de pasaporte/licencia de conducir (formatos específicos de cada país)
Lo que no se cubre:
- Su formato de ID de empleado (EMP-XXXXX)
- Su formato de número de cuenta de cliente (ACC-XXXXXXXX-XX)
- Su formato de ID de pedido (ORD-XXXXXXX)
- Su ID de usuario interno (formato UUID o personalizado)
- Sus códigos de referencia internos
- Identificadores específicos de socios
Las herramientas estándar detectan lo que es universal. Los identificadores específicos de la organización no son, por definición, universales. Requieren configuración personalizada.
El riesgo de re-identificación en la práctica
Una firma de servicios financieros procesa tickets de soporte al cliente para análisis de calidad. Su flujo de trabajo estándar de anonimización de PII elimina:
- Nombres de clientes ✓
- Direcciones de correo electrónico ✓
- Números de teléfono ✓
- Números de cuenta (formato ACC-XXXXXXXX-XX) ✗ — no detectado
La exportación del ticket va al equipo de análisis. Un analista de datos une la tabla de tickets con la base de datos de clientes por número de cuenta. La re-identificación es inmediata y completa.
Esto no requiere técnicas de ataque sofisticadas. Es una unión SQL de rutina que cualquier analista realizaría para agregar contexto demográfico del cliente al análisis de tickets de soporte. La exportación "anonimizada" no era anónima.
El Artículo 4(5) del GDPR define la seudonimización como "el procesamiento de datos personales de tal manera que los datos personales ya no pueden ser atribuidos a un sujeto de datos específico sin el uso de información adicional." Los números de cuenta fallan esta prueba cuando la información adicional (la base de datos de clientes) está fácilmente disponible.
Construyendo patrones de entidad personalizados
La creación de entidades personalizadas sigue un flujo de trabajo sencillo para equipos de cumplimiento no técnicos:
Paso 1: Identificar el formato del identificador Documente sus identificadores específicos de la organización y sus formatos:
- Cuenta de cliente: ACC-XXXXXXXX-XX (prefijo ACC, número de 8 dígitos, sufijo de 2 caracteres)
- ID de pedido: ORD-XXXXXXX (prefijo ORD, número de 7 dígitos)
- ID de empleado: EMP-XXXXX (prefijo EMP, número de 5 dígitos)
- ID de usuario interno: formato UUID (8-4-4-4-12 hexadecimal)
Paso 2: Generar el patrón de detección Describa el formato en lenguaje sencillo: "Números de cuenta que comienzan con ACC, luego un guion, luego 8 dígitos, luego un guion, luego 2 letras mayúsculas."
La generación de patrones asistida por IA produce: ACC-d{8}-[A-Z]{2}
Paso 3: Validar contra datos de muestra Suba de 20 a 30 documentos que contengan el identificador. Verifique:
- Todas las instancias son detectadas (sin falsos negativos)
- Sin falsos positivos (texto no identificador marcado incorrectamente)
Paso 4: Configurar el método de anonimización Para identificadores utilizados como claves de unión (ID de pedidos que aparecen en múltiples sistemas y necesitan ser consistentes para el análisis):
- Seudonimizar: Reemplace ACC-00123456-AB consistentemente con ACC-99876543-XY en todos los documentos. El reemplazo es consistente — la misma entrada siempre produce la misma salida — por lo que las uniones analíticas aún funcionan. El valor original no es recuperable sin la clave.
Para identificadores no necesarios para el análisis:
- Redactar: Reemplace con [REDACTADO]. Más simple, irreversible.
Paso 5: Guardar como preajuste La entidad personalizada (o múltiples entidades personalizadas) guardadas como un preajuste de equipo se aplican consistentemente en todos los procesos — cargas por lotes, llamadas API, interfaz de navegador. Los nuevos miembros del equipo obtienen automáticamente la configuración completa.
Estudio de caso: 180,000 tickets de soporte
Una firma de servicios financieros tiene números de cuenta de cliente (formato ACC-XXXXXXXX-XX) que aparecen en toda la exportación histórica de tickets de soporte. Las herramientas estándar de PII las pasaron por alto por completo.
Brecha identificada: Después de una revisión de cumplimiento, el equipo se dio cuenta de que 180,000 tickets de soporte históricos en su almacén de análisis contenían números de cuenta no redactados junto con nombres y correos electrónicos (ya anonimizados).
Cronograma de resolución:
- El oficial de cumplimiento define el patrón ACC (15 minutos)
- Prueba contra 30 tickets de muestra (20 minutos)
- Confirma la precisión del patrón (10 minutos)
- Procesa 180,000 tickets en un lote nocturno
- Reemplaza las tablas del almacén con versiones re-anonimizadas
Tiempo total para cerrar la brecha de cumplimiento: 45 minutos de tiempo del oficial de cumplimiento + lote nocturno. Sin la creación de entidades personalizadas, esto requeriría un ticket de ingeniería, tiempo de desarrollo, revisión de código y despliegue — semanas, no horas.
Más allá de los tickets de soporte: Dónde aparecen los identificadores personalizados
Los identificadores organizacionales personalizados se propagan a través de más tipos de documentos de los que la mayoría de los equipos de cumplimiento se dan cuenta:
Documentos internos:
- Notas de reuniones que hacen referencia a números de cuenta o ID de pedidos
- Hilos de correo electrónico con referencias a clientes
- Presentaciones con datos de estudios de caso
Compartidos con terceros:
- Informes a reguladores con números de referencia de casos
- Datos compartidos con auditores
- Documentos de proveedores con referencias a clientes
Investigación y análisis:
- Conjuntos de datos de análisis del viaje del cliente
- Conjuntos de datos de revisión de calidad de soporte
- Datos de entrenamiento para modelos de ML internos
Cada uno de estos requiere la misma configuración de entidad personalizada para producir una salida genuinamente anónima.
Seudonimización vs. Anonimización de GDPR: La Distinción Técnica
El GDPR distingue entre:
Seudonimización: Datos que pueden ser re-identificados con acceso a información adicional. Los datos seudonimizados siguen siendo datos personales bajo el GDPR. La regulación fomenta la seudonimización como una medida de reducción de riesgos, pero no elimina las obligaciones del GDPR.
Anonimización: Datos que no pueden ser razonablemente re-identificados. Los datos anónimos no son datos personales y no están sujetos al GDPR.
Los números de cuenta, ID de pedidos e ID de empleados son seudónimos — no anónimos — cuando existen tablas de búsqueda. Reemplazarlos con seudónimos consistentes (seudonimización) reduce el riesgo pero no elimina las obligaciones del GDPR. Reemplazarlos con tokens aleatorios (anonimización mediante destrucción de la clave) elimina las obligaciones del GDPR pero rompe las uniones.
Para compartir con terceros que no tienen acceso a sus tablas de búsqueda: la seudonimización puede ser suficiente (no pueden re-identificar sin la clave). Para análisis internos: se requiere anonimización completa o controles de acceso sobre la clave.
Conclusión
La brecha de detección de PII estándar no es una limitación técnica de los algoritmos de detección — es una brecha de configuración. Ninguna herramienta de detección puede conocer el formato del número de cuenta de su organización a menos que se lo diga.
La creación de entidades personalizadas cierra esta brecha en horas en lugar de semanas. Los equipos de cumplimiento — sin apoyo de ingeniería — pueden definir patrones específicos de la organización, validarlos contra datos de muestra y aplicarlos consistentemente en todos los modos de procesamiento.
Los 180,000 números de cuenta no redactados descubiertos en el estudio de caso no estaban allí debido a un fallo de la herramienta. Estaban allí porque nunca se le dijo a la herramienta que los buscara.
Fuentes: