El punto ciego RTL en el cumplimiento
El RGPD no termina en el Bósforo. Las empresas de la UE que usan herramientas diseñadas para texto latino tienen un punto ciego. Es real y en gran medida ignorado.
El problema no es solo la dirección del texto. Las escrituras de derecha a izquierda necesitan una tokenización diferente. Necesitan una segmentación diferente. Los límites de entidades funcionan de forma distinta que en el texto LTR. Los sistemas NER entrenados en inglés aplican reglas LTR. Esas reglas fallan en el texto RTL. Dan límites de entidades incorrectos.
La morfología árabe complica más las cosas. El idioma usa raíces. Una raíz genera docenas de formas de palabras. Un nombre como Mohammed puede aparecer como "Al-Mohammed", "bin Mohammed" o "Mohammed al-Rashid". Los patrones de expresión regular diseñados para nombres occidentales no capturan estas formas. Los modelos entrenados en inglés tampoco.
El RGPD no trata el idioma como un límite de cumplimiento. Una empresa de la UE que procesa correspondencia de clientes de la región MENA debe cumplir las mismas reglas que para correspondencia en francés. No detectar datos personales en texto RTL es un incumplimiento legal según el Artículo 32 del RGPD.
El caso de uso KYC
Una empresa fintech en Dubái que procesa documentos KYC para clientes de la UE ilustra bien esto.
Los archivos KYC de clientes árabes contienen nombres en escritura RTL, Emirates IDs de los Emiratos Árabes Unidos y direcciones RTL. Estos se combinan con texto comercial en inglés.
El formato del Emirates ID es 784-XXXX-XXXXXXX-X. Código de país 784. Año de nacimiento. Siete dígitos. Dígito de control. Las herramientas de detección de datos personales sin definiciones de entidades específicas para los Emiratos no pueden encontrar este formato. Los campos de nombres pasan por un NER de escritura latina. La segmentación es incorrecta. Los datos personales se vuelven invisibles en el flujo de trabajo.
Para las empresas con obligaciones RGPD sobre estos datos, la brecha crea un riesgo legal real. El Artículo 32 del RGPD exige medidas técnicas adecuadas. Una herramienta que no detecta identificadores en el 22 % de los idiomas del mundo no es una medida adecuada.
Documentos en hebreo y multilingües
El hebreo presenta problemas similares. La escritura va de derecha a izquierda. Los números de identidad israelíes usan una suma de comprobación — una prueba similar a Luhn sobre nueve dígitos.
Los documentos legales israelíes suelen mezclar hebreo, texto en escritura árabe e inglés en un mismo archivo. Esto es común en contratos donde el hebreo es el idioma principal y los términos en inglés se incorporan por referencia.
Los documentos con escrituras mixtas necesitan detección de script antes del NER. Sin ella, un solo paso de NER aplica reglas latinas a scripts RTL. El resultado es incorrecto.
Una investigación publicada en Nature Scientific Reports (2025) probó el NER multilingue en datos personales RTL. Los modelos estándar obtuvieron puntuaciones F1 de 0,60–0,83. XLM-RoBERTa ajustado en datos NER RTL obtuvo 0,88 y más.
La arquitectura multilingüe requerida
Una buena detección de datos personales RTL necesita tres cosas que las herramientas centradas en el mundo occidental generalmente no tienen.
Manejo de texto RTL: Cumplimiento del algoritmo bidireccional Unicode para un flujo de texto correcto. Tokenización adaptada al RTL que identifica los límites de palabras en el texto de derecha a izquierda.
NER con consciencia morfológica: Un analizador morfológico como Farasa para el árabe, o un modelo transformer ajustado en datos NER RTL. El modelo debe haber aprendido la variación morfológica.
Tipos de entidades específicos de la región: El Emirates ID, el ID israelí, el ID nacional saudí y el ID nacional egipcio requieren definiciones explícitas con reglas de formato. Las herramientas occidentales genéricas no las incluyen.
Consulte cómo nuestra pipeline NER multilingüe gestiona la detección de scripts en 48 idiomas. Para la lista completa de tipos de identificadores de la región MENA que admitimos, visite el catálogo de entidades. Nuestra guía de cumplimiento del RGPD explica cómo las brechas de detección generan exposición al Artículo 32.