قانون حماية البيانات الشخصية المصري رقم 151 لسنة 2020 وحوكمة الذكاء الاصطناعي

لماذا يعتبر PDPL مهماً لحوكمة AI؟

صدر قانون حماية البيانات الشخصية رقم 151 لسنة 2020 لتنظيم حماية البيانات الشخصية المعالجة إلكترونياً في مصر.

القانون ليس تشريعاً خاصاً بالذكاء الاصطناعي.

لكن كثيراً من أنظمة AI تعتمد على بيانات تتعلق بأشخاص طبيعيين.

لذلك يمكن أن يصبح PDPL واحداً من أهم القوانين التي يجب تحليلها عند تقييم AI use case.

AI Governance وData Protection ليسا الشيء نفسه

قد يكون النظام:

• technically robust.
• explainable.
• fair according to internal tests.
• aligned with AI governance guidelines.

ومع ذلك تكون طريقة جمع أو معالجة البيانات غير متوافقة مع متطلبات حماية البيانات.

وبالعكس، قد تكون معالجة البيانات قانونية بينما النظام نفسه يحمل مخاطر AI أخرى.

لذلك يجب تشغيل المسارين معاً.

ما هي البيانات الشخصية؟

المفهوم الأساسي هو البيانات التي ترتبط بشخص طبيعي محدد أو يمكن التعرف عليه.

في AI، المشكلة تصبح أكثر تعقيداً لأن النظام قد لا يستخدم الاسم مباشرة.

قد تستخدم المؤسسة:

• identifiers.
• behavior.
• location.
• device data.
• transactions.
• usage patterns.
• voice.
• images.
• profiles.
• inferred characteristics.

قد تسمح هذه البيانات بالتعرف على الشخص بصورة مباشرة أو غير مباشرة بحسب السياق.

البيانات المستنتجة

أحد أصعب تحديات AI هو أن النظام قد ينتج معلومات لم يقدمها الفرد مباشرة.

مثلاً قد يستنتج:

• تفضيلاً.
• سلوكاً.
• احتمالاً.
• فئة.
• مستوى مخاطر.
• علاقة.
• نمطاً.

وجود inference لا يخرج المعالجة تلقائياً من نطاق حماية البيانات إذا بقيت النتيجة مرتبطة بشخص طبيعي قابل للتحديد.

Data Subject

صاحب البيانات هو الشخص الطبيعي الذي تتعلق به البيانات.

من الخطأ تصميم نظام AI وكأن dataset هي مجرد asset تقنية منفصلة عن الأشخاص.

وراء كثير من records أفراد لهم حقوق ومصالح قانونية.

Controller

المتحكم هو الجهة التي تحدد أغراض ووسائل معالجة البيانات.

في مشروع AI قد يكون المتحكم مثلاً المؤسسة التي تقرر:

• لماذا تجمع البيانات.
• لماذا تستخدم النموذج.
• من هم الأشخاص المستهدفون.
• ما القرار الذي سيدعمه النظام.
• مدة الاحتفاظ.
• من يمكنه الوصول.

وجود مزود AI خارجي لا ينقل تلقائياً مسؤولية المتحكم إليه.

Processor

المعالج ينفذ معالجة للبيانات لصالح المتحكم أو بناء على تعليماته ضمن العلاقة المنظمة بينهما.

في AI ecosystems قد تظهر processors متعددة:

• cloud provider.
• model provider.
• data labeling company.
• analytics provider.
• managed service provider.
• hosting provider.

لكن توصيف كل طرف يجب أن يتم بناء على دوره الحقيقي وليس اسمه التجاري.

Data Holder

تتضمن المنظومة المصرية أيضاً مفهوم حائز البيانات.

هذا يوسع أهمية فهم من يمتلك أو يحتفظ بالبيانات فعلياً عبر سلسلة AI.

فقد توجد نسخة لدى:

• المؤسسة.
• المورد.
• cloud.
• backup service.
• logging platform.
• observability provider.

الأساس القانوني للمعالجة

بحسب مركز حماية البيانات الشخصية، لا تكون المعالجة مشروعة لمجرد أنها مفيدة تجارياً أو تقنياً.

يجب أن تقوم على أساس مشروع معترف به.

يذكر المركز أسساً مثل:

• consent.
• contractual necessity.
• legal obligation.
• تنفيذ حكم أو أمر ذي صلة.
• exercise or defence of legal rights.
• legitimate interests ضمن حدود حقوق وحريات صاحب البيانات.
• بعض الأغراض الإحصائية أو التعليمية غير الربحية وفق الضوابط.

لا ينبغي اختيار lawful basis بعد تشغيل النظام لتبرير ما تم فعله.

يجب تحديده قبل المعالجة.

Consent ليس الحل الدائم لكل شيء

من الأخطاء الشائعة اعتبار consent زر قبول يمكن استخدامه لأي مشروع AI.

الموافقة يجب أن تكون صحيحة في السياق القانوني وأن تتوافق مع الغرض.

كما أن الاعتماد على consent قد يخلق تحديات تشغيلية مثل:

• withdrawal.
• purpose changes.
• retraining.
• derived datasets.
• downstream processing.

لذلك يجب اختيار الأساس القانوني المناسب فعلاً، لا الأسهل شكلياً.

Purpose Limitation

من منظور الحوكمة، من الضروري تحديد لماذا جُمعت البيانات ولماذا ستستخدم.

مثال:

بيانات جُمعت لتقديم خدمة معينة لا ينبغي افتراض إمكانية استخدامها تلقائياً لتدريب نموذج جديد لغرض مختلف.

يجب تحليل الغرض الجديد والأساس القانوني والمتطلبات ذات الصلة.

Data Minimization

AI teams تميل أحياناً إلى منطق:

“كلما زادت البيانات تحسن النموذج.”

هذا المنطق لا يمكن أن يكون مبرراً وحيداً لجمع كل شيء.

الحوكمة الناضجة تسأل:

• ما البيانات الضرورية؟
• لماذا؟
• ما القيمة الإضافية؟
• ما المخاطر؟
• هل يمكن إزالة fields؟
• هل يمكن استخدام aggregation؟
• هل توجد بدائل أقل تدخلاً؟

Retention

الاحتفاظ بالبيانات يجب أن يكون مرتبطاً بالغرض والحاجة القانونية والتشغيلية.

في AI يجب التفريق بين:

• raw data.
• training data.
• validation data.
• prompts.
• outputs.
• logs.
• embeddings.
• backups.
• fine-tuning datasets.

حذف record من قاعدة التشغيل لا يعني بالضرورة أنه اختفى من كل هذه الطبقات.

AI Logs

Logging ضروري للمساءلة لكنه قد يصبح بحد ذاته مستودع بيانات شخصية.

مثلاً قد تحتوي logs على:

• prompts.
• names.
• IDs.
• documents.
• model outputs.
• system events.

لذلك يجب أن تخضع logging architecture نفسها لمراجعة حماية البيانات.

البيانات الحساسة

بعض أنواع البيانات تحتاج حماية أعلى.

بالنسبة لـAI، المخاطر لا تأتي فقط من جمع sensitive data مباشرة.

قد ينشئ model inference يؤدي عملياً إلى معلومات شديدة الحساسية.

لهذا يجب أن يغطي Data Protection Impact Analysis ليس فقط input fields بل outputs والاستنتاجات.

DPO

يحدد الإطار المصري دور مسؤول حماية البيانات داخل الجهات المعنية وفق القواعد المنظمة.

يوضح مركز حماية البيانات أن DPO يؤدي دوراً في:

• مراقبة الامتثال.
• متابعة الإجراءات الداخلية.
• التعامل مع طلبات أصحاب البيانات.
• العمل باستقلالية ضمن الوظائف المحددة.
• التسجيل في السجل المخصص لدى المركز بحسب المتطلبات.

في مشاريع AI لا ينبغي إشراك DPO فقط عند نهاية procurement.

يجب إشراك وظيفة حماية البيانات في مرحلة design.

PDPC

مركز حماية البيانات الشخصية هو الجهة الوطنية المختصة بإنفاذ وتطوير إطار حماية البيانات.

تشمل وظائفه بحسب مواده الإرشادية:

• إصدار قرارات وإرشادات.
• التراخيص والتصاريح.
• تسجيل DPOs.
• التفتيش والإشراف.
• تلقي الشكاوى.
• التنسيق.
• التوعية وبناء القدرات.

AI Vendor Due Diligence

عند استخدام مزود AI خارجي، لا يكفي سؤال المورد عن الأمن فقط.

يجب فحص:

• دوره القانوني.
• processing purpose.
• data location.
• subprocessors.
• retention.
• model training use.
• deletion.
• incident handling.
• cross-border transfers.
• access controls.
• audit evidence.

هل يستخدم المورد بياناتك لتدريب نموذج عام؟

هذا السؤال أصبح مهماً جداً.

إذا كان المورد يستطيع استخدام prompts أو uploaded data أو outputs في التدريب أو تحسين خدماته، فقد تتغير خريطة المعالجة والأغراض والأطراف.

لا تعتمد على افتراض.

يجب توثيق السياسة والعقد والإعدادات التقنية.

Cross-Border Data Transfer

نقل البيانات الشخصية خارج مصر يحتاج إلى تحليل مستقل وفق القانون واللائحة التنفيذية والضوابط الصادرة عن المركز.

في AI، يمكن أن يحدث النقل بدون أن يراه المستخدم بوضوح.

مثال:

واجهة المستخدم في القاهرة، لكن:

• inference في منطقة cloud خارجية.
• telemetry في دولة أخرى.
• backup في منطقة ثالثة.
• support access من دولة رابعة.

لذلك يجب رسم Data Flow فعلي.

Data Flow Mapping

[ممارسة تنفيذية]

لكل AI system ارسم المسار:

Data Subject → Collection → Internal Systems → AI Application → Model/API → Cloud/Hosting → Logs → Monitoring → Backup → Subprocessors → Output → Retention/Deletion

ثم اربط كل انتقال بـ:

• purpose.
• lawful basis.
• actor.
• jurisdiction.
• retention.
• security.
• contractual control.

Shadow AI

Shadow AI قد يخلق خرقاً لحوكمة البيانات حتى لو كان الموظف يستخدم أداة مفيدة.

مثلاً قد يضع الموظف داخل chatbot:

• بيانات عملاء.
• عقود.
• معلومات موظفين.
• سجلات طبية.
• تقارير داخلية.

بدون معرفة:

• أين تذهب البيانات.
• هل تحفظ.
• هل تستخدم للتدريب.
• من يستطيع الوصول إليها.

لذلك Acceptable Use Policy يجب أن ترتبط بمتطلبات PDPL.

Generative AI

GenAI يزيد التعقيد بسبب:

• prompts.
• uploaded documents.
• long context.
• memory.
• retrieval systems.
• vector databases.
• generated content.
• model training.

كل طبقة قد تنتج processing activity مختلفة.

Embeddings

تحويل النص إلى embedding لا يعني تلقائياً أن البيانات أصبحت anonymous.

إذا بقي بالإمكان ربط embedding أو النظام الناتج بشخص أو استرجاع معلومات عنه، يجب عدم افتراض خروجه من نطاق حماية البيانات دون تقييم حقيقي.

RAG

في Retrieval-Augmented Generation، المخاطر قد تأتي من repository وليس model نفسه.

قد يسترجع النظام بيانات مستخدم لشخص غير مخول بالوصول إليها.

لذلك يجب تطبيق:

• authorization.
• document-level access.
• tenant isolation.
• filtering.
• logging.
• testing.

Automated Decisions

أنظمة AI التي تؤثر في الأشخاص تتطلب اهتماماً أكبر بالشفافية والمساءلة والحقوق.

يجب ألا تختزل المؤسسة القضية إلى accuracy.

اسأل أيضاً:

• هل يعرف الفرد أن AI مستخدم؟
• هل يستطيع الاعتراض؟
• هل يوجد human review مناسب؟
• هل المخرجات explainable؟
• هل هناك bias؟
• هل البيانات صحيحة؟
• كيف يصحح الفرد بياناته؟

Privacy Notice

الشفافية تحتاج إلى Privacy Notice تعكس الواقع الفعلي.

لا تستخدم notice عامة تقول:

“قد نستخدم تقنيات حديثة.”

إذا كان AI جزءاً جوهرياً من المعالجة، يجب أن يكون وصف المعالجة مفهوماً ومناسباً للغرض القانوني.

Security

حماية البيانات في AI تشمل أكثر من encryption.

يجب فحص:

• access control.
• secrets.
• API keys.
• model endpoints.
• prompt injection.
• data leakage.
• insecure RAG.
• excessive logging.
• unauthorized model access.
• export/download controls.

Breach Governance

Incident response يجب أن يربط فرق:

• security.
• privacy.
• legal.
• AI owner.
• vendor management.
• communications.

لأن حادث AI قد يكون في الوقت نفسه:

• cybersecurity incident.
• personal data incident.
• model failure.
• vendor incident.

Records of Processing

منظومة AI الناضجة يجب أن تكون قابلة للتتبع ضمن سجل أنشطة المعالجة والوثائق التنظيمية ذات الصلة.

لا يكفي أن يعرف فريق ML كيف يعمل النظام بينما لا توجد صورة مؤسسية واضحة لمعالجة البيانات.

Privacy by Design

أفضل وقت لحل مشكلة الخصوصية هو قبل بناء النظام.

تشمل الأسئلة المبكرة:

• هل نحتاج personal data أصلاً؟
• هل يمكن استخدام synthetic data؟
• هل يمكن تقليل fields؟
• هل يمكن local processing؟
• هل يمكن تقليل retention؟
• هل يمكن pseudonymize؟
• هل يمكن منع prompts الحساسة؟

العلاقة مع National AI Governance Framework

إطار AI الوطني وقانون حماية البيانات لا يتنافسان.

كل واحد يعالج زاوية مختلفة.

قد يتطلب AI Framework:

• risk assessment.
• oversight.
• technical assurance.
• accountability.

بينما PDPL يعالج:

• lawful processing.
• data subject rights.
• controllers/processors.
• privacy obligations.
• transfer.
• protection.

المؤسسة تحتاج الاثنين.

AI Privacy Compliance Gate

قبل Go-Live لنظام يستخدم personal data، يجب ألا تكون الموافقة سؤالاً واحداً.

يفضل وجود gate يتأكد من:

1. Data inventory.
2. Purpose.
3. Lawful basis.
4. Controller/processor roles.
5. Vendor assessment.
6. Transfer analysis.
7. Retention.
8. Security.
9. Data subject transparency.
10. Rights handling.
11. DPO review.
12. Logging.
13. deletion.
14. monitoring.

الخلاصة

قانون حماية البيانات الشخصية ليس ملحقاً ثانوياً لمشروع AI.

إذا كان النظام يتعامل مع بيانات مرتبطة بأفراد، فإن حماية البيانات تصبح جزءاً من architecture نفسها.

السؤال الصحيح ليس:

“هل نموذجنا compliant؟”

بل:

هل كامل دورة البيانات التي تسمح للنموذج بالعمل متوافقة وقابلة للإثبات والمراجعة؟