By · Last updated 2026-04-01

العودة إلى المدونةتقني

البيانات الشخصية بالعربية والعبرية: فشل أدوات الكشف الغربية

لا تتوقف متطلبات اللائحة الأوروبية لحماية البيانات (GDPR) عند حدود البوسفور. تظل البيانات الشخصية باللغتين العربية والعبرية في سير العمل الأوروبية بلا حماية فعلية. يتناول هذا المقال الكشف متعدد اللغات باستخدام XLM-RoBERTa ومتطلبات بنية الكشف عن الكيانات في النصوص من اليمين إلى اليسار.

April 1, 20268 دقيقة قراءة
Arabic PII detectionHebrew NERRTL text processingMENA GDPR complianceXLM-RoBERTa multilingual

الفجوة الامتثالية في النصوص من اليمين إلى اليسار

لا تتوقف اللائحة الأوروبية لحماية البيانات (GDPR) عند حدود البوسفور. تعاني الشركات الأوروبية التي تعتمد على أدوات مبنية للغات اللاتينية من نقطة عمياء حقيقية يُتجاهل شأنها إلى حد بعيد.

المشكلة لا تقتصر على اتجاه النص. تستلزم النصوص المكتوبة من اليمين إلى اليسار تحليلًا صرفيًا مختلفًا وتجزئةً مختلفة، إذ تسير حدود الكيانات بطريقة مغايرة لتلك المعتادة في النصوص اليسارية. تعتمد أنظمة التعرف على الكيانات المسماة (NER) المُدرَّبة على اللغة الإنجليزية قواعد النصوص اليسارية، وهذه القواعد تنهار عند تطبيقها على النصوص اليمينية فتُنتج حدود كيانات خاطئة.

تزيد الصرافة العربية الأمر تعقيدًا. تعتمد اللغة العربية على جذور تشتق منها عشرات الصيغ الكلمية. فاسم كـ“محمد” يمكن أن يظهر في صور متعددة: “آل محمد” أو “بن محمد” أو “محمد الرشيد”. تفوت أنماط التعبير النمطي (regex) المصممة للأسماء الغربية هذه الصيغ، وكذلك النماذج المُدرَّبة على اللغة الإنجليزية.

لا تعترف اللائحة الأوروبية لحماية البيانات باللغة حدًا للامتثال. فالشركة الأوروبية التي تعالج مراسلات عملائها من منطقة الشرق الأوسط وشمال أفريقيا تخضع للقواعد ذاتها المطبَّقة على المراسلات الفرنسية. إن إغفال البيانات الشخصية في النصوص اليمينية يُشكّل إخفاقًا قانونيًا بموجب المادة 32 من اللائحة الأوروبية لحماية البيانات.

حالة الاستخدام: التحقق من هوية العملاء (KYC)

توضح شركة تقنية مالية دُبَيّة تعالج وثائق KYC لعملاء أوروبيين هذه المشكلة بجلاء.

تحتوي ملفات KYC للعملاء العرب على أسماء بالخط العربي وأرقام هويات الإمارات وعناوين مكتوبة من اليمين إلى اليسار، جنبًا إلى جنب مع نص أعمال إنجليزي.

تتبع بطاقة الهوية الإماراتية الصيغة: 784-XXXX-XXXXXXX-X، وتشمل رمز الدولة 784 وسنة الميلاد وسبعة أرقام ورقم تحقق. أدوات البيانات الشخصية الغربية التي لا تمتلك تعريفات لكيانات دولة الإمارات العربية المتحدة عاجزة عن اكتشاف هذا التنسيق. تمر حقول الأسماء عبر أنظمة التعرف على الكيانات المسماة المُصممة للنصوص اللاتينية بتجزئة خاطئة، مما يجعل البيانات الشخصية غير مرئية في سير العمل.

بالنسبة للشركات المُلزَمة بحماية هذه البيانات وفق اللائحة الأوروبية لحماية البيانات، تُولّد هذه الفجوة مخاطر قانونية حقيقية. تشترط المادة 32 من اللائحة اتخاذ تدابير تقنية ملائمة، وأداةٌ تفوّتها 22% من لغات العالم لا تُعدّ تدبيرًا ملائمًا.

العبرية والوثائق المتعددة اللغات

تطرح العبرية إشكاليات مماثلة. تُكتب من اليمين إلى اليسار، وتعتمد أرقام الهوية الإسرائيلية خوارزمية تحقق تشبه خوارزمية Luhn المطبَّقة على تسعة أرقام.

كثيرًا ما تمزج الوثائق القانونية الإسرائيلية بين العبرية والنصوص ذات الخط العربي والإنجليزية في ملف واحد، كما هو الحال في العقود التي تتخذ من العبرية لغةً رئيسية مع إضافة مصطلحات إنجليزية بالإحالة.

تستلزم الملفات متعددة الخطوط كشف الخط قبل تطبيق التعرف على الكيانات المسماة. بدونه، تُطبَّق تمريرة واحدة من التعرف على الكيانات قواعد النصوص اللاتينية على النصوص اليمينية، مما ينتج عنه نتائج خاطئة.

اختبرت دراسة نشرتها مجلة Nature Scientific Reports عام 2025 التعرف على الكيانات المسماة عبر اللغات في البيانات الشخصية للنصوص اليمينية. سجّلت النماذج المعيارية درجات F1 تراوحت بين 0.60 و0.83، في حين سجّل نموذج XLM-RoBERTa المُضبَّط على بيانات التعرف على الكيانات في النصوص اليمينية درجات 0.88 وما فوق.

متطلبات البنية متعددة اللغات

يستلزم الكشف الفعّال عن البيانات الشخصية في النصوص اليمينية ثلاثة عناصر كثيرًا ما تفتقر إليها الأدوات المُصممة أساسًا للغات الغربية.

معالجة النصوص من اليمين إلى اليسار: الامتثال لمعيار Unicode ثنائي الاتجاه لضمان التدفق الصحيح للنص، وتحليل صرفي يراعي الاتجاه الأيمن يتعرف على حدود الكلمات في النصوص اليمينية.

التعرف على الكيانات المسماة بوعي صرفي: محلل صرفي كـFarasa للعربية، أو نموذج تحويل (transformer) مُضبَّط على بيانات التعرف على الكيانات في النصوص اليمينية، مع ضرورة أن يكون النموذج قد تعلّم التنوعات الصرفية.

أنواع كيانات خاصة بالمنطقة: تستلزم هويات الإمارات وإسرائيل والمملكة العربية السعودية ومصر تعريفات صريحة بقواعد التنسيق الخاصة بكل منها. الأدوات الغربية العامة لا تمتلك هذه التعريفات.

اطلع على كيفية تعامل خط أنابيب التعرف على الكيانات المسماة متعدد اللغات لدينا مع كشف الخط عبر 48 لغة. للاطلاع على القائمة الكاملة لأنواع المعرفات في منطقة الشرق الأوسط وشمال أفريقيا المدعومة، تفضل بزيارة كتالوج الكيانات. يشرح دليل الامتثال للائحة الأوروبية لحماية البيانات كيف تُنشئ فجوات الكشف تعرضًا قانونيًا بموجب المادة 32.

المصادر

هل أنت مستعد لحماية بياناتك؟

ابدأ بإخفاء المعلومات الشخصية مع أكثر من 285 نوع كيان عبر 48 لغة.

About this page

We update this page when our platform or the law changes.

Read our founder note for how we work.

Each change shows up in the timestamp at the top.

Related reading

We follow these rules

  • GDPR (EU 2016/679).
  • ISO/IEC 27001:2022.
  • NIS2 (EU 2022/2555).
  • HIPAA safe harbor under 45 CFR § 164.514(b)(2).

Our promise

We do not sell your data.

We do not train models on your text.

We store your files in Germany.

You can delete your account at any time.

You own your work.

Where we run

Our servers live in Falkenstein, Germany.

We use Hetzner. They hold ISO 27001 certification.

All data stays in the EU.

Backups run every day.

Need help?

Email support@anonym.legal.

We reply within one business day.

How we test

We run a full check suite on every release.

Each surface gets its own sweep script and report.

Human reviewers spot-check the output each week.

We track recall and precision on a labelled set.

Bad runs block the deploy.

What we never do

  • We never sell your information to third parties.
  • We never train models on what you upload.
  • We never keep your work after you delete it.
  • We never share keys with any outside firm.
  • We never run ads inside the product.

Plans in plain words

We sell credits, not seats.

One credit covers one short job.

Long jobs use a few credits each.

You can top up at any time.

Unused credits roll over each month.

Read the plans page for current rates.

Who built this

A small team of engineers and lawyers built this.

We ship from Europe and work in the open.

Our founder note spells out why we started.

Where to start

How the parts fit

A browser add-on cleans text inside Chrome.

A Word plug-in handles drafts in Office.

A small desktop tool works on whole folders.

An agent protocol link feeds large models safely.

All four share one core engine and one rule set.

Words from our team

We started this work after a lunch about cookies.

One friend kept getting odd ads on her phone.

We asked why a court file leaked through a draft.

We sketched the first build on a napkin that week.

By month three we had a tiny demo for a friend.

She used it on her first case the next day.

Common questions we hear

Can the tool read scanned PDFs? Yes, with OCR.

Does it work on long files? Yes, in small chunks.

Can I roll my own rule set? Yes, save it as a preset.

Does it run offline? The desktop build runs offline.

Do you keep my files? No, the cloud build wipes after each run.

Will it learn from my work? No, we never train on inputs.

A short tour of the workflow

Upload a file or paste a snippet of prose.

Pick the entities you want gone from the draft.

Choose a method: replace, mask, hash, encrypt, or redact.

Press run and watch the side panel show each hit.

Skim the result and tweak any rule that misfired.

Save the cleaned file or send it to a teammate.