ذكاء اصطناعي مؤسسي متوافق مع GDPR: حدود البيانات في أنظمة RAG والوكلاء

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

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

لماذا تصبح GDPR موضوع تصميم مستقلا في مشاريع الذكاء الاصطناعي؟

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

لذلك تبقى المبادئ الأساسية في المادة 5 من GDPR كما هي، لكن تطبيقها يصبح أصعب:

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

ما المحطات التي تمر بها البيانات في نظام RAG؟

يبدأ أمن RAG المؤسسي برسم رحلة البيانات محطة بمحطة. في تدفق RAG النموذجي خمس محطات، لكل منها خطرها الخاص.

1. النظام المصدر: حيث توجد المستندات (خادم ملفات، نظام إدارة مستندات، CRM، أرشيف بريد). الخطر: إدخال مستندات خارج النطاق دفعة واحدة.
2. التحضير والتقسيم: حيث تحول المستندات إلى نص وتقسم. الخطر: معالجة البيانات الشخصية دون إخفاء.
3. التضمين وقاعدة المتجهات: حيث تحول المقاطع إلى متجهات وتخزن. الخطر: أن يكون نموذج التضمين واجهة برمجية خارجية، وأن تخزن المقاطع دون بيانات وصفية عن الصلاحيات.
4. الاسترجاع وتجميع الموجه: حيث تختار المقاطع لسؤال المستخدم وترسل إلى النموذج. الخطر: تسرب مقاطع لا يحق للمستخدم رؤيتها إلى الإجابة.
5. النموذج والتسجيل: حيث تولد الإجابة ويسجل الموجه والإجابة. الخطر: الاحتفاظ بالسجلات بلا حد زمني واستخدام المزود للبيانات لأغراضه الخاصة.

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

هل يعد إرسال البيانات إلى مزود النموذج نقلا إلى بلد ثالث؟

إذا أرسل موجه يحتوي على بيانات شخصية إلى مزود نموذج يعالجه خارج الاتحاد الأوروبي والمنطقة الاقتصادية الأوروبية، فهذا يعد في الغالب نقلا إلى بلد ثالث بموجب الفصل الخامس من GDPR (المواد 44 إلى 49). ويحتاج النقل إلى مسار قانوني. أولها قرار كفاية تصدره المفوضية الأوروبية بشأن بلد الوجهة. وبالنسبة للولايات المتحدة، يوفر إطار خصوصية البيانات بين الاتحاد الأوروبي والولايات المتحدة (EU-US Data Privacy Framework) مسار كفاية للمزودين المعتمدين ضمنه، وقد طعن فيه أمام القضاء، لذا تحققوا من وضعه الحالي مع مستشاركم بدل اعتباره دائما. وعند غياب قرار الكفاية تلزم ضمانات مناسبة، أكثرها شيوعا البنود التعاقدية القياسية الصادرة عن المفوضية (SCC) مع تقييم أثر النقل، أو قواعد الشركات الملزمة داخل المجموعة. أما الاستثناءات في المادة 49 فهي ضيقة ولا تصلح أساسا للمعالجة الروتينية.

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

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

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

كيف تنقون البيانات الشخصية قبل التضمين؟

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

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

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

كيف تطبق صلاحيات الوصول لحظة الاسترجاع؟

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

النهج الصحيح هو تطبيق الصلاحيات أثناء الاسترجاع لا بعد توليد الإجابة:

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

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

كيف يرسم حد البيانات في أنظمة الوكلاء؟

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

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

كيف تحدد السجلات ومدد الاحتفاظ؟

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

يبدو النهج المتوازن هكذا:

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

متى يكون تشغيل النماذج مفتوحة الأوزان على خوادمكم منطقيا؟

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

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

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

كيف تقيمون المخاطر قبل بدء المشروع؟

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

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

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

قائمة تحقق للذكاء الاصطناعي المتوافق مع GDPR

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

أسئلة شائعة

هل يعد إرسال بيانات شخصية إلى ChatGPT أو واجهة برمجية مشابهة مخالفة لـ GDPR؟ ليس بحد ذاته. تحتاجون إلى أساس قانوني، وعقد مع المعالج بموجب المادة 28، وإذا كان المزود يعالج البيانات خارج الاتحاد الأوروبي والمنطقة الاقتصادية الأوروبية فإلى مسار نقل صالح بموجب الفصل الخامس. وينبغي تثبيت طريقة معالجة المزود للبيانات وتخزينها في العقد. تحققوا من حالتكم مع مستشاركم القانوني.

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

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

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

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