الدليل الشامل لتطبيق نظام حماية البيانات الشخصية PDPL مع الذكاء الاصطناعي

ما الذي يجعل الذكاء الاصطناعي مختلفًا في PDPL؟

الأنظمة التقليدية غالبًا تتعامل مع حقول واضحة: اسم، رقم جوال، رقم عميل، عنوان، سجل شراء. أما الذكاء الاصطناعي فيتعامل مع نصوص وملفات وسياقات مفتوحة. الموظف قد ينسخ شكوى عميل كاملة في prompt، أو يرفع عقدًا فيه أسماء وأرقام، أو يطلب من النموذج تحليل أداء موظف بناءً على تقرير داخلي. الخطر هنا أن البيانات الشخصية لا تكون دائمًا في حقل اسمه "national_id"، بل قد تكون داخل جملة عادية أو صورة أو مرفق أو مخرج مولد.

لذلك يجب اعتبار كل مكوّن في دورة حياة AI نقطة معالجة محتملة: واجهة المستخدم، طبقة prompt، خدمة البحث الداخلي، مزود النموذج، قاعدة embeddings، سجل المحادثات، مخرجات التلخيص، وملفات الأدلة. إذا لم تكن هذه النقاط واضحة ومربوطة بالغرض، ستصير المؤسسة عاجزة عن الإجابة على أسئلة بسيطة: لماذا عالجنا هذه البيانات؟ هل كان الحد الأدنى كافيًا؟ هل خرجت البيانات خارج المملكة؟ هل يستطيع صاحب البيانات طلب التصحيح أو الإتلاف؟ ومن وافق على استخدام النموذج؟

الأساس النظامي والغرض المحدد قبل النموذج

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

الغرض المحدد يعني أن المؤسسة تستطيع شرح سبب الجمع والاستخدام والحفظ والإفصاح. ويعني أيضًا أن الاستخدام اللاحق للبيانات في تدريب نموذج أو تحسين منتج أو مشاركة مع مزود خارجي يحتاج مراجعة مستقلة، لأن الغرض الجديد قد لا يكون متوافقًا مع الغرض الأصلي. في الذكاء الاصطناعي، "تحسين النموذج" ليست عبارة كافية وحدها؛ يجب تحديد ما الذي سيتحسن، لماذا، ما البيانات اللازمة، وما البديل الأقل تدخلًا في الخصوصية.

تقليل البيانات وحماية البيانات الشخصية في AI

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

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

حقوق صاحب البيانات داخل أنظمة AI

حقوق صاحب البيانات لا تختفي لأن المعالجة تمت عبر نموذج. يجب أن يكون لدى المؤسسة مسار عملي للتعامل مع طلب العلم، الوصول، التصحيح، الحصول على البيانات بصيغة واضحة، الإتلاف عند تحقق شروطه، وسحب الموافقة عندما تكون الموافقة هي الأساس. التحدي في AI أن البيانات قد تظهر في أكثر من مكان: prompt، سجل محادثة، قاعدة بحث، ملف مرفق، تقرير مولد، أو سجل تدقيق. لذلك يجب أن يكون تصميم النظام قادرًا على البحث عن آثار البيانات ومعرفة ما يمكن تصحيحه أو إتلافه وما يجب الاحتفاظ به لالتزام نظامي.

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

تقييم الأثر ومصفوفة مخاطر AI

تقييم الأثر مطلوب عمليًا عندما تكون المعالجة واسعة أو حساسة أو عالية التأثير. في مشاريع AI، استخدم تقييمًا مبكرًا قبل الإنتاج، ثم حدّثه عند تغيير النموذج أو المورد أو نوع البيانات أو نطاق الاستخدام. التقييم الجيد لا يكتفي بوصف المخاطر؛ يربط كل خطر بضابط، مالك، دليل، وتاريخ مراجعة. بهذا الأسلوب يستطيع فريق الامتثال متابعة التنفيذ بدل الاكتفاء بتقرير جميل لا يغير طريقة العمل.

الموردون والمعالجون والنقل خارج المملكة

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

في العقود، انتبه لعبارات مثل "قد نستخدم بياناتك لتحسين خدماتنا" أو "نحتفظ بالسجلات حسب الحاجة". هذه عبارات واسعة جدًا إذا كانت prompts تحتوي بيانات شخصية. المطلوب أن تكون الشروط قابلة للتنفيذ: منع التدريب على بيانات المؤسسة، تحديد مواقع المعالجة، حذف السجلات خلال مدة واضحة، تمكين طلبات الحذف، إخطار خرق البيانات بدون تأخير غير مبرر، وتقديم تقارير امتثال أو شهادات أمنية عند الحاجة.

خطة تطبيق خلال 90 يومًا

آلية التحديث التلقائي عند تغير الأنظمة

هذه الصفحة تحتوي كتلة Regulatory Watch تربط المحتوى بالمصادر الرسمية المحددة أعلاه. عند تشغيل فحص النشر أو المراجعة الدورية، تتم مقارنة عناصر مهمة مثل تاريخ التحديث الرسمي، رقم الإصدار، عنوان الوثيقة، والمواد ذات الصلة. إذا تغيرت إحدى هذه الإشارات، يجب فتح تذكرة مراجعة للمحتوى وتحديث dateModified والسكيما والجداول التي تأثرت بالتغيير. هذه الطريقة تمنع الاعتماد على ذاكرة بشرية فقط، وتحوّل تحديث الأنظمة إلى إجراء واضح داخل دورة النشر.

الإشارات التي يجب مراقبتها في PDPL تحديدًا: تحديث اللائحة التنفيذية، تحديث قواعد مسؤول حماية البيانات، صدور إرشادات جديدة للتقليل أو الإتلاف أو النقل، أو تغير تعليمات البلاغات والحوادث. أي تغيير في هذه الإشارات يجب أن ينعكس على بطاقات الاستخدام، عقود المعالجين، سجلات أنشطة المعالجة، وخطة الاستجابة للحوادث.

ملحق تنفيذي: سجل أنشطة المعالجة الخاص بالذكاء الاصطناعي

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

في كل بطاقة استخدام، أضف سؤالين مهمين: هل يستطيع النموذج أو المزود الاحتفاظ بالمدخلات أو استخدامها لتحسين الخدمة؟ وهل يمكن حذف أثر البيانات عند طلب الإتلاف أو عند انتهاء الغرض؟ إذا كانت الإجابة غير واضحة، فلا تشغل الحالة على بيانات شخصية حتى تكتمل مراجعة المورد. هذه ليست مبالغة؛ لأن كثيرًا من مخاطر GenAI تظهر من شروط الخدمة والإعدادات الافتراضية وليس من كود المؤسسة نفسه.

سيناريوهات قابلة للاقتباس لفرق الامتثال

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

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

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

سيناريو RAG الداخلي: عندما يستخدم الموظف مساعدًا يبحث في وثائق المؤسسة، يجب أن تكون نتيجة البحث مقيدة بصلاحيات الموظف. لا يكفي أن يكون الموظف داخل الشبكة. إذا لم يكن يملك حق قراءة مستند الرواتب أو الشكاوى أو العقود، يجب ألا يستطيع المساعد استرجاع مقتطف منها. اختبر النظام بسيناريوهات adversarial مثل سؤال غير مباشر يحاول كشف مستند حساس.

قائمة مراجعة قبل الإطلاق

1. هل توجد بطاقة استخدام مكتملة لكل تطبيق AI يتعامل مع بيانات شخصية؟
2. هل تم تحديد الغرض والأساس النظامي وفئات البيانات ومكان المعالجة؟
3. هل يمنع النظام إدخال بيانات حساسة أو معرفات مباشرة عند عدم الحاجة؟
4. هل توجد مراجعة بشرية للسيناريوهات التي تؤثر على فرد أو حق أو مصلحة؟
5. هل عقود الموردين تمنع التدريب على بيانات المؤسسة أو تضبطه بوضوح؟
6. هل يمكن تنفيذ طلبات صاحب البيانات على السجلات والمخرجات ذات الصلة؟
7. هل خطة الحوادث تشمل تسريب prompt أو إرسال بيانات لمورد غير معتمد؟
8. هل تم اختبار الإخفاء والاسترجاع والصلاحيات بعينات واقعية قبل الإنتاج؟
9. هل يوجد ملف أدلة يثبت كل ما سبق بدون الرجوع إلى رسائل شخصية أو ذاكرة الفريق؟