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

لماذا يحتاج وكلاء الذكاء الاصطناعي إلى حوكمة لا تحتاجها روبوتات المحادثة؟

روبوت المحادثة يجيب، أما الوكيل فيتصرف: يردّ مبلغًا، ويغيّر خطة اشتراك، ويفعّل ميزة، ويدعو مستخدمًا. لم يعد الناتج نصًا يقرؤه شخص قبل أن يقرر، بل صار تغييرًا في نظام حقيقي.

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

ما الأسئلة التي يجب أن تجيب عنها طبقة الحوكمة لكل إجراء؟

يعجبني الإطار الذي يعتمده TrustRail. فعن كل عملية محمية يجب أن تجيب الطبقة عن خمسة أسئلة: أي وكيل طلبها، ومن فوّض هذا الوكيل، وما الحدود المطبَّقة، وهل كان الإجراء مسموحًا أو محظورًا أو معلَّقًا بانتظار الموافقة، وما الأدلة التي تسند النتيجة.

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

TrustRail دراسة تصميم عامة. يصف ملف README الخاص به إصدارًا أول يعمل على بيئات تجريبية اصطناعية (تاجر خيالي ومنتج SaaS خيالي)، وينص على أنه لا أموال حقيقية تتحرك. وهو ليس نظام إنتاج ولا أقدّمه على هذا الأساس، بل وسيلة لجعل الأفكار ملموسة وقابلة للاختبار.

ما المشكلة التي تحلّها طبقة السياسات؟

تستبدل طبقة السياسات عبارة « التعليمات تقول ألّا يفعل ذلك » بقاعدة تُقيَّم قبل كل إجراء ولا يمكن الجدال معها. التعليمات طلب موجَّه إلى النموذج، أما السياسة فقرار يُتخذ خارج النموذج.

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

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

متى ينبغي أن يوافق إنسان على إجراء يقوم به وكيل؟

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

الجدول التالي من صياغتي أنا، وليس مواصفة من TrustRail. أمثلة الإجراءات من النوع الذي يذكره README (ردّ المبالغ، والأرصدة، وتغيير الخطط، والدعوات)، أما المستويات والضوابط فهي نقطة البداية التي أقترحها.

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

ما الإيصال الموقَّع، ولماذا هو أكثر من سجل؟

السجل يكتبه النظام الذي نفّذ الفعل، ومن يتحكم في ذلك النظام يستطيع تعديله. أما الإيصال الموقَّع فهو سجل يستطيع طرف ثالث التحقق منه دون أن يثق بالنظام الذي أنتجه.

يصف README الخاص بـ TrustRail إيصالات موقَّعة بخوارزمية Ed25519 (بصيغة JWS) وحزمة تحقق منفصلة، ويذكر أن أحد المسارات جرى التحقق منه بصورة مستقلة. وهذا الفصل هو الجوهر. فإذا احتاج التحقق إلى قاعدة البيانات نفسها التي تحمل البيانات فهو يثبت القليل. أما إذا استطاع كل من يملك المفتاح العام فحص الإيصال، أمكن تسليمه إلى مدقق أو عميل أو زميل دليلًا.

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

كيف يكسب الوكيل استقلاليته؟

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

وهذا تسلسل عملي من منهجي الخاص وليس معيارًا، والغاية منه أن تتحرك الصلاحيات بقدر ما يتراكم من أدلة، لا بقدر ما يتزايد الحماس للتجربة:

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

ماذا ينبغي تسجيله لكل إجراء يقوم به وكيل؟

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

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

إلى أي مدى يمكن الوثوق بدراسة تصميم مثل TrustRail؟

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

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