اللائحة العامة لحماية البيانات (GDPR) والقرارات الآلية في الذكاء الاصطناعي المالي

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

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

ما الذي يُعدّ قرارًا آليًا

العبارة التي تحمل ثقل المعنى هي “مبني حصريًا على المعالجة الآلية” مقترنةً بـ “آثار قانونية” أو آثار “تمسّ الشخص على نحو مماثل في أهميته”. فرفض قرض، أو إغلاق حساب، أو تجميد دفعة، أو تسعير تأمين، أو تقديم بلاغ عن نشاط مشبوه (suspicious activity report) يؤدي إلى إنهاء التعامل مع شخص: كل هذه تتجاوز عتبة الأهمية دون جدال يُذكر. أما درجة الاحتيال (fraud score) التي تكتفي بترتيب طابور مراجعة يدوية فلا تتجاوزها عادةً، لأن هناك شخصًا لا يزال يتخذ القرار.

الفخّ يكمن في كلمة “حصريًا”. فوجود موظف بشري ضمن الحلقة (human in the loop) لا يُخرجك من نطاق المادة 22 إلا إذا كان هذا الموظف يقرر فعلًا. وقد جسّدت محكمة العدل الأوروبية (CJEU) هذا المبدأ في حكم SCHUFA (القضية C-634/21، ديسمبر 2023): إذ يمكن أن تُشكّل درجة الائتمان (credit score) بذاتها القرارَ الآلي بموجب المادة 22 عندما يعتمد عليها طرف ثالث “اعتمادًا قويًا” وتؤدي الدرجة دورًا حاسمًا في منح الائتمان من عدمه. وبالتالي فإن المحلّل الذي يوافق لاحقًا على ما تُمليه الدرجة أيًّا كان ليس ضمانةً، بل هو إجراء شكلي، ويبقى القرار آليًا.

يوجد سؤالان يحسمان التصنيف، وكلاهما قابل للإجابة انطلاقًا من بنيتك المعمارية لا من الرأي:

• هل يملك المراجِع البيانات والوقت والتفويض للوصول إلى استنتاج مختلف؟ إذا كانت الواجهة تعرض درجةً وزر موافقة ولا شيء غير ذلك، فالجواب لا.
• هل توجد عتبة يتصرف النظام دونها بلا أي تدخل بشري إطلاقًا، سواء كان ذلك موافقةً مباشرة (straight-through approval)، أو رفضًا آليًا، أو تقديم بلاغ آليًا؟ كل ما يقع تحت هذه العتبة يندرج مباشرةً ضمن النطاق.

نحن نُخطّط هذا على مستوى القرار، لا على مستوى النموذج. فنموذج واحد قد يُغذّي في آنٍ واحد رفضًا آليًا يقع ضمن النطاق وطابور مراجعة يقع خارجه. تنطبق التزامات المادة 22 على المسار (branch)، ولذا فإن المسار هو حيث نُثبّت أدوات القياس والتتبع.

هندسة الضمانات داخل بيئة التشغيل

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

إعادة البناء تلك مسألة تتبّع للنَسَب (lineage). فالحق في الطعن لا يكون ذا مغزى إلا إذا كنتَ قادرًا على أن تُجيب، بالنسبة لقرار اتُّخذ في تاريخ محدد، عن ماهية النموذج، وما هي السمات (features) التي اطّلع عليها، وما هي قيم تلك السمات في تلك اللحظة بالذات. وهنا تتوقف صحة النقطة الزمنية (point-in-time correctness) عن كونها مجرد ترف في مجموعة التدريب لتصبح التزامًا قانونيًا. فإذا كان مخزن السمات (feature store) لديك يقدّم القيمة الحالية لسمة ما عندما يطعن شخص في قرار اتُّخذ قبل ربعين ماليين، فأنت تفسّر قرارًا لم يحدث قط.

عمليًا، نحفظ لكل قرار يقع ضمن النطاق:

• إصدار النموذج ومتجه السمات (feature vector) الدقيق كما قُدّم، ملتَقَطًا كلقطة زمنية (snapshot) عند لحظة اتخاذ القرار، لا مُعادًا حسابه عند الطلب.
• القرار، والعتبة التي تجاوزها، ورموز الأسباب (reason codes) التي تصدّرت الترتيب لذلك السجل بالذات.
• ما إذا كان قد راجعه إنسان، ومَن هو، وما الذي كان بإمكانه رؤيته وتغييره.

تستحق رموز الأسباب عنايةً خاصة. فتوزيع الإسهامات على غرار SHAP عبر سماتك الإنتاجية يُشكّل أساسًا يمكن الدفاع عنه لتقديم “معلومات ذات مغزى عن المنطق المُتبَع” التي تشترطها المواد من 13 إلى 15، لكن بشرط أن تكون السمات مفهومة للبشر. فعبارة “السمة f_2291” لا تفسّر شيئًا لصاحب البيانات ولا شيئًا للجهة التنظيمية. لذا نُرجِع توزيعات الإسهامات إلى سمات مُسمّاة وموثّقة قبل أن تغادر النظام، ونحتفظ بجدول المطابقة (mapping) تحت التحكم في الإصدارات (version control) بحيث يظل التفسير المُقدَّم في يونيو قابلًا لإعادة الإنتاج في ديسمبر.

التفسير المُلزَم به فعلًا

توجد خرافة راسخة عن “حق واسع في التفسير” ضمن اللائحة العامة لحماية البيانات. فالنص القابل للإنفاذ يمنح الشخص معلومات ذات مغزى عن المنطق المُتبَع وعن أهمية المعالجة وعواقبها المُتوقَّعة (المواد من 13 إلى 15). أما الحق الصريح في تفسير قرار بعينه فيقيم في الحيثية (Recital) رقم 71، التي تُرشِد التفسير لكنها لا تُنشئ التزامًا قائمًا بذاته. وكثيرًا ما تذهب القواعد القطاعية إلى أبعد من ذلك. فإشعار الإجراء السلبي (adverse-action notice) في الولايات المتحدة يجب أن يذكر الأسباب الرئيسية المحددة، وقد بات قانون الائتمان الاستهلاكي الأوروبي يشترط الآن تفسيرًا ذا مغزى عندما يستند الرفض إلى تقييم آلي. وكلاهما يضع سقفًا أعلى مما تضعه اللائحة العامة لحماية البيانات وحدها.

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

لا شيء من هذا يتطلب أن يلمس إنسانٌ كل قرار، وهو المخوف الذي يُعطّل هذه المشاريع. بل يتطلب أن تحمل القرارات الواقعة ضمن النطاق سجلَّ تدقيق (audit trail) بكثافة كافية لإعادة بنائها والطعن فيها، وأن يمتلك مسار المراجعة البشرية سلطةً فعلية حيثما ادّعيتَ وجودها، وأن تكون العتبة الفاصلة بين الآلي والمُراجَع رقمًا مقصودًا وموثّقًا لا صدفةً نتجت عن مكان وضع أحدهم لحدّ الفصل. ابنِ هذه الثلاثة، وعندها تتوقف المعالجة المباشرة (straight-through processing) والمادة 22 عن كونهما في حالة تعارض.