سلطة اتخاذ القرار والمساءلة في حوكمة الذكاء الاصطناعي

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

من يستطيع السماح ببدء تجربة AI؟

من يوافق على الانتقال إلى الإنتاج؟

من يستطيع فرض شروط على الموافقة؟

من يقبل المخاطر المتبقية؟

من يمنح الاستثناء؟

من يستطيع تعليق النظام؟

ومن يقرر استئنافه بعد حادث أو تغيير جوهري؟

هذه ليست مجرد أسئلة عن المسؤوليات. إنها أسئلة عن سلطة اتخاذ القرار.

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

1. ما المقصود بسلطة اتخاذ القرار؟

سلطة اتخاذ القرار هي الصلاحية المؤسسية المخولة لطرف محدد لاتخاذ قرار معين ضمن نطاق وشروط وحدود معروفة.

وجود مسؤولية عن نشاط لا يعني تلقائيًا امتلاك سلطة القرار بشأنه.

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

وقد يملك فريق المنصة القدرة التقنية على نشر النظام، لكنه لا يملك بالضرورة السلطة المؤسسية للسماح بتشغيله.

لذلك يجب الفصل بين:

تنفيذ النشاط → تقديم الرأي → التوصية → اتخاذ القرار → تنفيذ القرار

وقد تقوم جهات مختلفة بهذه الوظائف.

2. لماذا تمثل سلطة القرار مشكلة خاصة في AI؟

تتداخل في AI أنواع متعددة من القرارات:

• أعمال.
• تقنية.
• مخاطر.
• أمن.
• خصوصية.
• قانون.
• بيانات.
• موردون.
• أخلاقيات واستخدام مسؤول.
• تشغيل واستمرارية.

وقد يكون لكل وظيفة رأي مشروع، لكن تعدد الآراء لا يحدد وحده من يملك القرار النهائي.

إذا لم تحدد المؤسسة سلطات القرار مسبقًا، فقد تظهر ثلاثة أنماط خطرة:

القرار بلا صاحب، حيث ينتظر الجميع موافقة شخص آخر.

القرار الجماعي الغامض، حيث توافق مجموعة دون معرفة من يتحمل القرار فعلًا.

القرار التقني المتخفي، حيث يصبح من يستطيع تنفيذ الإجراء تقنيًا هو صاحب القرار عمليًا.

3. السلطة المؤسسية ليست الصلاحية التقنية

هذه من أهم قواعد حوكمة AI.

وجود Permission داخل منصة أو Cloud أو Model Registry أو Agent Tool لا يساوي Authority مؤسسية.

قد يستطيع مهندس الضغط على Deploy.

وقد يستطيع Administrator منح Agent صلاحية الوصول إلى قاعدة بيانات.

وقد يستطيع مستخدم تغيير إعدادات نموذج.

لكن السؤال الحوكمي هو:

هل يملك هذا الشخص السلطة المؤسسية لاتخاذ القرار الذي ينفذه هذا الإجراء التقني؟

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

4. القرار ليس موافقة فقط

من الخطأ تصميم Governance Workflow وكأن كل قرار ينتهي بأحد خيارين:

Approved / Rejected

قد تشمل القرارات الحوكمية:

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

لذلك يجب تصميم Decision Taxonomy قبل تصميم مسار الموافقات.

5. قرار التجربة ليس قرار الإنتاج

منح الموافقة على Proof of Concept أو Sandbox أو Pilot لا يعني تلقائيًا السماح باستخدام النظام في الإنتاج.

قد تختلف:

• البيانات المستخدمة.
• عدد المستخدمين.
• الأشخاص المتأثرون.
• التكاملات.
• الصلاحيات.
• حجم الاعتماد على المخرجات.
• المخاطر.
• إمكانية الرجوع.
• متطلبات الرصد.
• الأدلة المطلوبة.

لذلك يجب تحديد نطاق القرار صراحةً.

Approval for experimentation ≠ Approval for production

6. من يملك قرار الاستخدام؟

قرار استخدام AI يجب أن يرتبط بالغرض والسياق والمخاطر ونموذج التشغيل.

لا توجد إجابة عالمية تقول إن «لجنة AI» أو «تقنية المعلومات» يجب أن توافق على جميع الاستخدامات.

قد تفوض الحالات منخفضة المخاطر إلى وحدات الأعمال ضمن ضوابط محددة، بينما تحتاج الحالات الأعلى أثرًا إلى مستويات مراجعة وسلطة أعلى.

المهم أن تكون القاعدة معروفة قبل ظهور الحالة:

أي نوع من القرارات يستطيع أي مستوى اتخاذه؟

7. من يملك قرار الإطلاق إلى الإنتاج؟

Production Approval من أكثر القرارات التي تحتاج وضوحًا.

قبل التشغيل قد تحتاج المؤسسة إلى التأكد من:

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

لكن استكمال هذه العناصر لا يجيب وحده عن السؤال:

من يملك قرار الإطلاق النهائي؟

يجب تحديد صاحب السلطة بحسب نموذج المؤسسة ومستوى المخاطر.

8. الموافقة المشروطة

ليست كل فجوة سببًا لرفض النظام بالكامل.

يمكن أن يكون القرار:

موافقة مشروطة — Conditional Approval

مثل السماح بالتشغيل بشرط:

• تقييد فئة المستخدمين.
• عدم استخدام نوع معين من البيانات.
• إبقاء Human Review إلزاميًا.
• إغلاق Finding خلال مدة محددة.
• تطبيق Monitoring إضافي.
• منع وظيفة معينة.
• تحديد سقف للصلاحيات.
• إعادة التقييم بعد فترة.

لكن الموافقة المشروطة تصبح ضعيفة إذا لم تكن الشروط:

محددة + قابلة للقياس + لها مالك + لها موعد + قابلة للرصد

9. قبول المخاطر ليس إغلاقًا للمشكلة

Risk Acceptance هو قرار واعٍ بالاحتفاظ بخطر متبقٍ ضمن حدود محددة.

لا ينبغي استخدامه كوسيلة لإغلاق Findings أو تجاوز الضوابط بلا تحليل.

قرار قبول الخطر يحتاج عادةً إلى معرفة:

• طبيعة الخطر.
• مستوى الخطر المتبقي.
• الضوابط القائمة.
• سبب عدم المعالجة الإضافية.
• المدة.
• صاحب السلطة.
• شروط إعادة التقييم.

ولا ينبغي أن يقبل الخطر طرف لا يملك السلطة المناسبة أو القدرة المؤسسية على تحمل نتائجه.

10. الاستثناء ليس قبول المخاطر

الاستثناء — Exception — وRisk Acceptance قد يرتبطان، لكنهما ليسا الشيء نفسه.

الاستثناء يعني السماح بالخروج عن متطلب أو سياسة أو ضابط محدد ضمن شروط معروفة.

أما قبول المخاطر فيتعلق بقرار الاحتفاظ بخطر متبقٍ.

قد يحتاج الاستثناء إلى قبول خطر ناتج عنه، لكن يجب عدم دمج المفهومين تلقائيًا في سجل واحد دون تمييز.

الاستثناء الجيد يجب أن يكون:

• محدد النطاق.
• مبررًا.
• معتمدًا من صاحب السلطة.
• محدد المدة.
• مرتبطًا بضوابط تعويضية عند الحاجة.
• قابلًا للتتبع.
• خاضعًا للمراجعة أو الانتهاء.

11. من يستطيع تعليق نظام AI؟

يجب تحديد Suspension Authority قبل وقوع الحادث.

قد تستوجب بعض الظروف تعليق النظام أو تقييد وظائفه، مثل:

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

في الحالات الحرجة، قد تحتاج المؤسسة إلى Emergency Stop Authority تسمح بالتدخل السريع دون انتظار دورة لجنة كاملة.

12. من يستطيع إعادة النظام إلى التشغيل؟

إذا كان تعليق النظام يحتاج سلطة، فإن استئنافه يحتاج سلطة أيضًا.

يجب ألا يصبح Restart مجرد إجراء تقني بعد أن يعلن الفريق أن المشكلة «تم إصلاحها».

قد يحتاج قرار الاستئناف إلى:

• تحديد السبب الجذري.
• تنفيذ المعالجة.
• إعادة الاختبار.
• مراجعة الضوابط.
• تقييم المخاطر المتبقية.
• التحقق من شروط الاستئناف.
• توثيق القرار.

وقد يختلف صاحب قرار الاستئناف عن الشخص الذي نفذ الإصلاح.

13. ما هو التفويض؟

التفويض هو منح مستوى أو طرف آخر سلطة محددة لاتخاذ نوع معين من القرارات ضمن حدود معروفة.

التفويض الجيد يحدد:

• القرار المفوض.
• الجهة المفوض إليها.
• النطاق.
• حدود المخاطر.
• الحدود المالية أو التشغيلية عند الحاجة.
• المدة.
• الشروط.
• حالات التصعيد.
• متطلبات التوثيق.

Delegation ≠ Abdication

تفويض القرار لا يعني تخلي المؤسسة عن بنية المساءلة.

14. لماذا تحتاج المؤسسة إلى حدود للتفويض؟

التفويض غير المحدود قد يحول النموذج الاتحادي إلى فوضى قرارات.

يمكن مثلًا تفويض الموافقة على حالات منخفضة المخاطر إلى وحدة أعمال إذا:

• كانت ضمن أنواع استخدام محددة.
• تستخدم أدوات معتمدة.
• لا تتعامل مع بيانات محظورة.
• لا تتجاوز مستوى أثر معين.
• لا تتضمن قرارات حساسة.
• تطبق الضوابط الأساسية.
• تُسجل مركزيًا.

أما تجاوز أحد الحدود فقد يحول الحالة إلى مسار أعلى.

هذه هي Delegation Boundaries.

15. متى يجب التصعيد؟

التصعيد لا ينبغي أن يعتمد فقط على شعور المراجع بأن الحالة «مقلقة».

يجب تحديد Escalation Triggers قدر الإمكان.

قد تشمل:

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

16. ماذا يحدث عند اختلاف الوظائف؟

قد يقول الأمن: الخطر غير مقبول.

وقد تقول الأعمال: التأخير سيؤثر في هدف استراتيجي.

وقد ترى الخصوصية أن شروطًا إضافية مطلوبة.

وقد يرى الفريق التقني أن المعالجة المقترحة غير عملية.

الهدف من الحوكمة ليس منع الاختلاف.

الهدف هو وجود آلية معروفة لحسمه.

يجب أن يحدد نموذج القرار:

من يقدم الرأي → من يستطيع الاعتراض → من يملك القرار → متى ينتقل القرار إلى مستوى أعلى

ولا ينبغي أن تتحول الاجتماعات المتكررة إلى بديل عن تحديد السلطة.

17. حق الاعتراض وحق النقض ليسا الشيء نفسه

قد تمنح المؤسسة وظيفة متخصصة حق الاعتراض أو طلب التصعيد دون منحها Veto مطلقًا على جميع الحالات.

وفي سياقات أخرى، قد تمنح وظيفة معينة سلطة منع محددة بسبب متطلب قانوني أو أمني أو مؤسسي.

يجب توثيق الفرق.

السؤال ليس فقط:

من يجب استشارته؟

بل:

ما الأثر المؤسسي لرأيه؟

هل هو:

• استشارة؟
• مراجعة إلزامية؟
• توصية؟
• شرط؟
• اعتراض يؤدي إلى تصعيد؟
• موافقة إلزامية؟
• سلطة منع؟

18. مصفوفة حقوق القرار

Decision Rights Matrix تساعد على ربط القرار بصاحب السلطة.

يمكن أن تحتوي على:

المصفوفة لا يجب أن تكون جامدة؛ يمكن ربطها بمستوى المخاطر ونوع الاستخدام.

19. RACI لا يحدد حقوق القرار وحده

قد تقول RACI إن شخصًا Accountable.

لكن هل يستطيع هذا الشخص:

• الموافقة؟
• الرفض؟
• قبول المخاطر؟
• منح استثناء؟
• تعليق النظام؟
• إعادة تشغيله؟

إذا لم تكن الإجابة موثقة، فما زالت هناك فجوة في السلطة.

لذلك تكمل Decision Rights Matrix مصفوفة الأدوار بدل أن تستبدلها.

20. القرار يحتاج إلى حزمة قرار

صاحب السلطة لا ينبغي أن يوافق اعتمادًا على رسالة بريد تقول:

«تمت المراجعة، الرجاء الموافقة.»

القرار الجوهري يحتاج إلى Decision Package متناسب مع المخاطر.

قد يشمل:

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

جودة القرار تعتمد جزئيًا على جودة المعلومات المتاحة لصاحبه.

21. ما الدليل الذي يثبت القرار؟

الموافقة الشفهية قد تكون مناسبة لبعض القرارات اليومية الصغيرة، لكنها ليست أساسًا كافيًا لكل قرار حوكمي جوهري.

يجب أن تترك القرارات المهمة أثرًا قابلًا للإثبات.

قد يشمل سجل القرار:

• القرار.
• صاحب القرار.
• تاريخ القرار.
• النسخة أو الحالة التي ينطبق عليها.
• المعلومات التي استند إليها.
• الشروط.
• المخاطر المقبولة.
• الاستثناءات.
• مدة الصلاحية.
• موعد المراجعة.
• سبب القرار عند الحاجة.

هذا يحقق Decision Traceability.

22. الموافقة ليست أبدية

أحد أخطر الافتراضات هو أن النظام «معتمد» إلى الأبد.

يجب أن تكون الموافقة مرتبطة بنطاق.

قد تكون مرتبطة بـ:

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

إذا تغير عنصر جوهري، فقد لا يبقى القرار السابق صالحًا.

23. التغيير الجوهري يعيد فتح القرار

Material Change قد يستوجب إعادة التقييم أو إعادة الموافقة.

قد يشمل مثلًا:

• تغيير النموذج.
• تغيير الغرض.
• إضافة فئة مستخدمين.
• إضافة بيانات حساسة.
• منح Agent أدوات جديدة.
• توسيع الصلاحيات.
• تغيير المورد.
• تغيير طريقة الاعتماد على المخرجات.
• انتقال النظام إلى سياق أعلى أثرًا.

القاعدة ليست أن كل تغيير يحتاج لجنة جديدة.

القاعدة أن المؤسسة تحتاج معايير تحدد:

أي تغيير يبقى داخل القرار السابق، وأي تغيير يعيد فتحه؟

24. ماذا عن القرارات الآلية؟

قد تستخدم المؤسسة AI للمساعدة في اتخاذ قرارات داخل عملياتها.

لكن هذا لا يلغي الحاجة إلى معرفة صاحب السلطة المؤسسية عن العملية.

إذا كان AI يقدم توصية، يجب معرفة من يقرر اعتمادها.

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

كلما زادت استقلالية النظام، ازدادت أهمية تحديد:

من فوض ماذا للآلة؟

25. سلطة الوكلاء AI Agents

مع Agentic AI تصبح المسألة أكثر وضوحًا.

يمكن أن يمتلك الوكيل Technical Permission لـ:

• إرسال رسالة.
• استدعاء API.
• تحديث سجل.
• إنشاء طلب.
• تنفيذ عملية.
• استدعاء Agent آخر.

لكن هذه القدرة لا تجيب عن:

هل يملك الوكيل سلطة اتخاذ القرار المؤسسي الذي يمثله الإجراء؟

يجب تصميم Agent Authority Envelope يحدد مثلًا:

• الأفعال المسموحة.
• الأدوات.
• البيانات.
• الحدود.
• الموافقات البشرية المطلوبة.
• سقف المعاملات.
• حالات التوقف.
• الإجراءات المحظورة.
• متى يجب طلب تدخل بشري.

الوكيل ينفذ ضمن سلطة مفوضة؛ لا ينشئ لنفسه سلطة مؤسسية.

26. القرارات في النموذج المركزي والاتحادي والهجين

في النموذج المركزي قد يحتفظ المستوى المركزي بعدد أكبر من سلطات القرار.

في النموذج الاتحادي يمكن تفويض سلطات أكبر للوحدات.

وفي النموذج الهجين يمكن ربط السلطة بالمخاطر.

مثال:

Low Risk → Delegated Approval

Medium Risk → Standard Governance Route

High/Critical Risk → Enhanced or Executive Decision Route

لكن اللامركزية الناجحة لا تعني غياب المركز.

قد يحتفظ المستوى المركزي بـ:

• السياسة.
• التصنيف.
• حدود التفويض.
• القرارات المحجوزة.
• الاستثناءات الكبرى.
• الرقابة على الأداء.
• القدرة على سحب التفويض.

27. القرارات المحجوزة

Reserved Decisions هي قرارات لا يجوز تفويضها تحت مستوى معين.

قد تحدد المؤسسة قرارات محجوزة مثل:

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

قائمة القرارات المحجوزة يجب أن تكون متناسبة مع المؤسسة، لا منسوخة بصورة جامدة من مؤسسة أخرى.

28. مؤشرات جودة القرار

لا ينبغي قياس الحوكمة بعدد الموافقات فقط.

يمكن مراقبة مؤشرات مثل:

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

الهدف ليس تقليل زمن القرار بأي ثمن، بل جعل القرار واضحًا، متناسبًا، قابلًا للتنفيذ، وقابلًا للإثبات.

29. أخطاء شائعة في تصميم سلطة القرار

جعل اللجنة صاحبة كل قرار

ينتج اختناقًا ويضعف المساءلة الفردية أو الوظيفية.

عدم تحديد القرار نفسه

عبارة «موافقة AI» واسعة جدًا لتكون سلطة دقيقة.

مساواة Technical Permission بالسلطة

من يستطيع التنفيذ تقنيًا ليس بالضرورة مخولًا بالقرار.

تفويض بلا حدود

يخلق سلطات واسعة دون معايير للتصعيد.

قبول المخاطر من مستوى غير مناسب

يحول Risk Acceptance إلى أداة إغلاق إداري.

استثناءات بلا انتهاء

تتحول الاستثناءات المؤقتة إلى الوضع الدائم.

موافقة بلا نطاق

يصعب معرفة ما إذا كان التغيير الجديد ما زال مشمولًا.

موافقة بلا دليل

يصعب لاحقًا إثبات ماذا تم اعتماده وعلى أي أساس.

إيقاف النظام بلا آلية استئناف

قد يحل خطرًا ويخلق مشكلة تشغيلية طويلة.

السماح للوكيل بالفعل دون تعريف حدود سلطته

يخلط القدرة التقنية بالتفويض المؤسسي.

30. كيف تبني المؤسسة Decision Authority Model؟

ابدأ بالقرارات، لا باللجان.

الخطوة 1 — احصر القرارات الجوهرية

مثل التجربة والإنتاج وقبول المخاطر والاستثناء والتعليق والاستئناف والتقاعد.

الخطوة 2 — صنف القرارات

حدد أيها منخفض الأثر وأيها جوهري أو محجوز.

الخطوة 3 — عيّن صاحب السلطة

حدد وظيفة أو مستوى مؤسسيًا لكل قرار.

الخطوة 4 — حدد حدود التفويض

وثق متى يستطيع المستوى الأدنى اتخاذ القرار.

الخطوة 5 — حدد المراجعات المطلوبة

ليس كل مراجع صاحب موافقة.

الخطوة 6 — حدد التصعيد

حدد ما الذي ينقل القرار إلى مستوى أعلى.

الخطوة 7 — حدد حزمة القرار

حدد المعلومات والأدلة التي يحتاجها صاحب السلطة.

الخطوة 8 — سجل القرار

اجعل القرار قابلًا للتتبع.

الخطوة 9 — حدد مدة ونطاق الصلاحية

لا تجعل الموافقة مطلقة.

الخطوة 10 — اربط القرار بالتغيير والحوادث

حدد متى يعاد فتحه.

اختبار سيادة لسلطة القرار

اختر نظام AI يعمل اليوم واسأل:

• من وافق على استخدامه؟
• هل كان يملك السلطة فعلًا؟
• ما الذي تمت الموافقة عليه تحديدًا؟
• ما الأدلة التي كانت متاحة؟
• هل كانت هناك شروط؟
• من يستطيع قبول مخاطره؟
• من يستطيع منحه استثناء؟
• من يستطيع إيقافه الآن؟
• من يستطيع إعادته إلى التشغيل؟
• هل يستطيع مالك النظام تغيير النموذج دون موافقة جديدة؟
• ما التغيير الذي يعيد فتح القرار؟
• هل يعرف Agent حدود سلطته التقنية والتشغيلية؟
• هل نستطيع إثبات القرار بعد سنة؟

إذا لم تكن هذه الإجابات واضحة، فقد تمتلك المؤسسة Workflow للموافقة دون أن تمتلك نظامًا حقيقيًا لسلطة القرار.

الخلاصة

حوكمة الذكاء الاصطناعي ليست مجرد تحديد من يشارك في العملية.

هي أيضًا تحديد:

من يستطيع أن يقول نعم؟

من يستطيع أن يقول لا؟

من يستطيع أن يقول نعم بشروط؟

من يستطيع قبول الخطر؟

من يستطيع منح الاستثناء؟

من يستطيع الإيقاف؟

ومن يستطيع إعادة التشغيل؟

النموذج الناضج يربط:

Decision → Authority → Scope → Evidence → Conditions → Delegation → Escalation → Traceability → Reassessment

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