أحد أكبر أخطاء الحوكمة هو التعامل مع Impact Assessment كوثيقة مرتبطة بتاريخ الإطلاق: نكملها، نحصل على الموافقة، ثم نعود إليها بعد سنة. في أنظمة AI، التغيير قد يحدث داخل النموذج أو حوله. وقد يكون التغيير صغيرًا تقنيًا لكنه كبيرًا من ناحية الأثر. لذلك يجب أن يكون قرار الاعتماد مرتبطًا بمحفزات واضحة لإعادة التقييم.
ما الذي يمكن أن يبطل التقييم السابق؟
مورد GCAI يقترح مجموعة واسعة من triggers تشمل:
- نظام AI جديد أو غرض استخدام مختلف بصورة جوهرية.
- تغيير النموذج أو بيانات التدريب.
- تغيير prompts أو retrieval أو fine-tuning.
- تغيير المزوّد.
- إضافة ذاكرة أو أدوات أو صلاحيات أو وصول لأنظمة أخرى.
- زيادة الاستقلالية.
- ظهور فئة مستخدمين أو أطراف متأثرة جديدة.
- التوسع إلى لغة أو قطاع أو جغرافيا أو نطاق أكبر.
- متطلبات قانونية أو تعاقدية أو سياسات جديدة.
- حادث أو شكوى أو إساءة استخدام أو نتيجة غير متوقعة.
- تجاوز threshold أو تراجع فعالية ضابط.
هذه المحفزات مهمة لأنها تفصل إعادة التقييم عن التقويم الزمني وحده.
تغيير النموذج ليس التغيير الوحيد
تطبيق عملي من سيادة
تخيل مساعدًا داخليًا يستخدم النموذج نفسه طوال ستة أشهر. في البداية كان يكتب مسودات فقط. لاحقًا تم ربطه بالبريد، ثم CRM، ثم أُعطي صلاحية إنشاء معاملات. من زاوية model version قد لا يتغير شيء. لكن مسار الأثر تغيّر بالكامل لأن النظام حصل على authority جديدة. لذلك يجب أن تشمل Change Management للـAI على الأقل:
Model
Data
Prompt / RAG
Tools
Permissions
Memory
Autonomy
Provider
Users
Affected Parties
Scale
Jurisdictionوليس Model Version فقط.
الأحداث التشغيلية أيضًا محفز
لا ينبغي انتظار تحديث تقني لإعادة التقييم. الحوادث والشكاوى والـnear misses والانحراف وتجاوز مؤشرات التحكم وظهور نمط إساءة استخدام جديد كلها أدلة على أن الافتراضات القديمة قد لا تزال صحيحة. كما يمكن أن يكون عدم تحقق الفائدة سببًا للمراجعة. إذا تحملت المؤسسة أو المستخدمون تكاليف وأعباء بينما لم تتحقق الفائدة التي بُني عليها قرار الاعتماد، فقد يتغير مبرر الاستمرار.
اربط القرار بشروط قابلة للمراقبة
المصدر يربط المراقبة بالمؤشرات والحدود والاستجابة والمسؤول. ليست الفكرة جمع metrics فقط، بل تحديد ما الذي سيحدث عند تجاوزها. وهذا يعني أن قرار «Approve with conditions» يجب ألا ينتهي بجملة عامة مثل «تتم المراقبة دوريًا». يجب أن تكون هناك شروط قابلة للتحقق: من يراقب؟ أي مؤشر؟ ما threshold؟ ما الإجراء؟ متى تصبح الحاجة إلى إعادة التقييم إلزامية؟
التقاعد جزء من دورة الحياة
المراقبة لا تنتهي بقرار الاستمرار. يجب التفكير أيضًا في التقاعد أو الانتقال: مصير البيانات، إشعار المستخدمين، البدائل، الاحتفاظ بالسجلات، سحب الوصول والصلاحيات، وأي مراقبة متبقية بعد الإيقاف. وهذا يمنع المؤسسة من ترك أنظمة AI قديمة أو accounts أو tokens أو integrations تعمل بعد أن انتهى الغرض منها.
كيف ننظم المحفزات داخل المؤسسة؟
تطبيق عملي من سيادة
يمكن تقسيمها إلى أربع مجموعات تشغيلية: 1. Change Triggers تغيير في النظام أو البيانات أو الأدوات أو الصلاحيات أو المزود أو النطاق. 2. Evidence Triggers حادث، شكوى، drift، test failure، ثغرة جديدة أو دليل بحثي جديد. 3. Obligation Triggers قانون أو عقد أو سياسة أو متطلب داخلي جديد. 4. Value Triggers الفائدة لا تتحقق، أو العبء ينتقل إلى فئة أخرى، أو تكلفة الضوابط تغير مبرر الاستخدام. هذا التقسيم من سيادة لتنظيم التشغيل، وليس تصنيفًا من GCAI أو ISO.
قاعدة عملية
قبل اعتماد أي نظام، اسأل:
ما الأحداث التي، إذا وقعت بعد ستة أشهر، ستجعل هذه الموافقة غير صالحة؟
إذا لم تكن الإجابة مكتوبة وقابلة للمراقبة، فالمؤسسة لا تملك Lifecycle Governance؛ لديها فقط قرار إطلاق.
الخلاصة
التقييم الجيد ليس Snapshot. هو فرضية موثقة عن نظام وسياق في لحظة معينة. عندما تتغير الفرضيات أو تظهر أدلة جديدة، يجب أن يتغير الحكم معها. لذلك إعادة التقييم ليست إعادة عمل بيروقراطي، بل جزء من آلية السيطرة على نظام يتطور باستمرار.