Herramientas PII solo en inglés: la brecha del RGPD
El RGPD no tiene preferencia lingüística
El RGPD cubre los datos personales en cualquier idioma. Alemán, francés, polaco, sueco — todos están cubiertos por igual. Un Steuer-ID omitido crea el mismo riesgo legal que un número de seguridad social omitido. La ley no distingue por idioma.
La mayoría de las herramientas de detección PII, sí.
Las principales herramientas comerciales y de código abierto fueron construidas para texto en inglés. Sus módulos de detección lo reflejan. Cubren bien los números de seguridad social de EE. UU., las licencias de conducir de EE. UU. y los formatos de teléfono NANP. Los módulos para identificadores nacionales no ingleses son menos precisos. Están menos bien mantenidos. Se saltan más a menudo los identificadores reales.
Para las empresas de los estados miembros de la UE, esto crea una brecha de cobertura. La herramienta indica que la detección está completa. Pero los identificadores no ingleses permanecen en los datos. Estos suelen ser los identificadores con mayor exposición al RGPD en ciertos países.
Las autoridades de protección de datos lo ven. Los auditores lo buscan. Una herramienta puede funcionar bien con registros en inglés. Pero si falla con registros alemanes o franceses, no cumple la normativa. Un informe limpio no cambia eso.
Los identificadores nacionales difieren en su estructura
La brecha entre las herramientas centradas en inglés y las multilingües no se trata de añadir más patrones regex. Los identificadores nacionales de la UE son muy diferentes entre sí. Necesitan lógica específica de cada país para ser detectados correctamente.
German Steuer-Identifikationsnummer (Steuer-ID): 11 dígitos. Usa una suma de verificación basada en una variante de la fórmula de Luhn. Un regex SSN genérico no lo detectará. Un regex para cualquier número de 11 dígitos genera demasiados falsos positivos en documentos alemanes.
French NIR (Numéro d'inscription au répertoire): 15 dígitos. El formato codifica sexo, año de nacimiento, mes de nacimiento y departamento de nacimiento. También incluye el orden de nacimiento y una clave de control de 2 dígitos. La clave de control debe validarse para una detección correcta.
Swedish Personnummer: 10 dígitos con un dígito de verificación Luhn. Las personas nacidas antes de 1990 usan el separador + en lugar de -. Eso cambia el formato que debe detectarse.
Polish PESEL: 11 dígitos. Codifica fecha de nacimiento, género y un dígito de verificación basado en sumas ponderadas. La detección correcta necesita tanto la coincidencia de formato como la validación de suma de verificación.
Estos no son variantes de un patrón común. Cada uno tiene una longitud diferente. Cada uno usa un método de verificación diferente. Cada uno codifica datos en un esquema de posición diferente. Un modelo NER entrenado en inglés que ve un NIR francés no lo reconocerá como identificador nacional. Lo ignorará o lo clasificará incorrectamente.
El riesgo práctico de cumplimiento
Considere un responsable de cumplimiento en un BPO europeo. Procesa datos de Alemania, Francia, Polonia y los Países Bajos a la vez. Su herramienta reporta una anonimización PII exitosa.
Pero el resultado no está completo. Los Steuer-IDs en los registros alemanes permanecen. Los números NIR en los registros franceses permanecen. Los números PESEL en los registros polacos permanecen. Los módulos de la herramienta para estos formatos están ausentes o son demasiado imprecisos.
Más tarde, el conjunto de datos va a análisis o a un socio de investigación. Los datos aún contienen identificadores nacionales re-identificables. El problema del RGPD no aparece en los registros de salida de la herramienta. Surge cuando llega una solicitud de acceso de un interesado. Puede surgir durante una auditoría de una autoridad de protección de datos. Puede surgir tras una violación de datos.
Las investigaciones que comparan enfoques híbridos multilingües con herramientas centradas en inglés encontraron resultados claros. Los métodos híbridos logran puntuaciones F1 de 0,60 a 0,83 en locales europeas. Las herramientas solo en inglés obtienen cerca de cero para formatos de ID nacionales no ingleses.
Consulte nuestra descripción general del cumplimiento del RGPD para ver cómo estas brechas se relacionan con las obligaciones del RGPD.
Lo que requiere una cobertura completa
La verdadera detección PII multilingüe para el cumplimiento del RGPD de la UE necesita tres capas.
Los modelos spaCy nativos por idioma proporcionan comprensión semántica en el idioma del texto. Un modelo entrenado en texto alemán sabe que "Müller" es un apellido alemán común. Existen modelos para 25 idiomas europeos de altos recursos.
Los modelos NLP Stanza amplían la cobertura a idiomas no incluidos en spaCy. Esto añade alcance para más comunidades lingüísticas de la UE.
Los modelos transformadores multilingües (XLM-RoBERTa) manejan casos entre idiomas. Un nombre en una oración francesa se reconoce como nombre de persona. Esto funciona incluso si el motor no fue entrenado en ese nombre específico.
El regex con validación específica del país cubre los identificadores nacionales estructurados. Steuer-ID, NIR, PESEL y Personnummer necesitan cada uno su propia lógica de suma de verificación. Esto reduce los falsos positivos. Las secuencias de dígitos que no pasan las reglas de validación del país se filtran.
La brecha es estructural. Añadir listas de palabras o más patrones regex solo proporciona una mejora menor. Incorporar la cobertura de identificadores de la UE desde el principio es el único enfoque fiable.
Verifique su herramienta actual
Pida a su proveedor puntuaciones F1 para registros alemanes, franceses, polacos y holandeses. "Soporta múltiples idiomas" a menudo significa que la herramienta usa traducción primero. Eso no es escaneo nativo. El cumplimiento del RGPD requiere escaneo nativo.
Pruebe con muestras reales de ID nacionales. Cree un conjunto de prueba corto con 10 ejemplos de cada tipo de ID en sus operaciones. Steuer-ID, NIR, PESEL, Personnummer. Verifique las tasas de detección. Es más rápido que una prueba F1 completa y revela las brechas rápidamente.
Consulte nuestra página de seguridad y cumplimiento para ver cómo anonym.legal aborda estos requisitos. Para definiciones de tipos de entidades, visite la referencia de entidades.