قانون حماية البيانات الشخصية البحريني وحوكمة الذكاء الاصطناعي: من البيانات إلى القرار الآلي

لماذا قانون حماية البيانات مهم لأنظمة AI؟

صدر قانون حماية البيانات الشخصية رقم 30 لسنة 2018 في مملكة البحرين ليضع إطارًا قانونيًا لمعالجة البيانات الشخصية وحمايتها.

AI لا يعمل خارج هذا الإطار لمجرد أن المعالجة تتم بواسطة model.

إذا كانت البيانات شخصية، فإن السؤال القانوني يبقى متعلقًا بـ:

• من يحدد الغرض؟
• لماذا تتم المعالجة؟
• من يحصل على البيانات؟
• ما الضوابط؟
• ما مدة الاحتفاظ؟
• من المورد؟
• أين تتم المعالجة؟
• كيف يتم تأمين البيانات؟

النموذج ليس نقطة البداية

الخطأ الشائع هو البدء من سؤال:

أي model نستخدم؟

Privacy governance تبدأ قبل ذلك.

ابدأ من:

Use Case → Data → Purpose → Roles → Flows → Controls

ثم انظر إلى النموذج.

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

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

أمثلة:

• user prompts.
• uploaded documents.
• chat history.
• recordings.
• support transcripts.
• account metadata.
• behavioral analytics.
• logs.
• embeddings.
• vector stores.
• model outputs.

Controller وProcessor

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

في AI cloud ecosystem قد يكون لدينا:

Organization → AI Vendor → Cloud Provider → Subprocessor

وهنا لا يكفي معرفة اسم vendor الأول فقط.

اختيار المعالج

القانون يفرض على المتحكم اختيار معالج يوفر ضمانات كافية بشأن التدابير التقنية والتنظيمية المناسبة.

هذا يعني أن Procurement لا يستطيع أن ينظر فقط إلى:

• السعر.
• features.
• performance.

يجب أيضًا تقييم:

• security.
• confidentiality.
• access.
• subprocessors.
• operational controls.

العقد مع المعالج

المعالجة بواسطة processor ترتبط أيضًا بعلاقة تعاقدية تحدد عمله وفق تعليمات المتحكم والتزامه بمتطلبات الحماية ذات الصلة.

في AI يجب أن يجيب العقد عن أسئلة عملية:

• هل يستخدم المورد البيانات للتدريب؟
• هل يستطيع الاحتفاظ بها؟
• ما مدة retention؟
• من subprocessors؟
• كيف نحذف البيانات؟
• كيف يبلغ عن incident؟
• ما الذي يحدث بعد termination؟

Technical and Organizational Measures

قانون البحرين يفرض تدابير تقنية وتنظيمية مناسبة لحماية البيانات من مخاطر مثل الفقد أو التدمير أو الوصول أو الإفصاح غير المصرح به.

AI يزيد تعقيد هذه التدابير لأن البيانات قد تنتقل بين:

• application.
• model endpoint.
• retrieval layer.
• logs.
• observability.
• storage.
• backup.
• support.

Data Flow Mapping

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

أنشئ لكل AI system Data Flow Map يوضح:

1. مصدر البيانات.
2. نوع البيانات.
3. الغرض.
4. الأنظمة التي تمر بها.
5. الموردين.
6. مواقع المعالجة.
7. مدة الاحتفاظ.
8. نقاط الحذف.

بدون هذا الرسم، Privacy Review تكون تخمينية.

Purpose Limitation

إذا جُمعت البيانات لغرض معين، ثم أرادت المؤسسة استخدامها لاحقًا لتدريب model، فهذه ليست بالضرورة مجرد "إعادة استخدام تقنية".

يجب إعادة تقييم الغرض والأساس والضوابط.

Data Minimization

AI teams تميل أحيانًا إلى الاحتفاظ بكل البيانات "لأنها قد تكون مفيدة".

هذه ممارسة ضعيفة.

كل بيانات إضافية تعني:

• مخاطر أكبر.
• مساحة هجوم أكبر.
• retention burden أكبر.
• تعقيد أكبر عند deletion.

Training Data

افحص training dataset من حيث:

• provenance.
• personal data.
• sensitivity.
• quality.
• labeling.
• duplication.
• retention.

Fine-Tuning

Fine-tuning على بيانات المؤسسة قد ينشئ نسخة جديدة من المعلومات داخل artifacts أو checkpoints أو datasets.

لذلك يجب توثيق lifecycle بدقة.

Inference Data

حتى إذا كان model لم يُدرب على بيانات المؤسسة، prompts نفسها قد تحتوي على بيانات شخصية.

هذا شائع جدًا في:

• customer service.
• HR.
• legal.
• medical support.
• document summarization.

Prompt Logging

قد يقوم provider أو التطبيق بحفظ:

• prompt.
• output.
• timestamp.
• identifiers.
• attachments.
• errors.

يجب معرفة ما الذي يسجل فعلًا.

Embeddings

الـembedding ليس نسخة نصية تقليدية من الوثيقة، لكنه مشتق منها.

لذلك deletion architecture يجب ألا تقتصر على حذف الملف الأصلي.

Vector Stores

في أنظمة RAG، يجب فحص:

• tenant isolation.
• authorization.
• deletion.
• stale data.
• backup copies.

RAG Authorization

المستخدم الذي يستطيع الوصول إلى chatbot لا يجب أن يستطيع تلقائيًا استرجاع كل وثيقة داخل knowledge base.

التحقق يجب أن يحدث عند retrieval layer أيضًا.

Sensitive Data

كلما ارتفعت حساسية البيانات، ارتفعت الحاجة إلى:

• stronger controls.
• restricted access.
• encryption.
• logging.
• monitoring.
• review.

Automated Decisions

إذا كان AI يدخل في قرار مؤثر على فرد، ترتفع أهمية:

• accountability.
• transparency.
• explainability.
• human review.
• auditability.

لا يعني ذلك أن القانون البحريني أنشأ تلقائيًا حقًا منفصلًا يسمى "AI explanation right"، لكن القرار المؤثر يبرر مستوى أعلى من الحوكمة.

Human Oversight

المراجع البشري يجب أن يكون قادرًا على:

• فهم سياق القرار.
• الاعتراض.
• التصحيح.
• التصعيد.
• توثيق السبب.

Privacy by Design

Privacy by Design تعني معالجة أسئلة الخصوصية قبل اختيار architecture النهائية.

مثلاً:

هل نحتاج إرسال المستند كاملًا إلى model خارجي؟

أم يمكن استخراج حقول محددة محليًا؟

هل نحتاج الاحتفاظ بالprompt؟

هل يمكن pseudonymization؟

Cross-Border Processing

AI cloud قد ينقل البيانات عبر أكثر من jurisdiction.

لا تستخدم اسم region التسويقي وحده.

تحقق من:

• inference region.
• logging region.
• storage.
• backup.
• support access.
• subprocessors.

Vendor Due Diligence

اسأل المزود عن:

• Security Certifications.
• Data Use.
• Retention.
• Training.
• Encryption.
• Access.
• Subprocessors.
• Incident Handling.
• Deletion.
• Exit.

Subprocessor Risk

المورد قد يستخدم طرفًا ثالثًا لتقديم:

• cloud.
• monitoring.
• support.
• security.
• analytics.

المؤسسة يجب أن تعرف السلسلة التي تمس البيانات.

Confidentiality

القانون يفرض متطلبات تتعلق بسرية المعالجة وعدم استخدام البيانات خارج الحدود المسموحة.

وهذا مهم في AI عندما يتمكن موظف أو contractor أو support engineer من الوصول إلى prompts أو logs.

Access Control

طبق Least Privilege على:

• application users.
• admins.
• developers.
• vendors.
• support.
• service accounts.

Machine Identities

AI agents وpipelines تستخدم service identities.

يجب إدارتها مثل المستخدمين:

• authentication.
• scoped permissions.
• rotation.
• logging.
• revocation.

Security Testing

Privacy تعتمد على الأمن.

اختبر:

• data leakage.
• prompt injection.
• unauthorized retrieval.
• access bypass.
• exposed storage.
• insecure APIs.

Retention

حدد retention بصورة منفصلة لـ:

• raw data.
• training data.
• prompts.
• outputs.
• logs.
• embeddings.
• backups.

لا تستخدم retention واحدًا لكل شيء.

Deletion

يجب معرفة ما معنى delete تقنيًا.

قد توجد نسخة في:

• primary database.
• cache.
• vector store.
• backup.
• vendor system.

Backups

الحذف الفوري من production لا يعني الحذف الفوري من backup.

وثق دورة انتهاء النسخ الاحتياطية.

Incident Response

إذا أدى AI إلى كشف بيانات أو وصول غير مصرح به، يجب ألا يبقى الحادث داخل فريق AI.

اربطه بمسار:

Security + Privacy + Legal + Business

بحسب طبيعة الحالة.

Privacy Incident Evidence

احتفظ بمعلومات عن:

• ما حدث؟
• متى؟
• ما البيانات؟
• من تأثر؟
• ما النظام؟
• ما المورد؟
• ما الإجراء؟
• هل تم الاحتواء؟

DPIA كأداة داخلية

حتى عندما لا نستخدم مصطلح DPIA باعتباره متطلبًا قانونيًا عامًا لكل AI system، فإن إجراء تقييم أثر خصوصية منظم للاستخدامات الحساسة يساعد المؤسسة على إثبات أنها فحصت المخاطر قبل النشر.

High-Impact AI

الاستخدامات التي تستحق Privacy Review أقوى تشمل:

• biometrics.
• employee monitoring.
• customer profiling.
• eligibility.
• scoring.
• identity verification.
• large-scale analytics.

Data Provenance

اعرف:

• من أين جاءت البيانات؟
• متى؟
• بأي غرض؟
• من عدلها؟
• أي version استخدم؟

هذا ضروري للتحقيق وإعادة الإنتاج.

Model Outputs as Personal Data

في بعض الحالات قد يحتوي output نفسه على بيانات شخصية أو استنتاجات مرتبطة بفرد.

لذلك لا تركز على inputs فقط.

Hallucinated Personal Data

GenAI قد ينتج معلومة غير صحيحة عن شخص.

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

Privacy Monitoring

بعد Go-Live راقب:

• data leakage.
• unusual access.
• excessive retrieval.
• complaints.
• deletion failures.
• vendor changes.

Change Management

أعد Privacy Review عند:

• provider change.
• new subprocessor.
• new dataset.
• new use.
• new user population.
• new region.
• new model behavior.

Evidence Pack

احتفظ بـ:

1. Use Case.
2. Data Inventory.
3. Data Flow.
4. Roles.
5. Purpose.
6. Security Controls.
7. Vendor Assessment.
8. Contracts.
9. Retention.
10. Deletion Design.
11. Risk Assessment.
12. Approvals.
13. Monitoring.
14. Incidents.
15. Changes.

نموذج عملي قبل Go-Live

قبل تشغيل AI system يعالج بيانات شخصية:

• أكد الـOwner.
• صنف البيانات.
• ارسم التدفق.
• حدد الموردين.
• راجع العقود.
• راجع security.
• حدد retention.
• اختبر access control.
• اختبر deletion.
• حدد escalation.
• وثق approval.

العلاقة مع سياسة AI الوطنية

السياسة الوطنية تضيف طبقة حوكمة مسؤولة وآمنة.

وقانون حماية البيانات يضيف طبقة قانونية لحماية البيانات الشخصية.

لا ينبغي دمجهما فكريًا حتى يصبحا شيئًا واحدًا.

الأفضل هو:

AI Governance + Privacy Governance + Cybersecurity

تعمل معًا داخل lifecycle واحد.

الخلاصة

أصعب جزء في خصوصية AI ليس معرفة أن البيانات "حساسة"، بل معرفة أين توجد كل نسخة منها، ولماذا تعالج، ومن يصل إليها، ومن يملك قرار الاحتفاظ أو الحذف.

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