"لا" في مكانها الصحيح: أين تضيف الحوكمة احتكاكاً، وأين لا ينبغي لها ذلك

لا ينبغي للحوكمة أن تُبطئ قراراً إلا حين يكون التراجع عنه صعباً أو الخطأ فيه مكلفاً. وفي كل ما عدا ذلك، لا تعدو البوابة الإجرائية كونها تأخيراً يتقنّع بمظهر السيطرة.

السرعة ليست عدوّ الجودة

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

ضَع الاحتكاك قبل نقطة اللاعودة

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

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

اجعل الاحتكاك متناسباً مع حجم العاقبة

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

بُعد الذكاء الاصطناعي

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

الأثر العملي

قبل إضافة أي بوابة أو الإبقاء عليها، اطرح ثلاثة أسئلة:

1. هل هذا باب ذو اتجاه واحد أم ذو اتجاهين؟
2. مَن يتحمّل الكلفة إن جاء القرار خاطئاً؟
3. وما الذي تُغيّره هذه البوابة ولن يفعله مالك القرار المُطَّلع على الأمر؟

فإن كانت الإجابات: باب ذو اتجاهين، ولا أحد ذو صلة يتحمّل الكلفة، ولا شيء يتغيّر، فأزل البوابة. أما إن كان التغيير يصعب التراجع عنه وتقع كلفته على من لم يُستشر يوماً، فهناك بالتحديد مكان "اللا".

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