Detección multilingüe de datos personales para el RGPD
Actualizado para 2026
La brecha oculta del RGPD
El RGPD no tiene preferencia lingüística. El artículo 4(1) define los "datos personales" sin mencionar el idioma en que aparecen. Un Steuer-ID alemán está tan protegido como un número de seguridad social estadounidense. Un NIR francés está tan regulado como un número de seguro nacional británico.
La mayoría de las herramientas de detección de datos personales fueron diseñadas solo para inglés.
Investigaciones de ACL 2024 muestran que las herramientas NLP híbridas alcanzan puntuaciones F1 de 0,60 a 0,83 para locales europeos. Las herramientas solo en inglés obtienen puntuaciones cercanas a cero para formatos de ID nacionales no ingleses. La brecha es grave. Una herramienta puede detectar el 95 % de los datos personales en inglés. Pero omite entre el 40 y el 60 % de los datos personales en alemán, francés, polaco u holandés en el mismo archivo. Es un problema serio. Expone a las empresas a riesgos.
Esta es una brecha real del RGPD. Afecta a casi todas las empresas globales que usan herramientas de redacción centradas en inglés. Consulte nuestra guía del RGPD para más información.
Por qué los datos personales son específicos al locale
La detección de datos personales tiene dos partes.
La primera es la detección basada en patrones. Cubre identificadores estructurados como números fiscales y formatos de teléfono.
La segunda es la detección basada en NER. Cubre entidades contextuales como nombres y direcciones.
Ambas partes dependen del locale.
Los IDs estructurados difieren por país
| País | ID fiscal | Formato | Validación |
|---|---|---|---|
| Alemania | Steuer-ID | 11 dígitos | Módulo-11 |
| Francia | NIR | 15 dígitos + clave de 2 dígitos | INSEE |
| Suecia | Personnummer | 10 dígitos | Luhn |
| Polonia | PESEL | 11 dígitos | Módulo-10 |
| Países Bajos | BSN | 9 dígitos | Elfproef |
| España | DNI/NIE | 8 dígitos + letra | Módulo-23 |
| Italia | Codice Fiscale | 16 caracteres | Suma de comprobación |
Un regex solo en inglés para SSN (NNN-NN-NNNN) no coincidirá con ninguno de estos formatos. Cada uno necesita su propio regex. Cada uno también necesita su propia lógica de suma de comprobación.
La NER necesita modelos nativos
Los nombres alemanes difieren de los ingleses. "Hans-Dieter Müller" es claro para un modelo alemán nativo. Un modelo entrenado en inglés suele omitirlos.
Los falsos positivos también son un problema. El rastreador de issues de Microsoft Presidio muestra palabras alemanas clasificadas erróneamente como datos personales en inglés. La palabra "Null" (cero en alemán) es un ejemplo. Activa detecciones falsas de nombres en modelos entrenados en inglés. En producción, las tasas de error se inflan a 3 falsos positivos por entidad real (Alvaro et al., 2024).
Riesgo regulatorio
Las autoridades europeas de protección de datos son conscientes de este problema. Varias APD nacionales han emitido orientaciones.
BfDI alemán: El artículo 5(1)(f) del RGPD aplica a todos los registros. Cubre datos no ingleses procesados por herramientas de terceros.
CNIL francesa: El informe anual 2024 de la CNIL expresó preocupaciones. Señaló herramientas de IA que procesan datos franceses sin detección de datos personales en francés.
APD europeas en general: El artículo 25 del RGPD (Privacidad desde el diseño) exige salvaguardas adecuadas para los datos realmente procesados. Esto incluye datos personales no ingleses en implantaciones globales.
El riesgo es claro. Una empresa puede mostrar un 95 % de detección de datos personales en contenido inglés durante una auditoría del RGPD. Pero si también maneja registros alemanes, franceses y polacos con la misma herramienta, aparecerán brechas. Los auditores lo notan. Pueden seguir multas. Consulte nuestra página de seguridad para ver cómo lo abordamos.
Arquitectura de tres niveles
La investigación y la práctica coinciden en que un diseño híbrido de tres niveles es el mejor enfoque.
Nivel 1: Modelos spaCy nativos
spaCy proporciona modelos entrenados para 25 locales. Estos incluyen alemán, francés, español, portugués, italiano, holandés, ruso, chino, japonés, coreano y polaco. Cada modelo se entrena en texto nativo. Aprenden la sintaxis y los patrones de entidades de cada locale. Esto importa. El entrenamiento nativo significa mejor recuperación y menos falsos positivos.
Para alemán: de_core_news_lg maneja sustantivos compuestos y patrones de nombres alemanes.
Para francés: fr_core_news_lg maneja entidades francesas, títulos, nombres de lugares y organizaciones.
Los modelos nativos superan a los modelos multilingues para la detección de nombres en locales de alta disponibilidad.
Nivel 2: Stanza para más locales
La biblioteca Stanza de Stanford cubre locales no incluidos en spaCy. Estos incluyen croata, esloveno y ucraniano. Esto amplía el alcance a grupos de hablantes de la UE que spaCy no cubre. Stanza es gratuito y de código abierto. Se integra bien con el resto de la pila.
Nivel 3: XLM-RoBERTa para amplio alcance
Para locales donde spaCy y Stanza carecen de modelos NER, XLM-RoBERTa llena el vacío. Se entrena en texto Common Crawl de 100 locales. Alcanza un F1 multilingue del 91,4 % para la detección de datos personales (HuggingFace 2024). Maneja bien el cambio de código. Es una característica clave. Importa cuando un documento contiene texto en varios locales a la vez.
Visite nuestros docs del sistema de tokens para ver cómo las llamadas API escalan con el volumen multilingue.
Tipos de entidades específicos del locale
Los modelos solos no son suficientes. La conformidad con el RGPD también requiere cobertura de tipos de entidades para IDs nacionales.
IDs nacionales de la UE por país:
- DE: Steuer-ID, Sozialversicherungsnummer, Personalausweisnummer
- FR: NIR, SIREN, SIRET
- PL: PESEL, NIP, REGON
- NL: BSN
- SE: Personnummer, Samordningsnummer
- ES: DNI, NIE, NIF, CIF
- IT: Codice Fiscale, Partita IVA
Formatos de teléfono: Cada país de la UE tiene estructuras de prefijo únicas. +49, +33 y +48 tienen cada uno su propia lógica de validación.
Formatos de dirección: Los códigos postales varían mucho. El PLZ alemán usa 5 dígitos. Los códigos franceses usan 5 dígitos (rango 01–99). Los códigos postales del Reino Unido son alfanuméricos. Los códigos españoles usan 5 dígitos (01000–52999).
Caso real: Empresa farmacéutica suiza
Una empresa suiza procesa contratos de trabajo. Cada contrato mezcla texto en alemán, francés e inglés. Suiza tiene cuatro idiomas oficiales. Su herramienta estaba configurada solo para alemán. Omitía todo el PII de las secciones en francés.
Un contrato para un empleado con sede en Ginebra incluía un número AVS francés (13 dígitos), un IBAN de banco suizo y un nombre en formato francés. La herramienta solo para alemán omitió el nombre en formato francés. No encontró el número AVS francés. El formato AHV-Nummer alemán es diferente. Solo detectó parcialmente el IBAN.
El enfoque de tres niveles procesa todo el documento. Detecta el locale por segmento de texto. Aplica el modelo NER correcto para cada parte. Valida cada ID nacional con la lógica correcta del país.
Documentos con locales mixtos
El caso más difícil es la mezcla de locales dentro de un documento. Ejemplos:
- El contrato en inglés de una empresa alemana con registros de empleados alemanes (nombres, IDs fiscales)
- Un formulario de consentimiento RGPD en francés con un extracto de política de privacidad en inglés
- Un chat donde el agente responde en inglés y el cliente escribe en árabe
XLM-RoBERTa lo maneja de forma nativa. No necesita declaraciones de locale explícitas. Procesa texto con locales mixtos sin segmentación previa. Esto ahorra tiempo. También evita errores por divisiones incorrectas.
Para uso en producción, combinar la detección automática de locale (a nivel de oración) con la inferencia XLM-RoBERTa proporciona un manejo robusto de documentos con locales mixtos.
Pasos prácticos
Audite el alcance de su herramienta. Pida a su proveedor de redacción puntuaciones F1 para sus locales específicos. "Compatible con 20 idiomas" a menudo significa que la herramienta primero traduce el texto automáticamente. Eso no es detección nativa.
Mapee sus registros por locale. Haga un inventario de registros que incluya la distribución por locale. Una empresa global con 70 % en inglés, 20 % en alemán y 10 % en francés tiene riesgos diferentes. Una con 95 % en inglés está en una posición diferente.
Pruebe con muestras de IDs nacionales. Cree un conjunto de prueba con 10 ejemplos de cada ID nacional en sus operaciones: Steuer-ID, NIR, PESEL, BSN y otros. Verifique las tasas de detección. Es más rápido que una prueba F1 completa.
Revise sus EIPD. Compruebe si se incluye el alcance por locale. Una EIPD incompleta que asuma registros solo en inglés puede necesitar una actualización. Actúe ahora. No espere a una auditoría para descubrir la brecha.
Para definiciones completas de tipos de entidades, consulte la referencia de entidades y las preguntas frecuentes. Para planes y tarifas de llamadas API, visite precios.
El motor de detección PII de anonym.legal usa un enfoque multilingüe de tres niveles. Cubre 25 locales de alta disponibilidad con modelos spaCy nativos. Stanza añade alcance adicional de locale. Los transformadores multilingues XLM-RoBERTa extienden el alcance a 48 locales. Los tipos de entidades específicos de cada país para todos los estados miembros de la UE están incluidos.