مقدمة
تسجّل معظم المؤسسات التي تستخدم الذكاء الاصطناعي في قرارات خاضعة للتنظيم - كتقييم الجدارة الائتمانية، وفرز المرشحين للتوظيف، والاكتتاب التأميني، والإبلاغ عن حالات الاحتيال - شيئاً ما بالفعل: طابعاً زمنياً، ومدخلاً، ومخرجاً، وربما رقم إصدار النموذج. وعندما تطعن جهة تنظيمية أو شخص متأثر في ذلك القرار بعد أشهر، نادراً ما يكون ذلك السجل كافياً. فالسؤال الذي يُطرح فعلاً ليس «ماذا كانت مخرجات النموذج؟» بل «هل يمكنك إثبات أن النموذج الذي أصدر هذا القرار كان يعمل على البيانات التي كان يُفترض أن يعمل عليها، دون أي تعديل، في اللحظة التي اتخذ فيها هذا القرار؟». ولم تُبنَ معظم البنى التحتية الحالية للتسجيل قط للإجابة عن ذلك.
ما الذي يتطلبه فعلاً مسار تدقيق يرقى إلى معايير الجهات التنظيمية
يجب ربط القرار وإصدار النموذج والبيانات - ربطاً دائماً
يربط مسار التدقيق القابل للدفاع عنه ثلاثة عناصر في لحظة اتخاذ القرار: المدخل والمخرج المحددين، والإصدار الدقيق للنموذج الذي أنتجه (لا تسمية متغيرة مثل «production» تشير بصمت إلى أوزان مختلفة مع مرور الوقت)، والحالة المحددة لأي بيانات مرجعية أو بيانات تدريب اعتمد عليها النموذج. وإذا أمكن لأي عنصر من هذه العناصر الثلاثة أن يتغير بمعزل عن العنصرين الآخرين في السجل التاريخي، تنقطع السلسلة، ولا يعود ممكناً إعادة بناء القرار المطعون فيه بثقة.
يجب أن يكون السجل كاشفاً للتلاعب، لا مجرد سجل يقبل الإلحاق فقط
يُعدّ التسجيل بالإلحاق فقط (append-only) أساساً جيداً، لكنه لا يثبت بحد ذاته أن شيئاً لم يُعدَّل - بل يجعل التعديل العابر أصعب فحسب. أما مسار التدقيق الذي يرقى إلى معايير الجهات التنظيمية فيتطلب أن يكون أي تعديل على السجل التاريخي، أياً كانت طريقة حدوثه، قابلاً للكشف بالوسائل التشفيرية. وهذا هو الفرق بين سجل يثق به مهندس لأنه هو من بناه، وسجل يستطيع مدقق خارجي التحقق منه بشكل مستقل دون الاعتماد على كلمة المؤسسة.
يجب أن تتجاوز مدة الاحتفاظ فترة الطعن، لا دورة حياة النموذج
تُوقَف إصدارات النماذج ويُستغنى عنها وفق جدول زمني هندسي. أما فترات الطعن التنظيمية والقانونية فلا تتبع ذلك الجدول - إذ يمكن الطعن في قرار توظيف أو في رفض طلب ائتمان بعد وقت طويل من استبدال النموذج الذي أصدره. وأي بنية لمسار التدقيق تربط مدة الاحتفاظ بالسجلات بدورة حياة النموذج بدلاً من فترة الطعن القانونية المعمول بها ستعاني من ثغرات في المواضع الأكثر أهمية تحديداً.
صلة ذلك بمنشأ البيانات، لا بالتسجيل فحسب
إن مسار التدقيق الذي يسجل القرار بأمانة لكنه لا يستطيع التحقق بشكل مستقل من سلامة البيانات التي يستند إليها لم يحل سوى نصف المشكلة. فإذا كان من الممكن أن تكون بيانات التدريب أو البيانات المرجعية نفسها قد عُدِّلت دون أن يُكتشف ذلك، فإن حتى مسار القرارات المسجَّل على أكمل وجه يقوم على أساس لا يمكن التحقق منه. ويجب حل المشكلتين - تسجيل القرارات وسلامة البيانات - معاً، مع إرسائهما على الجذر التشفيري نفسه، وإلا فإن أقوى ما يمكن أن يدّعيه مسار التدقيق يتحول إلى «لم نلاحظ أي خلل»، وهذا لا يرقى إلى مستوى الدليل.
- ربط كل سجل قرار بإصدار محدد وغير قابل للتغيير من النموذج - وليس أبداً بتسمية متغيرة
- إرساء حالة البيانات المرجعية وبيانات التدريب إلى جانب القرار، لا في نظام منفصل ومعزول
- جعل أي تعديل على السجل التاريخي قابلاً للكشف بالوسائل التشفيرية، وعدم الاكتفاء بالإلحاق فقط
- تحديد مدة الاحتفاظ وفقاً لفترة الطعن القانونية المعمول بها، لا وفقاً لدورة حياة نشر النموذج
إن سجل القرارات الذي لا يستطيع أن يثبت بشكل مستقل سلامة البيانات التي يستند إليها ليس مسار تدقيق - بل مجرد ادعاء. اكتشف كيف تُرسي ROOTKey القرارات وإصدارات النماذج وحالة البيانات في سجل واحد قابل للتحقق.