حوكمة وكلاء الذكاء الاصطناعي: من يقرر، ومن يحاسب، وما الذي يُوثَّق؟

الحوكمة ليست لوحة صلاحيات: الفرق بين الضبط والإدارة

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

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

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

• علامة على فجوة حوكمة: وكيل يعمل في الإنتاج ولا يوجد له مالك باسم صريح في الهيكل التنظيمي.
• علامة أخرى: تغيير نطاق البيانات أو الأدوات المتصلة بالوكيل يتم دون موافقة موثقة.
• علامة ثالثة: لا توجد مراجعة دورية تربط بين سلوك الوكيل والمخاطر التي بُرِّر من أجلها.

أربعة قرارات يجب حسمها قبل نشر أي وكيل

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

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

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

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

سجل الوكلاء: أصغر وثيقة تحمي أكبر قدر من المساءلة

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

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

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

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

تصنيف المخاطر: لماذا لا تحتاج كل الوكلاء إلى نفس مستوى الموافقة؟

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

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

المقايضة هنا صريحة: كل طبقة موافقة إضافية تكلف وقتاً وتُبطئ التبني، وكل طبقة محذوفة تزيد احتمال حادثة لا يمكن تفسيرها لاحقاً. الإطار الجيد يجعل هذه المقايضة مرئية للإدارة بدل تركها تُحسم عشوائياً في محادثات الفرق.

• وكيل قراءة داخلي — تسجيل إلزامي ومراجعة خفيفة؛ مالك العملية يوافق.
• وكيل كتابة داخلية (تذاكر، مسودات، تحديث سجلات) — موافقة مالك العملية مع مراجعة تقنية وأدلة اختبار.
• وكيل تواصل خارجي أو مالي — موافقة مشتركة من العملية والمخاطر مع مراجعة بشرية عند نقاط محددة.
• وكيل متعدد الخطوات أو مستقل التنفيذ — تصنيف أعلى، حدود صلاحيات ضيقة، ومراجعة أقصر أمداً.

الأدلة والمراجعة: ما الذي يجب أن يُسجَّل حتى تصبح الحوكمة قابلة للتحقق؟

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

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

في الممارسة، أسقط كثير من الفرق هذه الطبقة لأن الأدوات كانت موزعة: نموذج في مكان، والمصادر في مكان آخر، والسجلات عند مزود ثالث. وجود مساحة عمل موحدة يقلل هذا التشتت، وهو الاتجاه الذي تبنيه منصات مثل Pilardin عبر وحدات Matrix التي تجمع المحادثة مع المستندات والأنظمة المتصلة، مع مسار /matrix لمن يريد استعراض البنية قبل بناء سياسة الحوكمة.

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

دورة حياة الوكيل: من التسجيل إلى التقاعد

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

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

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

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

الخلاصة: الحوكمة قرارات صغيرة متكررة، لا وثيقة تُكتب مرة واحدة

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

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

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

FAQ

هل حوكمة وكلاء الذكاء الاصطناعي تعني تقليل عدد الوكلاء في المؤسسة؟

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

من يملك الوكيل: فريق تقنية المعلومات أم صاحب العملية؟

المساءلة عن الهدف والنتائج تقع على صاحب العملية الذي يعرف لماذا أُنشئ الوكيل وما النتيجة المقبولة. أما منصة الذكاء الاصطناعي فهي مسؤولة عن التمكين التقني والصلاحيات والسجلات. فصل الملكية عن التمكين يمنع حالتين سيئتين: أن يتحمل فريق التقنية مسؤولية قرارات لا يملكها، أو أن يُطلق صاحب العملية وكيلاً دون ضوابط.

هل نحتاج سياسة مستقلة للوكلاء أم يكفي تعديل سياسة الذكاء الاصطناعي الحالية؟

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

كيف نتعامل مع وكيل يستدعي وكلاء آخرين أو أدوات متعددة؟

يُعامل كتوسع في النطاق لا كتفصيل تقني. كل أداة أو وكيل فرعي يضيفه يزيد سطح المخاطرة، поэтому يجب تسجيله وتحديد صلاحياته والموافقة عليه ضمن نفس الإطار. من المفيد أيضاً منع الاستدعاء غير المحدود ووضع سقف لعدد الخطوات، حتى يبقى مسار التنفيذ قابلاً للتتبع والمراجعة.

ما الحد الأدنى الذي يمكن البدء به هذا الشهر؟

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